Figure 2.15 – RHEL 9 in Google Cloud Platform: VM instance – console
It takes some time to get set up in the cloud, configure your account, and find the SSH key
(which will be shown in Chapter 8, Administering Systems Remotely),
but once it’s all set up, it’s easy to get a
new instance up and running.
To become an administrator, you only need to run the following command:
[miguel@rhel-instance ~]$ sudo -i
[root@rhel-instance ~]#

Deploying RHEL on the cloud 55
Now, you can check the time configuration with timedatectl and change it, as follows:
[root@rhel-instance ~]# timedatectl
Local time: Sat 2021-12-12 17:13:29 UTC
Universal time: Sat 2021-12-12 17:13:29 UTC
RTC time: Sat 2021-12-12 17:13:29
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
[root@rhel-instance ~]# timedatectl set-timezone Europe/Madrid
[root@rhel-instance ~]# timedatectl

Local time: Sat 2021-12-12 18:20:32 CET
Universal time: Sat 2021-12-12 17:20:32 UTC
RTC time: Sat 2021-12-12 17:20:32
Time zone: Europe/Madrid (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
You can also change the language configuration with localectl, like so:
[root@rhel-instance ~]# localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: us
X11 Layout: n/a
To change locale or language support, you will need to install its language package first, as follows:
[root@rhel-instance ~]# yum install glibc-langpack-es –y
... [output omitted] ...
[root@rhel-instance ~]# localectl set-locale es_ES.utf8
[root@rhel-instance ~]# localectl

System Locale: LANG=es_ES.utf8
VC Keymap: us
X11 Layout: n/a

RHEL 9 Advanced Installation Options:
You now have a machine configured that you can use throughout this book. These locale changes are
not needed to proceed—they’re only needed to create a machine with the same configuration as in
the previous chapter.
Now that we know how to automatically redeploy VMs using Anaconda and how to get instances
in the cloud, let’s move on and look at some of the best practices to be taken into account when
performing installations.
Installation best practices
RHEL installations have many options you can choose from, and what you choose should be tailored
for your specific use case. However, some common recommendations apply. Let’s look at the most
common types.
The first type is blueprints. Here’s how you can use them:
• Standardize the core installation and create a blueprint for it:
‚ This blueprint will be minimal enough to serve as the base for all other blueprints
and deployments.
• Build a set of blueprints for common cases when needed:
‚ Try to use an automation platform to build extended cases (that is, Ansible).
‚ Try to make the cases modular (that is, an app server; database blueprints can be combined
into one single machine).
‚ Be aware of the requirements you must apply to your templated blueprints and adapt to the
environments you will use.
The second type is software. Here are some guidelines regarding this:
• The less software that’s installed, the smaller the attack surface. Try to keep servers with the
minimal set of packages required on them for them to run and operate (that is, try not to add
a graphical user interface (GUI) to your servers).
• Standardize the installed tools where possible to be able to react quickly in case of emergency.
• Package your third-party applications so that you have healthy life cycle management (whether
with RPM Package Manager (RPM) or in containers).
• Establish a patching schedule.
Installation best practices 57
The third type is networking. Here are some recommendations in terms of this:
• In VMs, try not to overuse the number of network interfaces.
• In physical machines, use interface teaming/bonding whenever possible. Segment networks
using virtual local area networks (VLANs).
The fourth type is storage. Here are some useful suggestions on how best to use this:
• For servers, use Logical Volume Manager (LVM) where possible (usually, everything but
/boot or /boot/efi).
• If you think you will need to reduce your filesystems, use ext4; otherwise, go for the default
of xfs.
• Partition the disk carefully by doing the following:
‚ Keep the default boot partition with its default size. If you change it, enlarge it (you may
need space there during upgrades).
‚ The default swap partition is the safest bet unless the third-party software has specific
requirements.
‚ For long-lived systems, have at least separate partitions for / (root) /var, /usr, /tmp,
and /home, and consider even a separate one for /var/log and /opt (for ephemeral
cloud instances or short-lived systems, this does not apply).
The fifth type is security. Follow these guidelines:
• Do not disable Security-Enhanced Linux (SELinux). It has been improved a lot in the latest
versions and it’s unlikely to interfere with your system (if required, set it in permissive mode
instead of fully disabling it).
• Do not disable the firewall. Automate port opening with the service deployment.
• Redirect logs to a central location whenever possible.
• Standardize the security tools and configuration that you want to install to check system
integrity and audit (that is, Advanced Intrusion Detection Environment (AIDE), logwatch,
fapolicyd, Integrity Measurement Architecture (IMA), and auditd).
• Review software install (RPM) GNU Privacy Guard (GPG) keys, as well as ISO images, to
ensure integrity.
• Try to avoid using passwords (especially for your root account) and use strong ones where needed.
• Review your systems with OpenSCAP to check on security (if needed, create your own hardware
Security Content Automation Protocol (SCAP) profile with help from your security team).
58 RHEL 9 Advanced Installation Options
Finally, we will look at the miscellanea type, as follows:
• Keep system time synchronized.
• Review logrotate policies to avoid “disk full” errors due to logs.
Following these best practices will help you avoid issues and make the installed base more manageable.
With that, you know how to deploy RHEL on a system in a structured, repeatable manner while
providing services to other teams in a fast and resilient fashion.
Summary
In the previous chapter, we mentioned how to prepare a machine that we can work with throughout
this book. An alternative to that is using cloud instances, with which we could be consuming VM
instances from the public cloud, which may simplify our consumption and provide us with enough
free credit to prepare for RHCSA. Also, once the self-training process is complete, the machines can
be still used to provide your own public services (such as deploying a blog).
Understanding the need to standardize your environments and the impact of doing so is also important
when you’re working with Linux as a professional. It is key to start with a good set of practices
(automating installations, keeping track of installed software, reducing the attack surface, and so on)
from the beginning.
Now that you’ve completed this chapter, you are ready to continue with the rest of this book, since
you now have an instance of RHEL 9 available to work and practice with. In the next chapter, we will
review the basics of the system to make ourselves comfortable and gain confidence in using the system.

Basic Commands and Simple Shell Scripts
Once you have your first Red Hat Enterprise Linux (RHEL) system running, you want to start using it, practicing, and getting comfortable with it. In this chapter, we will review the basics of logging into the system, navigating through it, and getting to know the basics in terms of its administration.
The set of commands and practices described in this chapter will be used on many occasions when managing systems, so it is important to study them with care.
The following topics will be covered in this chapter:
• Logging in as a user and managing multi-user environments
• Changing users with the su command
• Understanding users, groups, and basic permissions
• Using the command line, environment variables, and navigating through the filesystem
• Understanding I/O redirection on the command line
• Filtering output with grep and sed
• Listing, creating, copying, and moving files, directories, links, and hard links
• Using tar and gzip
• Creating basic shell scripts
• Using system documentation resources
60 Basic Commands and Simple Shell Scripts
Logging in as a user and managing multi-user
environments
Login is the process during which a user identifies themselves in the system – usually, by providing a
username and password, a couple of pieces of information often referred to as credentials.
The system can be accessed in many ways. The initial case for this, which we are covering here, is
how a user accesses it when they install a physical machine (such as a laptop) or via the virtualization
software interface. In this case, we are accessing the system through a console.
During installation, the user was created with an assigned password, and no graphical interface was
installed. We will access the system in this case via its text console. The first thing we are going to
do is to log in to the system using it. Once we start the machine and the boot process is completed,
we will enter, by default, the multi-user text mode environment in which we are being requested to
provide our login:
Figure 3.1 – The login process and username request
The blinking cursor will let us know that we are ready to enter our username, in this case, user, and
then press Enter. A line requesting the password will appear:
Figure 3.2 – The login process and password request
We may now type the user’s password to complete the login and, by pressing Enter on your keyboard,
start a session. Note that no characters will be displayed on the screen when typing the password to
avoid eavesdropping. The following screenshot shows the session running:
Logging in as a user and managing multi-user environments 61
Figure 3.3 – The completed login process and the session running
Now, we are fully logged in to the system with the credentials for a user called user. This will define
what we can do in the system, which files we can access, and even how much disk space we are assigned.
The console can have more than one session. To make that possible, we have different terminals
through which we can log in. The default terminal can be reached by simultaneously pressing the
Ctrl + Alt + F1 keys. In our case, nothing will happen, as we are already in that terminal. We could
move to the second terminal by pressing Ctrl + Alt + F2, to the third one by pressing Ctrl + Alt + F3,
and so on for the rest of the terminals (by default, six are allocated). This way, we can run different
commands in different terminals.
Using the root account
Regular users will not be able to make changes to the system, such as creating new users or adding
new software to the whole system. To do so, we need a user with administrative privileges and for
that, the default user is root. This user always exists in the system and its identifier – the User Id
(UID) – has the value 0.
In the previous installation, we configured the root password, making the account accessible through
the console. To use it by logging in to the system, we only need to type the user root into one of the
terminals shown right next to the login, then hit Enter, and then provide its password, which won’t
be displayed. This way, we will access the system as the administrator, root:
Figure 3.4 – The completed login process for root
62 Basic Commands and Simple Shell Scripts
Important Note
Above the login prompt, there is a message suggesting how the activation of the web console
(cockpit) can be done – the cockpit is a set of tools that enables web management for the system.
The cockpit is covered in Chapter 4, Tools for Regular Operations.
Using and understanding the command prompt
The command line that appears once we have logged in and are waiting for our commands to be typed
and run is called the command prompt.
In its default configuration, it will show the username and hostname between brackets to let us know
with which user we are working. Next, we see the path, in this case, ~, which is the shortcut for the
user’s home directory (in other words, /home/user for user, and /root for root).
The last part and, probably the most important one, is the symbol before the prompt:
• The $ symbol is used for regular users with no administrative privileges.
• The # symbol is used for root or once a user has acquired administrative privileges.
Important Note
Be careful when using a prompt with the # sign, as you will be running as an administrator
and the system will likely not stop you from damaging it.
Once we have identified ourselves within the system, we are logged in and have a running session.
It is time to learn how to change from one user to the other in the following section.
Changing users with the su command
As we have entered a multi-user system, it is logical to think that we will be able to change between
users. Even when this can be done easily by opening a session for each, sometimes we want to act as
several users within one session.
To do so, we can use the su tool. The name of the tool is usually referred to as Substitute User.
Let’s use that last session, in which we logged in as root, and turn ourselves into user.
Before doing so, we can always ask which user we are logged in as by running the whoami command:
[@rhel-instance ~]# whoami
root
Changing users with the su command 63
Now, we can make the change from root to user:
[root@rhel-instance ~]# su user
[user@rhel-instance root]$ whoami
user
Now, we have a session as user. We can finish this session by using the exit command:
[user@rhel-instance root]$ exit
exit
[root@rhel-instance ~]# whoami
root
As you may have seen, when we are logged in as root, we can act as any user without knowing
its password. But how can we impersonate root? We can do so by running the su command and
specifying the root user. In this case, the root user’s password will be requested:
[user@rhel-instance ~]$ su root
Password:
[@rhel-instance user]# whoami
root
As root is the user with the ID 0 and the most important one, when running su without specifying
the user we want to turn into, it will default to turning us into root:
[user@rhel-instance ~]$ su
Password:
[root@rhel-instance user]# whoami
root
Each user can define several options in their own environment, such as, for example, their preferred
editor. If we want to fully impersonate the other user and take their preferences (or environment
variables, as they are referred to on many occasions), we can do so by adding - after the su command:
[user@rhel-instance ~]$ su -
Password:
Last login: mar feb 15 04:57:29 CET 2022 on pts/0
[root@rhel-instance ~]#
64 Basic Commands and Simple Shell Scripts
We can also switch from root to user:
[root@rhel-instance ~]# su - user
Last login: Tue Feb 15 04:53:02 CET 2022 from 192.168.122.1 on
pts/0
[user@rhel-instance ~]$
As you can observe, it behaves as if a new login was done, but within the same session. Now, let’s move on
to managing the permissions for the different users in the system, as addressed in the following section.
Understanding users, groups, and basic permissions
Multi-user environments are defined by being able to handle more than one user simultaneously. But
to be able to administer the system resources, two capabilities help with the tasks:
• Groups: Can aggregate users and provide permissions for them in blocks.
Each user has a primary group.
By default, a group is created for each user and assigned to it as a primary with the same name
as the username.
• Permissions: Assigned to files, determining which users and groups can access each file.
Standard Linux (and UNIX or POSIX) permissions include user, group, and others (ugo).
The whole system comes with a set of permissions assigned by default to each file and directory. Be
careful when changing them.
There is a certain principle in UNIX that Linux has inherited: everything is a file. Even when there
may be some corner cases to this principle, it remains true on almost any occasion. It means that
a disk is represented as a file in the system (in other words, such as /dev/sdb mentioned in the
installation), a process can be represented as a file (under /proc), and many other components in
the system are also represented as files.
This means that, when assigning permissions to files, we can also assign permissions to many other
components and capabilities implemented by them by virtue of the fact that