Questions and Answers

Bjorn Satdeva

Is there any chance Sys Admin might have a back issue dealing with changing the lp services spool directory? I have very little room left on my root filesystem where the default spool directory is (/usr/spool/lp). I have tried setting the SPOOLDIR variable in /etc/rc2.d/S80lp before lpsched is called, but it just ignores my new directory tree and goes on spooling to the default directory.

We don't have an issue that addresses your problem, but I can suggest two possible ways to get around it. The quick-and-dirty solution is to create a symbolic link from the current directory to the new place where you want to keep the directory. Use something like the following code:

mkdir /my/new/spool/dir
cd /my/new/spool/dir
(cd /usr/spool; tar -cvpf - lp ) | tar -xvpf -
cd /usr/spool
mv lp lp.ol
ln -s /my/new/spool/dir/lp /usr/spool/lp

then restart the line printer daemon (or reboot the system). When you are certain that everything is working, you can remove the lp.old directory.

This trick does help when you are short of disk space, but it should be seen as only a temporary solution. Otherwise, you run the risk of amassing a significant number of symbolic links, with nothing where you really expect it to be. If you create lots of such links, you end up with what I call the symbolic links from Hell. The result can be a situation in which each system is a special case unto itself, with the time required for maintaining each system steadily increasing.

A better solution is to use a separate filesystem. You can then simply mount the filesystem you wish to use on the target directory (/usr/spool/lp) or, in this case, on the parent directory (/usr/spool). As a general configuration rule, I prefer not to have /usr/spool or /var directories on my root filesystem, the reason being that I try to make that filesystem as close to "read-only" as possible. Although the filesystem software in the kernel is much more solid today than it was a decade ago, large numbers of "write" accesses to the root filesystem, create the risk of serious damage. And as we all know, a severely damaged root filesystem is more difficult (read: time-consuming) to repair than any other filesystem on the machine.

In the May/June 1995 "Questions and Answers," in a discussion of Satan, you refer to a paper laying out the concepts involved and available as admin-guide-to cracking.101.z. Do you know where I can obtain a text version of that file that I can download and read? I understand that .z files are UNIX files - do you know of any MS or Windows 3.1 software that can read .z files?

This paper is distributed with the Satan software in html format.

The .z (lower-case) extension means that the file was compressed with the very old pack command, which is no longer in use because there are much more effective compression algorithms available today. A .Z (upper-case) extension means that the file has been compressed with the compress program, while a .gz extension means it was compressed by the GNU gzip program (which uses by far the most efficient compression algorithm). I have been told that unzip for MS-DOS will correctly uncompress files compressed with compress and gzip.

Can you help me figure out which network platform is better for a company that is expanding from a small, one-building, client/server network to multiple sites? Specifically, if a company opens three or four new sites and wants them all connected, which is better, Unix or NT? I am interested particularly in the architecture used and the physical and cost requirements involved in the expansion.

This question can't be answered unless you specify which applications you need to run. For the most part, it's no longer appropriate to purchase an operating system for a computer; instead, you would choose the application platform that does what you need it to do, then select the operating system that best supports your application.

I hope you can help with a problem I'm having in setting up two network cards on a Unix server. I have a UNIX server using TCP/IP, with two ethernet cards, one of which is set up correctly on the network. I am trying to get the second card correctly addressed and operative. So far, no luck. The network will not recognize the connection, and I'm out of ideas.

First of all, you need to make sure that your kernel is configured to support two network cards. Depending on the vendor, this may or may not be the case by default. You will probably also need to ensure that the IP packet is forwarded between the two networks (this is the default for most vendors). Once these basic steps have been taken, you can use the ifconfig command to configure the network card to talk to the network.. The syntax is partially vendor-dependent, but should look something like this:

ifconfig le1 inet 165.227.19.1 netmask 255.255.255.0

The ifconfig should be placed in one of the rc files, together with the ifconfig command for the first interface card. Again, the exact location is vendor-dependent.

If you have tcpdump or a similar program, you can see what information is going across the wire. You should be able to see traffic from the other systems on that network segment (unless you are using ethernet switches).

I learned recently of a document which describes the necessary job qualifications for system administrators. Do you know if this document is available on the net?

You may be thinking of the SAGE (System Administrators Guild) publication "Job Descriptions for Sysadmins." You can find it at:

http://www.usenix.org/sage/jobs/jobs-descriptions.html

Any system administrator who does not know this document should have a look. You can also purchase a more complete version from USENIX with more explanatory information. I recommend that any system administrator who has to hire other system administrators or who is currently looking for another position get the full document and read it very carefully.

Where do I find documentation describing the DNS round-robin mechanism and explaining how to implement that method for my root nameserver? Our network is not open to the world, so our primary nameserver is declared as root for our internal domain name.

If you get the latest version of the BIND nameserver, this behavior is included by default.

Can you tell me how to use crontabs?

are configuration files for the cron daemon. The cron daemon is started when you boot the system, and is used to execute programs at predetermined times. It is most commonly used to perform cleanup and system checks during the night, but can be used for any procedure that can be automated. Some examples are removing temporary files, rotating logfiles, and restarting programs.

The behavior of the cron daemon is described in the crontab files, which are typically located in /var/spool/cron/crontabs. There is one crontab file for each user. cron reads these files when it starts, and it wakes up every minute to examine all stored crontabs to see if any command is supposed to be run at that time.

When cron runs a command, the output of the command is emailed to the user whose crontab file contained the command.

The commands are specified in the crontab file, one command to a line. Each line in a crontab file has six fields, separated by white space:

minutes hours day-of-month  month day-of-week command

Figure 1 defines the fields. Figure 2 shows a crontab file with some entries I use.)

The commands are executed when the minute, hour, and month fields match the current time, and when at least one of the two day fields (day-of-month, or day-of-week) match the current time.

In the sample in Figure 2,, make is executed once an hour, at ten minutes before the top of the hour. The make file checks to see if any of the system files need updating. Since all of the day- and month-related fields are wildcarded, make is called every hour, and will update the files as needed.

The monthly cleanup script (/etc/monthly) is specified to be executed at 5:30 AM on the first day of the month: the minute field is 30, the hour field is 5, the day-of-the-month is 1, and both month and day-of-the-week are wildcarded.

The syntax of the crontab file gives you all the control you need. If, for example, you want to execute a command once a year, at 8:33 AM on the first Monday in January, the first five fields of the crontab file would look like this:

33   8 * 0 1

A word of warning: beware that shifts to and from Daylight Savings Time affect any command you choose to execute in the first hour of the day (hour zero). This hour disappears when Daylight Savings Time takes effect in the spring, but occurs twice with the shift back to standard time in the fall.

I am having problems using the sunos and solaris as servers. We run applications on three servers, each with 96Mb of memory. The messages we get are:

1. Cannot fork: Not enough memory   on SUNOS
2. Cannot fork: Not enough space    on SOLARIS.

With regard to tuning, I've tried set maxusers=60 on the SOLARIS; thus far I have not changed anything on the SUNOS.

The fork system call will fail in three cases: if there is not enough memory; if you have exceeded the limit of the number of processes per user; or if you have exceeded the limit of the total number of processes on the system. You can find out which case by examining the return value of the fork system call (assuming you have access to the source). Reconfiguring the system to allow more swap space - e.g., by adding a second swap partition to the system (or for the short term, to swap to a file) - may help. You can diagnose lack of memory and/or swap space through the information you get from vmstat. On a healthy system, you will have some free memory (fre) and the system will not page out (po) too frequently.

A useful resource in this regard is Mike Loukides' System Performance Tuning, from O'Reilly and Associates. This book offers many hints for dealing with these issues, and includes very clear explanations of how to use vmstat to get information about what goes on inside your computer.

The bottomline is that you probably need to add memory to your machines, but you need first to diagnose the specific problems and understand why they are occurring.

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.