Unit 6: Network Storage, Boot, Security, and Installation - Subjective Questions

Network-attached storage (NAS) is file-level storage provided by a remote server and accessed over a network. Network File System (NFS) is a common protocol used by Linux systems to access such storage.

A Linux client accesses an NFS share as follows:

• The NFS server exports a directory to authorized clients.
• The client installs the required package using dnf install nfs-utils.
• Available exports can be inspected with showmount -e server.example.com when supported by the server.
• A local mount point is created, for example: mkdir -p /mnt/shared.
• The export is mounted using mount -t nfs server.example.com:/shared /mnt/shared.
• Users access remote files through /mnt/shared as if they were stored locally.

Access is controlled by the server's export configuration, network firewall rules, file permissions, ownership, and SELinux policies.

The procedure for manually mounting an NFS file system is:

1. Install NFS client utilities:
   • Run dnf install nfs-utils.
2. Create a mount point:
   • Run mkdir -p /mnt/nfsdata.
3. Mount the remote export:
   • Run mount -t nfs server.example.com:/exports/data /mnt/nfsdata.
4. Verify the mount:
   • Use mount | grep nfs.
   • Use findmnt /mnt/nfsdata.
   • Use df -hT /mnt/nfsdata to display capacity and file-system type.
5. Test access:
   • Run ls -l /mnt/nfsdata and create a file if write access is permitted.
6. Unmount when required:
   • Run umount /mnt/nfsdata.

If unmounting fails because the file system is busy, lsof +D /mnt/nfsdata or fuser -vm /mnt/nfsdata can identify processes using it.

A persistent NFS mount is configured by adding an entry to /etc/fstab.

Example entry:

server.example.com:/exports/projects /projects nfs defaults,_netdev 0 0

The fields specify:

• server.example.com:/exports/projects: Remote NFS export.
• /projects: Local mount point.
• nfs: File-system type.
• defaults,_netdev: Standard options, with _netdev indicating that network access is required.
• 0: Disables dump backup processing.
• 0: Disables local file-system checking for the NFS mount.

Procedure:

1. Install nfs-utils.
2. Create the mount point with mkdir -p /projects.
3. Edit /etc/fstab and add the entry.
4. Test it using mount -a.
5. Verify it using findmnt /projects.

Testing with mount -a before rebooting is important because an invalid entry can delay or disrupt startup. Options such as nofail may be used when booting must continue even if the NFS server is unavailable.

Automounting mounts a remote file system only when a user or process accesses its configured directory. After a period of inactivity, the file system can be unmounted automatically. This reduces unnecessary mounts and avoids some boot-time failures when servers are unavailable.

Example configuration:

1. Install the package:
   • dnf install autofs
2. Create a master map file such as /etc/auto.master.d/projects.autofs containing:
   • /remote /etc/auto.projects
3. Create /etc/auto.projects containing:
   • projects -rw,sync server.example.com:/exports/projects
4. Enable and start the service:
   • systemctl enable --now autofs
5. Access /remote/projects to trigger the mount.
6. Verify it with findmnt /remote/projects.

Here, /remote is the base directory, projects is the map key, and the final field identifies the NFS export. Configuration changes can be applied by reloading or restarting autofs.

Comparison of /etc/fstab and autofs:

• Mount time:
  • /etc/fstab mounts the share during boot or when mount -a is executed.
  • autofs mounts the share when its path is accessed.
• Server availability:
  • An unavailable server may delay an /etc/fstab mount unless suitable options are used.
  • autofs postpones the mount attempt until access is requested.
• Resource usage:
  • /etc/fstab mounts generally remain active.
  • autofs can unmount inactive shares after a timeout.
• Configuration:
  • /etc/fstab uses one entry for each mount.
  • autofs uses a master map and one or more indirect or direct maps.
• Typical use:
  • /etc/fstab is suitable for shares that must always be available.
  • autofs is suitable for many user directories or occasionally accessed shares.

Therefore, the choice depends on availability requirements, the number of shares, and how frequently they are accessed.

The Linux boot process consists of the following stages:

1. Firmware initialization: BIOS or UEFI performs hardware initialization and selects a boot device.
2. Bootloader execution: The firmware loads GRUB2. GRUB2 presents the boot menu and loads the selected kernel and initial RAM file system.
3. Kernel initialization: The kernel initializes processors, memory, device drivers, and essential kernel subsystems.
4. Initramfs stage: The initial RAM file system contains temporary tools and drivers required to locate and mount the real root file system. It may activate LVM, RAID, or encrypted storage.
5. Root file-system switch: The system switches from the temporary initramfs root to the actual root file system.
6. systemd startup: The kernel starts systemd as process ID 1.
7. Unit activation: systemd activates required targets, services, sockets, mounts, and other units according to dependencies.
8. Target reached: The system reaches a target such as multi-user.target or graphical.target, after which users can log in.

Failures at each stage require different tools, such as GRUB editing, initramfs emergency shells, or journalctl.

A systemd target groups systemd units and represents an operating state. It replaces the traditional SysV run-level concept.

Common targets include:

• poweroff.target: Shuts down the system.
• rescue.target: Starts a minimal single-user environment with basic services.
• multi-user.target: Starts a text-based multiuser system.
• graphical.target: Starts multiuser services and a graphical interface.
• reboot.target: Reboots the system.
• emergency.target: Provides the most minimal emergency shell.

Useful commands:

• View the default target: systemctl get-default
• Set the default target: systemctl set-default multi-user.target
• Switch immediately: systemctl isolate rescue.target
• List target units: systemctl list-units --type=target

For a one-time boot, edit the GRUB kernel command line and append systemd.unit=rescue.target or another required target. isolate should be used carefully because services not required by the selected target may be stopped.

rescue.target:

• Provides a single-user maintenance environment.
• Starts more supporting services than emergency mode.
• Usually mounts local file systems.
• Prompts for administrative authentication when entered normally.
• Is appropriate for service repair, configuration correction, and routine recovery.

emergency.target:

• Provides the smallest possible environment.
• Starts an emergency shell with very few services.
• May mount the root file system as read-only.
• Does not automatically activate all local file systems or networking.
• Is appropriate for serious boot failures, damaged /etc/fstab entries, or file-system repair.

An administrator can select these modes using systemctl isolate rescue.target, systemctl isolate emergency.target, or by adding systemd.unit=rescue.target or systemd.unit=emergency.target to the temporary GRUB kernel command line.

A commonly used recovery procedure is:

1. Reboot and display the GRUB2 menu.
2. Select the required kernel entry and press e to edit it.
3. Locate the line beginning with linux or linuxefi and append rd.break.
4. Press Ctrl+x to boot with the modified command line.
5. At the initramfs prompt, remount the real root file system as writable:
   • mount -o remount,rw /sysroot
6. Enter the installed system:
   • chroot /sysroot
7. Reset the password:
   • passwd root
8. Request SELinux relabeling:
   • touch /.autorelabel
9. Exit the chroot and then exit the recovery shell.
10. Allow the system to reboot and complete SELinux relabeling.

The relabeling step is important because changing password-related files while outside the normal SELinux environment may leave incorrect labels. Physical and bootloader access must be secured because GRUB-based recovery can provide administrative access.

File-system boot failures may result from damaged file systems, missing devices, incorrect UUIDs, or invalid /etc/fstab entries.

Diagnostic and repair procedure:

1. Enter emergency.target, rescue.target, or the initramfs emergency shell.
2. Review errors using journalctl -xb and systemctl --failed.
3. Identify devices and file systems using lsblk -f and blkid.
4. Compare actual device UUIDs and mount points with /etc/fstab.
5. Correct invalid /etc/fstab entries and test them with mount -a.
6. Ensure the damaged file system is unmounted before repairing it.
7. For supported ext file systems, use an appropriate command such as fsck -f /dev/device.
8. For XFS, use xfs_repair /dev/device; ordinary fsck does not repair XFS.
9. Reboot and verify mounts with findmnt and failed units with systemctl --failed.

Repair commands can modify file-system metadata, so backups should be available. They should never be run on a mounted read-write file system unless specifically documented as safe.

firewalld is the dynamic firewall management service used in Red Hat Enterprise Linux. It applies packet-filtering rules through the system's firewall framework without requiring complete firewall restarts for ordinary changes.

Key concepts are:

• Zone: A trust level containing a set of firewall rules. Examples include public, internal, trusted, and drop.
• Interface: A network interface can be assigned to a zone, causing traffic arriving through it to follow that zone's rules.
• Service: A predefined XML-based definition containing the ports and protocols required by an application, such as ssh, http, or https.
• Port: A specific transport-layer port and protocol, such as 8080/tcp.
• Runtime configuration: Active immediately but normally lost after a reload or reboot.
• Permanent configuration: Stored on disk and applied after a reload.

Administrators should allow only required traffic and should use predefined services when available because they are easier to understand and maintain.

Assuming the public zone is being used, the configuration can be performed as follows:

1. Check active zones:
   • firewall-cmd --get-active-zones
2. Allow the predefined HTTP service permanently:
   • firewall-cmd --permanent --zone=public --add-service=http
3. Allow a custom port such as TCP port 8080 permanently:
   • firewall-cmd --permanent --zone=public --add-port=8080/tcp
4. Apply permanent changes:
   • firewall-cmd --reload
5. Verify the complete zone configuration:
   • firewall-cmd --zone=public --list-all
6. Verify individual rules:
   • firewall-cmd --zone=public --query-service=http
   • firewall-cmd --zone=public --query-port=8080/tcp

A firewall rule only permits network traffic; it does not start the application or make it listen on that port. The service must also be running, and SELinux must permit the service to use the selected port.

Runtime configuration is the active in-memory configuration. Changes made without --permanent take effect immediately but are normally lost after firewalld is reloaded or the system is restarted.

Permanent configuration is stored on disk. Changes made with --permanent do not affect the active rules until a reload is performed.

Examples:

• Add a runtime service: firewall-cmd --add-service=https
• Add a permanent service: firewall-cmd --permanent --add-service=https
• Apply permanent rules: firewall-cmd --reload
• Remove a permanent service: firewall-cmd --permanent --remove-service=https
• Remove a permanent port: firewall-cmd --permanent --remove-port=8080/tcp
• Save the current runtime configuration as permanent: firewall-cmd --runtime-to-permanent

A safe method is to test a rule at runtime, confirm connectivity, and then preserve it using --runtime-to-permanent. Administrators must verify the correct zone to avoid changing rules that do not apply to the intended interface.

SELinux port labeling associates network ports with SELinux port types. A confined service can bind only to ports permitted by its security policy. For example, an HTTP server domain is normally permitted to bind to ports labeled http_port_t.

To permit a web server to use TCP port 8080:

1. Install the package that provides semanage if necessary:
   • dnf install policycoreutils-python-utils
2. Inspect HTTP-related port labels:
   • semanage port -l | grep http_port_t
3. Add the label if port 8080 is not already defined:
   • semanage port -a -t http_port_t -p tcp 8080
4. If the port already has another SELinux definition, modify it appropriately with:
   • semanage port -m -t http_port_t -p tcp 8080
5. Allow the port through firewalld if remote access is required.
6. Configure and restart the web server.

Both SELinux and the firewall must permit the operation. Disabling SELinux is not an appropriate solution.

Firewall control and SELinux port labeling operate at different security layers:

• Firewall control: Determines whether network packets may enter, leave, or pass through the system. Opening 8080/tcp allows packets to reach that port.
• SELinux port labeling: Determines whether a confined process is allowed to bind to or use a particular port. The port must have a type permitted for that service domain.

A service may still fail when the firewall port is open because:

• The service is stopped or has failed.
• The service is listening only on the loopback address.
• No process is listening on the configured port.
• SELinux denies the process permission to bind to that port.
• The wrong firewalld zone was modified.
• The service configuration contains an error.
• An upstream firewall or router blocks the traffic.

Useful diagnostic commands include ss -lntup, systemctl status service-name, journalctl -u service-name, firewall-cmd --list-all, and ausearch -m AVC -ts recent.

A typical interactive Red Hat Enterprise Linux installation includes these stages:

1. Prepare installation media: Download the correct ISO image, verify its checksum, and create bootable media or attach it to a virtual machine.
2. Boot the installer: Start the system from the installation source and select the installation option.
3. Choose language and localization: Configure language, keyboard layout, date, time, and time zone.
4. Select installation source and software: Choose repositories and a base environment such as Server or Minimal Install.
5. Configure storage: Select target disks and use automatic or custom partitioning. LVM, encryption, swap, and mount points may be configured.
6. Configure networking: Enable the required interface and set the hostname, DHCP, or static addressing.
7. Configure users and authentication: Set administrative access and create a regular user where appropriate.
8. Begin installation: The installer partitions storage, installs packages, and configures the bootloader.
9. Reboot and verify: Remove installation media, boot the installed system, register it if required, update packages, and verify networking and services.

Planning storage, networking, and software requirements before installation reduces configuration errors.

Automatic partitioning allows the installer to create the required partitions and logical volumes. It is quick and suitable for standard systems.

Custom partitioning allows the administrator to define mount points, sizes, file-system types, LVM volumes, encryption, and other storage features.

Important design factors include:

• The required size of /, /home, /var, /boot, and swap.
• Whether UEFI requires an EFI System Partition.
• Expected growth of logs, databases, user data, and application files.
• Whether LVM is needed for flexible volume resizing.
• Whether sensitive data should be encrypted.
• Performance requirements and the availability of multiple disks.
• Backup, recovery, and compliance requirements.
• Isolation of rapidly growing directories such as /var to prevent them from filling the root file system.

Separate file systems can improve management and fault isolation, but excessive partitioning may waste space or make future capacity planning difficult.

Kickstart is a method of automating Red Hat Enterprise Linux installation by supplying installation answers in a text configuration file. It enables consistent, repeatable, and unattended deployments.

A Kickstart file commonly contains:

• Installation commands: Language, keyboard, time zone, installation source, network settings, bootloader options, user configuration, and storage layout.
• %packages section: Lists package groups and individual packages to install or exclude.
• %pre section: Runs scripts before storage and package installation; it can be used for dynamic preparation.
• %post section: Runs scripts after installation; it can configure services, create files, install additional software, or register the system.
• %addon sections: Configure installer extensions when needed.

The file can be stored on HTTP, HTTPS, NFS, or local media. At boot, its location is supplied with an option such as inst.ks=http://server.example.com/ks/server.cfg. The installer reads the file and performs the specified installation steps with minimal or no user interaction.

A reliable Kickstart workflow includes:

1. Create the file: Write a new file or adapt the /root/anaconda-ks.cfg file generated by an earlier installation.
2. Define required settings: Specify the installation source, networking, storage, bootloader, package selection, and post-installation tasks.
3. Validate syntax: Use ksvalidator file.cfg when the validation utility is available.
4. Publish the file: Place it on an accessible HTTP, HTTPS, NFS, or local source.
5. Boot with Kickstart: Pass inst.ks=location to the installer.
6. Test safely: Perform test installations in a virtual machine before production deployment.
7. Review logs: Installer logs are available under /tmp during installation and under /var/log/anaconda on the installed system.

Security precautions:

• Avoid storing plain-text passwords; use properly generated password hashes.
• Restrict access to the Kickstart file because it may contain network or account information.
• Protect %post scripts and downloaded content.
• Use trusted repositories and secure transport where possible.

Common failures include inaccessible URLs, incorrect disk names, invalid partition instructions, repository errors, and syntax mistakes.

A RHEL virtual machine can be installed using KVM for hardware-assisted virtualization and libvirt for management.

Procedure:

1. Confirm that the processor supports virtualization and that it is enabled in firmware.
2. Install the virtualization packages, such as the RHEL virtualization package group, libvirt, and management tools.
3. Enable the virtualization service with systemctl enable --now libvirtd where that service model is used.
4. Prepare a RHEL installation ISO or network installation source.
5. Create storage for the guest, commonly a qcow2 disk image or a libvirt storage volume.
6. Select virtual CPUs, memory, disk capacity, and firmware appropriate for the workload.
7. Configure networking using the default NAT network, a bridge, or another required libvirt network.
8. Create the guest with virt-install or a graphical management tool.
9. Complete the interactive installation or attach a Kickstart file for automation.
10. Verify the guest using virsh list --all, access its console, test networking, and install guest integration tools where appropriate.

Resources should be allocated according to host capacity. Over-allocation can reduce performance for both the host and its virtual machines.