Manage Software Configurations
Date: Jan 9, 2023
This chapter from CompTIA Linux+ XK0-005 Exam Cram covers XK0-005 Objective: 1.7: Given a scenario, manage software configurations.
In Chapter 6, “Build and Install Software,” you learned about managing software. In this chapter the focus shifts toward software configuration. You will learn how to manage software repository configurations and how to configure the kernel. You will also learn how to configure common system services, such as SSH, NTP, and syslog.
This chapter provides information on the following topics: updating configuration files, configuring kernel options, configuring common system services, and localization.
Updating Configuration Files
This section explores the package management configuration files that you should know how to update.
Procedures
If you upgrade a package, you might need to restart or reload a service. Typically the documentation that comes with the software package should indicate if a restart or reload is required. You also might need to restart or reload a service if changes are made to the configuration file for the software. This section addresses these procedures.
Restart Service
The restart option is used with the systemctl command to restart a service that is currently running. A restart can make the service unavailable for a short period of time.
Syntax:
systemctl restart process_name
You can determine whether a service is currently running by using the active command:
# systemctl active cups enabled
Reload Service
The reload option is used with the systemctl command to reload a service that is currently running. This command does not stop the service but rather has the service reread its configuration file and change its behavior based on changes in the configuration file.
Syntax:
systemctl reload process_name
You can determine whether a service is currently running by using the active command:
# systemctl active cups enabled
.rpmnew
When RPMs are installed, they might overwrite the default configuration files of the software package as new configuration settings are added or older configuration settings are removed.
The overwriting of the configuration files can lead to frustration if the system administrator has spent time and effort creating a customized configuration file. As a result, software developers might choose to place the new configuration file contents in a file called .rpmnew. Then a system administrator can review the .rpmnew file and determine which new settings should be incorporated into the primary configuration file.
Another technique is for the software developers to use a .rpmsave file, as described in the next section.
.rpmsave
When RPMs are installed, they might overwrite the default configuration files of the software package as new configuration settings are added or older configuration settings are removed.
The overwriting of the configuration files can lead to frustration if the system administrator has spent time and effort creating a customized configuration file. As a result, software developers might choose to place the previous configuration file contents in a file called .rpmsave. Then a system administrator can review the .rpmsave file and determine which of the previous settings should be incorporated into the primary configuration file.
Another technique is for the software developers to use a .rpmnew file, as described in the previous section.
Repository Configuration Files
Repository configuration files, discussed in Chapter 6, are an integral component of package management. The Linux+ XK0-005 exam lists these topics in different exam categories, so the following section headings have been preserved to inform you where to go to find details about these topics.
/etc/apt.conf
See the “APT” section in Chapter 6.
/etc/yum.conf
See the “YUM” section in Chapter 6.
/etc/dnf/dnf.conf
See the “DNF” section in Chapter 6.
/etc/yum.repo.d
See the “YUM” section in Chapter 6.
/etc/apt/sources.list.d
See the “APT” section in Chapter 6.
Configure Kernel Options
The Linux kernel is highly configurable. You can make changes to the kernel by using parameters and kernel modules. This section covers these configuration features.
Parameters
A kernel parameter is a value that changes the behavior of the kernel.
sysctl
You can view and change parameters by using the sysctl command. For example, to view all the kernel and kernel module parameters, execute the sysctl command with the -a option:
[root@onecoursesource ~]# sysctl -a | head kernel.sched_child_runs_first = 0 kernel.sched_min_granularity_ns = 1000000 kernel.sched_latency_ns = 5000000 kernel.sched_wakeup_granularity_ns = 1000000 kernel.sched_tunable_scaling = 1 kernel.sched_features = 3183 kernel.sched_migration_cost = 500000 kernel.sched_nr_migrate = 32 kernel.sched_time_avg = 1000 kernel.sched_shares_window = 10000000
The name of the parameter (kernel.sched_child_runs_first, for example) is a relative pathname that starts from /proc/sys and has a dot (.) character between the directory and filename rather than a slash (/) character. For example, the /proc/sys/dev/cdrom/lock file is named using the dev.cdrom.lock parameter:
[root@onecoursesource ~]# sysctl -a | grep dev.cdrom.lock dev.cdrom.lock = 1
You can change the value of this parameter by using the sysctl command:
[root@onecoursesource ~]# sysctl dev.cdrom.lock=0 dev.cdrom.lock = 0 [root@onecoursesource ~]# sysctl -a | grep dev.cdrom.lock dev.cdrom.lock = 0
It is actually safer to use the sysctl command than to modify the file directly because the sysctl command knows which values for the parameter are valid and which ones are not:
[root@onecoursesource ~]# sysctl dev.cdrom.lock="abc" error: "Invalid argument" setting key "dev.cdrom.lock"
The sysctl command knows which parameter values are valid because it can look at the modinfo output. For example, the value of the lock file must be a Boolean (0 or 1), according to the output of the modinfo command:
[root@onecoursesource ~]# modinfo cdrom | grep lock parm: lockdoor:bool
If you modify the file directly or use the sysctl command, the changes are temporary. When the system is rebooted, the values go back to the defaults, unless you make changes in the /etc/sysctl.conf file. The next section provides more details about /etc/sysctl.conf.
/etc/sysctl.conf
The /etc/sysctl.conf file is used to specify which kernel parameters to enable at boot.
Example:
[root@OCS ~]# cat /etc/sysctl.conf # System default settings live in/usr/lib/sysctl.d/00-system.conf. # To override those settings, enter new settings here, or # in an /etc/sysctl.d/<name>.conf file. # # For more information, see sysctl.conf(5) and sysctl.d(5). net.ipv4.ip_forward=1
In this example, the kernel parameter ip_forward is turned on, which means this machine will act as a router between two networks.
There are thousands of possible kernel settings, including dozens of settings that affect networking. The ip_forward setting is one of the most common network settings.
The parameters that optimize the IO (input/output) scheduler are examples of kernel parameters. Several parameters can be set to change the behavior of the scheduler. This section covers the parameters that are important for the Linux+ XK0-005exam.
To see the current scheduler, view the contents of the /sys/block/<device>/queue/scheduler file (where <device> is the actual device name). Here’s an example:
[root@OCS ~]# cat /sys/block/sda/queue/scheduler [noop] deadline cfq
The value within the square brackets is the default. To change this, use the echo command, as shown here:
[root@OCS ~]# echo "cfq" > /sys/block/sda/queue/scheduler [root@OCS ~]# cat /sys/block/sda/queue/scheduler noop deadline [cfq]
Additional scheduler types include the following:
cfq: The Completely Fair Queuing schedule has a separate queue for each process, and the queues are served in a continuous loop.
noop: This schedule follows the FIFO (first in, first out) principle.
deadline: This is the standard scheduler. This scheduler creates two queues: a read queue and a write queue. It also puts a timestamp on each I/O request to ensure that requests are handled in a timely manner.
Modules
A module is a small software program that, when loaded, provides more features and capabilities to the kernel. This section describes the management of modules using the lsmod, imsmod, rmmod, insmod, modprobe, and modinfo commands.
lsmod
The lsmod command displays the kernel modules that are loaded into memory. This command has no options.
In the output of the lsmod command, each line describes one module. There are three columns of information for each line:
The module name.
The size of the module, in bytes.
The “things” that are using the module. A “thing” could be a filesystem, a process, or another module. In the event that another module is using this module, the dependent module name is listed. Otherwise, a numeric value that indicates how many “things” use this module is provided.
Example:
[root@OCS ~]# lsmod | head Module Size Used by tcp_lp 12663 0 bnep 19704 2 bluetooth 372944 5 bnep rfkill 26536 3 bluetooth fuse 87741 3 xt_CHECKSUM 12549 1 ipt_MASQUERADE 12678 3 nf_nat_masquerade_ipv4 13412 1 ipt_MASQUERADE tun 27141 1
imsmod
The imsmod command is used to add modules to the currently running kernel.
Syntax:
insmod [module_name]
The exact location of the module needs to be specified. For example:
[root@OCS ~]# lsmod | grep fat [root@OCS ~]# insmod /usr/lib/modules/3.19.8-100.fc20.x86_64/kernel/ fs/ fat.ko [root@OCS ~]# lsmod | grep fat fat 65107 0
There are no options to the insmod command; however, each module might have modules that can be passed into the module using the following syntax:
insmod module options
The insmod command has two disadvantages:
You have to know the exact location of the module.
If the module has any dependencies (that is, if the module needs another module), it will fail to load.
rmmod
The rmmod command is used to remove modules from the currently running kernel.
Syntax:
rmmod [options] [module_name]
Example:
[root@OCS ~]# lsmod | grep fat fat 65107 0 [root@OCS ~]# rmmmod fat [root@OCS ~]# lsmod | grep fat
Modules that are currently in use will not be removed by this command by default.
Key options for the rm command include the following:
-f attempts to force removal of modules that are in use (which is very dangerous).
-w waits for a module to be no longer used and then removes it.
-v displays verbose messages.
insmod
The insmod command is used to add modules to the currently running kernel.
Syntax:
insmod [module_name]
The exact location of the module needs to be specified. For example:
[root@OCS ~]# lsmod | grep fat [root@OCS ~]# insmod /usr/lib/modules/3.19.8-100.fc20.x86_64/kernel/ fs/ fat.ko [root@OCS ~]# lsmod | grep fat fat 65107 0
There are no options to the insmod command; however, each module might have modules that can be passed into the module using the following syntax:
insmod module options
The insmod command has two disadvantages:
You have to know the exact location of the module.
If the module has any dependencies (that is, if the module needs another module), it will fail to load.
modprobe
The modprobe command is used to add and remove modules from the currently running kernel. It also attempts to load module dependencies.
Syntax:
modprobe [options] [module_name]
When used to remove modules (with the -r option), the modprobe command also removes dependency modules unless they are in use by another part of the subsystem (such as the kernel or a process).
Key options for the modprobe command include the following:
-c displays the current modprobe configuration.
-q causes modprobe to run in quiet mode.
-R displays all modules that match an alias to assist you in debugging issues.
-r removes the specified module from memory.
-v displays verbose messages; this is useful for determining how modprobe is performing a task.
modinfo
The modinfo command is used to provide details about a module.
Syntax:
modinfo [module_name]
Example:
[root@OCS ~]# modinfo xen_wdt filename: /lib/modules/3.19.8-100.fc20.x86_64/kernel/drivers/watchdog/ xen_wdt.ko license: GPL version: 0.01 description: Xen WatchDog Timer Driver author: Jan Beulich <jbeulich@novell.com> srcversion: D13298694740A00FF311BD0 depends: intree: Y vermagic: 3.19.8-100.fc20.x86_64 SMP mod_unload signer: Fedora kernel signing key sig_key: 06:AF:36:EB:7B:28:A5:AD:E9:0B:02:1E:17:E6:AA:B2:B6:52: 63:AA sig_hashalgo: sha256 parm: timeout:Watchdog timeout in seconds (default=60)(uint) parm: nowayout:Watchdog cannot be stopped once started (default=0) (bool)
One of the most important parts of the output of the modinfo command is the parm values, which describe parameters that can be passed to this module to affect its behavior.
Configure Common System Services
This section focuses on configuring common system services, including SSH, NTP, syslog, chrony, and localization.
SSH
The Secure Shell (SSH) protocol is designed to replace insecure remote communication operations, such as the telnet, ftp, rlogin, rsh, rcp, and rexec commands/protocols. The primary issue with earlier communication methods is that those methods send data across the network in plaintext rather than in an encrypted format. In some cases, such as with telnet and ftp, this can include sending user account data (such as name and password) across the network in plaintext.
SSH provides a better level of security by encrypting the data sent across the network. SSH has become such a standard in Linux that almost all distributions include both the client and server software by default. In the event that you do not have this software installed on your system, you should install the openssh, openssh-server, openssh-clients, and openssh-askpass software packages.
The /etc/ssh directory is the location where the Secure Shell configuration files are stored. The configuration file for the SSH server is the /etc/ssh/sshd_config file. Don’t confuse this with the /etc/ssh/ssh_config file, which is used to configure client utilities, such as the ssh, scp, and sftp commands.
There are two different SSH protocols that are numbered 1 and 2. These are not versions but rather two separate protocols developed to provide secure data connections. There was a time when both protocols were commonly used, but now almost all SSH clients use only protocol 2. To set the protocol that your SSH server accepts, use the Protocol keyword:
Protocol 2
If you have some older SSH clients that require protocol 1, you can configure your SSH server to accept both protocol connections by using the following keyword setting in the /etc/ssh/sshd_config file:
Protocol 1,2
If you have multiple network cards (or virtual interfaces), you may want to limit the SSH server to listen to only some of the network cards. To do this, use the ListenAddress keyword and specify the IP address assigned to the network cards that SSH should accept connections on:
ListenAddress 192.168.1.100:192.168.1.101
The standard port number that the SSH server listens to is port 22. You can modify the SSH server to listen to another port by using the Port keyword:
Port 2096
You might need to change what sort of log messages you want the SSH server to record. This can be set by using the LogLevel keyword. The levels available are as follows:
QUIET
FATAL
ERROR
INFO
VERBOSE
DEBUG
DEBUG1 (which is the same as DEBUG)
DEBUG2
DEBUG3
Network Time Protocol (NTP)
The Network Time Protocol daemon (ntpd) is a process that ensures the system clock is in sync with the time provided by remote NTP servers. Most of the configuration for this process is handled via the /etc/ntp.conf file. Table 7.1 shows the important settings of the /etc/ntp.conf file.
TABLE 7.1 /etc/ntp.conf File Settings
Option |
Description |
|---|---|
driftfile |
Contains a value that represents the typical delta (change) over time from the NTP-reported time and the system clock. This value is used to regularly update the system clock without having to access an NTP server. |
restrict |
Used to indicate restrictions for the daemon, including what machines can access this NTP server when it is used as a service. |
server |
Used to list an NTP server for this machine when it is used as an NTP client. |
Here is an example of a typical /etc/ntp.conf file:
# For more information about this file, see the man pages # ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5). driftfile /var/lib/ntp/drift # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict default kod nomodify notrap nopeer noquery # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 restrict ::1 # Hosts on local network are less restricted. # restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap # Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join. html). server 0.fedora.pool.ntp.org iburst server 1.fedora.pool.ntp.org iburst server 2.fedora.pool.ntp.org iburst server 3.fedora.pool.ntp.org iburst # Enable public key cryptography. #crypto includefile /etc/ntp/crypto/pw # Key file containing the keys and key identifiers used when operating # with symmetric key cryptography. keys /etc/ntp/keys
The pool.ntp.org address is a link to a cluster of NTP servers that are geographically spread throughout the world. These servers can be freely used within the /etc/ntp.conf file. For example, the following servers are provided by the Fedora project (but note that these are often mirrors, pointing to other systems, so the resulting hostnames for these servers will be different once you have connected to them):
0.fedora.pool.ntp.org
1.fedora.pool.ntp.org
2.fedora.pool.ntp.org
3.fedora.pool.ntp.org
The ntpq command allows you to perform queries on NTP servers. For example, the ntpq command in the following example displays a summary of the status of NTP servers:
[root@onecoursesource ~]# ntpq -p
remote refid st t when poll reach delay offset
jitter
============================================================
*propjet.latt.ne 68.110.9.223 2 u 120 1024 377 98.580 7.067
4.413
-services.quadra 208.75.88.4 3 u 272 1024 377 72.504 -10.689
1.612
+mirror 216.93.242.12 3 u 287 1024 377 20.406 -2.555
0.822
+108.61.194.85.v 200.23.51.102 2 u 741 1024 377 69.403 -3.670
1.610
Table 7.2 lists some important options to the ntpq command.
TABLE 7.2 ntpq Command Options
Option |
Description |
|---|---|
-d |
Enables debugging mode. |
-n |
Lists host IP addresses rather than names. |
-p |
Prints a list of all peers. |
Syslog
The syslog service has existed since 1980. Although it was advanced at the time it was created, its limitations have grown over time as more complex logging techniques have become required.
In the mid-2000s, the rsyslog service was created as an extension of the traditional syslog service. The rsyslog service extends the capabilities of syslog through the inclusion of modules.
The configuration of syslog and rsyslog services is consistent, with the exception of slightly different naming conventions (for example, rsyslog.conf versus syslog.conf) and additional features available in the log files.
The syslogd or rsyslogd daemon is responsible for logging of application and system events. It determines which events to log and where to place log entries, based on configuration settings in the /etc/syslog.conf file.
Table 7.3 describes some important options to the syslogd and rsyslogd commands.
TABLE 7.3 syslogd and rsyslogd Command Options
Option |
Description |
|---|---|
-d |
Enables debugging mode. |
-f |
Specifies the configuration file (with /etc/syslog.conf as the default). |
-m x |
Creates a timestamp in the log files every x minutes. (You can set x to 0 to omit timestamps.) |
-r |
Enables the syslogd daemon to accept logs from remote systems. |
-S |
Enables verbose mode. |
-x |
Disables DNS lookups for IP addresses. |
The /etc/rsyslog.conf file is one of the configuration files for the rsyslogd daemon. The following is a typical rsyslog.conf file with the comments and blank lines removed (along with the modules):
[root@OCS ~]# grep -v "^$" /etc/rsyslog.conf | grep -v "^#" *.info;mail.none;authpriv.none;cron.none /var/log/messages authpriv.* /var/log/secure mail.* -/var/log/maillog cron.* /var/log/cron *.emerg * uucp,news.crit /var/log/spooler local7.* /var/log/boot.log
Every line represents one logging rule that is broken into two primary parts: the selector (for example, uucp,news.crit) and the action (/var/log/spooler). The selector is also broken into two parts: the facility (uucp,news) and the priority (crit). Note that when a priority is provided, it means “this priority and all priorities of a higher level.”
The following list shows the available facilities in order from lower level to higher level:
auth (or security)
authpriv
cron
daemon
kern
lpr
mail
mark
news
syslog
user
uucp
local0 through local7
The following list shows the available priority levels:
debug
info
notice
warning (or warn)
err (or error)
crit
alert
emerg (or panic)
The following list shows the available “actions”, which are really just where the log entry should be sent:
Regular file (where using - before the filename prevents syncing with every log entry, thus reducing hard drive writes)
Named pipes
Console or terminal devices
Remote hosts
Users, which write to the specified user’s terminal windows (where * specifies all users)
chrony
Traditionally, the NTP server on Linux has been the ntpd server (discussed earlier in this chapter, in the “Network Time Protocol [NTP]” section). A newer alternative, chrony, provides some benefits over the ntpd server, including:
Faster synchronization
Typically more accurate time
Improved response to clock frequency changes
No need for periodic polling of other NTP servers
Smaller (less memory and CPU utilization)
Localization
Several commands can be used to display or modify the date and time on a system, as well as the locale of a system. This section explores these commands.
timedatectl
Use the timedatectl command to display the system clock.
Syntax:
timedatectl [option] [value]
Example:
[root@OCS ~]# timedatectl
Local time : Wed 2018-10-10 14:41:41 PDT
Universal time: Wed 2018-10-10 21:41:41 UTC
RTC time: Wed 2018-10-10 09:51:09
Timezone: America/Los_Angeles (PDT, -0700)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2018-03-11 01:59:59 PST
Sun 2018-03-11 03:00:00 PDT
Next DST change: DST ends (the clock jumps one hour backwards)
at
Sun 2018-11-04 01:59:59 PDT
Sun 2018-11-04 01:00:00 PST
As the root user, you can use this command to set the system clock. Table 7.4 demonstrates the most commonly used methods of changing the system clock.
TABLE 7.4 Methods to Change the System Clock
Method |
Description |
|---|---|
set-time [time] |
Sets the system clock to the specified time. |
set-timezone [zone] |
Sets the system time zone to the specified zone. |
set-ntp [0|1] |
Enables (1) or disables (0) Network Time Protocol. |
localectl
The BASH shell and other processes need customized operations to fit the location of the user. For example, if currency is to be displayed and the user is located in the United States, the $ character should be used. If the user is located in Great Britain, the £ character should be used.
This section focuses on the variables used to inform programs what settings to use based on a user’s locale.
LC_* refers to a collection of locale settings used to change the way the shell and other programs handle differences based on the geographic region of the user (or a region the user is familiar with). These values can be viewed by executing the locale command:
[root@OCS ~]# locale LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
The most important locale settings are described in Table 7.5.
TABLE 7.5 Locale Settings
Setting |
Description |
|---|---|
LANG |
Language |
LC_CTYPE |
Case conversion |
LC_NUMERIC |
Numeric format |
LC_TIME |
Time and date format |
LC_COLLATE |
Collation order |
LC_MONETARY |
Currency format |
LC_MESSAGES |
Format of message |
LC_PAPER |
Paper size format |
LC_NAME |
Name format |
LC_ADDRESS |
Address format |
LC_TELEPHONE |
Telephone format |
LC_ALL |
When set, LC_ALL will override all other locale settings. This provides an easy means to change all locale settings by modifying one environment variable. |
The localectl command can display and change both locale values and keyboard layouts.
Syntax:
localectl [options] command
To display values, use status:
[root@OCS ~]# localectl status
System Locale: LANG=en_US.utf8
VC Keymap: us
X11 Layout: us
X11 Model: pc105+inet
X11 Options: terminate:ctrl_alt_bksp
Set the locale and keyboard as follows:
[root@OCS ~]# localectl set-locale "LANG=de_DE.utf8"set-keymap "de"
There are a handful of options to the localectl command, but none of them are commonly used.