Questions and Answers

Bjorn Satdeva

One of the questions I get asked most frequently by system administrators new to their trade is what they need to learn in order to get good at their chosen profession (or in some cases the one chosen for them by their manager). I think that they expect me to tell them that they should learn everything about NFS or Sendmail or DNS or something of the kind. Good technical skills are, of course, a must in our profession, but that is only part of the picture.

To become a good system administrator, the ability to plan and to focus is also essential. We work in a high-interrupt environment, in which people and phone calls are constantly breaking our train of thought. So how do we learn these skills? For me, an essential part has been to learn good time management.

The first element of time management is to plan the day ahead (i.e., what meeting do you need to go to, when is it time to do the backup, and so on). Try to set aside at least an hour of uninterrupted time each day working on strategic issues, the stuff that would make your life easier if it were done, but that you never find the time to do. It can be difficult to justify to other other people and especially to yourself, when there are a dozens fires burning all around you. Nevertheless, if you try for at least a couple of weeks to do so, you will be amazed at the results you can produce.

Try also for a few weeks to carry a small notebook around with you, and make minute notes of how you spend your time. When you get interrupted, make a note. When you doze off or are just staring into nowhere for a few minutes, note it down. Keep track of how much time you spend on NetNews or browsing the Web. You may be surprised at how you actually spend (or rather waste) your time.

Most system administrators are unable to keep their work week to just 40 or 45 hours a week, and some work much more than that. Wouldn't it be nice if you could cut a few hours off your work week, and maybe have a weekend now and then? So, pull out the notebook, and get to work on your work habits!

I've gotten some really useful tips and learned a lot of tricks from following your column in root and Sys Admin and am hoping you can help me with something I've been wrestling with for a while.

I am trying to find an easy (if there is such a thing) way to calculate what yesterday's date was from within a shell script. I'm getting hung up on trying to deal with month and year changes. I'm writing a system auditing script for novice systems administrators that will go through the system log files and pick out those entries from the previous day that might need attention. Note that this is not intended to be run on servers, but on UNIX workstations that typically have 1-3 users and very little activity.

I don't know of any easy way to do this directly in a shell script. Also, I don't know how far you have come in your project, but you have two options I can think of. You can get the date command from the BSD 4.4 lite or the Linux distribution and hack it to output yesterday's date, or you can write your scripts in Perl. In my opinion, programming in the shell, except for the smallest scripts, is obsolete, and all such projects should be done in Perl instead. There are several reasons for this. The most important is that a Perl script is less likely to depend on execution of other programs, while the shell is extremely dependent on the same thing. This makes a Perl script both a lot faster and much more difficult to spoof.

You can get yesterday's date in Perl, with very little code. The following script illustrates what you need to do (remember that there are 86,400 seconds in a 24-hour period):

#! /usr/bin/perl

require "ctime.pl";

$Yesterday = &ctime( time - 86400 );
print "$Yesterday";

I was reading Sys Admin from Nov/Dec 1995. In the Q&A section, you mentioned NCSA web server had a major security hole. We are running that server and wanted to follow up on that topic.

A server for which this problem has not been corrected can be tricked into executing shell commands and may give remote users unauthorized access to the account (userid) under which the HTTP server is running. The specifics of this security problem are described in a CERT Advisory from February 17, 1995 about the NCSA HTTP Daemon for UNIX Vulnerability.

The HTTPD Team at SDG at NCSA has provided a solution that is described in detail in the CERT advisory. The advisory can be found in a file named:

CA-95:04.NCSA.http.daemon.for.unix.vulnerability

You can get it from the CERT ftp server or from the system administration ftp archive at:

ftp://ftp.sysadmin.com/pub/admin/alert/cert/advisory

Anybody who runs the NCSA server should make sure that this patch is indeed applied to their sources from which the server is built.

I have just built a prototype support tool that our customers would access via a web browser. We are now finding that some companies refuse to allow their employees web access. Is there a feasible way to provide them a pseudo-PPP connectivity, but only to one host? (We have the modems and phone lines since the tool to replace is a serial-based PC application.)

My thought is that we could use something like TIA or SLiRP. But preventing access to other machines would require another box as a comserver that had a host entry only for the web server. Is there a cleaner way?

There is no easy way to do this! I can only think of two reasons why your customer will not permit the users access to the World Wide Web: either productivity or security reasons. In either case they will probably be very reluctant to open up this potential can of worms. Establishing the PPP connection is, technically speaking, very simple, but in either of the above cases, you will need to restrict the connections to just between their web browsers and your web server. You can design a packet filter that is installed in your end, which will resolve the issues, but you will need to enforce that the customers can only connect their web browser to your web server. They will not be able to obtain or offer a service anywhere else (including each other!)

Your suggestion of having an extra system with only the web server in the host file will hardly stop anybody who wants to get access through that system.

It is possible to build a solution to this problem using firewall technology, but unless you are accustomed to dealing with network security and Internet firewalls, this is not something to implement without a very good understanding of the issues involved. You might also discover that your customer will not trust such an implementation, and will still refuse connectivity (See my column in the May issue of Sys Admin to see a few scratches of the World Wide Web nightmare waiting to unfold.)

You might need to provide an old technology-style solution to some of your customers, so they can dial-in to an old-fashioned bulletin board and get the information that way.

I enjoy reading your column in Sys Admin magazine (I just started subscribing about 2 months ago), and I looked at the info on your home page. Can you tell me where I can get some of your old articles that were written in root and Login?

Back issues of Sys Admin can be ordered from customer service at (800) 444-4881 or on our web site at http://www.samag.com. Back issues of its predecessor root are no longer available. A few of my articles published in root are available on my ftp server:

ftp://ftp.sysadmin.com/pub/admin/papers/bjorn

It is my plan to make them all available in my copious spare time.

I have been subscribing to Sys Admin for about a year now and find it very useful. In almost every issue, I find an article that I can implement locally. But, there is one tool that I have never seen.

The tool I am after should store all edited system files (passwd, rc.local, /etc/exports, etc.) from all hosts under a common backup directory something like /sysadm/<HOST>/<original path>/RCS/<original file> so that an edited version of /etc/exports from the host "hosta" would end up in /sysadm/hosta/etc/RCS/exports,v.

This tool should also handle the cases where the input file is on an automounted filesystem, either the vendor stock automounter or amd. The tool should handle several input files on the command line, both with relative and absolute paths. Do you know if such a tool exists?

I do not know of any tool that can do all of what you want, but it should not be too difficult to put an ad hoc solution together by combining make, CVS, and rdist. I have seen a number of such solutions over the years. The important thing is to build it in such a way that you can continue to maintain it.

As a reader of your column in Sys Admin, I wondered if you could answer a simple question on awk for me. My question is whether it is possible to pass a command line parameter into an awk statement, whereby the parameter is used as the search pattern. For example:

awk '/pattern/ {print $1}' pattern=parameter datafile

I last wrote an awk program before Perl 3 was released, and I have happily forgotten most of awk. Both shell and awk programming should, in my opinion, be something of the past, not to mention such abominations and programs that are a combination of the two. Some of our readers may have a direct answer for you, but my recommendation is to write your program in Perl.

For people who have never used Perl, the interpreter is available from the ftp archive:

ftp://ftp.sysadmin.com/pub/admin/languages/perl4

and

ftp://ftp.sysadmin.com/pub/admin/languages/perl5

Larry Wall and friends have done an incredible amount of work to make this program compile on a very large number of machines. There are two good books on how to use Perl, Learning Perl by Randal L. Schwartz and Programming Perl by Larry Wall and Randal L. Schwartz, both from O'Reilly and Associates.

I have noticed that you sometimes use the old notation for an ftp file, like

ftp.sysadmin.com:/somefile

and sometimes the World Wide Web notation:

ftp://ftp.sysadmin.com/somefile

Why are you switching between them?

I am dating myself. For many years I have used the old syntax, so it is now microprogrammed into my fingers. If I do not think about it, I fall back to the old notation; however, many people seem to prefer the newer syntax, so I do what I can to accommodate the change.

I am trying to learn to format documents with troff. Do you know any good books I can learn from?

I am amazed that anybody is learning troff in this day of WYSIWYG editors and word processors. I am considered almost an iconoclast by many people because I still prefer a good text editor and typesetting system over a WYSIWYG. To answer your question, there is a highly recommendable book by Narain Gehani, Document Formatting and Typesetting on the UNIX System, published by Silicon Press. It covers the "mm" macro packages and how to create tables and figures. It will get you going in no time.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.