Newusers is a tool that you can use for fast and furious setup of accounts on a Linux server, but you need to know how it works before you put it into use. First, what is it? Newusers is a tool that you'll find on Linux systems that takes a file that looks more or less like the /etc/passwd file -- actually it's like the passwd file before it was separated into /etc/passwd and /etc/shadow -- and uses the information in that file to create accounts on your server. The basic format of a passwd file looks like this. The "gecos" field is generally the user's full name, but sometimes contains other information such as their telephone extension or business unit might be included as well. It's an odd name, but it goes back a long way!
So, the first field in the colon-separated data file is, of course, the username. If the username is the same as that of an existing user, the newusers command is going to take the entries in that line as representing changes that you want to make to that user's account. It will process changes for a user's:
- gecos information
- home directory
The tool notably doesn't add startup files like .bash_profile to the accounts that it creates and it doesn't pay attention if you change group assignments or UIDs for existing accounts. So don't depend on it for those kind of changes. In addition, the newusers command only create groups for new users. The GID field can either be a numeric group ID (i.e., normal format) or it can be a group name. If it's a group name and the group doesn't exist in /etc/group, the tool will add that group (again, new users only). Don't omit the GID field or you will probably end up with the group being 0 (root's group). Newusers doesn't seem to follow the convention of using the next available UIDs and GIDs if these fields are missing from your user list file. Omitting both UID and GID, you may end up with 10-digit values for both in a test user -- like 4294967295! Passwords will be unencrypted in your user list file, so you should remove your user list file after use or at least encrypt it so as not to create a new risk on your system. There doesn't seem to be any way to tell newusers to create the accounts in a locked state or force the user to change his password on first login. If you use the same initial password for more than one user, the password hashes will be identical. This is only viewable by admins since the hashes are stored in the /etc/shadow file, but it's more than I'd want anyone to see -- that multiple users, even temporarily, have the same passwords. If no password is provided, newusers uses a default hash. Can you migrate an existing passwd file? Yes, absolutely. This would be an easy way to create accounts for people you are moving from another server. But you need to watch out for things like duplicate UIDs (i.e., conflicts with your existing users) as newusers will just happily re-use the UIDs that you provide. And, of course, newusers is going to take the password placeholder "x" as if it's the new password. So you ought to follow up immediately by changing the passwords or locking the accounts. If groups are included in your user list only as GIDs, the group name in /etc/group will be the name of the first user assigned. If there are not enough data fields in your user list files (you need all seven), newusers will fail with an "invalid line" error. The command works real fast, creating the records you need in the /etc/passwd, /etc/shadow, /etc/group files and providing empty home directories, but it won't do everything you might want if your data file isn't complete and it never populates home directories with startup files. Plus it doesn't watch out for errors that you might make creating your user list file (except for omitting fields). So you might want to do a little additional processing to make sure your user list file is clean before you use the tool or build your own script to look for problems or create your accounts with some additional checking.
Read more of Sandra Henry-Stocker's Unix as a Second Language blog and follow the latest IT news at ITworld, Twitter and Facebook.
This article is published as part of the IDG Contributor Network. Want to Join?