Questions and Answers
Bjorn Satdeva
I have received many emails related to my comments regarding policies (Sys Admin 6(4):63-65). Several people asked what it takes to write and implement good policies. Unfortunately, there is no simple answer to this question. A policy is part of the documentation at your site that shows "how we do business here." Both policies and procedures should consist of individualized documents tailored to your site. When I start to work with a client site on these topics, there is one thing I always stress: all sites already have policies and procedures. The problem is that they are not documented; or in some cases, part of it might be documented, but it might not be up to date or well distributed. The biggest problems in such situations is that either people know that policies and procedures exist, but they do not agree on what they are, or the policies do not exist and must be created from scratch. System administrators do not typically have the clout to create and implement policies. This requires the involvement of upper management, who will need to provide some overall vision. If you are working at a place that does not have policies and procedures, you might be better off starting closer to home and document the procedures just for yourself and your staff. For example, document how you are doing backup, where and how tapes are stored, and how restores are done. Start with how you are doing it today. It is tempting to write a procedure that describes how you would like things to be done, but this is not useful, unless you immediately start doing it that way. In fact, unless you describe what you have today, you might never get a real start on this project. When you begin this process, start with something that is easy to document, and then stick with the documentation process until it is completed. Complete one procedure at a time, and make sure that it is usable before continuing on to the next one. As you gain some early victories in this area, you can move on to more challenging projects. It is important that everybody in your group agrees to follow each procedure as it is completed. Not only will everybody start to do the work the same way, they will also start to build a common understanding of how the work should be done at your site. And as you build a body of procedures, you will be able to use this documentation to get your junior admins up to speed in areas where you needed a senior person before. Later, when you have your house in better order, it will be easier to get the high level and more political stuff in place.
ftp://ftp.uu.net ftp://gatekeeper.dec.com ftp://coast.cs.purdue.edu ftp://ftp.win.tue.nl ftp://ftp.net.ohio-state.edu ftp://sunsite.unc.edu ftp://coast.cs.purdue.edu ftp://ciac.llnl.gov
The problem is finding what you need. Each site will normally have a file, typically named ls-lR, which has a listing of all the files on the site. This is helpful if you know what you are looking for. However, it can still be exhaustive to search each archive for what you need. The Web can be a helpful tool, but in spite of the availability of many search engines, it can be difficult to find what you are looking for, unless you can narrow the search by using more complex search instruction. If you know what you are looking for, then try archie, a search tool that predates the World Wide Web, but which still is useful. Archie is a information server, which is able to tell about the content of many of the archive sites accessible through the Internet. It is useful when you are looking for a certain package but do not know which archive site contains it. In the old days, when you wanted to use archie, you did a telnet to a site that ran the archie server. Today, you can access archie from the World Wide Web. A good entry point for archive and other search engines is:
http://www.agrenv.mcgill.ca/SEARCH.HTM
Therefore, let us look at what could go wrong when installing the server and the client on a machine. The server was a simple text-based server, which took its input from the standard input. It is therefore possible to test the server directly by executing it from the shell and verifying that it behaves as expected. When this is verified, install it in the right directory, and verify access permission. Then, if not already done, enter the port and protocol in the /etc/services file. The line should look like this:
server 570/tcp
Then, inetd must know what to do. So, we enter a line in the /etc/inetd.conf file like this:
server stream tcp nowait root /user/bjorn/server server
When this line is added, we need to tell inetd that the configuration has been modified. This is done by sending a hangup signal to the daemon. The hangup signal (SIGHUP or 1) is interpreted by inetd as an instruction to re-read the configuration. If the process number of the inetd is 176, the command will look like this:
kill -1 176 or kill -hup 176
You should now be able to telnet to port 570 to ensure that the server is working and responding correctly:
% telnet mimi 570 Trying 10.1.1.123... Connected to mimi.sysadmin.com. Escape character is '^]'. ...
If you get an access denied message, doublecheck that the path name is correct (e.g., do a cut and paste with your mouse). I do it this way, because I am a lousy typist and can easily mistype a pathname without noticing it. When the server responds, you know it is working correctly. You can then test and install the client. The above troubleshooting method is useful, as you might need to install new servers on your machine, many of which are text based. Examples of text-based servers that you can talk to via telnet as shown above are sendmail (port 25), nntp (port 119), POP (port 110), and daytime (port 13). Although you do not want to use a telnet session to do real work, it is great for troubleshooting. For example if you want to verify that a POP server is functional, you can check it by doing a telnet to the server port on the machine. You should see something like this:
% telnet mimi 110 Trying 10.1.1.123... Connected to mimi.sysadmin.com. Escape character is '^]'. +OK QPOP (version 2.2-krb-IV) at mimi.sysadmin.com starting. quit +OK Pop server at mimi.sysadmin.com signing off. Connection closed by foreign host.
About the AuthorBjorn 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.
|
I recently compiled a pop3 mail server on our DG-UX server. I then discovered a "new" problem - supplying the users with an address book of email addresses and groups. I started to do research and found LDAP. I'm trying to compile the University of Michigan LDAP 3.3, but I've run into some problems with compiling and am trying to locate resources on the Net. Can you help me find some useful UNIX sites?
I maintain an ftp server: ftp://ftp.sysadmin.com, which has a lot of system administration-oriented stuff. There are a number of other good archives out there, too many to mention them all. Here is a small list: