Cover V04, I04
Article

jul95.tar


Questions and Answers

Bjorn Satdeva

Before I get started, first a correction to the previous issue. The Canadian company which sells UNIX tools for MS-DOS was misnamed: the correct name is MKS, and the software is called the MKS Toolkit. MKS can be reached at:

Mortice Kern Systems, Inc. (MKS) 35 King Street North Waterloo, Ontario N2J 2W9 CANADA

info: 519/884-2251 orders: 800-265-2797 email: inquiry@mks.com

Report from SANS

SANS 4 took place in Washington, DC in April. This conference is growing, and is in its own right becoming a major event for UNIX system administrators. It differs from LISA, which is also aimed at the UNIX system administration community, in that it has a somewhat more commercial aim: vendors are more welcome, and are better integrated into the conference. It is not, however, a vendor-driven conference, as is the case with so many of the conferences that feature large vendor shows. SANS is still less than half the size of LISA, which makes it a pleasant, more personal experience. Two of my favorite papers from this year's conference were "How To Find Good System Administrators in Twelve Easy Questions" and "Building a Security Infrastructure: What You Want vs. What You Need vs What You Can Afford," both by Michele D. Crabb, a security specialist from NASA Ames. Another very good paper is "People Skills for the System Administrator," by P. David Parks. The best ad-hoc tool was described in "The NetScanner Network Monitoring Tool," by Jack Stewart.

The conference proceedings contain the full text of all papers, along with the results of the 1994 System Administration Salary Survey. (An overview of those results was published in the Jan/Feb issue of Sys Admin.)

The conference proceedings, should you be interested, can be purchased from USENIX, a co-sponsor of the SANS conference:

USENIX Conference Office 22672 Lambert Street, Suite 613 El Toro, CA 92630 USA (714) 588-8649; FAX: (714) 588-9706 email: conference@usenix.org

Sun Microsystems Sunscreen

Sun finally unveiled its new firewall, cutely named SunScreen, which had been rumored for some time. It is essentially a packet screening filter, apparently similar to screend, running under Solaris on a Sparc 5 platform. The packet filter is managed by a graphical user interface, running on a separate Windows machine. While the screening mechanism was a disappointment, SunScreen has a number of interesting details that are worth mentioning. It uses what the Sun marketing folks call a unique "stealth" design -- ethernet connections which implement only the lower part of TCP/IP protocol stack and therefore do not provide any means of getting access to the machine itself. The product also offers encrypted traffic across the Internet, but this is not as newsworthy, as almost all other firewall vendors either offer it already, or are scrambling to provide it soon.

All in all, this is not an unattractive packet, although very pricey, as a basic system starts at $40,000, and according to Sun, a more realistic implementation would go for $100,000.

One More Word on SATAN

Ironically, SATAN, the much discussed security checking system, proved to be a security risk in itself. If you are using SATAN, you are advised to use the latest version, currently version 1.1.1.

And now to this month's questions.

 Q We have a number of servers which I would like our users to be able to access in a round-robin manner. Is this supported in BIND?

 A It is not (yet) supported in the standard version of BIND (Berkeley Internet Domain -- the UNIX implementation of the nameserver). However, this feature has been discussed for some time, and there is at least one BIND code patch floating around the Internet that implements it. However, if you are not a regular BIND hacker, you will have to be a bit patient, as modifying BIND is not for the weak of heart. The sooner Paul Vixie (the current main BIND architect) gets around to including this feature, the better for the rest of us.

 Q We are about to install News on our site. As I never have done this before, I have two questions: how difficult is it to do, and which News software should we use?

 A Another question where the answer is: It depends. There are two main packages currently used as News transfer agents. Which one to choose depends on the local circumstances. C-News, written by Geoff Collyer and Henry Spencer, which is the older of the two (the name is chosen for historical reasons; C-News was a successor to the older B-News transfer agent), was originally written using UUCP as the underlying transfer mechanism, although it can use NNTP when the separate nntp package is added (nntp is just one implementation of the NNTP [Network News Transfer Protocol]). This package is still a good choice for smaller News sites -- that is, sites which do not receive a full news feed -- whether UUCP or NNTP is used as the underlying transfer mechanism. Larger Internet sites will probably want to use the newer INN (Internet Network News), written by Rich Salz. INN is a faster and more efficient implementation than C-News, at the cost of being a memory hog. However, this tradeoff enables INN to keep up with the heavy traffic load in today's News servers.

For smaller sites, there is a third alternative to be considered. If you have a reasonable amount of network bandwidth, but not many users who read News, then you should consider reading News from another site. You can do this by providing your users with a News reader which uses NNTP to read News, rather than depending on local files. If this works for you, you do not need to install and maintain a News agent. Many Internet service providers can provide you with this service, or you may get permission to read News from a large site in your area (but choose somebody using the same provider; you get higher performance that way).

 Q I am relatively new to System V, and am trying to get an overview of the RC files used by that system. The number involved makes it difficult for me to understand as well as I would like.

 A The System V release 4 implementation of RC files is a great example of a good idea taken far beyond a reasonable scope. Unfortunately, that seems to be typical for that flavor of UNIX. These files are an example of the linked files from Hell. Before you start looking at the content of the files, you will need to figure out which files are linked together. As hard links are used, you will need to sort them out according to their inode numbers. The files that have the same inode numbers are really a single file which appears to be in more than one place. When you have done this, you will end up with many fewer files, and you only have to read one version of each set of linked files. It is still messy, but at least you have a chance to figure out what the system does at boot time.

 Q Perl 5 has been out for some time now. Should I upgrade?

 A That would probably be a very good idea. Perl 5 appears to be almost perfectly backwards compatible with perl 4. In addition, the interpreter is faster, and there are a number of nice extensions to the language. I especially appreciate the better facility for data structures and pointers, which opens the language up to "real" programming.

 Q We are connected to the rest of the world by UUCP. A few weeks ago, we suddenly started having problems receiving files, although we had made no changes to the UUCP configuration, and our UUCP feed claims that they had not made any changes either. What could be wrong?

 A I think both of you should check your modems, and ensure that modem flow control is enabled. If you are using fast modems, which almost everyone does these days, make sure that you are using hardware flow control, as software flow control might not be fast enough, particularly if the machine the modem is connected to is slow or heavily loaded.

If a UUCP file transfer starts up, runs for a while, and then for some mysterious reason stops or gets very slow, you can almost always place a safe bet that it is a modem problem. In fact, I do not remember ever having seen this problem not be caused by misconfigured modems.

 Q Where can I find the newest version of the UNIX Name Server?

 A You can get it by anonymous ftp from ftp.vix.com/pub/bind/testing (or in URL speak ftp://ftp.vix.com/pub/bind/testing). This version is semi-public and primarily intended for testing purposes; however, it appears to be fairly stable.

The last version that has been officially fully released is available from ftp.uu.net, in the directory /networking/ip/dns/bind.

 Q I'm a subscriber to Sys Admin magazine, and I've been downloading code listings via UUNET's 900 number. Unfortunately, UUNET has cancelled that service. The people at Sys Admin suggested I email you and ask if the ftp site you're setting up will allow ftp via email (I have a uucp Internet connection through holonet). TIA.

 A I have no immediate plans for adding ftp via e-mail for the sysadmin ftp archive, as I want the archive to become more complete before venturing out into other projects. In the meantime, you can ftp by mail, using the service from decwrl. Send email to ftpmail@decwrl.dec.com, with the necessary ftp commands in the mail body.

 Q I am having a problem uncompressing may95.tar.Z. I downloaded the file from ftp.sysadmin.com to my PC, then used binary ftp to transfer it to our UNIX workstation. When I do an "uncompress" or "compress -d may95.tar," I get an error message "file not in compressed format." When I look at the file it sure looks compressed. Nothing is recognizable. Any suggestions?

 A Most of the files on ftp.sysadmin.com are compressed with the gzip program. You can recognize which compression algorithm has been used by looking at the extension of the file. A ".Z" extension used the older, and less efficient, compress program, while files with a ".gz" extension have been compressed by the much more efficient gzip program. You can find the source for both programs in the compress directory. Also, I have changed the files with Sys Admin content to no longer be compressed.

 Q I work as a system administrator, supporting our IBM RS/6000 line of workstations running AIX. Recently, I was posed an interesting and seemingly impossible question by one of our clients. The site where they are working has a large number of user accounts on one machine. This site is a hospital, and when a report or memo is typed up and saved on this machine, at best it is meant to be read only by people in their group. To enforce this security, my client has set up each department within the hospital in its own group on the RS/6000.

Unfortunately, this has led to a problem. From what we can determine, NIS will ignore anything past the 512th character in the file /etc/groups. This is not good since many of these groups have large numbers of users.

My question is this: Is there a third-party application that we can run that allows for more users in a group?

 A I don't like NIS, in part for basic design considerations, but especially for reasons of security. I therefore avoid using NIS whenever I have the chance to do so, and it seems ironic that your client is basing security on a piece of software that can be broken so easily.

You might be able to solve your problem by not using the NIS maps for the /etc/group file. Instead, start distributing this information using rdist (get the new version from the University of Southern California). This will also remove one security hole (more or less -- NIS will leave another open). However, because you are not only using NIS, but also AIX, you might have a worse problem, because SMIT, the AIX system administration tool, makes such solutions very difficult to work out in practice. You might also check to see if your vendor is planning to migrate to NIS+, which fixes many of the problems identified in NIS.

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.