New Messages

From: Karl Vogel (vogelke@dnaco.net)
Subject: Letter to "New Messages" section, Sys Admin

I liked the letters in your October 2000 issue dealing with processing command-line options in shell scripts. For what it's worth, I'm including a script template that is flexible but doesn't rely on getopts.

1. I avoid using outside programs if possible; case is used instead of test for string comparisons, because test is an external program on some systems. The script relies on egrep and sed.

2. I use sed instead of awk or expr because it's usually smaller.

3. Usage and help information are taken directly from the script comment header. Version information comes from an internal RCS string.

4. I use /bin/ksh where possible, because the Bourne shell may not exit properly if exit is called from a subshell or within a loop.

Karl Vogel

Karl, Thank you for this additional information. The script you provided is now available for download on the Sys Admin Web site in the January tar file. --AA

I enjoyed your article on securing Solaris. I am relatively new to working with UNIX. My current job position allows me to learn more about UNIX and Solaris in particular. Your article was well laid out and a great start to exploring more security possibilities in a Solaris environment.

Some administrators may feel that your article is too elementary, meaning that you may not have needed to explain why certain commands or programs work the way they do or what results they are to produce. Many administrators already know. Other articles written in Sys Admin seem hard to follow at times even for the seasoned administrator. But from my position, explaining these commands and terms is good to do in an article such as yours.... By laying it out like you have in this article, many will find your article very inviting and will use a lot of your information in conversations yet to come.

Thank you for writing this article. I gained tremendously from it.

Kurt Schadewald

I enjoyed your article "Securing Solaris" -- it covered a lot of the TCP tuning parameters that are typically "black magic" because of, as you mentioned, lack of documentation. I'm also glad you covered ipfilter -- it's become part of the default installation for the Solaris machines my team builds.

However, I have a comment about your ipblock shell script. After rebuilding the ruleset, you flush the current rules and reload with the following commands:

/sbin/ipf -F i
/sbin/ipf -f /tmp/ipfule.$$

/sbin/ipf -IFi -f /tmp/ipfule.$$
/sbin/ipf -s

Matthew,

Thanks for the note/fix. I had looked through the documentation on ipfilter as to how to get it to update its ruleset automically but couldn't figure it out easily. I agree that the way my ipblock script does not flush the rules automatically, and that does leave the host system unnecessarily unprotected.

Thanks again for pointing that out. I will fix the script and give it to Sys Admin magazine to put on their site. --Ido

Note: The revised script is available on the Web site in the November supplement tar file. --AA

Our latest Sys Admin magazine arrived yesterday with an added bonus: Solaris Administration. Cool! We've got a Sun SPARCStation (however, IPX) running Solaris 7. The Sys Admin supplement is a great reference magazine!

We also have a Linux server/workstation at home, and we are looking forward to the next Sys Admin supplement for Linux (although, most of UNIX and Linux are interchangeable). [I've taught some Linux "gurus" some stuff they didn't know from my UNIX experience from 10 years ago.]

All I need to do now is to find an OS for my VaxStation and Sun 3 (we're also running Win NT 4.0 Workstation and Windows 2000 Professional at home)!

Thank you,
Ralph Hightower

Rich Teer has some good items in his article (November supplement), which I will be using. There are other items that I don't agree with, but this letter is not that kind of a critique. Still yet, are items in his scripts which he didn't cover in his article. I checked up on the items I had not heard about and found a problem related to versions.

I found the problem in his Phase 1 script, as shown in the code snippet below:

if [ "$USE_NTP" = "true" ]; then
     echo "set dosynctodr = 0" >> $SYSTEM
fi

From Symptoms and Resolutions: 19195:

The common lore for setting up xntpd on Solaris using the freeware version included the warning to set the kernel variable dosynctodr to 0 in the /etc/system file thus: set dosynctodr=0

When using NTP on Solaris 2.6 or later, the kernel variable MUST be left at the default value of 1. Prior to 2.6 this variable controlled whether or not to rein in the softclock using the hardware clock, with the result that NTP and the hardware clock would fight for control of the soft clock; thus before 2.6 you had to set dosynctodr to 0. At 2.6, every system call that adjusts the softclock also sets the hard clock, thus while NTP controls the soft clock, the hard clock is also controlled. Setting dosynctodr to 0 reverts the behavior back to the pre 2.6 default behavior, having exactly the opposite effect as that intended.

Do not set dosynctodr to 0.

Jim Cooper
UNIX Systems Administrator

I am writing to comment on Bill Bollenbach's article from November. As a member of large team of UNIX SAs supporting more than 200 servers running 5 different flavors of UNIX, I welcome publication of an article that is devoted to AIX. This subject stands out from most of the other articles that, unfortunately, are devoted to Solaris and Linux.

This article describes a how-to procedure for reducing the size of the filesystem. The term "ReOrg" used in the article's title is misleading, as reorg can mean many types of reorganization, such as enlargement and rename of defragmentation. Next, most of the article uses AIX command-line utilities to perform basic LVM structure manipulations. But in two cases, the author uses menu-based SMIT utility. I do not object to the use of SMIT, which is much more dependable and extensive than other similar SA menu interfaces, but the context here calls for usage of command-line utilities instead -- that is, mklv instead of smitty lv, and mkfs instead of smitty fs. Usage of such utilities is much more appropriate because it can show significant details that relate to the article's purpose and fit more with the level of readers of the magazine. The suggestion to precede complex commands with comment sign (#) is strange at least; mistyping of most of the commands listed in the article can cause data and system destruction.

The habit of putting comments in the round brackets but in the same font as commands typed at the terminal is misleading, comments should be kept in separated lines and be visually distinct from the code. See steps 4, 5, 6, of the article.

In step 6, you have lost the redirection sign, the line should be:

ls -alR /fs.old >fsold2

In Step 10, you have omitted the slash at the start of the name of the mounted filesystem.

In my view, this list is far too long for a professional magazine of the kind that your publication is trying to be. I strongly advise you to improve your editing practices, by adding review of all published materials by professionals at the highest possible level. Your readers will be misled by wrong recommendations. I tried to be as constructive as possible in my letter, now I am expecting constructive actions on your side.

From: Bill Bollenbach
Subject: Re: Facts and Opinions

Mr. Polyak is correct regarding the typos in Steps 8 and 10; fs.oldlv should read fslv.old, and Step 6 should have a redirection (>) included in it. I apologize if these typos created any confusion.

It is also correct that I mixed command-line content with SMIT utilities panel calls. I didn't want to get into the partition sizing issues inherent in commands like mklv (which are highly site specific), and I tried to limit the focus of the article to the resizing process. I assumed that general filesystem creation would be well understood, but in the interest of clarity, perhaps it would probably have better to say something like: "Create the secondary filesystem at a reduced size using whatever means you prefer", and proceed from there.

As far as the practice of commenting the command and then recalling it to ensure accuracy; the reader is incorrect, in that most of the commands listed will not have an impact on existing FS if typed incorrectly. Mounting and unmounting, removing a mirrored copy, or changing the FSname will not even occur if the target is typed incorrectly. The system will simply tell the SA that such a target does not exist. Commenting significant commands and recalling them in this fashion is a fairly common practice. It was provided as a simple caution and can be used at the reader's discretion.

Regarding the title of the article, it is correct that the general reader can interpret the word "reorg" in a number of different ways. However, one of these would include the resizing operation described there. This complaint would seem to be a matter of semantics and style. More important than questions of style is whether a routine provides admins with a useful tool. I hope this routine does that. Please feel free to call it whatever you wish, reorg, resize, or rebuild.

Best wishes,
Bill Bollenbach

Just wanted to drop a line and tell you what a valuable magazine I have found Sys Admin to be. Your staff needs a pat on the back.

I received the Solaris Administration issue and lightly skimmed through the articles (read titles and 1st paragraph). Some interesting stuff.

I would like to request an issue devoted to AIX System Administration. I suppose you have probably received the same request from some Linux folks. So it's okay by me if you do them one after you do one for me. :-)

With AIX-L on the horizon perhaps both audiences can be served. Again, thanks for the work that goes into making Sys Admin a valuable tool in my tool bag.

Readers,

I invite you to submit AIX-related article proposals to me. We may or may not be able to produce a supplement, but perhaps we can increase the amount of AIX information provided in the magazine.

Thank you all.
Amber Ankerholz

The following attribution was omitted from Jeff Ruggeri's article in the Solaris Administration Supplement:

The text of the article "Starfire Administration" was adapted from Ruggeri's contribution to the book Solaris Solutions for System Administrators by Sandra Henry-Stocker and Evan R. Marks, published by Wiley Computer Publishing.