Cover V01, I02
Article

jul92.tar


New Messages

We ask that letters with code listings be submitted in an ASCII text file on an MS-DOS formatted disk or via email. Our net address is: saletter@rdpub.com ("...!uunet! rdpub!saletter").

First of all, let me thank you for what looks to be a very useful magazine. One suggestion I would like to make is that you make your listings available in electronic form. Being able to submit this letter via E-mail is very convenient for me. It would be even more convenient if I didn't have to type in the listing for any program or shell script I found interesting. The ideal situation would be for all of the files contained in an issue to be available via anonymous ftp. Failing that, an automated mail server, or even a BBS system, would suffice.

On to content. I particularly liked the article by Leor Zolman on the overnight job spooler. I do have a few comments.

Mr. Zolman is concerned that jobs submitted after the spooler has begun processing for the night will be "lost" until the next night. He has added several checks to help prevent this. I believe there is a much simpler solution. The main body of "onitego.sh" consists of a while loop wrapped around an if. If the statement "priority=0" were added, just before the "fi", then the priority loop would reset to 1 on the next iteration, and any newly queued jobs would be caught. The while loop would only terminate after ALL priority levels had been found to be empty. The potential hole for a "lost" job still exists, but it is VERY tiny.

My other comment is more serious. These scripts, as they stand, represent a huge security risk! Since the jobs are run with root access, nothing prevents a user from accessing (or destroying!) sensitive data. This issue needs to be addressed before these scripts can be used on any system where the sysadmin has anything less than absolute faith in the integrity of all users. I've tossed several ideas around in my head, but I haven't come up with a secure solution yet.

dwayne@stratsft
Dwayne Bailey
Redford, Michigan

It has been our intention all along to make SysAdmin listings available electronically; however, as the Premiere issue went to press, we had still not completely ironed out the details. SysAdmin code, as well as the code for our sister publications The C Users Journal and Windows/DOS Developer's Journal, is now available via UUNET for ftp or uucp transfer (with or without a UUNET account). See the announcement on page 24 of this issue for the gory details.

Thank you for your kind comments about SysAdmin and the Overnight Spooler article. Your point relating to the security issue is right on target; I've tried to at least scratch the surface of this problem with some comments in my article this month. The bottom line, though, is that the Onite system as presented last issue is not secure, nor can it be made truly secure without a total rewrite. Think of it more as a jumping-off point or initial sketch for such an application.

Now regarding my way of dealing with late queuing of overnight jobs: If the technique you suggest for processing "stragglers" were implemented, then there would be the serious possibility of order-sensitive jobs running in the wrong order. For example, the backup script could run before a "late-spooled" job that alters the database, potentially leading to some confusion if there were ever any need to restore from the backup. By explicitly closing the door at the time the overnight spooler kicks into action, the potential for this problem is eliminated.

Around our office, there's rarely anyone spooling jobs past 6 P.M. anyway. If you want folks in your work environment to be able to spool jobs at any time, and you're not too concerned about the priority issues, then I'd say go ahead and apply your patch with my blessings... --lz

Dear SysAdm staff,
Liked your first issue. Some of it was pretty deep for our fledgling staff (including me). We develop applications for our International missions offices running DOS and SCO Unix using the DBL programming language (similar to DEC's DIBOL).

Really liked the short programs and include our version of "largest" and another variation called "newest":

:
# largest
# gives a directory listing
# in reverse size order
#
ls -l $* | sort -r -n +4 -5 |
pg -sp "<return> = advance
a page,  <->
= back up a page,  <q> = quit: "

:
# newest
# gives the end of a
# directory listing in date
# order
#
ls -lrt $* | tail -22 ; date

Is there ANY way for an extension sorted list? I would kill for this option in Unix after working on DEC opsys for years.

Future editions could address safe ways to clean up filesystem fragmentation without using a utility, only tape restore. What does "fsck -S" do to help in this regard if anything?

Managing an elm system could be a big help for us. Just configuring the elmrc file could be a topic for an issue. I would like a step-by-step procedure to take a distributed SCO Unix system and attach a T-bit modem and start exchanging files on internet.

Also need to know how to config a system to dial into another to do interactive updates for support purposes.

How about an article on system manager suggestions for daily, weekly and monthly housekeeping? Which are the files that "grow" and need pruning?

How to use "sa" to tune a system and keep it simple -- most of us can't spend weeks on this but need a rough cut to optimize the significant parameters and not hassle with the final 10 percent that takes 90 percent of the effort.

You have a great shot at a great mag, don't blow it!

Regards,
Ron Tenny
Operation Mobilization, Inc. - USA
285 Lynnwood Ave., PO Box 444
Tyrone, GA 30290-0444
AT&T: (404) 631-0508
FAX: (404) 631-0439
emory.mathcs.emory.edu!omusa!ron

Thanks for the encouragement (I think). I think you are in luck on most of your suggested topics. For example, we have installed and configured (and patched for our idiosyncracies) elm; we communicate via a telebit modem and we run SCO (presently Xenix, but UNIX in the not too distant future). Thus, we won't even need to search for an author to satisfy many of your requests.

All the same, I'd be happy to see manuscripts from others on any of these topics. System performance tuning is an especially dark black hole to me. I'd welcome some information from someone experienced and knowledgeable.

Meanwhile, here's an answer from Kenji Hino, of SysAdmin's technical staff, to your request for an extension-sorted list. --rlw

$ ls | sort -t"." +1 -2

Dear Leor,
I don't know how it happens, but you seem to be able to publish what I need within minutes of when I think of it. Miraculous.

Specifically, I'm talking about the overnite scheduler in SysAdmin. It seems that I can always count on your articles to have useful and understandable functions. This is certainly not true of your contemporaries! Keep up the good work, please!

I'm enclosing a small program that may repay you in a (very) small way. I needed (wanted) a way to emulate a "hot key" in a shell script -- that is, ask a user for a single keystroke entry and act on that keystroke without having to wait on a carriage return as is required by the shell's read command. After trying many different ideas, I contacted an acquaintance at the Military Personnel Center here on the base. He supplied the following small program that works beautifully:

/*****

Thanks to Lt Caley (AFMPC, Randolph AFB, TX):
Compile: cc -g getone.c -l curses -o getone ****/ #include <curses.h> int main() { int key; newterm(NULL, stdin, stdin); key = toupper(getch()); reset_shell_mode(); putchar(key); exit(0); }

the only caveat is that the program will not allow a ctrl-d to be processed as a shell exit. You must explicitly provide an exit choice in your script. I hope this is of some use.

Thanx again
P. David Sorgen
Randolph AFB, TX 78150-6421
DSN 487-3214 Com: 512-652-3214
dsorgen@cpmc.mpc.af.mil

Hi,
I run a network of about 700 machines, of which 500 are UNIX (all kinds of UNIX), and would like a couple of topics discussed.

I am looking for things that are not in UNIX books -- mainly interoperablitly between different vendors. I am hoping that SysAdmin will be for serious system administrators.

Topics I'm interested in include:

1) How to put together a "Getting Started with UNIX, the X-Window System, etc." packet. I know that most things are site dependent, but there should be some general info. I have been an adm for so long that I don't remember being a novice user ... and all the novice users I have met do not know the questions to ask. (But this may not be appropriate for SysAdmin.)

2) How to configure routers and bridges -- not what is in the books, but how to block and maybe make firewalls and security and whether or not every remote network bridge/router should have a modem, just in case.

3) A script that duplicates a directory from one machine to another machine (I would like to know all the ways this could be done). What I really want is a standard way of copying a directory that will keep everything the same (modifications, times, permissions). Most problems I have run into are with tar and cpio and have to do with pathname length (either 128 or 256 characters absolute pathname lengths). I have yet to find a way that works for all cases.

4) Managing files on UNIX boxes. Example: I use symbolic links for printcap, networks, sendmail.cf and /usr/spool/mail or /usr/mail and for the same types of systems these are linked to one machine (with a backup machine ready). I was thinking of using SCCS on these files so I could keep revisions. You could also discuss making huge crontab files like mine!

5) Adding new NIS maps like a global telephone phone list and making it work with Sun, DEC, Silicon Graphics, Nighthawk, HP, IBM ... etc (though most of this is probably available in books).

6) Inconsistencies between all platforms -- like maybe an article on /etc/fstab differences on different systems; or NIS on all systems; or how Sun will not use bind unless a Sun is the NIS master.

7) An ongoing list of system administration books that are good references: the best books for tcp/ip; the best for NIS and NFS and such.

8) Fast ways of loading different systems (and loading the machine with as few commands as possible). I have Apollo systems and can load 4-5 at a time with one command, then reboot and issue one command for each. It's an Ethernet load and loading 4-5 machines puts a local Ethernet to 25-30 percent and takes 2-3 hours. I am starting to work on loading DEC (Ultrix) systems quickly and will probably use dd in a script through the SCSI because MOP (from DEC) is not ready for serious loading "out of the box." Doing it by hand is fine if you have a few days to spend on it and only 10 or so systems to load but when you have several hundred and you reload 2-6 of one type of system a month, this isn't an option.

9) System performance and analysis scripts and tools.

10) Perhaps an issue a year devoted to backups -- the best and fastest ways.

Some notes and questions:

Are you going to put your code on uunet.uu.net?

Will you try to get real input from USENET?

Are you going to be a mag for real sysadms?

It's time for a serious magazine that takes sysadm out of the normal 10-30 systems and puts it in with the 300-10000 node networks. Keep it technical (please!!!) and geared for large networks with few administrators (like most large networks), where time is essential and magazines go unread because it takes too long to read through the stuff that you already know or that is in all the books in your office. I thought your first cut was pretty fair, but "My Favorite One Liners: Some Useful Shell Programs" should have just been RTRM and some tips on manuals to read (it has no place in a sysadm mag).

If this mag is going to be for sysadms then realize your readers are SYSADMS! and they know all about shell scripts and they know how to port programs. Please in your articles talk about real sysadm issues!!!!

Russ Hill
rhill@dale.ksc.nasa.gov
rhill@pulse.spacecoast.org

See above (and page 24) for information about network postings of the code.

As to whether we'll be for "real sysadms": Yes, I want it to be a magazine for "real sysadms." You and our other readers will judge whether we succeed.

I feel strongly that sophisticated practicing professionals (as opposed to researchers) are seriously underserved in almost every technical area. Sophisticated professionals are by definition a small audience. Most financially viable publishers aren't interested in small audiences; they need large audiences to attract advertisers. Thus when large publishers bring out so-called "technical" magazines, they tend to deal in abstract generalities, in market and product information, and in religious exhortations. Unfortunately, sophisticated professionals seldom learn much from reading another abstract overview of "How to choose an operating system"; most likely know where to obtain more specific, reliable, and comprehensive product information than our small company can generally provide; and have probably already developed a highly productive understanding of what is "good practice" -- and thus aren't prime candidates for a new religious experience. Moreover, the very practices that make a magazine more valuable to broad, inexpert audiences (e.g., eliminating jargon, avoiding platform specific details, tutorials on well-known subjects, "friendlier" restatements of reference manuals) make it significantly less valuable to the sophisticated professional. You can't serve both audiences well in the same publication.

We do things differently. As of this publication date, this magazine has about 5,000 subscribers. Most of the small trade journal publishers I know maintain that a publication can't be profitable until it reaches at least 15,000 subscribers. Perhaps they are right -- by their definition of profitable. But they are also wrong. As we've proven with The C Users Journal and Windows/DOS Developer's Journal, small, tightly-focused, demanding publications can be financially viable. They won't make anyone rich, but they can pay their own way.

So, the short form answer to your question is: I have no interest in attracting and tutoring the masses. I want this magazine to be read, respected, and valued by some of the most talented and experienced System Administrators out there.

Having said that, I must also point out that there are talented and experienced people working in systems with 30 users, too. And there are talented and sophisticated people who aren't yet deeply experienced sysadms. And there are experienced and sophisticated sysadms who aren't yet expert in every speciality or platform. Thus, I don't intend to publish pabulum, but that doesn't mean every article in every issue will cover something new to you. What it should mean is that at least one article in every issue will bring you something valuable and useful. That's the best we can hope to do for any real-world audience -- and it's far better than any other UNIX magazine is presently doing for sophisticated system administrators. --rlw

Just received your first issue. GREAT! Insightful, provides "real" info SysAdmin types can "real"ly use, right-to-the-point, congrats on a top notch publication.

Tom Cropper

Thanks and Bless you. It's great to know we're making a difference. --rlw