Questions and Answers

Bjorn Satdeva

I continue to get email from people who say the sag (System Activity Graph) tool is on their system, and prove it by sending me a copy of the man page. There is little doubt that many vendors are shipping the executable, but does it work? If you have used the program, and know that it works, it would be of interest to our readers.

The Network Security '96 conference will take place November 4-8, 1996 at the Washington Convention Center, Washington, DC. It features tutorials by people who work with these issues every day. Some of the topics covered in these tutorials are Internet Firewalls, Effective Incident Response, Building A Successful Security Infrastructure, Security and the Web, and Windows NT Security.

I am looking for some information on the recommended maximum number of systems that can/should be supported by a System Administrator. We will soon have more than 1,000 systems in multiple locations that are supported centrally. I would like to find some sort of benchmark to compare the SA to machine ratio of our company with the rest of the UNIX world. Are you aware of any information in this area?

I am not aware of any information that is up to date, and for a very good reason! There is no answer to this question that will be right in more than a small percentage of cases. As with many questions relating to the field of system administration, the answer ties in very closely with the policies set forth by upper management. In your case, the answer would depend on what kind of support you and your group are supposed to provide. Also, the structure of your organization will have a big influence how many people you need, and how they should be organized. As a very general rule, the more you can centralize the administration and the tighter control you have over the machines and network, the fewer people you need. If you compare different environments, you will see different numbers of people required to provide similar levels of support. In an MIS environment, administrators will often have a great deal of control, and will therefore need fewer people, compared to a typical academic environment where everything is looser and support is provided in a more ad hoc manner.

An answer to this quesion that apparently works for one site will most likely not work as expected at your site. Also, your management is likely to ignore a request for more people just because your admin-to-machine ratio is less than somewhere else.

You need to get a clear idea of the level and type of support you and your group are supposed to provide, and then work out the logistics from there. You will almost certainly need a job tracking system, not only to keep track of user requests but also to track work that has and has not been completed. The data you can extract from such a system will be invaluable when you are negotiating more resources with your manager, and will in turn provide him with good ammunition when he is negotiating with the next level of management.

Also, as I have mentioned in the past, you should have your group structured somewhat. It is of course good if everybody is able to do everything, but they should not be required to do so in the day-to-day working situation. You should take advantage of people's skills and interests, so the work can be done as smoothly as possible, and so people have an opportunity to grow. This may sound difficult, but is important. Good sys admins are becoming more difficult to find, so you need to grow them within your own organization in such a way that they'll want to stay for a long time.

Finally, when you build your sys admin group, it is important to leave some of your most senior sys admins free to worry about the future. Unless you have someone to do the strategic planning, you will sooner or later (and probably much sooner) find that you have "painted yourself into a corner." There you will find that you do not have enough resources (or are unable to efficiently utilize them) to provide the service you are supposed to.

If you find that you have difficulty justifying additional resources and that everybody is always busy fighting fires, it might be a good idea to get somebody from the outside to analyze your situation. They can then recommend what should be done to improve the situation. Not only will a consultant skilled in such issues be able to see both problems and solutions that may be invisible to you, but recommendations from a third party are sometimes more readily accepted by upper management than those from within the company.

Is there a limitation to the number of files/directories, lines or bytes that a tar exclude file can have? We routinely use tar for (hot) filesystem backups. We exclude active Oracle database files by excluding their directories. That said, not all of the excluded directories are excluded. As you might imagine, we run out of tape before the tar is done. I include the exclude file. The comments are removed before the "permanent" file is copied to our working version in /var/tmp. There, the current tar activity log is appended to it. The tar command (beginning in the root dir, /) is as follows:

tar cBfivX /dev/rmt/2h /var/tmp/backup.tar_exclude

Any ideas?

Yes, there is a limit on the number of excluded files; and as you have experienced, it is too low. If you want to continue to use tar for backup, see whether GNU tar will work better for you. This version of tar uses dynamic memory allocation for the excludes.

However, I should also mention that tar is not very well suited for regular backup duties. It was written to be used for archiving (which is slightly different from backups), and it does this well. For daily backup, I have learned from experience that dump is superior to any other backup software I have seen and used. Although dump has an obnoxious user interface, it is more reliable than programs such as tar or especially cpio. It understands the low level format of the disk and bypasses much of the UNIX I/O overhead, which makes it both faster and more reliable. And in your case, because dump will back up the disks one partition at a time, you will eliminate the need for an exclude file.

For an eye opener, read Elizabeth Zwicky's paper from LISA V: "Torture-testing Backup and Archive Programs: Things You Ought to Know But Probably Would Rather Not." The paper and the backup testing software are available from the system administration archives at:

ftp://ftp.sysadmin.com/pub/admin/backup/torture.gz

We are currently using Siemens nixdorf SINIX 5.41 operating system. I am looking for shareware or freeware programs for it. Also I want to download Linux from Internet to my home computer. Where can I find Linux?

Shareware is mostly a PC kind of thing. Traditionally, freeware programs for UNIX are traditionally made available in source form. There are an almost countless number of places where you can find such programs. The problem may be finding software that is already ported to your platform, as it is not very common. However, here are a few URLs to start out with: The system administration archives: ftp://ftp.sysadmin/pub/admin The UUNET archives: ftp://ftp.uu.net/pub The GNU sources: ftp://prep.ai.mit.edu

Linux is available in many places, too. Here is one URL:

ftp://tsx-11.mit.edu:/pub/linux

The big problem is finding the software that matches your immediate need. If you know the name of the software, you can use the archie program or otherwise try one of the many search engines available on the Web.

I've been a subscriber since the magazine's infancy. Many of the scripts that you publish are Perl scripts. Where is the best place to acquire it, and what are the system prerequisites if any?

Perl runs on almost every architecture and operating system, maybe only short of your microwave oven. See below for a list, which by now may be incomplete. You can get the sources for Perl at:

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

These are the systems for which a "hint file" exists. Perl should compile without problems or with very little work on many other systems.

Without a lot more specific information about the system, it is almost impossible to pinpoint the problem. Frequently, the problem with slow systems is insufficient memory or bottlenecks in the disk I/O system. There is a very good book on system performance from O'Reilly and Associates, which discusses these and many other issues related to performance tuning. (The book is System Performance Tuning by Mike Loukides. - AA)

I read your column on a regular basis. I wondered if you have ever encountered a script that would consume a sendmail log file and produce a summary of the errors that occurred during the time frame covered. This report in turn could be chopped by user name, so that individual users whose mail encountered problems could be notified.

No such tool exists. One of the problems is that there is not that much useful information in the sendmail log file, which is not intended for troubleshooting of the configuration. Users are notified by email if there are delays in delivery or if mail cannot be delivered at all. However, although these messages are clear to people used to working with email problems, they are often misunderstood by end users (e.g., warnings about delays in delivery are often interpreted by end users as a much more serious problem).

If you write such a tool, it should not be too complicated to implement in Perl. There are a limited number of messages generated by sendmail, and there are excellent capabilities for regular expression built into Perl that are useful for tasks such as this.

I need to build a Web server for my company. What do I need to do to make sure it is secure?

If you need to use CGI scripts, then it becomes almost impossible to make it secure. You will need to worry both about the interface between the web server and the CGI scripts and interpreter, as well the interface between the scripts and the operating system. To give you an idea of the difficulties, one site where the people were in the business of writing secure CGI scripts put up some guidelines on their Web page for other people to follow. Unfortunately, they had made some minor mistakes, and the site was broken into through the CGI interface.

Unless you are able to limit your Web server to serving some simple HTML text with GIF pictures, without any CGI, you are almost certainly at risk. Using Java will help on the server side, but then you will need to decide how to deal with Web browsers that are not Java-aware. Your best bet is to assume from the very start that your server will be compromised, and design it accordingly. Although you still should do everything you can to prevent the server from being penetrated in the first place, you should also focus on what can happen if the server is penetrated. You should most certainly ensure that an intruder cannot leave the system after a successful penetration. In other words, make the Web server a firewall unto itself, and make sure that it is impossible to telnet, ftp, or rlogin out from that system. And, of course, no one anywhere should trust the system. As always, when dealing with security issues related to the Web, it is much worse than you think!

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.