In this article we are going to look at account management. The tasks covered in this article are adding, deleting and modifying user accounts from the command line. We will also look at creating and managing groups from the command line.
Home directory skeleton
In this section of the article we will look at specifying the contents which are placed into the newly created users home directory. If you have ever created a new user in SUSE Linux Enterprise Server 10 SP1 you might have noticed that certain files are placed into the users home directory as listed in Table 1.
||This file contains a list of previous typed bash commands.
||This directory is created so users can store their documents within this directory making it easier to find their documents.
||This directory is used to store HTML content. When the Apache web server has been enabled and has the UserDir option enabled this directory is published on the Internet.
||This file is for the emacs editor.
Table 1: Directories and files created by default.
As you can see in Table 1 there are some files that are created that do not need to be there for example, the public_html directory is not needed unless you are going to be running the Apache web server. The file .emacs is also only needed if your going to be using the emacs text editor.
The directory that holds these files is called: 'skel' and is located within the /etc directory. When new users are created, the contents of the 'skel' directory are copied into the users home directory with the appropriate permissions applied. In this article we will remove the public_html directory and the .emacs file so that, when new users are created these objects will not be copied into their home directory. Figure 2.1 shows the objects being deleted.
server1:~ # rm /etc/skel/public_html/
server1:~ # rm /etc/skel/.emacs
Figure 2.1: Removing the two objects within the skel directory.
In this section of the article we will look at creating users from the command line using the useradd command. The useradd command allows you to add users and specify certain criteria such as: comments, the users home directory, shell type and many others account properties.
The first user we will add is called: 'damian' and we will give him a shell type of bash. Figure 3.1 shows the command used to create the user 'damian' and Table 2 explains what each qualifier is used for.
server1:~ # useradd -m -c "Damian Myerscough" -s /bin/bash damian
Figure 2.2: Creating the user 'damian'.
||This qualifier makes the useradd command create the users home directory.
|-c "Damian Myerscough"
||This qualifier specifies a comment about the user, in this example we just specified the users whole name.
||This qualifier specifies which shell the user should use.
||The final qualifier is the username of the user.
Table 2: Figure 3.1 explained.
Once you have successfully created the user 'damian' you may have noticed that we did not set a password for this user, thus denying the user access to the box until he or she has a password set. To set a users password you can use the passwd command as shown in Figure 3.2.
server1:~ # passwd damian
Changing password for damian.
Reenter New Password:
Figure 3.2: Setting a password for the user 'damian'.
Once the password has been set the user should be able to successfully login to the workstation/server.
The next user that we will create is called: 'chisa'. We will set her home directory to /srv/www, set her shell type to /bin/false and also set her account to expire on the 28th June 2008. Figure 3.3 shows the command used to create this user and Table 3 explains what each qualifier does.
server1:~ # useradd -d /srv/www -c "Chisa Hasegawa" -s /bin/false -e 2008-06-28 chisa
Figure 3.3: Creating the user 'chisa'.
||This qualifier sets the users home directory to /srv/www.
|-c "Chisa Hasegawa"
||This qualifier sets a comment for the user chisa, the comment here is the users full name.
||This qualifier sets the users shell type, here we set the type to /bin/false which stops the user logging in.
||This qualifier specifies the date in which the account will expire, in this example it expires on the 28th June 2008.
||This last qualifier is the users username.
Table 3: Figure 3.3 explained.
Once the user has been successfully created you can issue the passwd command to set the users password as shown in Figure 3.2.
Once you have added the two users you can view their details within the passwd file located within the /etc directory, you can use the tail command to see the last two users added as shown in Figure 3.4. Table 4 explains what each field represents.
server1:~ # tail -n 2 /etc/passwd
Figure 3.4: /etc/passwd file contents.
||This field specifies the username of the user.
||This field specifies the password, the 'x' means the password is encrypted and stored within the /etc/shadow file.
||This field specifies the users ID.
||This field specifies the users group ID.
||This field specifies the comments associated with the account.
||This field specifies the users home directory.
||This field specifies the users shell type.
Table 4: /etc/passwd file format.
In this section of the article we will look at manipulating the two users we created previously. The command we will be using to manipulate the user accounts is usermod. This command allows you to change any of the account properties that we previously set.
The first user that we will modify is 'chisa', her current shell type is /bin/false which will stop her from logging into the workstation/server. We will also change her account expiry date to the 20th June 2008. Figure 4.1 shows the command used to modify this user.
server1:~ # usermod -m -s /bin/bash -e 2008-06-20 -d /home/chisa chisa
Figure 4.1: Modifying the user 'chisa'.
Once you have modified the user 'chisa' you can view the passwd file and you should be able to see the user now has the shell type of /bin/bash and with a new home directory as shown in Figure 4.2.
server1:~ # grep -i chisa /etc/passwd
Figure 4.2: Checking the changed effects.
As you can see from Figure 4.2 the users shell type has been modified and the users home directory now points to /home/chisa.
The second account that we will modify is the user 'damian'. We will modify this account so that the account will expire and will also set a constraint which will disable the account after the account has expired. Figure 4.3 shows the command used to modify these options and Table 5 explains what each qualifier is used for.
server1:~ # usermod -e 2008-06-28 -f 1 damian
Figure 4.3: Modifying the user 'damian' account.
||This qualifier sets an expiry date for the user 'damian'.
||This qualifier sets how many days to wait after the account has expired before the account is disabled. In this example the account will be locked one day after the account has been expired.
||The final qualifier is username of the user you are modifying.
Table 5: Figure 4.3 explained.
In this section of the article we will look at deleting the user 'damian'. The command to delete users is userdel which can be specified with the -r qualifier which will remove their home directory and mail spool.
In this article we will remove the user 'damian' from the system and also his home directory and mail spool. Figure 5.1 shows the command used to remove the user 'damian'.
server1:~ # userdel -r damian
no crontab for damian
Figure 5.1: Removing the user 'damian'.
Once you have issued the userdel command, you will notice that the /home/damian directory has been removed. If you only want to delete the user but leave their home directory intact, you can issue the same command but without the -r qualifier.
In this section of the article we will look at creating groups. The command we will use to create a group is groupadd. In this article we will create a group called: "secure" and assign the user 'chisa' to the group. You may be wondering why you would want to create groups and the reason for this is that it makes managing a large number of users easier. Consider the example where there are ten users working on the same project and you want to ensure only those ten users have access to the project files. This can be achieved by using groups. Using groups enables the administrator to apply constraints to resources for example, one group may allow users to read the contents of a file whereas another group may have permission to edit the articles.
The first example we are going to do is create a group called: 'secure' as shown in Figure 6.1. Figure 6.2 shows the command used to assign a user to this group.
server1:~ # groupadd secure
Figure 6.1: Creating the group 'secure'.
server1:~ # groupmod -A chisa secure
Figure 6.2: Assigning the user 'chisa' to the 'secure' group.
Once you have assigned the user 'chisa' to the 'secure' group you can issue the groups command to see if the user 'chisa' was successfully added to the group.
server1:~ # groups chisa
chisa : users dialout video secure
Figure 6.3: Checking groups users are assigned to.
Now that you have successfully created a group, you may assign users to the group, remove users from the group or rename the group; this can be done by using the groupmod command.
The first task which we will perform is removing the users 'chisa' from the 'secure' group, Figure 7.1 shows the command used to perform this action.
server1:~ # groupmod -R chisa secure
server1:~ # groups chisa
chisa : users dialout video
Figure 7.1: Removing the user 'chisa' from the 'secure' group.
As you can see from Figure 7.1 the user 'chisa' was remove from the 'secure' group, to reassign the user 'chisa' to the 'secure' group you can issue the groupmod followed by the -A qualifier as shown in Figure 7.2.
server1:~ # groupmod -A chisa secure
server1:~ # groups chisa
chisa : users dialout video secure
Figure 7.2: Assigning the user 'chisa' to the 'secure' group.
As you can see from Figure 7.2 the user 'chisa' has successfully been added to the 'secure' group. Now that you know how to assign and remove users from groups I will demonstrate how it is possible to rename groups with the -n qualifier as shown in Figure 7.3.
server1:~ # groupmod -n nonsecure secure
Figure 7.3: Renaming the 'secure' group to 'nonsecure'.
Once you have done this all the users that were in the 'secure' group will be placed into the 'nonsecure' group.
Once you know how to create and manipulate groups you can now start to assign passwords to the groups. You maybe wondering why you would want to set a password on a group. The answer is simple, it makes administrators lives easier. For example, you may have a group of users that are working on some documents and every two days more users start to work on the group, it would be a pain if the administrator had to keep adding the users to the group, with a password protected group you can give the manager the password and he can allow new users to join the group without constantly bothering the system administrator to add new users to the group. In this article we will set a password for the 'nonsecure' group, this can be done simply by issuing the gpasswd command followed by the name of the group as shown in Figure 8.1.
server1:~ # gpasswd nonsecure
Changing the password for group nonsecure.
Re-enter new password:
Figure 8.1: Creating a password for the 'nonsecure' group.
Once you have created the passworded group you can allow other users to join this group by giving the user the group password, the command used to join the group is newgrp as shown in Figure 8.2.
uid=1003(jason) gid=100(users) groups=16(dialout),33(video),100(users)
jason@server1:~> newgrp nonsecure
uid=1003(jason) gid=1000(nonsecure) groups=16(dialout),33(video),100(users),1000(nonsecure)
Figure 8.2: Allowing the user 'jason' to join the 'nonsecure' group.
The passworded groups are very useful for multiple users working on a system that need access to certain resources which can be granted with the group ID (GID).
The final step in managing groups is deleting groups. The deletion of groups is very similar to deleting users the command used to delete groups is groupdel, Figure 9.1 shows the command removing the 'nonsecure' group.
server1:~ # groupdel nonsecure
Figure 9.1: Removing the 'nonsecure' group.
In this article you should now have a basic understanding of managing users and groups from the command line. I would also strongly recommend you read the manual page for the login.defs file which defines the site-specific configuration for the shadow login suite.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.