Linux Administration
Complete Practical Guide

Linux is a Unix-like operating system built around the kernel, user-space utilities, filesystems, services, and applications. Enterprise distributions such as CentOS Stream, RHEL, Rocky Linux, and AlmaLinux share many administration concepts, but package versions, support policies, repositories, and security tooling can differ.

Linux architecture

• Kernel: CPU scheduling, memory management, device drivers, networking, and system calls.
• Init/service manager: systemd commonly manages boot, services, targets, dependencies, and cgroups.
• User space: shells, libraries, utilities, daemons, and applications.
• Package ecosystem: RPM packages and repository metadata provide repeatable software installation.
• Configuration and logs: commonly stored under /etc, /var/log, and systemd journal storage.

Administrator responsibilities

• Availability, capacity, patching, monitoring, backups, security, change control, and incident response.
• Document changes and preserve evidence during troubleshooting.
• Prefer least privilege, automation, and tested rollback procedures.

Essential discovery commands

The Linux command line follows a composable-tool approach: one command produces data and another filters, transforms, counts, or stores it. This is particularly useful for logs, inventory, audits, and operational reports.

Shell fundamentals

• pwd shows the current directory.
• cd changes location; cd - returns to the previous directory.
• command --help provides quick usage information.
• man command provides authoritative local documentation.

Redirection and pipelines

• > overwrites a file; >> appends.
• 2> redirects standard error.
• &> redirects standard output and error in Bash.
• | connects standard output to another command.
• tee displays output and writes it simultaneously.

Common text utilities

Vim operates primarily in Normal mode and Insert mode. Press Esc whenever you are unsure which mode is active.

Safe editing workflow

1. Back up critical configuration before editing.
2. Open the file and inspect existing content.
3. Make the smallest required change.
4. Save, validate syntax, and test the affected service.
5. Record the change and rollback method.

Useful commands

Linux treats many resources as filesystem objects. Understand the difference between a file’s content, metadata, inode, pathname, and open file descriptor.

Important concepts

• Absolute path: starts from /.
• Relative path: interpreted from the current directory.
• Hard link: another directory entry for the same inode.
• Symbolic link: a path reference that can cross filesystems.
• inode: metadata structure containing ownership, permissions, timestamps, and block references.

Permissions

For files, read means viewing, write means modifying, and execute means running. For directories, read permits listing, write permits creating/deleting entries, and execute permits traversal.

Account management should follow identity governance: each person receives a unique account, access is granted through groups, privileged actions are auditable, and inactive accounts are disabled.

Key files

• /etc/passwd: account identity and shell fields.
• /etc/shadow: password hashes and aging data.
• /etc/group: group membership.
• /etc/sudoers and included files: controlled privilege delegation.

Operational guidance

• Do not share root credentials.
• Use visudo to validate sudo policy.
• Review UID/GID consistency in centrally managed environments.
• Use non-login shells for service accounts when interactive access is unnecessary.

Quotas are useful on multi-user filesystems, shared application areas, hosting platforms, and environments where uncontrolled growth can affect availability.

Quota concepts

• Soft limit: threshold that may allow a grace period.
• Hard limit: maximum permitted usage.
• Block quota: controls space consumption.
• Inode quota: controls the number of filesystem objects.

Quota support and commands vary by filesystem and distribution. Plan maintenance windows and verify support before enabling quotas on production filesystems.

systemd uses unit files to describe services, sockets, mounts, timers, targets, and other resources. Separate runtime state from boot-time enablement: starting a service now does not necessarily enable it at boot.

Service lifecycle

• start activates a service now.
• stop stops it now.
• restart stops and starts it.
• reload asks the service to reread configuration without a full restart.
• enable configures activation during boot.
• mask prevents activation until unmasked.

Control groups, or cgroups, organize processes hierarchically and apply resource accounting or limits. systemd creates and manages cgroups for services, sessions, slices, and scopes.

Useful resource controls

• CPUQuota: limits CPU time available to a service.
• MemoryMax: caps memory consumption.
• TasksMax: limits the number of processes or tasks.
• IOWeight: influences relative I/O priority where supported.

Apply limits gradually and monitor service behavior. A limit that is too low can cause instability or repeated restarts.

A process has a PID, parent PID, credentials, open files, environment, scheduling attributes, and resource usage. Diagnose before terminating: identify the command, owner, dependencies, and impact.

Signals

• SIGTERM requests graceful shutdown.
• SIGKILL cannot be caught and should be a last resort.
• SIGHUP is often used to request configuration reload, depending on the daemon.

A firewall should implement the minimum network exposure required by the workload. Document the intended source networks, destination ports, protocol, owner, and expiration or review date.

firewalld concepts

• Zone: trust level associated with interfaces or sources.
• Service: predefined group of ports and protocols.
• Runtime configuration: active immediately but may not survive reboot.
• Permanent configuration: saved policy applied after reload or restart.

A PHP deployment commonly includes Apache or Nginx, PHP packages or PHP-FPM, a database, TLS certificates, application files, and log collection. Keep runtime configuration separate from application code and avoid exposing diagnostic output publicly.

Validation checklist

• Confirm supported PHP version and required extensions.
• Use a dedicated service account where appropriate.
• Restrict configuration and secret-file permissions.
• Disable verbose errors in production responses.
• Test the application through the same path used by clients.

Do not replace the distribution’s system Python blindly. Enterprise utilities may depend on a vendor-supported interpreter. Prefer virtual environments, application-specific paths, modules, or containers for independent workloads.

Recommended application pattern

1. Install a supported Python runtime.
2. Create a virtual environment.
3. Pin dependencies in a requirements file.
4. Run the application with a dedicated account.
5. Use systemd, a container, or another supervisor.
6. Log errors and define a health check.

Ruby applications may require a specific interpreter, Bundler version, native libraries, and environment variables. For development, a version manager can isolate projects; for production, standardize the runtime and deployment artifact.

Operational concerns

• Match Ruby and Bundler versions to the application lockfile.
• Compile native gems only with approved build dependencies.
• Keep secrets outside source control.
• Use a process manager and monitor memory and restart behavior.

Perl remains common in older enterprise automation and monitoring environments. When maintaining Perl scripts, document interpreter requirements, modules, input assumptions, exit codes, and security-sensitive operations.

Good scripting practices

• Use strict and warnings.
• Validate input and quote shell arguments carefully.
• Prefer Perl modules over fragile shell interpolation.
• Log failures and return meaningful exit codes.

LDAP is a directory protocol used for identity and configuration data. Important concepts include entries, attributes, object classes, distinguished names, the directory information tree, binds, search bases, and access controls.

Design considerations

• Define naming contexts and schema before deployment.
• Use strong administrator and service-account credentials.
• Restrict anonymous reads and write access.
• Use TLS for credentials and directory data in transit.
• Back up directory data and test restoration.

TLS provides encryption, server authentication, and integrity for network communication. A deployment normally contains a private key, leaf certificate, intermediate chain, service configuration, and renewal process.

Certificate checklist

• Confirm subject alternative names match the hostname.
• Check validity dates and issuer chain.
• Protect private keys with restrictive permissions.
• Test from a client perspective after deployment.
• Automate renewal and reload services safely.

Apache commonly serves static content, reverse proxies applications, terminates TLS, and writes access and error logs. Configuration is modular, and exact paths vary by distribution.

Deployment checklist

• Define the listening address and ports.
• Configure virtual hosts and document roots.
• Disable directory listing unless required.
• Set ownership and permissions for web content.
• Enable TLS and security headers where appropriate.
• Validate configuration before reload.

MySQL and MariaDB are relational database systems. Treat database deployment as an application dependency: define storage requirements, authentication, backup strategy, recovery objectives, connection limits, and patching procedures.

Security essentials

• Do not expose database ports broadly to untrusted networks.
• Use separate application accounts with minimum privileges.
• Protect backups because they contain sensitive data.
• Monitor slow queries, storage, connections, and replication where applicable.

Mail systems combine multiple components: Postfix commonly handles SMTP transport, while Dovecot provides IMAP and POP3 access. DNS records, reverse DNS, authentication, TLS, spam controls, queue monitoring, and reputation all affect deliverability.

Operational safeguards

• Do not operate an open relay.
• Use authenticated submission for clients.
• Require TLS where appropriate.
• Monitor queue growth and deferred mail.
• Configure SPF, DKIM, and DMARC according to organizational requirements.

Traditional FTP transmits control and data connections separately and does not provide encryption by itself. Anonymous FTP should be considered legacy and used only when explicitly required, isolated, and protected by policy.

Safer design

• Prefer SFTP over SSH or HTTPS-based transfer.
• If anonymous access is required, restrict it to a dedicated directory.
• Prevent uploads from becoming executable content.
• Monitor disk usage and access logs.
• Do not expose sensitive data through public download paths.

SSH is the preferred remote administration protocol for Linux servers. Use unique accounts, key-based authentication, access restrictions, logging, and controlled privilege escalation.

SSH hardening

• Disable direct root login where policy permits.
• Restrict allowed users or groups.
• Use strong keys and protect private keys.
• Limit forwarding features when unnecessary.
• Monitor authentication logs and failed attempts.

VNC and X11 forwarding may be useful for specific graphical tasks, but they increase complexity and should be protected through SSH tunnels or private networks.

Traffic monitoring should distinguish bandwidth utilization from packet loss, errors, retransmissions, latency, and application response time. Capture a baseline before diagnosing abnormal behavior.

Investigation sequence

1. Check interface link and address state.
2. Review routes and default gateway.
3. Inspect socket listeners and connection counts.
4. Check interface errors and drops.
5. Test DNS and destination ports.
6. Correlate network data with application and system logs.

Logs are evidence. Establish a timeline, preserve relevant entries, correlate multiple sources, and avoid deleting or modifying evidence during an incident.

Useful journal filters

• Boot: current or previous boot.
• Unit: one service.
• Priority: errors and above.
• Time: a defined investigation window.
• Identifier: kernel, sshd, sudo, or another component.

Backups must be planned around recovery point objective, recovery time objective, retention, off-host copies, encryption, immutability where required, and regular restore testing.

Backup patterns

• File-level: selective restoration and efficient synchronization.
• Block-level: image-based recovery for compatible disks and systems.
• Archive: portable bundles for long-term storage.
• Application-aware: consistent database or application state.

Never treat a successful backup job as proof of recoverability until restoration has been tested.

Patching is a lifecycle process: inventory, risk assessment, testing, approval, deployment, validation, and rollback or remediation. Kernel updates may require reboot planning; application updates may require service restarts.

Patch workflow

1. Review advisories and affected systems.
2. Confirm backups and rollback options.
3. Test in a representative environment.
4. Apply updates during an approved window.
5. Validate services, monitoring, and application health.
6. Record versions and evidence.

Bash is effective for orchestration of existing command-line tools. Use Python or another language when data structures, error handling, portability, or API integration become complex.

Script quality principles

• Quote variables unless word splitting is intended.
• Validate arguments and required commands.
• Use meaningful exit codes.
• Log actions and errors.
• Use temporary files safely.
• Test with non-production data first.

Core constructs

RPM is the package format and database; YUM and DNF resolve dependencies and interact with repositories. Prefer supported repositories and verify package origin before installation.

Common tasks

• Search by name or description.
• Inspect package metadata and files.
• Install or remove packages with dependency resolution.
• Review transaction history.
• Verify installed files where appropriate.

LVM separates physical storage from logical allocation. A typical design is disk or partition → physical volume → volume group → logical volume → filesystem → mount point.

Planning rules

• Confirm the correct device using serials, WWNs, and lsblk.
• Understand filesystem growth and shrink limitations.
• Back up data before storage changes.
• Use persistent UUIDs or stable device identifiers in /etc/fstab.
• Monitor free space in both the volume group and filesystem.