I'd like to point out a few things in the “Paranoid Penguin” article on DMZ networks (March 2001): RPC is remote procedure call and not RP control protocol; r commands like rsh, rlogin and rcp don't use RPC. In my humble opinion, examples should use runlevel three instead of two because three is the default runlevel for most Linux servers. Changes in level two don't have an effect because Linux runlevels are independents and not additionals as they are in other UNIX flavors.
Bauer replies: You're right that RPC is remote procedure call and not RP control protocol and that r commands like rsh, rlogin and rcp don't use RPC. But my point was that both RPC and r commands are inappropriate for use on publicly accessible systems, and I stand by that. As far as which runlevel to use for examples, I could have been clearer on that. By the way, Debian defaults to runlevel two.
I hate to bother you with a question for Stew, but since it is a real newbie type of question you can probably answer it without getting him involved.
In his article in the April 2001 issue “Providing E-mail Services for a Small Office” he shares his cron job in Listing 5. I usually like Korn shell and write my little scripts there, but when I only use one > on redirecting output, I only get the last line sent to the file. Is Bourne better about understanding > vs. >> ? According to the way I read his tracking script, he would not get the output in listing 6. I would have had to put >> on all the lines except the first one if I wanted the output in listing 6. Am I missing something?
So far as I'm aware, > and >> mean the same thing in Korn, Bourne and, for that matter, csh. > replaces the file, >> appends to it. Listing 5 would not produce the output seen in listing 6. Looking at the author's original, it read:
#!/bin/sh ST=/etc/sendmail.st MS=/usr/sbin/mailstats MSO=/tmp/mailstats.txt if [ -s $ST -a -f $MS ]; then echo "General Mail Statistics" > $MSO echo "" echo "local = Mail local to fileserver echo "smtp = Internet mail" echo "relay = Mail from/to Sun system echo "" $MS cp /dev/null $ST fi echo "" echo "Mail Filter/Forwarding Statistics echo "" /usr/bin/mailstat -l /home/thriftycompany/mail/from chown thriftycompany /home/thriftycompany/mail/from cat $MSO | mail -s "Daily Email Summary" rm $MSO exit 0
Apparently the original was inadvertently modified at some point in the production process. The listing on our FTP site is correct. Our apologies.
Thank you all for the best computer-related magazine in all categories. I eagerly await every issue of LJ (we have a subscription at the school where I work as a teacher) and read almost everything from the front cover on. In the April 2001 issue I read a presentation of Kylix, which I have been waiting for, being a Pascal and Delphi programmer, but the price of these two commercial products has made it impossible for my budget. When I read your article “Stop the Presses” new hope came to me as I thought an Open Edition existed for free download. That hope turned to disappointment when I went to Borland's web page and didn't find any mention of an Open Edition, only the two overpriced commercial products. So where is this Open Edition of Kylix?
The free download version of Open Edition is expected to be available sometime in Summer 2001.
I wanted to let you know that I think you're doing a great job with Linux Journal, and the article “The New Vernacular” was one of the most intelligent articles I've ever read in a magazine.
I enjoyed the review on Descent 3 from Loki (Linux Journal, April 2001). I think I will enjoy this game because I like the thought of controlling a doomed ship and trying to find help from others, as well as investigating sabotage done to the ship and sending out radio transmissions. Everything about this game is quite intriguing. I do believe you sold me!
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
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- 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