Manage Software Configurations

By

Date: Jan 9, 2023

Return to the article

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:

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:

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:

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:

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:

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:

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:

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:

The following list shows the available priority levels:

The following list shows the available “actions”, which are really just where the log entry should be sent:

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:

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.

800 East 96th Street, Indianapolis, Indiana 46240

sale-70-410-exam    | Exam-200-125-pdf    | we-sale-70-410-exam    | hot-sale-70-410-exam    | Latest-exam-700-603-Dumps    | Dumps-98-363-exams-date    | Certs-200-125-date    | Dumps-300-075-exams-date    | hot-sale-book-C8010-726-book    | Hot-Sale-200-310-Exam    | Exam-Description-200-310-dumps?    | hot-sale-book-200-125-book    | Latest-Updated-300-209-Exam    | Dumps-210-260-exams-date    | Download-200-125-Exam-PDF    | Exam-Description-300-101-dumps    | Certs-300-101-date    | Hot-Sale-300-075-Exam    | Latest-exam-200-125-Dumps    | Exam-Description-200-125-dumps    | Latest-Updated-300-075-Exam    | hot-sale-book-210-260-book    | Dumps-200-901-exams-date    | Certs-200-901-date    | Latest-exam-1Z0-062-Dumps    | Hot-Sale-1Z0-062-Exam    | Certs-CSSLP-date    | 100%-Pass-70-383-Exams    | Latest-JN0-360-real-exam-questions    | 100%-Pass-4A0-100-Real-Exam-Questions    | Dumps-300-135-exams-date    | Passed-200-105-Tech-Exams    | Latest-Updated-200-310-Exam    | Download-300-070-Exam-PDF    | Hot-Sale-JN0-360-Exam    | 100%-Pass-JN0-360-Exams    | 100%-Pass-JN0-360-Real-Exam-Questions    | Dumps-JN0-360-exams-date    | Exam-Description-1Z0-876-dumps    | Latest-exam-1Z0-876-Dumps    | Dumps-HPE0-Y53-exams-date    | 2017-Latest-HPE0-Y53-Exam    | 100%-Pass-HPE0-Y53-Real-Exam-Questions    | Pass-4A0-100-Exam    | Latest-4A0-100-Questions    | Dumps-98-365-exams-date    | 2017-Latest-98-365-Exam    | 100%-Pass-VCS-254-Exams    | 2017-Latest-VCS-273-Exam    | Dumps-200-355-exams-date    | 2017-Latest-300-320-Exam    | Pass-300-101-Exam    | 100%-Pass-300-115-Exams    |
http://www.portvapes.co.uk/    | http://www.portvapes.co.uk/    |