The
-m
specified indicates that
useradd
should create the home directory. This will
also populate the home directory with the skeleton files needed for interactive logins.
In the case of the group ID specified,
useradd
requires that the group exist. If you
want your user to have its own group, you can use
groupadd
to create a new group
and then use
useradd
to create the user that belongs to the new group. If you want to
add your user to multiple groups, you can edit the
/etc/group
file and add your user to
the end of each group line you want your user to be a member of. To pick up any
permissions associated with those groups’ access to files, for example, you need to log
out and log back in again. That will pick up the changes to your user, including the
new groups.
Once you have created the user, you should set a password. That’s done using the
passwd
command. If you are root and want to change another user’s password, you
use
passwd kilroy
in the case of the user created in the preceding example. If you just
use
passwd
without a username, you are going to change your own password.
Shells
The common default shell used is the Bourne Again Shell (bash).
However, other shells can be used. If you are feeling adventurous,
you could look at other shells like zsh, fish, csh, or ksh. A shell like
zsh offers the possibility of a lot of customization using features
including plug-ins. If you want to permanently change your shell,
you can either edit
/etc/passwd
or just use
chsh
and have your shell
changed for you.
Service Management
For a long time, there were two styles of service management: the BSD way and the
AT&T way. This is no longer true. There are now three ways of managing services.
Before we get into service management, we should first define a service. A
service
in
this context is a program that runs without any user intervention. The operating envi‐
ronment starts it up automatically and it runs in the background. Unless you got a list
of processes, you may never know it was running. Most systems have a decent num‐
ber of these services running at any point. They are called
services
because they pro‐
vide a service either to the system, to the users, or sometimes to remote users.
Since there is no direct user interaction, generally, in terms of the startup and termi‐
nation of these services, there needs to be another way to start and stop the services
that can be called automatically during startup and shutdown of the system. With the
facility to manage the services in place, users can also use the same facility to start,
stop, restart, and get the status of these services.
