English:Systems Administration
Systems Administration
Introduction
Systems Administration is the disciplined practice of keeping computer systems reliable, secure, maintainable, and useful to the people and services that depend on them. A system administrator works across operating systems, servers, networks, storage, identities, applications, virtualization platforms, cloud services, monitoring systems, and organizational processes. The role combines technical depth with careful change management, documentation, communication, and risk judgment.
At university level, you should treat systems administration as more than learning commands. The important question is how components interact: how an authentication failure can look like a network problem, how a storage bottleneck can become an application outage, how a rushed software update can break dependencies, and how automation can either reduce or amplify mistakes. You therefore need a systems view as well as practical command-line skill.
A modern administrator may work with physical servers, virtual machines, containers, managed cloud services, or a hybrid of all four. The underlying goals remain similar: preserve availability, protect data and access, understand capacity, make changes safely, detect failures early, and restore service when prevention fails.
Learning Outcomes
After completing this aiMOOC, you should be able to explain the responsibilities of a system administrator, navigate and inspect a Linux system, reason about users and permissions, manage services, interpret networking and DNS behavior, plan storage and backups, use monitoring data, automate repeatable configuration, compare virtualization with containers, apply security hardening principles, and design operational procedures for incidents and change.
You should also be able to justify administrative choices. For example, you should be able to explain why a particular backup schedule fits a recovery objective, why a service account should have narrower permissions than a human administrator, or why an automated deployment requires validation and rollback.
The Systems Administration Mindset
Systems administration is a socio-technical activity. Technical components matter, but so do users, organizational policies, maintenance windows, budgets, compliance requirements, and human error. Good administrators make the state of a system observable, minimize unnecessary complexity, automate carefully, and keep enough documentation that another competent person can understand and recover the environment.
Three ideas are especially important. Least privilege means giving users, services, and administrators only the permissions they need. Defense in depth means combining independent safeguards rather than trusting a single control. Reproducibility means that important configurations can be rebuilt from documented procedures or code instead of depending on memory.
A useful operational loop is: establish the intended state, measure the actual state, compare the two, change the system safely, verify the result, and record what happened. This loop applies to patching, capacity, security, configuration management, troubleshooting, and incident response.
Operating System and Command-Line Foundations
Files, Directories, and the Shell
On Unix-like systems, many administrative tasks are exposed through files, processes, devices, and text-based interfaces. The shell lets you combine small tools into repeatable workflows. Important commands include pwd for the current directory, ls for directory contents, cp and mv for file operations, grep for text filtering, find for searching, and less for controlled viewing.
You should understand absolute and relative paths, hidden files, symbolic links, ownership, permissions, standard input, standard output, standard error, pipes, redirection, and shell quoting. Administrative mistakes often come from incorrect path assumptions or unsafe expansion of shell variables, so you should inspect before changing and prefer commands whose effects you understand.
The directory /etc commonly stores system-wide configuration, /var stores changing data such as logs and spools, /home stores user home directories, and /tmp provides temporary space. These conventions can vary across operating systems and applications, so documentation and local policy remain important.
Packages and Software Lifecycle
Package managers install software while tracking versions, files, dependencies, and repositories. Debian-derived systems commonly use tools such as apt, while Fedora and Red Hat-derived systems commonly use dnf. A responsible update process separates routine patching from major version changes, reviews release notes for critical services, tests high-impact upgrades, and keeps a rollback or recovery path.
Unpatched software increases exposure to known vulnerabilities, but blind updating can also cause outages. The administrative task is therefore risk management: know what is installed, know what must be updated, understand dependencies, schedule change appropriately, and verify the result.
Identity, Authentication, and Authorization
User accounts, groups, service identities, and credentials are central to system security. Authentication answers who or what is requesting access. Authorization determines what that identity may do. Accounting and audit logging record relevant actions so that administrators can investigate behavior later.
On Linux, file permissions commonly distinguish the owning user, owning group, and others. Read, write, and execute rights have different effects on files and directories. Tools such as id, ls -l, chmod, chown, and getfacl help you inspect and manage access. The sudo mechanism can delegate privileged commands without requiring every administrator to share a root password.
Public-key authentication is especially important for remote administration. A private key should remain under the control of its owner, while a corresponding public key can be installed on systems that trust that identity. Strong key management still requires lifecycle controls: protect private keys, remove access when roles change, and avoid leaving unused authorized keys in place.
Processes, Services, and Boot
A process is a running program with an identifier, memory, open files, and credentials. Administrators inspect processes to understand load, dependency, ownership, and failures. Useful tools include ps, top, pgrep, kill, and nice. Sending a signal asks a process to take an action; abrupt termination should be a later choice, not an automatic first step.
Many contemporary Linux distributions use systemd as the system and service manager. It organizes services and other resources into units, controls startup dependencies, and integrates with the journal. Commands such as systemctl status, systemctl start, systemctl stop, systemctl restart, and systemctl enable are common. A good troubleshooting sequence checks service state, recent logs, configuration validity, listening sockets, resource limits, and dependencies before changing anything.
Storage and File Systems
Storage administration connects physical devices, logical volumes, file systems, mount points, redundancy, performance, and data protection. Tools such as lsblk, blkid, df, du, findmnt, and file-system-specific utilities help reveal capacity and structure. Capacity planning must distinguish space used by files, metadata, snapshots, logs, databases, and temporary workloads.
RAID can improve availability or performance by combining drives in different layouts, but RAID is not a backup. A mirrored or parity-protected array can still faithfully replicate accidental deletion, corruption, malicious encryption, or operator error.
A sound storage design therefore asks separate questions: How much capacity is needed? What performance is required? Which failures should the storage layer tolerate? Which data needs snapshots? Which data must be copied to an independent backup location? How quickly must the organization be able to restore it?
Networking, DNS, and Remote Access
Administrators need practical network reasoning. A host requires an interface configuration, an IP address, a route to relevant networks, and usually working name resolution. Tools such as ip addr, ip route, ping, ss, traceroute, dig, and curl help test different layers of connectivity.
A useful troubleshooting habit is to move from the local host outward. Verify whether the interface is up, confirm the expected address, check the routing table, test the default gateway, test a remote address, then test name resolution and finally the application protocol. This reduces guesswork and helps separate a DNS issue from a routing issue or an application issue.
Domain Name System
The Domain Name System maps names to information such as IP addresses. DNS is hierarchical and distributed. A client usually asks a recursive resolver, which may consult root, top-level-domain, and authoritative name servers as needed. Caching reduces repeated lookup work, so record changes can take time to become visible according to time-to-live values.
When diagnosing a name-resolution problem, compare direct IP connectivity with name-based connectivity, inspect resolver configuration, query relevant record types, and distinguish an authoritative answer from cached or recursive behavior.
Secure Shell
Secure Shell provides encrypted remote login, command execution, and related transport functions. SSH host keys help a client detect whether it is connecting to the expected server, while user authentication can rely on public keys, passwords, or other configured methods. Administrators should verify host-key changes rather than ignoring warnings, restrict privileged remote access according to policy, and remove obsolete credentials.
Remote access deserves special protection because it often crosses trust boundaries. Network filtering, multi-factor authentication where appropriate, key rotation, session logging, bastion hosts, and restricted administrative networks can reduce exposure.
Logging, Monitoring, and Observability
Logs are event records. Metrics are numerical measurements over time. Traces follow requests across components. Together they help administrators answer different questions about system behavior. A mature environment collects these signals centrally, protects their integrity, retains them according to policy, and attaches alerts to conditions that require action.
Monitoring should focus on service health rather than isolated numbers. High CPU usage may be acceptable if users receive fast responses, while a low CPU reading can still accompany a complete outage. Useful operational measures include request success rate, latency, resource saturation, queue depth, disk errors, certificate expiry, backup success, and capacity trends.
Alerting should be actionable. If every warning wakes an administrator, people learn to ignore alerts. Good alerts identify a real symptom, include enough context for first response, and link to a runbook or diagnostic path. This is closely related to site reliability engineering, which emphasizes measurable reliability targets and disciplined operational feedback.
Backup, Restore, and Disaster Recovery
A backup is valuable only if it can be restored. Administrators should define what data is protected, how frequently copies are made, where they are stored, how long they are retained, how they are encrypted, who can access them, and how restore tests are performed.
The recovery point objective describes the maximum acceptable amount of data loss measured in time. The recovery time objective describes the target time to restore a service after disruption. These objectives influence backup frequency, replication design, staffing, automation, and infrastructure cost.
A robust strategy often includes multiple independent copies and at least one copy that is isolated from ordinary administrative failures or destructive attacks. Restoration exercises should test both technical recovery and the documentation needed to carry it out under pressure.
Automation and Configuration Management
Manual administration does not scale well when the same change must be applied safely to many systems. Configuration management tools describe or enforce a desired state and help make changes repeatable. Infrastructure-as-code practices also make system intent reviewable and version-controlled.
Idempotence is a useful property: applying the same desired-state operation repeatedly should converge on the same result rather than creating duplicate or progressively damaged state. Idempotence does not remove the need for testing; it makes repeated automation easier to reason about.
Ansible is one example of an automation tool used for configuration, orchestration, and repeatable administration. A playbook can express desired packages, files, services, users, and other resources. Administrators should review changes, protect secrets, test against representative systems, and make scope explicit before running automation broadly.
Automation can make one person effective across hundreds of systems, but it can also turn a small error into a large outage. Safe automation therefore uses version control, code review, staged rollout, validation, observability, and rollback.
Virtualization, Containers, and Cloud Systems
A virtual machine emulates or virtualizes a complete machine environment and normally runs its own guest operating-system kernel. A container packages an application and its dependencies while sharing the host kernel through operating-system isolation mechanisms. These approaches have different security boundaries, performance characteristics, management models, and operational costs.
Containers encourage immutable images and rapid replacement rather than hand-editing long-lived instances. Administrators must still manage host security, image provenance, secrets, networking, persistent storage, resource limits, logging, vulnerability management, and orchestration.
Cloud administration shifts some responsibilities to a provider but does not eliminate administration. You still need identity and access management, network design, cost controls, patch strategy for systems you manage, logging, data protection, encryption, and incident response. The practical question is always which layer is managed by you and which is managed by the provider.
Security Hardening
Hardening reduces unnecessary exposure while preserving required functionality. Common principles include removing or disabling unused services, applying security updates, restricting network access, using strong authentication, protecting secrets, enforcing least privilege, maintaining trusted time synchronization, centralizing relevant logs, and monitoring configuration drift.
A secure baseline should be documented and versioned. Exceptions should be explicit, justified, and reviewable. Security settings also need operational testing: an access control that blocks emergency recovery can be as dangerous as an access control that is too weak.
Administrators should distinguish prevention, detection, response, and recovery. No single control guarantees safety. A firewall may limit reachability, authentication controls identity, authorization limits actions, logging supports investigation, backups support recovery, and segmentation can reduce the spread of a compromise.
Reliability, Change, and Incident Management
Systems fail because hardware fails, software contains defects, dependencies become unavailable, capacity is exhausted, credentials expire, networks partition, and people make mistakes. Reliability engineering assumes that failures are possible and designs recovery paths before they happen.
A planned change should state the objective, scope, prerequisites, validation checks, expected impact, rollback path, communication plan, and responsible owner. High-risk changes benefit from peer review and staged deployment. After the change, verify not only that a command succeeded but that the service behaves as intended.
During an incident, establish a shared view of impact, stabilize the service, assign clear roles, communicate status, preserve useful evidence, and record a timeline. Afterward, a blameless review should examine contributing conditions and identify improvements to design, tooling, documentation, training, or process.
Documentation and Operational Knowledge
Documentation is part of the system. Inventories identify what exists. Architecture diagrams explain dependencies. Runbooks describe routine procedures. Incident playbooks define coordinated responses. Change records explain what was altered. Configuration repositories preserve machine-readable intent.
Good operational documentation is specific enough to act on, but not so brittle that every minor version change makes it useless. It should state assumptions, prerequisites, verification steps, ownership, and recovery actions. Keep secrets out of ordinary documentation and point to approved secret-management systems instead.
A useful test is whether another qualified administrator can answer three questions: What is this system supposed to do? How can I tell whether it is healthy? What should I do when it is not?
Practical Administration Workflow
For a new server or service, begin by identifying its purpose, owners, data sensitivity, dependencies, network exposure, and recovery requirements. Establish a baseline configuration, document it, and automate repeatable settings where practical.
Next, make the service observable. Confirm that logs, metrics, health checks, and alerts reveal meaningful failures. Define backup and restore requirements, test recovery, and record who is responsible for decisions during incidents.
Finally, keep the system maintainable. Patch it, remove obsolete access, review capacity, rotate credentials according to policy, verify backups, test automation, review alerts, and retire the system cleanly when it is no longer needed.
Interactive Tasks
Quiz: Test Your Knowledge
What is a primary goal of systems administration? (Reliable secure and maintainable operation) (!Maximum hardware use at all times) (!Elimination of all human involvement) (!Permanent avoidance of software updates)
Which location commonly stores system-wide configuration on Linux? (The etc directory) (!The home directory) (!The tmp directory) (!The media directory)
What does the principle of least privilege require? (Grant only the access needed for the task) (!Give every administrator unrestricted access) (!Store credentials in shared documents) (!Disable logging for privileged actions)
Which component commonly manages services on many modern Linux distributions? (systemd) (!DNS) (!RAID) (!SSH)
Why is RAID not a complete backup strategy? (It cannot protect against every form of data loss) (!It never uses more than one disk) (!It cannot improve availability) (!It always stores data off site)
What is the primary purpose of DNS? (Map names to network information) (!Encrypt file systems) (!Schedule operating system processes) (!Mirror storage blocks)
What does SSH primarily provide for administrators? (Encrypted remote access) (!Disk redundancy) (!Package dependency resolution) (!Database normalization)
What does idempotence mean in configuration automation? (Repeated application converges on the same desired state) (!Every run creates a different state) (!Automation requires manual editing after each step) (!Configuration is stored only in memory)
What should an operational alert ideally indicate? (A condition that requires meaningful action) (!Every small metric fluctuation) (!Only successful user logins) (!The total number of installed files)
What does a recovery point objective express? (Maximum acceptable data loss expressed as time) (!Maximum number of administrator accounts) (!Minimum processor frequency) (!Target number of network interfaces)
Memory Game
| Idempotence | Repeating automation gives the same desired state |
| RPO | Maximum acceptable data loss window |
| RTO | Target time to restore a service |
| Daemon | Background service process |
| Baseline | Approved reference configuration |
| Runbook | Procedure for an operational task |
Drag and Drop
| Match the correct terms. | Systems Administration |
|---|---|
| DNS | Resolves names to network information |
| SSH | Provides encrypted remote administration |
| RAID | Combines disks for redundancy or performance |
| systemd | Manages services and boot-related units |
| Ansible | Applies repeatable configuration across systems |
Match each technology to the administrative function it most directly supports, then explain one limitation of each technology.
Crossword Puzzle
| Daemon | What word describes a background service process on a Unix-like system? |
| Kernel | What core operating-system component manages hardware and system resources? |
| Logging | What practice records events so that administrators can investigate system behavior? |
| Firewall | What security control filters network traffic according to rules? |
| Backup | What independent data copy supports restoration after data loss? |
| Ansible | What automation tool can apply repeatable configuration to many systems? |
LearningApps
Cloze Text
Open-Ended Tasks
Easy
- System Inventory: Create a one-page inventory for a lab machine that records operating system, hostname, interfaces, storage, important services, and administrative owner.
- Permission Audit: Inspect a set of sample files and directories, explain their owners and permissions, and propose one least-privilege improvement.
- Service Observation: Choose one running service, record its status, process identifier, listening socket if any, and recent log messages, then explain how the evidence fits together.
- Network Path Sketch: Draw a diagram showing how a client reaches a named web service through local networking, routing, DNS resolution, and the destination application.
Standard
- Backup Plan: Design a backup policy for a small university research server, including protected data, frequency, retention, encryption, restore testing, and recovery objectives.
- Monitoring Dashboard: Build or prototype a dashboard for one service that distinguishes availability, latency, saturation, and capacity, then justify each selected metric.
- Configuration Automation: Write a small Ansible playbook or equivalent configuration definition that creates a user, installs a package, deploys a configuration file, and ensures a service is running.
- Incident Interview: Interview an administrator or technical staff member about a past outage, then reconstruct the timeline, symptoms, diagnostic steps, communication choices, and lessons learned.
Advanced
- Hardening Baseline: Develop a defensible security baseline for a Linux server, map each control to a risk, identify likely operational trade-offs, and specify how exceptions would be reviewed.
- Failure Injection Lab: In an isolated test environment, deliberately stop a service, fill a temporary file system, or break a safe configuration copy, then measure detection and recovery while documenting every step.
- Hybrid Architecture Review: Design a small hybrid environment using local systems and a cloud service, then analyze identity boundaries, network paths, backups, observability, cost, and shared responsibility.
- Automation Safety Review: Produce a short video or demonstration showing how a configuration error could propagate through automation, then redesign the workflow with review, staging, validation, and rollback.
Learning Assessment
- Reliability Analysis: Given a service with repeated brief outages, combine logs, metrics, dependency information, and recent changes to form and rank plausible hypotheses before proposing tests.
- Access-Control Design: Design user, group, service-account, and administrative access for a shared research server and justify how your model applies least privilege without blocking legitimate work.
- Recovery Design: Compare two backup architectures for a critical dataset and argue which better satisfies stated recovery point, recovery time, security, and cost requirements.
- Change Proposal: Write a production change plan for a major service upgrade that includes prerequisites, staged rollout, validation, communication, rollback, and post-change observation.
- Incident Review: Analyze a hypothetical outage caused by interacting storage, DNS, and configuration problems, then identify technical and process improvements that would reduce recurrence.
- Automation Evaluation: Review a configuration-management design for idempotence, secret handling, blast radius, validation, and auditability, then recommend concrete improvements.
Evidence of Learning
Knowledge: You can explain operating-system organization, service management, storage, networking, DNS, SSH, identity, permissions, backups, monitoring, automation, virtualization, containers, security, and operational reliability as connected parts of an administered environment.
Skills: You can inspect system state, interpret logs and metrics, diagnose failures systematically, manage accounts and permissions, verify services and network behavior, plan backups, automate repeatable configuration, and validate changes.
Products: Your evidence can include inventories, architecture diagrams, runbooks, backup plans, monitoring dashboards, hardening baselines, automation code, change plans, incident timelines, and recovery-test reports.
Transfer achievements: You can apply the same reasoning to unfamiliar environments, compare alternative technologies according to operational goals, identify hidden dependencies, justify trade-offs, and design safer processes for systems you did not originally build.
OERs on the Topic
Linked Learning Areas
Systems administration connects computer science theory with practical information technology operations. It is especially relevant to operating systems, networking, cybersecurity, distributed systems, cloud computing, DevOps, platform engineering, and site reliability engineering. In professional settings, the work overlaps with network administration, security administration, cloud engineering, database administration, and service operations.
aiMOOC Projects
MOOCwiki · Deutsch
Nach dem Lernen ist vor dem Lernen
Entdecke direkt den nächsten Lernkurs. Weitere Inhalte erscheinen, wenn Du weiter nach unten scrollst.
Zur MOOCwiki-HauptseiteMediathek
Mediathek
Mediathek wird aus dem Wiki geladen ...
Keine passenden Inhalte gefunden. Bitte ändere Suche oder Filter.