From: Karl Vogel (email@example.com)
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
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
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
From: Kurt Schadewald
To: Ido Dubrawsky (firstname.lastname@example.org)
Subject: Securing Solaris article (November supplement)
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
From: Matthew Zeier (email@example.com)
To: Ido Dubrawsky
Subject: Your article in Sys Admin Supplement (November)
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.$$
I think a more preferable method, and the method that /etc/init.d/ipfboot
uses, would be:
/sbin/ipf -IFi -f /tmp/ipfule.$$
By flushing the input rules, even for a second, you leave the host
machine unnecessarily unprotected and open to possible attacks. --mz
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
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
From: Ralph Hightower (firstname.lastname@example.org)
Subject: attaboy -- Solaris Admin Supplement
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)!
To: Amber Ankerholz
Subject: Rich Teer's article "New Approaches to Making
Solaris More Secure"
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
if [ "$USE_NTP" = "true" ]; then
echo "set dosynctodr = 0" >> $SYSTEM
SUNSOLVE has this to say about it.
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:
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.
UNIX Systems Administrator
From: Alex Polyak
Subject: Facts and Opinions
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
ls -alR /fs.old >fsold2
In Steps 8 and 10, you refer to the name of the old filesystem as
fs.oldlv instead of fslv.old, which was used in preceding
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.
From: Gary Luther <email@example.com>
Subject: Sys Admin -- AIX Style
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
I received the Solaris Administration issue and lightly skimmed
through the articles (read titles and 1st paragraph). Some interesting
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.
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.
Correction to Solaris Supplement:
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.