All Linux distributions group software into packages, which can be defined as a collection of files and subdirectories comprising a product.
If all the software on the system has been installed using the package management utilities, installation, removal, checking integrity and upgrading of software becomes easier and more stable.
Of course, there will be other files on the system, such as configuration files and user data, which generally will either be outside the packaging system, or be modified by system administrators from their original content.
There are two main packaging systems in use in Linux systems; RPM (used for example in all variations and descendants of Red Hat Enterprise Linux, Fedora and SUSE); and deb (used for example in Debian and Ubuntu).
It is important to note that there are always at least two levels of the package management software. The lower level simply installs, updates or removes a package, as in:
$ sudo rpm -ivh libaio-devel-0.3.109-12.el7.x86_64.rpm
which would install the development package associated with the asynchronous I/O library on a Red Hat-derived system. We will shortly show the use of dpkg and apt-get to do these operations on Debian-derived distributions.
$ sudo rpm -ivh libaio-devel-0.3.109-12.el7.x86_64.rpm libaio-l-0.3.109-12.el7.x86_64.rpm
However, this will fail if the actual library itself is not installed. Thus, one would have to install them in the proper order, or both at the same time, as in:
This can be a process which is both error-prone and frustrating, as you can easily get into dependency hell, where each time you add a package, you find another one missing, and the rpm command is not robust enough to always tell you what package it is you need.
Furthermore, you have to download the packages first, and supply the full name, including version and architecture, both of which are painful steps.
The higher level utilities handle this automatically. For example, on Red Hat-based systems, the command:
$ sudo yum install libaio-devel
will resolve any needed dependencies and then download all needed packages from one or more repositories the system has been configured to utilize, and then install them in the proper order. Likewise, the command:
$ sudo yum remove libaio
will not only remove libaio but also libaio-devel, since it cannot work without the base package. Obviously, you have to be careful when removing packages, as a cascading effect can happen, but yum will always give you a chance to change your mind before doing it.
Each distribution has such higher level management utilities. For example, deb-based systems have apt-get and apt-cache, while SUSE-based systems have zypper. They also have graphical utilities for package management which can insulate you from the command line. Recent Fedora systems use a newer program called dnf in place of yum.
There are a lot of holy wars in the Linux community about which packaging system is the best and there are others besides these two, both older ones and newer cutting edge ones. Often, the criticisms of the various methods are mistakenly applied to the lower level commands, when they should be applied to the higher level ones that deal with dependencies, etc.
Of course, all distributions have graphical system administration utilities for package management, that can do all of this without resort to the low-level commands, but once you know the basic commands, working at the command line tends to be significantly quicker.
From time to time, software on the system must be upgraded (or updated) or patched for one or more of the following reasons:
Incorporation of new features
Optimization and performance improvements
Security and bug fixes.
In many operating systems, such patching can be a laborious and error-prone task, which may require frequent reboots. These can be extremely disruptive on server systems, and system administrators have learned to be very cautious when deploying patches.
Linux does not employ a patching model. Rather, it installs complete new packages. For example, on RPM-based systems, the command:
$ sudo rpm -Uvh libaio-devel-0.3.109-12.el7.x86_64.rpm
will put in the newest version; a similar command, using dpkg, can be used on Debian-based systems. Even better, depending on the distribution, one of the following commands:
$ sudo yum update libaio-devel
$ sudo zypper update libaio-devel
$ sudo apt-get upgrade libaio-dev
will go out and check if an update is available, download it and install it, and, at the same time, update any other installed packages that require synchronization. The commands:
$ sudo yum update
$ sudo zypper update
$ sudo apt-get update
$ sudo apt-get dist-upgrade
will update (and/or upgrade) all packages on the system. Note that Debian-based systems require update to first synchronize repository information before updating the entire package system.
In order to avoid large downloads, most recent distributions can use features such as delta rpms, which can download a smaller binary patch file, and then use that to recreate the full rpm. However, when bandwidth is high, the time spent on reconstruction of the full rpm may constitute a net minus.
All distributions have configurable background daemons that run at specified intervals to check for updates, and then either install them automatically, or ask for approval.
The only time you should ever need to reboot a Linux system during the update process is when the kernel itself is updated. This is a feature whose beauty cannot be overemphasized.
The following table lists the basic packaging operations and their rpm and deb-based equivalents. The zypper-based commands are almost identical to the yum ones; look at the man page for zypper on SUSE-based systems.
| Operation | RPM | deb |
|---|---|---|
| Install a package | rpm -i foo.rpm | dpkg --install foo.deb |
| Install a package with dependencies from repository | yum install foo | apt-get install foo |
| Remove a package | rpm -e foo.rpm | dpkg --remove foo.deb |
| Remove a package and dependencies using a repository | yum remove foo | apt-get remove foo |
| Update package to a newer version | rpm -U foo.rpm | dpkg --install foo.deb |
| Update package using repository and resolving dependencies | yum update foo | apt-get install foo |
| Update entire system | yum update | apt-get dist-upgrade |
| Show all installed packages | rpm -qa or yum list installed | dpkg --list |
| Get information about an installed package including files | rpm -qil foo | dpkg --listfiles foo |
| Show available packages with “foo” in name | yum list foo | apt-cache search foo |
| Show all available packages | yum list | apt-cache dumpavail foo |
| What package does a file belong to? | rpm -qf file | dpkg --search file |
Recent Fedora systems have replaced yum with a new program called dnf. The basic commands are the same as those with yum. However, advanced commands can be different or missing.
The intention is to eventually replace yum; for now, when you issue yum commands, a warning is printed out and the equivalent dnf command is displayed and carried out.
On Linux systems, user directories are conventionally placed under /home, as in /home/coop, /home/student, etc. All personal configuration, data, and executable programs are placed in this directory hierarchy.
On other UNIX-like operating systems, the concept of the /home directory tree exists, but can be subtly different. For example, on Solaris, user directories are created in /export/home and then, the automount facility will eventually mount them in /home.
This is because the usual situation is that the home directory may be anywhere on a corporate network, probably on an NFS server, and the home directory will be mounted automatically upon first use.
Linux has these sameautomount facilities, but many users are not even aware of them, and on self-contained systems, the concept of NFS mounts will probably not apply.
A given user can always substitute the environment variable HOME for their root directory, or the shorthand ~; i.e. the following are equivalent:
$ ls -l $HOME/public_html
$ ls -l ~/public_html
There is one very important exception: the home directory for the root user on Linux systems is always placed in /root. Other system-provided accounts (such as daemon and bin) can also have directories in locations other than /home.
System log files are essential for monitoring and troubleshooting. In Linux, these messages appear in various files under /var/log.
Ultimate control of how messages are dealt with is controlled by the syslogd daemon (usually rsyslogd on modern systems) common to many UNIX-like operating systems. The newer systemd-based systems can use journalctl instead, but usually retain syslogd and cooperate with it.
Important messages are sent not only to the logging files, but also to the system console window; if you are not running X or are at a virtual terminal, you will see them directly there as well. In addition, these messages will be copied to /var/log/messages (or to /var/log/syslog on Ubuntu), but if you are running X, you have to take some steps to view them.
A good way to see them is to open a terminal window, and in that window, type tail -f /var/log/messages. On a GNOME desktop, you can also access the messages by clicking on System > Administration > System Log or Applications > System Tools > Log File Viewer in your Desktop menus, and other desktops have similar links you can locate.
In order to keep log files from growing without bound, the logrotate program is run periodically and keeps four previous copies (by default) of the log files (optionally compressed) and is controlled by /etc/logrotate.conf.
Here are some of the important log files found under /var/log:
| File | Purpose |
|---|---|
| boot.log | System boot messages |
| dmesg | Kernel messages saved after boot. To see the current contents of the kernel message buffer, type dmesg |
| messages or syslog | All important system messages |
| secure | Security related messages |
Enterprise Linux distributors often offer only a relatively small subset of the total number of packages available and the versions supported are often not the latest cutting edge ones.
This is done to permit better control over package interaction as the potential number of problems tends to rise rather dramatically as more software is included.
However, there are many software packages that are well-understood and probably can be added without big problems. While one can always install from source, binary packages are much easier to deal with.
NOTE: This lab can only be done on a RHEL or CentOS system.
For Red Hat Enterprise Linux installations (including CentOS), a handy resource is the EPEL repository (Extra Packages for Enterprise Linux). For the most part these are packages which have been used on Fedora systems, which are very similar to the current Red Hat system, and are expected to install cleanly and play well with the rest of the software on the system, although no technical support can be provided.
To install the EPEL repository, you need to download the RPM file from the EPEL repository, selecting the version appropriate for your major release version.
You can then install as in:
$ sudo rpm -Uvh epel-release*.noarch.rpm
or, to be explicit:
$ sudo rpm -Uvh epel-release-7.5.noarch.rpm
You will notice this creates a file, /etc/yum.repos.d/epel.repo which you should examine, as it is a template for how other repositories can be added.
You may already have the EPEL repository installed; for example, if you are using a Linux Foundation CentOS virtual machine. In such a case, just make sure you know how to obtain the RPM file and examine /etc/yum.repos.d/epel.repo.
Every Linux user, every user on the system is assigned a unique user ID, which is really just an integer, and you also get a group ID and we'll talk about that second, but that's also just an integer.
Now, all modern Linuxsystems store normal users with an ID of 1,000 and they go up from there. So, the first user when the system is installed will be 1,000, the next user it's added it will be 1001, et cetera.
Very old Linux systems from Red Hat started with 500, but now everybody uses 1,000.
User IDs of less than a 1,000 are certain system users which have special purposes and the superuser root has a user id of 0.
There is very important files on the system in the /etc directory, there is /passwd and /group.
Adding and Removing Users and Groups Adding a new user is done with useradd and removing an existing user is done with userdel. In the simplest form, an account for the new user bjmoose would be done with:
$ sudo /usr/sbin/useradd bjmoose
which, by default, sets the home directory to /home/bjmoose, populates it with some basic files (copied from /etc/skel), adds a line to /etc/passwd such as:
bjmoose:x:1002:1002::/home/bjmoose:/bin/bash
and sets the default shell to /bin/bash.
Additional options can be specified to change these properties, and to set others, such as the user name, etc. (see man useradd).
Before the account can be used, a password must be set. This can be done with the -p option to useradd, or by doing:
$ sudo passwd bjmoose
which will then prompt for adding a password.
Note that only the superuser, or root, has the right to establish (or remove) an account.
Removing a user account is as easy as:
$ sudo /usr/sbin/userdel bjmoose
However, this will leave the /home/bjmoose directory intact. This might be useful if it is a temporary inactivation, for example. To remove the home directory while removing the account, you need to use the -r option to userdel.
You can change the user’s characteristics after the account has been established with usermod. For example, you could use the -d option to change the home directory, or the -p option to change the password.
Adding a new group is done with groupadd:
$ sudo /usr/sbin/groupadd anewgroup
establishes the group anewgroup with default properties. The group can be removed with:
$ sudo /usr/sbin/groupdel anewgroup
Adding a user to an already existing group is done with usermod. For example, you would first look at what groups the user already belongs to:
$ groups bjmoose
bjmoose : bjmoose
and then, add the new group:
$ sudo /usr/sbin/usermod -aG anewgroup bjmoose
$ groups bjmoose
bjmoose: rjsquirrel anewgroup
Once again, these utilities must be run as superuser or root, and update /etc/group as necessary. The groupmod utility can be used to change the group’s properties, most often the numerical Group ID with the -g option, or its name with the -m option.
Removing a user from the group is somewhat trickier. The -G option to usermod must be given a complete list of groups. Thus, if you do:
$ sudo /usr/sbin/usermod -G rjsquirrel rjsquirrel
$ groups rjsquirrel
rjsquirrel : rjsquirrel
only the rjsquirrel group will be left.
An additional command, id, can be used to quickly glimpse user information. With no argument, it gives information about the current user, as in:
$ id
uid=1000(george) gid=1000(george) groups=106(fuse),1000(george)
If given the name of another user as an argument, id will report information about that other user.
Suppose you have a file and obtain a detailed listing of its properties: After the initial dash, there are nine letters, in three groups of three, that indicate read, write and execute permissions for owner, group, and world. In the above example, the owner of the file can read, write and execute, all members of the group can read or execute, and all others (in the world) can only execute.
$ ls -lF file
-rwxr-x--x 1 coop coop 42 Jun 18 13:59 some_file*
These file access permissions are a critical part of the Linux security system. Any request to access a file requires comparison of the credentials and identity of the requesting user to those of the owner of the file.
This authorization is granted depending on one of these three sets of permissions, in the following order:
If the requester is the file owner, the file owner permissions are used.
Otherwise, if the requester is in the group that owns the files, the group permissions are examined.
If that does not succeed, the world permissions are examined.
Note that permissions can be changed with chmod and ownership with chown. One user is special; the superuser or root user, who has access to all files on the system. This is essentially the equivalent to the administrator account, or privilege, in other operating systems.
Linux contains a full implementation of POSIX ACLs (Access Control Lists) which extends the simpler user, group, world and read, write, execute model.
Particular privileges can be granted to specific users or groups of users when accessing certain objects or classes of objects.
While the Linux kernel enables the use of ACLs, it still must be implemented as well in the particular filesystem. All major filesystems used in modern Linux distributions incorporate the ACL extensions.