4. Managing and propagating local accounts

User accounts can be managed in many ways using additional servers such as LDAP or Active Directory. For our purposes, we will, however, restrict ourselves only creating local accounts and propagating these to all machines by synchronizing the passwd, group, shadow, and gshadow files.

These four text files together define all users and group accounts, as well as passwords for all local user accounts.

Manipulating these files manually should be avoided, unless you know what you are doing. Most distributions come with tools which allow you to manipulate these files using commands. Use the command’s manpage to learn about its options.

useradd

Create a new user account

groupadd

Create new group

passwd

Set user password

chage

Lock accounts or set expiration date

usermod

Change user attributes such as group memberships, shell, home directory location

4.1. What happens during user creation?

If you run useradd testuser, a lot of things happen automatically for you.

  1. The group testuser is created

  2. The user testuser is created

  3. The home directory /home/testuser is created

  4. Files from /etc/skel/ are copied into the new home directory

  5. All permissions of the folder and copied files are changed to be owned by the new user and group

You can modify this default behavior by adding options to useradd or editing /etc/default/useradd.

4.2. Creating a new user in a cluster environment

We will first create a local user account for testuser on the master node. To make this user available on all compute nodes we will have to

  1. Synchronize /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow from master to each compute node

  2. Update the autofs configuration so that this user directory is automounted when necessary

As with any repetitive task, this calls for writing a script. By the end of this exercise each group should have a shell script which asks for user details and then creates the user account.

First we need to create the account. Unlike regular users, we want the home directory to be stored not in /home but in /data/home/. Create this folder first.

[root@master ~]# mkdir -p /data/home

You can use the -b option of useradd to specify this different base directory.

[root@master ~]# useradd -b /data/home testuser

Verify that this user has been created using the id command.

[root@master ~]# id testuser
uid=1000(testuser) gid=1000(testuser) groups=1000(testuser)

This shows that testuser was created with user id (uid) 1000. At the same time a new testuser group was created, with group id (gid) 1000. The primary group of this new user is testuser (gid: 1000).

Use the pinky command to look at the information of the user.

[root@master ~]# pinky -l testuser
Login name: testuser                    In real life:
Directory: /data/home/testuser          Shell:  /bin/bash

You can change information, such as the user’s full name using the chfn command (provided by the util-linux-user package, install it if the command is not found) . This can be done interactively or by passing entries as arguments.

[root@master ~]# chfn testuser
Changing finger information for testuser.
Name []: John Smith
Office []:
Office Phone []:
Home Phone []:

Finger information changed.

Finger information may help you to quickly identify an individual on your system if there isn’t an easy mapping between your username and the real name.

[root@master ~]# pinky -l testuser
Login name: testuser                    In real life:  John Smith
Directory: /data/home/testuser          Shell:  /bin/bash

The pinky information also confirms that the testuser home directory is located in /data/home/testuser.

Verify that the contents of this home directory matches with what was defined in /etc/skel:

[root@master ~]# tree /data/home -a
/data/home
└── testuser
    ├── .bash_logout
    ├── .bash_profile
    └── .bashrc

1 directory, 3 files

[root@master ~]# ls -lah /data/home/testuser
total 20K
drwx------ 2 testuser testuser 4.0K Mar  2 18:02 .
drwxr-xr-x 3 root     root     4.0K Mar  2 18:02 ..
-rw-r--r-- 1 testuser testuser   18 Oct 30 13:07 .bash_logout
-rw-r--r-- 1 testuser testuser  193 Oct 30 13:07 .bash_profile
-rw-r--r-- 1 testuser testuser  231 Oct 30 13:07 .bashrc

[root@master ~]# ls -lah /etc/skel/
total 28K
drwxr-xr-x.  2 root root 4.0K Apr 11  2018 .
drwxr-xr-x. 90 root root  12K Mar  2 18:08 ..
-rw-r--r--.  1 root root   18 Oct 30 13:07 .bash_logout
-rw-r--r--.  1 root root  193 Oct 30 13:07 .bash_profile
-rw-r--r--.  1 root root  231 Oct 30 13:07 .bashrc

4.3. Pushing updates to compute nodes

Next we want to make the new user known to the rest of the cluster. For this we will push the necessary files to each compute node.

[root@master ~]# scp /etc/{passwd,shadow,group,gshadow} c01:/etc/

Verify that the testuser user now exists by logging into your compute node and using id or pinky.

Create a push.sh script which does this for you.

4.4. Export the user home directories folder via NFS

Edit your /etc/exports file and add /data/home as rw export.

/data/opt    192.168.16.0/20(rw)
/data/home    192.168.16.0/20(rw)

Don’t forget to update your exports with exportfs.

4.4.1. autofs setup of /data/home

To access a user’s home directory from a compute node we will have to configure autofs to automatically mount it via NFS.

Add the following line to /etc/auto.master to add a new file to the autofs configuration.

/data/home  /etc/auto.home  --timeout=1200

Create the /etc/auto.home file and add an entry for loading the testuser home directory on demand from master.hpc.

testuser -fstype=nfs4,rw,async,ac,nfsvers=4,wsize=8192,rsize=8192,bg,hard master.hpc:/data/home/testuser

Reload the autofs service and try to access /data/home/testuser.

Even if the configuration is correct, you will get a “Permission Denied” error. Try to find out what is going on.

4.4.2. autofs bind mounts

Instead of using an unusual home directory location such as /data/home/testuser, we now want to change the home directory location to be /home/testuser on master and on all compute nodes.

For compute nodes, this only requires changing

/data       /etc/auto.data  --timeout=1200
/data/home  /etc/auto.home  --timeout=1200

to

/data  /etc/auto.data  --timeout=1200
/home  /etc/auto.home  --timeout=1200

in /etc/auto.master and reloading the autofs service.

While we could use the same configuration on master, it doesn’t really make sense to go over a network protocol to access a local directory tree. Instead we can use bind mounts to accomplish the same effect.

Bind mounts allow you to show the same directory in multiple locations. For this to work, we first create an empty auto.master on the master node.

/home  /etc/auto.home  --timeout=1200

Second, create a auto.home with the following content:

testuser -fstype=bind :/data/home/testuser

Reload the autofs service and verify you can access the /home/testuser directory.

Finally, update the user’s home directory location using usermod and push these changes to your compute nodes.

Finally, verify the location of the testuser home directory:

[root@master ~]# cd ~testuser
[root@master ~]# pwd
/home/testuser

4.4.3. Summary:

master and compute nodes have different autofs configurations.

  • On master we use bind mounts to map our home directories to /home, although they are located at /data/home.

  • Compute nodes use regular NFS mounts in autofs, but mount them directly into /home.

During user creation you will first have to create the user home directory in /data/home/USERNAME. You need to update both auto.home for master and compute nodes separately. Reload the autofs service on master and then change the user home directory to /home/USERNAME. Finally propagate the changes to your compute nodes and reload their services too.