Questions and Answers
In June of 1997, for the first time ever, a DES-encrypted message was broken. DES (Data Encryption Standard) is an encryption block cipher defined and endorsed by the US government in 1977 as an official standard. DES had been considered unbreakable, and is used by banks and commercial companies worldwide for the encryption of vulnerable data. The June break resulted from a secret-key challenge issued by RSA Data Security at a security conference in January of this year. RSA offered a $10,000 prize to anyone who could successfully attack DES, and on June 17, they found their winner.
The data was decoded through a brute force attack engineered by Rocke Verser of Loveland, CO (in a brute force attack, all available CPU power is used to keep trying possible keys: where it succeeds, it succeeds by sheer force of effort). Verser created a cracking program that could be distributed and downloaded over the Internet and ultimately enlisted thousands of volunteer computers in the project, code-named DESCHALL. For each new machine, the DESCHALL team created new portions of the DES key space to test, meanwhile eliminating keys that did not work. The DESCHALL effort solved the DES challenge after searching only 24.6 percent of the key space.
The software developed by Rocke Verser cannot be exported outside the US and Canada, but a similar effort in Sweden has the potential for making this type of software available worldwide. For more information on the DES code breakage see:
In Australia, the Senate Committee on Community Standards is expected to release a report recommending that material rated legal for adults in other media be banned from transmission via the Internet. In effect, the report seeks a G-rated Internet, with fines of $100,000 for non-compliance.
Such reports have the double effect of causing both amusement and discomfort, if not outright fear. The amusing part is the politicians' attempt to assert local control over an entity that is, for all practical purposes, global. In this particular case, it was Australian politicians, but the Australians have no monopoly here: we've seen similar attempts to control the Internet from countries all over the world. The politicians may win in the short term, but in the long term I would bet on the Internet to redefine politics - and probably not a bad thing at that.
The discomforting part arises when I consider who might be held responsible when laws like this are broken. In particular, to what degree will system administrators be held responsible for any breach of such laws? There is no way for us to be fully knowledgeable about the kinds of information stored on our servers. Not only is there too much information to allow for comprehensive oversight, but to try to extend such oversight would probably violate a number of privacy laws. Clear policies could help, but few organizations have such policies. Further, even if we are not legally liable for such material, will our jobs be on the line if the organization we work for is indicted for violating such a law? With so few facts and no practical experience, there's room for an awful lot of speculation here.
I am a recent graduate of the Computer Learning Center, where for several months I've been involved with UNIX. I really like this OS and would like to know how I can become a certified UNIX system administrator. Does California offer certification of UNIX?
A number of u niversities offer courses in system administration topics, as do a number of private entities, but there is no standard industry-wide or nationwide certification program. In practice, system administration is still generally taught through the apprentice system. From my perspective, the best education available seems still to be the courses taught at the SANS, LISA, and USENIX conferences, as these classes are predominantly taught by practicing system administrators. I find this approach far preferable to courses taught by people who have never done real system administration.
There are also many excellent books available. Virtually all of the O'Reilly & Associates UNIX administration books are first-rate. The basic text in UNIX system administration is Evi Nemeth's UNIX System Administration Handbook (published by Specialized Systems Consultants; ISBN: 0131510517), which gives an overview of the task of administering a network of UNIX systems. Start with the Nemeth book, then fill in with books from O'Reilly on the topics where you need more details.
Finally, you will need a place to work and experiment. With only a few months of experience, you probably won't be able to find a job as full-blown system administrator, but if you're lucky, you may wind up with one of the companies that still grow their own system administrators, through an apprentice system. If you are attending a university or college, another possibility is to apply to become a student helper for the system administration group.
When it comes to landing a real job as a system administrator, working experience is still more important than degrees and certification. For more information, check out the SAGE publication Job Descriptions for Sys Admins. You can find it at
or order it from the USENIX office. This publication lists job descriptions for various levels of system administrators, and also outlines the kind of experience needed for each level.
Whichever way you choose, make sure to hang in there. Remember that people who are now senior system administrators and who look like they know everything there is to know about UNIX (or any other OS, for the matter) were once where you are today. You can learn from others, or you can do as we did in the old days, and learn from your mistakes. Believe me, the latter is more painful.
This is the best I can offer in answer to your question. The short of it is that there is no generally accepted course of study for learning how to become a system administrator. I would appreciate hearing from any senior system administrator out there who can recommend good system administration courses, that is, courses in which students truly learn how to run reliable systems in a real-world context.
I am the administrator of our company's UNIX system. Using telnet, I get an error I do not understand. The error message is
"telnetd : Could not grant telnet slave pty."
The telnet daemon is using a pseudo-terminal, commonly referred to as a pty. Your device directory should contain a large number of pseudo-terminal device files. The version of telnetd I have access to does not include this specific error message, but the message seems to indicate that you cannot access your pseudo-terminal device files. Make sure that the kernel you use is configured for pty's and that the device files exist and are accessible.
I am trying to add page numbers to my text files, and I can't seem to make pr work with the lp option. According to the man page, I should be able to accomplish this using the command
lp -opr -dnameofprinter filename
but thus far I've had no luck. Can you help?
The command you cite should work, but in UNIX there are always other options. First, make sure that the pr program is located where the printer spooler expects to find it. The System V print spooler uses shell scripts for most of its configuration: check the scripts to see whether they actually do what you expect them to do. In most cases, you can execute the scripts directly, and thus ensure that they do what is needed. In testing the scripts, though, be aware of the environment. When you execute the script from your own prompt, you are using your environment, which may be different from the one used by the line printer spooler. Make sure that the script is setting all the necessary environment variables, such as the default search path.
For the moment, you can use a workaround by piping the file you want to print through the pr program before parsing it to the lp command:
pr <options> <filename> | lp -d<printer>
as in, for example,
pr myfile | lp -dlp
I've encountered a problem in trying to configure my SINIX DNS, on a server using Siemens RM300 sinix. I find that my server can't ping itself, but since the PC connected to the server can ping the domain, the server's named must have executed. I think there must be some problem on the server's client program, but I don't know how to find or fix it. At this point, I have reinstalled the sinix operating system four times, so will be very glad if you can give me some advice.
I am not familiar with the Siemens system, but I suggest that you try to examine the resolver configuration (normally in /etc/resolv.conf). It should point back to itself in this form
where the IP number must be that of the server. Standard behavior for a name server is to use the local machine if there is no resolver configuration file. It may also be that the Siemens version of UNIX has a configuration file that determines how the name service lookup is performed (e.g., through the hostfile, /etc/hosts, the name server, or some other type of directory service, such as NIS, NIS+, or any combination thereof).
On a related topic, you should aim to have at least two name servers on your network: one primary and at least one secondary. Otherwise, you will have a reliability problem if your name server dies, either from a name server problem or because the machine it is running on has shut down or crashed.
For a detailed and clear explanation of these issues, consult the O'Reilly & Associates book DNS and BIND, by Paul Albitz and Cricket Liu.
Hi, Bjorn. I am a Sys Admin subscriber, and I am having a big problem with our UNIX file server. When trying to create, delete, or change a file, I get this message: "Cannot create the specified file." The first time this happened, I shut the computer down, and then could not get back in. Finally, I restored from a tape (mksysb), but now the same problem is occurring. I also dismounted the /home f/s, and now I can't remount it. I get the same message: "Cannot create the specified file," along with another message, "There is an input or output error." Do you have any suggestions?
I can't diagnose your problem from the information you've given me. However, I can suggest several things to look for that should help you to isolate the problem.
I am assuming that you are performing changes as root and from the console. If not, try it that way. Make sure /dev/tty exists and has reasonable permissions (use 777 while troubleshooting, if in doubt - remember to set it back afterwards, though).
Look in the various logfiles for possible problems, including disk read/write errors. Check to see whether file and directory permissions look reasonable. A failing disk controller can change permission bits and file types randomly, making it look as though normal files had been changed into device files. Run fsck on all file systems at least twice and make sure that all systems come up clean both times. The reason for doing this twice is in case you have reconfigured the hard disk and have somehow managed to create overlapping partitions.
Check to see if the system behaves in a normal manner when booted into single-user mode, or, as some vendors call it, diagnostic mode. Most of the network operations will not work in single-user mode, as the various daemons will not yet have been started, but all basic diagnostics can and should be performed in that mode.
In general, look for anything that seems out of place. Track any changes you make and undo them as soon as possible to avoid the nightmare of a massive cleanup afterwards. Keep a log of all changes (on paper, not online; you cannot read an online file on a dead system), and double-check that all changes that did not have a positive effect have been undone. As a golden rule, be conservative about making changes to a broken system: if you do not understand the part of the system you are working on and don't really know what to expect from your changes, you are more likely to break the system further than to fix the original problem. In such circumstances, even if you do somehow manage to fix the original problem, you will still have a broken system, it will just be broken in a different way.
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 firstname.lastname@example.org; or by phone at (408) 241-3111.