Unit 3: Networking, Packages, File Systems, and Virtualization - Subjective Questions

Essential networking concepts:

• IP address: A logical address that uniquely identifies a host or network interface. IPv4 uses 32-bit addresses such as 192.168.1.10, while IPv6 uses 128-bit addresses.
• Subnet mask or prefix: Identifies the network and host portions of an IP address. For example, /24 corresponds to 255.255.255.0 in IPv4.
• Default gateway: The router to which packets are sent when their destination is outside the local network.
• DNS server: Converts host names such as server.example.com into IP addresses and may also perform reverse resolution.
• Network interface: A physical or virtual connection to a network, identified by names such as enp1s0 or ens33.

Together, these settings allow a RHEL system to communicate locally, reach remote networks, and resolve host names.

Network validation should proceed from the local system toward the remote destination:

1. Use ip link to verify that the network interface exists and is UP.
2. Use ip address show to confirm that the expected IP address and prefix are assigned.
3. Use ip route to inspect connected routes and the default gateway.
4. Use ping -c 4 127.0.0.1 to test the local TCP/IP stack.
5. Ping the system's own IP address, followed by the default gateway.
6. Ping a remote IP address to test routing without depending on DNS.
7. Use getent hosts hostname or host hostname to validate name resolution.
8. Use ss -tuln to check listening TCP and UDP services.
9. Inspect NetworkManager with nmcli device status and nmcli connection show.
10. Review logs with journalctl -u NetworkManager when configuration errors are suspected.

This sequence helps distinguish interface, addressing, routing, DNS, and service-level problems.

nmcli is the command-line interface for NetworkManager. A static connection can be created as follows:

• Identify interfaces using nmcli device status.
• Create a connection:
  nmcli connection add type ethernet ifname enp1s0 con-name static-enp1s0 ipv4.method manual ipv4.addresses 192.168.10.20/24 ipv4.gateway 192.168.10.1 ipv4.dns 192.168.10.1
• Enable automatic connection at boot:
  nmcli connection modify static-enp1s0 connection.autoconnect yes
• Activate it:
  nmcli connection up static-enp1s0
• Verify it:
  nmcli connection show static-enp1s0
  and ip address show enp1s0.

Multiple DNS servers may be supplied as a comma-separated list. Configuration errors should be corrected with nmcli connection modify before reactivating the connection.

DHCP configuration:

• Receives an IP address, prefix, gateway, and usually DNS settings automatically.
• Is convenient for clients and systems whose addresses do not need to remain fixed.
• Uses the NetworkManager IPv4 method auto.

Static configuration:

• Uses administrator-defined addressing information.
• Is appropriate for servers, routers, and services that require predictable addresses.
• Uses the IPv4 method manual.

To use DHCP:
nmcli connection modify CONNECTION ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""

To use static addressing:
nmcli connection modify CONNECTION ipv4.method manual ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.dns 192.168.1.1

Apply the changes with nmcli connection up CONNECTION. Remote administrators should take care because incorrect changes can terminate their connection.

Persistent NetworkManager profiles are commonly stored under /etc/NetworkManager/system-connections/ as keyfiles. A profile contains sections such as:

• [connection] for the connection name, UUID, type, and interface.
• [ethernet] for Ethernet-specific options.
• [ipv4] and [ipv6] for addressing methods, addresses, gateways, and DNS settings.

When editing a profile manually:

• Preserve the file's valid keyfile syntax.
• Ensure that the connection UUID and interface assignment are correct.
• Protect credentials and other settings by using restrictive permissions, normally root:root ownership and mode 600.
• Reload profiles with nmcli connection reload.
• Activate the changed profile with nmcli connection up CONNECTION.
• Validate the result using nmcli, ip address, and ip route.

Using nmcli is generally preferred because it validates many properties and reduces syntax errors.

Host name configuration:

• Display the current settings with hostnamectl.
• Set a persistent static host name with hostnamectl set-hostname server1.example.com.
• The configured static host name is recorded in /etc/hostname.

Name resolution:

• /etc/hosts provides local static mappings, for example 192.168.1.20 server1.example.com server1.
• /etc/resolv.conf contains resolver settings such as DNS server addresses and search domains. On NetworkManager systems, this file is usually generated from active connection profiles.
• /etc/nsswitch.conf determines the lookup order through the hosts: entry, commonly consulting local files and DNS.

Resolution can be tested with getent hosts server1.example.com, host server1.example.com, or dig server1.example.com. getent is particularly useful because it follows the Name Service Switch configuration used by applications.

tar combines multiple files and directories into one archive while preserving directory structure and metadata.

• Create an archive: tar -cf backup.tar /etc
• List its contents: tar -tf backup.tar
• Extract it: tar -xf backup.tar
• Extract into another directory: tar -xf backup.tar -C /restore
• Add a file to an uncompressed archive: tar -rf backup.tar newfile

Common options include:

• -c: create an archive.
• -t: list archive contents.
• -x: extract files.
• -f: specify the archive file.
• -v: display processed files.
• -C: change directory before performing the operation.

Absolute paths are normally stored without the leading /, reducing the risk of unexpectedly overwriting absolute locations during extraction.

gzip: Fast compression and decompression with a moderate compression ratio.

• Create: tar -czf backup.tar.gz data/
• Extract: tar -xzf backup.tar.gz

bzip2: Usually compresses more effectively than gzip but is slower.

• Create: tar -cjf backup.tar.bz2 data/
• Extract: tar -xjf backup.tar.bz2

xz: Often provides the highest compression ratio but may require more CPU time and memory.

• Create: tar -cJf backup.tar.xz data/
• Extract: tar -xJf backup.tar.xz

The options -z, -j, and -J select gzip, bzip2, and xz respectively. The appropriate format depends on whether transfer size, processing time, memory usage, or compatibility is the main concern.

Both scp and sftp use the SSH protocol, providing encrypted authentication and data transfer.

Using scp:

• Copy a local file to a remote system: scp report.txt user@server:/home/user/
• Copy a remote file locally: scp user@server:/var/tmp/data.txt .
• Copy a directory recursively: scp -r project/ user@server:/srv/
• Specify a nonstandard SSH port: scp -P 2222 file user@server:/tmp/

Using sftp:

• Start a session with sftp user@server.
• Use put file to upload and get file to download.
• Use ls, cd, lcd, mkdir, and pwd to navigate and manage paths.

SSH keys can provide secure, noninteractive authentication. Users must have appropriate permissions on both the source and destination paths.

rsync synchronizes files and directory trees locally or across a network. When used with SSH, the connection is encrypted.

Example:
rsync -avz -e ssh /srv/data/ user@server:/backup/data/

Important options include:

• -a: archive mode, preserving recursion, permissions, ownership, timestamps, and links where permitted.
• -v: verbose output.
• -z: compress transferred data.
• -e ssh: use SSH as the remote transport.
• --delete: remove destination files that no longer exist at the source; this must be used carefully.
• --dry-run: preview changes without modifying files.

rsync is preferred for repeated transfers because it usually sends only changed files or changed portions of files. The trailing slash is significant: /source/ copies the source directory's contents, while /source normally creates or updates a source directory at the destination.

RPM is the underlying package format and low-level package management system used by RHEL. An RPM package contains software files, metadata, dependencies, scripts, version information, and digital signatures.

Yum is a higher-level package manager that works with RPM packages and enabled repositories. It:

• Resolves and installs dependencies automatically.
• Downloads packages from configured repositories.
• Installs, upgrades, removes, and queries software.
• Maintains package transaction history.
• Verifies package signatures when configured correctly.

Commands such as rpm -q package query the local RPM database, while yum install package obtains the package and its dependencies from repositories. Modern RHEL versions may implement yum through DNF, while preserving familiar yum command behavior.

Common yum operations include:

• Install a package: yum install httpd
• Update one package: yum update httpd
• Update all installed packages: yum update
• Remove a package: yum remove httpd
• Search names and descriptions: yum search web server
• Display package information: yum info httpd
• List installed packages: yum list installed
• Identify the package that supplies a file or command: yum provides '*/semanage'
• Display transaction history: yum history

Yum calculates dependencies, presents a transaction summary, downloads packages, verifies signatures, and updates the RPM database. Administrators should review the proposed changes before confirming significant installations or updates.

A yum repository is a collection of RPM packages and metadata available through a local path or a network service such as HTTP or HTTPS.

Repositories can be managed as follows:

• List repositories: yum repolist all.
• Enable a repository for one command: yum --enablerepo=repo-id install package.
• Disable a repository for one command: yum --disablerepo=repo-id update.
• Enable persistently: yum config-manager --enable repo-id.
• Disable persistently: yum config-manager --disable repo-id.
• Add a repository: yum config-manager --add-repo URL.

Repository definitions are commonly stored in /etc/yum.repos.d/*.repo. Important properties include name, baseurl, enabled, gpgcheck, and gpgkey. Administrators should use trusted sources, enable GPG verification, import the correct signing key, and verify accessibility with yum repolist or yum makecache.

An uninstalled RPM file can be examined by combining query mode with the -p option:

• Display package information: rpm -qip package.rpm
• List contained files: rpm -qlp package.rpm
• List configuration files: rpm -qcp package.rpm
• List documentation files: rpm -qdp package.rpm
• Show requirements: rpm -qRp package.rpm
• Show capabilities provided: rpm -q --provides -p package.rpm
• Display installation and removal scripts: rpm -q --scripts -p package.rpm
• Verify the signature and digest: rpm -K package.rpm

These checks reveal what the package installs, what it requires, whether it executes administrative scripts, and whether it was signed by a trusted source. yum install ./package.rpm is generally preferable to direct installation with rpm -i because yum can resolve dependencies.

A RHEL system uses subscription services to gain authorized access to Red Hat repositories.

Typical steps are:

1. Register the system with subscription-manager register and provide valid organization credentials or an activation key.
2. Check status using subscription-manager status and subscription-manager identity.
3. View available subscriptions with subscription-manager list --available.
4. Attach an appropriate entitlement where required, for example subscription-manager attach --pool=POOL_ID.
5. List repositories with subscription-manager repos --list.
6. Enable a required repository using subscription-manager repos --enable=REPOSITORY_ID.
7. Verify access with yum repolist and install updates with yum update.

The exact attachment behavior depends on the Red Hat subscription model and organization settings. Before transferring or retiring a system, it can be unregistered with subscription-manager unregister.

Linux exposes storage devices as files under /dev. Examples include /dev/sda, /dev/vda, and /dev/nvme0n1, while partitions may appear as /dev/sda1 or /dev/nvme0n1p1.

Useful identification commands include:

• lsblk: Displays block devices, partitions, mount points, and relationships.
• lsblk -f: Adds file-system types, labels, and UUIDs.
• blkid: Reports file-system metadata such as TYPE, LABEL, and UUID.
• df -hT: Shows mounted file systems, types, and space usage.
• findmnt: Displays the current mount hierarchy and mount sources.

A file-system label is a human-readable identifier, while a UUID is designed to be unique. Persistent mount configurations commonly use UUID= or LABEL= rather than device names because names such as /dev/sdb1 may change when device detection order changes.

To mount a file system temporarily:

1. Identify it with lsblk -f or blkid.
2. Create a mount point, for example mkdir -p /data.
3. Mount it using mount /dev/sdb1 /data or mount UUID=uuid-value /data.
4. Verify it with findmnt /data or df -hT /data.

To unmount it, use umount /data. If the target is busy, commands such as lsof +D /data or fuser -vm /data can identify processes using it.

For automatic mounting, add an entry to /etc/fstab, such as:
UUID=uuid-value /data xfs defaults 0 0

The six fields specify the source, mount point, file-system type, options, dump setting, and file-system check order. After editing, test the entry with mount -a and verify it with findmnt; this helps detect errors before rebooting.

Hard links:

• Are additional directory entries referring to the same inode and file data.
• Are created with ln original hardlink.
• Usually cannot refer to directories.
• Cannot cross file-system boundaries.
• Continue to provide access to the data if another link name is deleted.

Symbolic links:

• Are separate special files containing a path to another file or directory.
• Are created with ln -s target symlink.
• Can refer to directories and can cross file-system boundaries.
• Can use absolute or relative target paths.
• Become dangling links if the recorded target path no longer exists.

ls -li can display inode numbers, making it possible to confirm that hard-linked names share an inode. readlink linkname displays the path stored in a symbolic link.

find: Searches the live directory hierarchy and supports conditions and actions. Examples include find /var -type f -name '*.log', find /home -user student, and find /tmp -mtime +7 -delete. Permissions may restrict the results.

locate: Searches a prebuilt file-name database and is usually faster than find. Because the database is updated periodically, very recent changes may not appear. The database can be refreshed with updatedb when the relevant package and privileges are available.

which: Searches directories in the current PATH for an executable command, for example which python3.

whereis: Locates a command's binary, source, and manual-page files in standard locations, for example whereis passwd.

Thus, find is best for accurate property-based searches, locate for fast name searches, and which or whereis for command-related files.

RHEL virtualization commonly uses KVM for hardware-assisted virtualization, QEMU for machine emulation, and libvirt for management.

A typical procedure is:

1. Confirm that the processor and firmware support virtualization.
2. Install the required virtualization packages, such as the appropriate virtualization package group and tools including libvirt and virt-install.
3. Enable and start the required libvirt service or socket units.
4. Verify the host with commands such as virsh list --all and, where available, virt-host-validate.
5. Prepare installation media, storage, and a libvirt virtual network or bridge.
6. Create a guest with virt-install, specifying its name, memory, virtual CPUs, disk, network, installation source, and operating-system information.
7. Complete the operating-system installation through a console or graphical viewer.

Virtual machines can then be managed with virsh start NAME, virsh shutdown NAME, virsh reboot NAME, virsh console NAME, and virsh undefine NAME. Administrators must also plan CPU, memory, storage, networking, security, and guest update requirements.