Back to Subject

Unit 6: Network Storage, Boot, Security, and Installation

CSE493 — Linux System Administration 10 min read

I. System Administration Foundations

Linux system administration coordinates storage, startup, security, installation, and virtualization through kernel facilities, systemd units, configuration files, and administrative tools. On Red Hat Enterprise Linux (RHEL), persistent configuration should remain predictable across reboots and comply with discretionary access controls, SELinux policy, and firewall rules.

  • Privilege model: System-wide operations normally require root privileges, obtained through direct login, sudo, or an emergency environment.
  • Persistent configuration: Files such as /etc/fstab, /etc/exports, and Kickstart files preserve settings beyond the current session.
  • Service management: systemctl controls systemd units, while targets group units into bootable operating states.
  • Layered security: File permissions, SELinux labels, service configuration, and firewalld must all permit an operation.
  • Verification principle: Commands such as findmnt, systemctl status, firewall-cmd --list-all, and getenforce confirm the effective state.
  • Change discipline: Administrators should back up important data, validate configuration, inspect logs, and test recovery procedures before production use.

II. Network-Attached Storage — Remote File-System Access

A. Accessing Network-Attached Storage

Network-attached storage allows a client to use files hosted by another system across a network.

  • Storage model: File-level protocols expose shared directories; NFS is standard on Linux, while SMB is common in mixed Windows and Linux environments.
  • Discovery: An NFS server’s exports can be queried with:
    BASH
      showmount -e server.example.com
  • Dependencies: RHEL NFS clients use the nfs-utils package:
    BASH
      dnf install nfs-utils
  • Path convention: An NFS resource combines a server and exported path, such as server.example.com:/projects.
  • Access controls: Successful access depends on server export rules, network reachability, identity mapping, permissions, SELinux, and firewall configuration.
  • Diagnosis: rpcinfo, showmount, findmnt, and journalctl help distinguish server, network, and mount failures.

B. Mounting Network-Attached Storage with NFS

An NFS share may be mounted temporarily with mount or persistently through /etc/fstab.

  1. Temporary mount: The mount lasts until unmounted or the client reboots.
    BASH
       mkdir -p /mnt/projects
   mount -t nfs server.example.com:/projects /mnt/projects
   findmnt /mnt/projects
   umount /mnt/projects
  2. Persistent mount: An /etc/fstab entry requests mounting during startup.
    TEXT
       server.example.com:/projects /mnt/projects nfs defaults,_netdev 0 0
    • Network ordering: _netdev identifies the resource as network-dependent.
    • Validation: After editing /etc/fstab, test without rebooting:
      BASH
        mount -a
  findmnt --verify
    • Common options: ro prevents client writes; rw permits them subject to server permissions; vers=4.2 requests a specific NFS version.
    • Failure risk: Invalid persistent mounts can delay startup, so hostnames, paths, options, and DNS resolution must be checked.

C. Automounting Network-Attached Storage

Automounting mounts a remote resource when accessed and releases it after inactivity, reducing boot dependencies and idle mounts.

  • systemd automount: Add x-systemd.automount to /etc/fstab:
    TEXT
      server:/projects /mnt/projects nfs defaults,_netdev,x-systemd.automount 0 0
  • Activation: Reload systemd and access the directory:
    BASH
      systemctl daemon-reload
  ls /mnt/projects
  • Direct map: With autofs, /etc/auto.master.d/projects.autofs can contain:
    TEXT
      /- /etc/auto.projects

    /etc/auto.projects then maps the exact path:
    TEXT
      /mnt/projects -rw server.example.com:/projects
  • Service control: Enable the automounter with systemctl enable --now autofs.
  • Benefit: Automounting tolerates temporarily unavailable servers better than unconditional boot-time mounts.

III. Boot Management — systemd Targets and Recovery

A. Controlling the Boot Process

RHEL boots through firmware, a boot loader, the kernel and initramfs, and finally systemd.

  • Firmware stage: BIOS or UEFI selects the boot device and starts GRUB2.
  • GRUB2 stage: GRUB selects a kernel and supplies kernel command-line parameters.
  • Kernel stage: The kernel initializes hardware and uses the initramfs to locate the real root file system.
  • systemd stage: PID 1 starts units according to dependencies and the selected target.
  • Inspection: journalctl -b displays current-boot messages; journalctl -b -1 displays the previous boot when persistent logs exist.
  • Control operations:
    BASH
      systemctl reboot
  systemctl poweroff
  systemctl isolate rescue.target

B. Selecting the Boot Target

A systemd target represents an operational state and replaces traditional SysV runlevels.

  • Common targets: multi-user.target provides non-graphical multiuser operation; graphical.target adds the graphical interface; rescue.target supplies minimal local recovery.
  • Current default:
    BASH
      systemctl get-default
  • Persistent selection:
    BASH
      systemctl set-default multi-user.target
  • Immediate selection: systemctl isolate graphical.target changes state without changing the next boot’s default.
  • One-time boot: At the GRUB editor, append systemd.unit=rescue.target to the kernel command line.
  • Caution: Isolating a target stops units not required by it and may terminate active sessions.

C. Resetting the Root Password

A forgotten root password can be reset by entering an early-boot recovery shell with physical or console access.

  • GRUB modification: Edit the kernel entry and append rd.break to interrupt boot before switching to the installed root.
  • Writable root: The installed system is commonly mounted at /sysroot read-only:
    BASH
      mount -o remount,rw /sysroot
  chroot /sysroot
  passwd root
  • SELinux relabeling: Request relabeling so changed authentication files receive valid contexts:
    BASH
      touch /.autorelabel
  exit
  exit
  • Security implication: Unprotected console and GRUB access can bypass account authentication; firmware passwords, encrypted storage, and physical security reduce this risk.
  • Completion: The relabeling reboot may take longer because SELinux examines the file system.

D. Repairing File System Issues at Boot

File-system repair identifies structural corruption and restores a mountable state using tools appropriate to the file-system type.

  • Initial diagnosis: Boot failures may show emergency mode, failed mount units, or incorrect UUID entries; use journalctl -xb, lsblk -f, and /etc/fstab.
  • Unmount requirement: Repair should normally target an unmounted file system, often from rescue media or emergency mode.
  • XFS repair:
    BASH
      xfs_repair /dev/mapper/vg-data

    XFS uses xfs_repair, not fsck.xfs, for structural repair.
  • ext4 repair:
    BASH
      e2fsck -f /dev/mapper/vg-data
  • Configuration errors: A missing device may require correcting its UUID in /etc/fstab, rather than running a repair utility.
  • Data protection: Forced or log-destructive options should be last resorts after backups or storage snapshots.

IV. Network Security — Firewall and SELinux Enforcement

A. Managing Network Security

Network security minimizes exposed services and applies controls at application, host, and network layers.

  • Service exposure: Use ss -tulpn to identify listening TCP and UDP sockets and their owning processes.
  • Least privilege: Disable unnecessary daemons with systemctl disable --now service.
  • Encrypted administration: SSH protects remote sessions; key authentication is preferable to reusable passwords.
  • Patch management: dnf update installs security and reliability fixes from configured repositories.
  • Layer interaction: A reachable service still requires a listening process, firewall permission, valid SELinux policy, and application-level authorization.
  • Evidence: journalctl, /var/log/secure, and SELinux audit records support investigation and troubleshooting.

B. Managing Server Firewalls

RHEL uses firewalld to organize packet-filtering policy through zones, services, ports, and runtime or permanent configurations.

  1. Runtime configuration: Takes effect immediately but is lost when firewalld restarts.
    BASH
       firewall-cmd --add-service=http
  2. Permanent configuration: Survives restart but must be reloaded before becoming active.
    BASH
       firewall-cmd --permanent --add-service=http
   firewall-cmd --reload
    • Zones: Interfaces and sources belong to trust levels such as public, internal, or trusted.
    • Inspection:
      BASH
        firewall-cmd --get-active-zones
  firewall-cmd --list-all
    • Service definitions: Named services such as http are clearer than raw ports and may include multiple protocol requirements.
    • Removal: Replace --add-service with --remove-service, then reload when changing permanent policy.

C. Controlling SELinux Port Labeling

SELinux port labels determine which confined service domains may bind to particular network ports.

  • Policy relationship: A firewall opening does not authorize a process to bind; SELinux independently checks whether the port has an allowed type.
  • Inspection:
    BASH
      semanage port -l | grep http_port_t
  • Custom HTTP port: Permit an HTTP daemon to bind TCP port 8088:
    BASH
      semanage port -a -t http_port_t -p tcp 8088
  • Modification: Use -m when the port already exists under another SELinux type; use -d to delete a locally added mapping.
  • Package requirement: The semanage utility is supplied by policycoreutils-python-utils on current RHEL releases.
  • Verification: Check denials with ausearch -m AVC -ts recent; do not disable SELinux merely to conceal a labeling error.

V. RHEL Deployment — Interactive and Automated Installation

A. Installing Red Hat Enterprise Linux

RHEL installation begins by booting installation media and configuring localization, storage, software, networking, and credentials in Anaconda.

  • Media sources: Installation may use a DVD ISO, boot ISO with network repositories, PXE, or virtual media.
  • Storage planning: Select disks and define standard partitions, LVM logical volumes, encryption, or automatic partitioning.
  • Essential file systems: The installation requires a root file system; UEFI systems also require an EFI System Partition.
  • Software selection: Base environments range from minimal server installations to graphical systems.
  • Network identity: Configure hostname, interfaces, DNS, and time synchronization where required.
  • Pre-installation caution: Repartitioning can destroy existing data, so target disks must be identified by size, device name, and purpose.

B. Installing Red Hat Enterprise Linux

Post-installation work converts the newly installed operating system into a supported and operational host.

  • Registration: Connect an entitled system to Red Hat services:
    BASH
      subscription-manager register
  • Updates: Apply available fixes with dnf update, then reboot when a new kernel or critical component requires it.
  • Validation: Confirm release, kernel, storage, network, and failed units using cat /etc/redhat-release, uname -r, lsblk, and systemctl --failed.
  • Administration: Create named administrator accounts and grant controlled sudo access rather than sharing the root password.
  • Baseline security: Verify getenforce reports Enforcing, expose only required firewall services, and disable unused daemons.
  • Recovery readiness: Record partitioning, repository, encryption, and console-access details before placing the host into service.

C. Automating Installation with Kickstart

Kickstart provides a declarative text file that answers Anaconda installation questions consistently and repeatably.

  • Core directives: Typical entries define installation source, language, keyboard, network, storage, package selection, and reboot behavior.
  • Package section:
    TEXT
      %packages
  @^minimal-environment
  chrony
  %end
  • Script sections: %pre runs before storage installation; %post configures the installed system and may use --log for diagnostics.
  • Validation:
    BASH
      ksvalidator /path/to/system.ks
  • Invocation: Supply the file through a kernel argument such as inst.ks=http://server/system.ks.
  • Sensitive data: Passwords should use supported hashes, and access to Kickstart files must be restricted because they may expose credentials or deployment details.

VI. Virtualization — Guest Installation and Configuration

A. Installing and Configuring Virtual Machines

RHEL commonly uses KVM, QEMU, libvirt, and virt-install to create isolated guest systems backed by hardware virtualization.

  • Host preparation: Install virtualization packages and activate libvirt:
    BASH
      dnf install qemu-kvm libvirt virt-install
  systemctl enable --now libvirtd
  • Capability check: virt-host-validate tests CPU virtualization, kernel support, and device access.
  • Guest creation:
    BASH
      virt-install --name rhel-guest --memory 4096 --vcpus 2 \
    --disk size=30 --cdrom /var/lib/libvirt/images/rhel.iso
  • Virtual resources: Each guest needs suitable vCPUs, RAM, disk capacity, firmware, installation media, and network connectivity.
  • Networking: Libvirt’s default NAT network gives outbound connectivity; bridged networking places guests directly on the external LAN.
  • Management: virsh list --all, virsh start, virsh shutdown, and virsh console control guest lifecycle.
  • Operational constraint: Allocated CPU, memory, and storage must fit host capacity; excessive overcommitment causes unstable performance.
Previous
Unit 5