Local user accounts allow individual people access to a system, and allow them to keep their files separate from each other. See how to create a regular user and a system user.
- We can add a user to the system with the adduser command. Adduser is a front-end for another command, called useradd. And while you can use that directly if you'd like, in this video I'll focus on the adduser command. Adduser lets us specify some parameters for adding a user account. And it also reads a configuration file, /etc/add.user.conf for these default settings like the shell and where home folders are located. We can override these, but it's convenient to have them pre-set if we don't want to have to write them out every time we create a user.
This file sets out the path that home folders will be created in. And if you have a lot of users, you can choose to create a sub folder with the first letter of the user name to help keep things a little bit more organized. And you can specify what's called the skeleton for the home folder. If you want to populate some things into the home folders of new users automatically. That can be helpful for giving people a welcome document, or some links to shared resources, or something like that. There are other options in here about the directory mode and ranges for group and user IDs.
But we'll leave those alone for now. Let's take look at the man page, and see what options are available for adduser. Here we can see there are two primary ways of using adduser to add a regular user or a system user. And some options about adding groups, and adding a user to a group, which we'll get into in the video about groups. Let's add a regular user to the system here. I'll quit out of the man page, and then I'll use the adduser command.
And then I'll set a user name. With just this, I'm creating a user, and then adduser is taking care of setting up the user themself with ID 1001, the user's group, also 1001, and the user's home folder. The path to this home folder, the /home portion, we saw earlier in the adduser.conf file. And now I'm being prompted for a password. I'll set that.
And confirm it. The user can reset that later if they want to. And now I'm asked for the full name, which I'll add. And some other information. A room number, and some phone numbers. I'll leave these blank. These are the fields that show up with commas in the fifth field of the ETC password file; the description. This is called GECOS information; G-E-C-O-S, for General Electric Comprehensive Operating Supervisor. A system that used information in this format.
And the format stuck around. I'll confirm that the information's correct. And now I have a user. They've got a home folder, and I can switch over to using that user with su, or s-u, and log in. CD will take me to this user's home directory. And there we go. I'll exit back to my other user. That user is a normal user, intended for a human to use.
So it has a UID of over 1,000. And it has a primary group. We can also create system users with UIDs less than 1,000, which have no group. And they're intended for more service account type things, like daemons and other automated processes. To create a system user, we'd use adduser --system. And let's call this one botuser. I see that the UID is below 1,000. In this case it's 122.
In that range reserved for system users. It has a group of nogroup, and we're not prompted for a password. Lots of system accounts don't have passwords because they don't need to log in. The system can just start up processes as that user to keep things separate and secure. If I take a look at the information for this user, I can double check that it's user ID is a system user ID, and that it's group ID and its group membership are set to nogroup.
The system users also have their shell set to false, preventing them from logging in.
- Creating, modifying, and deleting user accounts
- Creating and modifying groups
- Configuring and monitoring user resources
- Configuring permissions to allow group collaboration
- Working with pluggable authentication modules (PAM)
- Managing user and group information with an LDAP directory
- Authenticating clients with Kerberos