User Administration

All of the Linux distributions come with facilities for automating the process of adding, modifying and removing users. All include shell scripts or programs such as adduser, useradd, usermod and userdel. Some distributions, notably Caldera and Red Hat, come with additional programs to do the job. Caldera uses its LISA program to handle adding and deleting users. Red Hat's usercfg, for use in a graphical (X11) environment, not only handles user additions and deletions, but also helps manage groups.

All accomplish certain basic chores beyond just adding a line to the /etc/passwd file and appropriate entries to the /etc/group file. Given the sensitivity of the /etc/passwd file and the consequences of corrupting this file, that alone would warrant its use. A system no one (not even root) can log into isn't much use. In fact, if you do edit /etc/passwd with an editor, you shouldn't keep it open long. This file is accessed by numerous programs for login and authentication purposes, and holding this file open (especially if another user decides to change his password) could cause system instability.

All these scripts and programs prompt you through the information needed to create the new account. If you need to add or delete group accounts, the groupadd and groupdel (delgroup, addgroup, groupmod, etc.) programs can be found on most systems to accomplish this task.

The use of Network Information Services (NIS), formerly known as the Yellow Pages (a trademark of British Telecom) and still carrying the “yp” prefix on the programs, will necessarily change some of the procedures I've discussed, but the basics remain the same. NIS is used at larger sites to ease the administrative burden of pushing changes to each machine. But accounts still need to be set up. NIS just centralizes and distributes files from the master server instead of changing files on each machine individually. If you do work at a large site that uses NIS, you'll still have some normal accounts set up on each machine for those times when maintenance requirements dictate bringing the machine up in single user or non-networked modes.

Since I've been mentioning security from the beginning of this article, I thought I would mention a few programs to help you maintain security on your system.

The first program, npasswd (no relation to the file created by reversing the shadow password conversion), does some sanity checking when users change their password. This program is used in place of the regular passwd program by renaming the passwd binary (/usr/bin/passwd not /etc/passwd) to something like passwd.orig and creating a link to npasswd from passwd.

Another program you may be interested in is pwgen. This program generates random passwords containing mixed upper and lower case characters, numbers and legal (for a password) punctuation. Personally, I find these passwords too difficult to remember, and since writing them down is a security no-no, I devise my own (hopefully) secure passwords.

I mention the pwdutils package only for those using NIS. This package contains NIS compatible programs. Those contemplating using NIS or shadow files need to ensure that the programs they use for system administration (particularly user administration) work with NIS or the shadow suite. Above all, before you begin installing either NIS or the shadow suite, RTFM—read the fine manual (and keep an emergency boot disk handy).

Among the myriad things you can do that will make your life easier as a systems administrator is to maintain certain files and subdirectories. One such subdirectory that is often overlooked is /etc/skel. This subdirectory is the skeleton used by all (that I'm aware of) scripts and programs to create the new user's $HOME directory. You've seen how administration programs add users to /etc/passwd. You've noticed that at the same time a /home/$USER subdirectory is created with proper permissions and a few common files, such as .bashrc, .cshrc, etc. All this is done by copying /etc/skel with all its files and subdirectories to the user's new home directory and changing the ownership (chown) to the new user. Use the /etc/skel directory to keep all the files you wish new users to have—maybe a default .fvwmrc for their X sessions or some changes to their .bashrc files. Then the new user will be ready to start working as soon as you've run the adduser program.

If you view some of the programs I've discussed, you'll note some are binaries and some are scripts. I prefer to use a modified adduser script in which I have included a couple of lines for something I occasionally forget. My Caldera boxes run a modified fvwm (from LST) that writes to the file /var/run/xlaunch/$USER/background-:0.0. While not a fatal error if the directory doesn't exist, I don't like to see error messages scrolling through my console box. So, my modified script includes two lines to create this subdirectory and then touch the file name. You can modify your scripts in a similar manner.