Adding Users to FreeBSD

01/03/2001

So far in this series, we've looked at the basics of setting up a FreeBSD system, navigating the system, and understanding some of the internal structures of FreeBSD. In the next few articles, I want to concentrate on basic system administration tasks.

FreeBSD is a multiuser environment; one of the main tasks of a system administrator is to create user accounts and provide a secure environment for users to do their work in. To accomplish this effectively requires some pre-planning before any users are created.

Even if you are the only user on your home-based FreeBSD system, you will still need to create at least one user account to do your regular work in. Remember, you only use the superuser account for tasks that require superuser permissions.

It is a good idea to practice planning like an administrator on your own FreeBSD system, as you will gain the skills that will be essential when you begin to administer in a "real" production environment.

A lot of stuff happens in the background when you create a user: Several databases are updated, a mail folder is created, and a home directory for the user is created. When you create the user, you will have to supply a fair amount of information, including the username and password. In this week's article, I want to concentrate on user policies and creating user accounts.

Every user account you create must have a unique name across your FreeBSD system. This is easy to accomplish in a small environment, but a little harder to manage if you have to create dozens, hundreds, or even thousands of users. To help ensure uniqueness, you should have a user naming policy. If there is no existing policy in place and you need to create a naming scheme, keep in mind that there are a few restrictions on user names. First, they are limited to 16 characters, and some protocols, such as NIS, require a user name limit of 8 characters. Second, they cannot begin with the hyphen character "-". And third, you should avoid the use of capital letters and periods as these may confuse some mail programs.

An example policy in a small environment would be to create user names using the first name and last initial of the user. You might have to modify this slightly to avoid conflicts. For example, if you needed to create accounts for Mike Smith and Mike Spencer, you could create "mikes" and "michaels" or "mikesm" and "mikesp."

Another policy would be to create user names using the last name and first initial of the user, with possible modifications to avoid conflicts. If you need to create accounts for Mark Smith and Michelle Smith, you could create "smithma" and "smithmi."

In a larger environment, you might want to use a certain number of characters for the first name and a certain number of characters for the last name. For example, if the policy is the first four characters of the user's first name followed by the first four characters of their last name, Mark Smith would become "marksmit" and Michelle Smith would become "michsmit." You'll still need a backup plan for users whose first or last ames are shorter than the specified amount of characters. For example, if I needed to create an account for My Lee using the above policy, I could create "my_lee".

Unless you are in an extremely small environment, it's wise to avoid non-descriptive nicknames such as the "biko" and "genisis" that I use on my home system.

To summarize, a good user naming policy is aware of the restrictions placed on usernames and has a contingency method to avoid naming conflicts.

Once you've decided on a naming scheme, you can create the user accounts using the adduser utility. This utility has a configuration file called /etc/adduser.conf, and it also reads a message file called /etc/adduser.message. These files aren't actually created until the first time you use the adduser utility. Follow along as I create a user; I'll use the v or verbose switch so we'll see all the possible prompts. You'll note that adduser will first create its configuration file, then it will use it as a template when creating the user.

adduser -vYou are not root!

Oops. Looks like this is an administrative task that requires root
permissions. Let's try this again (I'll indent my remarks):

suPassword:adduser -v/etc/adduser.conf: No such file or directory

Notice that this is the first time I've run the "adduser" utility on this system; it does not have a configuration file yet.

The script adduser read a file called /etc/shells which contains the paths to all of the shells installed on the system; it then displayed the possible shells available for the user. Note that the default shell offered to users was the Bourne shell (sh), but I changed it to tcsh.

You'll note that a home directory was created for the user and that it contains a lot of files that begin with a period or dot. Remember that dot-file directory mentioned when we used the adduser utility? Let's take a look at it now:

Note that the eight files created in our new user's home directory were copied from the template files contained in this directory. Also note that only the superuser can edit the files contained in the skel directory. For example, if you wished all users to receive a customized shell prompt, the superuser could modify the usr/share/skel/dot.cshrc file which would then be copied to all users' home directories when you created the users. Also, the superuser can also place any other dotfiles he wishes users to receive in the skel directory; for example, you can create a customized .xinitrc file for users.

Now let's take a look at the /etc/adduser.message file that was created by the adduser utility:

You'll note that I was logged on as the user "genisis" before I became the superuser in order to use the adduser command. The message my new user received was the message contained in adduser.message with the actual values for the $fullname and $name variables inserted.

When we created the user, we were given the following option:

Add anything to default message (y/n) [n]:

If I create another user and type in y at this option, I'll receive this prompt:

Use "." or ^D alone on a file to finish your message

Whatever I type will be added to the default message sent to this particular user; however, it will not overwrite the /etc/adduser.message file I originally created. Let's try an example of this; I'll add a user called "test" and show just the output we're concerned with and "snip" the rest:

It looks like only this user received the additional message, as we expected. I want to do one more example before we leave the adduser.message file. Let's say I want users to receive this additional information in their welcoming mail message:

If you have any problems, contact the administrator at admin@thiscompany.com

Try creating a user yourself and add this line to their message; you'll note that when you log in as that user, your additional line will be missing from their mail message. However, if you modify the message so it reads like this:

If you have any problems, contact the administrator at admin\@thiscompany.com

the user will receive the additional information. Notice that we had to escape the @ symbol with a backslash in order for it to be interpreted correctly.

You'll note that this is a straightforward file containing the answers to the questions the adduser utility prompted us for. We'll get into defaultclasses and UIDs next week when we take a closer look at the password databases. The only other new information you'll notice in this file is the location of the logfile for adduser. If I take a quick look at this file, I should see entries for when I created my users:

Next week, we'll take a look at the format of the databases that get updated when you create a user account.

Dru Lavigne
is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.