Cover V04, I02
Figure 1
Figure 2
Figure 3
Figure 4
Listing 1


Creating New Users with perl

Russ Hill

Why use a script to create new user accounts? Most sites would probably rather edit the password file directly to create a new user, and then make the home directory manually. However, I often noticed that this approach can lead to problems such as not completing the job, forgetting critical steps, and creating users different ways. Many small sites never document how to create a user.

A simple "make user" script can fix all of these problems. I wrote mkuser to prevent mistakes in adding users, to create users exactly the same way, and to save time. The script itself provides a primitive form of self-documention, showing a way to create a user. Documentation does not need to change because the user interface never needs to change.

With a simple command interface, operators can answer the questions and create a user correctly. It's not necessary to change the user interface if you make minor changes within the script to add extra tasks. mkuser lets you incorporate changes without adding steps for an operator or redocumenting the process of creating a user.

Different Tools

Most UNIX systems have system administration tools to help create and maintain user accounts and groups -- AIX has smit and SVR4 has sysadm; some SVR4 systems have useradd, usermod, and userdel; useradd is similar to adduser on ULTRIX. Other systems, such as Domain/OS, have entirely different ways of adding users. Some SVR4 systems have groupadd, groupdel, and groupmod for modifying the /etc/group file. Although all of these tools provide either a menu or a command-line interface, none make it particularly easy to automate user and group administration.

It's true that useradd can be done in one line. However, you must give it a uid and a gid, which means you have to write a shell script wrapper around useradd to find the next available unused uid. Large sites will probably have pockets of different systems, each with their own way of adding a user.

The mkuser Script

I wrote a perl script called mkuser (Listing 1) and have used it on a few flavors of UNIX to solve user administration problems. It's fast and easily portable. There are, of course, a few site dependencies, but this script can be used for many different sites with only minor changes.

I originally developed mkuser on SVR4 NCR 2.02 UNIX with the useradd command as the final execution. I later changed it to modify the /etc/passwd and /etc/shadow files directly because useradd is too OS dependent. I then used the script on AT&T Starservers and on SunOS and ULTRIX. The input into the script seems generic enough. I looked back at a shell script I had written to add a user to Apollo Domain/OS systems. I found it was easy to use mkuser on the Apollo. I did have to make a number of changes in the final stage of the script, but neither the script interface nor the password generator changed.

I've also used mkuser to create users from a cron shell script. I took tables dumped from an Informix database, ran them through awk, and sent them to mkuser to create the users. The entire task was completely automated.

Why perl?

Besides being a very easy language to learn, perl bridges the gap between C and shell programming. It provides the best of both worlds, especially for many system administration tasks, and some operating systems now ship perl as a standard part of UNIX.

To run mkuser, you must port perl to your system. perl is easily available, free, and quickly portable to all types of UNIX systems (see Figure 1 for an example session).

mkuser is exactly the type of project that perl was written to handle. If I had used shell, I would have needed an extra C program to encrypt the password. That would mean three files: the script, the C source, and the executable C program. Having everything in one file makes maintenance much easier.

Modifying the Script

You can use mkuser with or without command-line arguments. Of course, you'll need to modify it for your site, but these changes should be minimal.

A new user's default shell directory on some SVR4 systems comes from /etc/skel. This directory contains the default dot (.) files as well as other directories that you want included in a new user's setup, such as startup scripts in special csh and ksh directories. mkuser will copy everything in the default directory tree to the new user's home directory. You should change the script to use a default directory for the new users and point the $defaultcshdef or the $defaultkshdef to those locations. I made mkuser shell-dependent since you will want different dot files depending on the type of shell you plan to run. You may wish to add other shell defaults, such as bash or tcsh.

For your default ksh directory, you will probably include .kshrc, .profile, .Xdefaults, .mwmrc, and possibly bin, src, and tmp directories. For your default csh directory, you will probably want .Xdefaults, .cshrc, .login, .logout, .openwin-init, .openwin-menu, and possibly bin and tmp directories. There may be other files and directories you wish to add as well.

Other script defaults to set include the group default, which names the group with the most users, and the default home directory, where most of the users will reside.

Aspects of mkuser

Because many sites use the login as the password and users never change their password, I added a password generator for security reasons. At most sites, I can crack 50 percent of the passwords (crack is a password checker that can be used regularly to notify users when their passwords were cracked; see Figure 2 for an example session of obtaining and porting crack). The generator makes English-like words that are not really words. However, users need to be educated about what passwords are best (see Figure 3 for two password selection methods).

I used crypt in the script instead of calling passwd. passwd is tied to the tty. Shelling out to execute passwd makes the operator type the user's password by hand twice. By encrypting the password and just putting it into the new user's password field, I have automated the script's password section.

Other tasks that mkuser could automate include adding the user to a phone list and making a mail alias.

Using mkuser

Figure 4 lists mkuser's command-line arguments. All are optional. Running mkuser without arguments, as

# /usr/local/bin/mkuser

causes it to ask all questions for creating a new user. However, you can also give it all the user's information on the command line:

# /usr/local/bin/mkuser joe smith jsmith jsmith next workgroup home/bin/csh

This creates a user named "Joe Smith," which goes in the GECOS field. The user's login name is set to jsmith and his home directory will have that same name. This is because the logname (third argument) and username (fourth argument) are identical. mkuser sets jsmith's UID to the next available, sets his group to workgroup, sets his home directory tree to home, and specifies that the account will run csh at login. Because no password argument was given after the login shell argument,the login name, jsmith, becomes the password.

Another example

# /usr/local/bin/mkuser tom thibodeaux tthibode tthibodeaux next gen home /bin/ksh

differs from the previous one primarily by using a logname ("tthibode") that doesn't correspond with the username ("tthibodeaux"). In this case, the home directory name, which is based on the username argument, will be /home/tthibodeaux. The other arguments are similar, except that this user will belong to the gen group and use ksh. Again, the logname becomes the user's first password.

Another example

# /usr/local/bin/mkuser tom thibodeaux tthibode \
tthibodeaux next gen home /bin/ksh o,iltay

adds an explicit password ("o,iltay") to the arguments shown in the previous example.

Perl References

Schwartz, Randal L. Learning Perl (aka "The Llama Book"). Sebastopol, CA: O'Reilly & Associates, ISBN 1-56592-042-2.

Wall, Larry, and Randal L. Schwartz. Programming Perl (aka "The Camel Book"). Sebastopol, CA: O'Reilly & Associates, ISBN 0-937175-61-1.

Perl FAQ.

About the Author

Russ Hill is a University of Florida Gator with a degree in Computer Engineering. He works as a UNIX Analyst in Dallas, TX for Paranet. His earlier article, "How to Login to Any UNIX System and Get Your Email," appeared in the Sept/Oct 1993 of Sys Admin.