Letters to the Editor
The Tech Tip on page 16 [Linux Journal, March 2001] is great! Unfortunately, your tech ignored least common multiples and lowest common denominators. With the numbers given in paragraph five, you will fsck all four filesystems every 15th reboot, making the problem worse than the default scenario.
A better approach is to use prime numbers like 13, 17, 19 and 23. This way, you won't fsck two filesystems until the 221st reboot (13*17), and you won't fsck all four filesystems until the 96,577th reboot. Assuming an average uptime of 90 days (bad hardware, security updates), this is in the year 25,814.
I found Mick Bauer's proposed solution on page 33 [“Paranoid Penguin”, March 2001] a bit awkward at best. Renaming a start script this way will result in a failure if you upgrade. (For example, ude to a security fix in the package.)
The preferred way for Red Hat Linux is to use chkconfig. So the sample should be:
chkconfig named off
For other distributions, you should move it to K70named (that is 100-n) or use whatever system that distribution uses.
—Hugo van der Kooij
Bauer replies: You are of course correct, chkconfig is the preferred way to manage startup-scripts in Red Hat. I didn't know this, having only recently switched from SuSE to Red Hat. But “awkward”? My way is common practice on most of the SysVInit implementations I deal with, including SuSE (unless SuSE 7.1 is different—haven't tried it yet). Regardless, I consider this a minor point: any upgrade “failure” caused by my method would be easy to fix. The only such weirdness I've experienced myself has been the occasional creation of redundant symbolic links, which I'd hardly categorize as a failure.
I am greatly concerned about the review of Mandrake 7.2 found in the March 2001 issue. To cut to the chase, Mandrake works almost flawlessly out of the box, and many of the problems were as a result of the reviewer trying to install Helix GNOME on top of the Distribution (Helix GNOME has known errors and does not support Mandrake7.2). Taking screen shots in the GIMP does work out of the box, just not with the Helix version, which was obviously tacked on after the fact. The lack of a back button is absolutely false because the installer does not need a back button. (The installer screen has icons on the side which allow you to jump to any point in the install and shows you where you are in the installation.)
The sidebar says that Mandrake includes Helix GNOME; this is false. It does include GNOME, but not Helix. In fact, Helix does not even support Mandrake 7.2 (but it does support earlier versions).
I personally run Mandrake 7.2 both at work and at home, out of the box, and it runs almost flawlessly (though there are a few minor issues, but updates are available). I have also tried the GNOME formerly known as Helix on one of my 7.2 machines and found that it did break many things. The point is, Mandrake 7.2 worked fine out of the box and only started breaking after adding Helix GNOME!
Black replies: As clearly stated in the article, the review I did was, evidently and provably, not of the final released version. I twice inquired of Mandrakesoft regarding this and they would not answer my e-mail. None of the Helix/Ximian problems evaporated with a clean, Helix/Ximian-free installation, and while the stars on the left side of the screen do work as back buttons, this sure isn't obvious to the Mandrake newbie. I have heard some wonderful things about the actual release version of Mandrake. I'm thinking about downloading it and putting it on a server, as it seems to work especially well in that capacity. Its security is well-noted. But as a reviewer, I can only work with what is sent. I can do the research, ask the questions (or try to), etc., but I can't say “well, gee, this is marvelous” if I can't run the software in a normal fashion. I have a rule for developing software: if I can break software with my innocuous little system, then that software probably needs fixing anyway.
Mick Bauer's “The 101 Uses of OpenSSH: Part 2” [February 2001] is an excellent article with a small flaw. He writes: “To specify a particular key to use in either an ssh or scp session, use the -i [flag].” He also provides an example that suggests the use of DSA keys.
However, OpenSSH did not support the use of DSA keys with the -i flag until the very latest version (2.5.1, released just four days ago). Earlier versions silently ignored the DSA key indicated (RSA keys work just fine). Hence, anyone trying that example will see ssh mysteriously default to password authentication every time.
This limitation is actually documented in the ssh man page. Versions prior to 2.5.1 said:
-i identity_file<\n> Selects the file from which the identity (private key) for RSA authentication is read. [...]
Version 2.5.1, of course, says “...RSA or DSA...”. However, it's easy for even experienced users to miss the distinction—I certainly did the first few times.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide