Career path
Linux Administrator
Keep Linux servers available, secure and up to date, put them into service reproducibly and bring them back when they break.
Aim for this jobWhat this job does
- 7 responsibilities
- 16 missions
- 62 skills
- 258 hours of work an estimate, starting from zero
The job
What a Linux Administrator does
Seven responsibilities. Each one is carried out through concrete missions, which require skills.
Put secure servers into service
Missions that make it up
-
Migrate a service and its data to a new server
Deliverablea service and its data moved, checked and back in service on a new server
-
Manage a team's accounts and access
Deliverableaccounts and groups created, privileged rights restricted, key-based SSH access
-
Put a server into production
Deliverablea hardened Linux server, its storage configured, its services started at boot and checked after a reboot
- Administer a systemd service
- Prepare local storage: disks, partitions, file systems and mounting
- Manage a server's accounts and delegation: users, groups, LDAP directory, sudo and ACLs
- Filter a server's traffic with a host firewall, NAT included
- Run a server under SELinux or AppArmor: modes, contexts and troubleshooting
- Manage logical volumes, software RAID and disk encryption
-
Harden a server and measure its compliance
Deliverablea hardened server (access, confined services) and a replayable gap report against a baseline
- Manage a server's accounts and delegation: users, groups, LDAP directory, sudo and ACLs
- Filter a server's traffic with a host firewall, NAT included
- Run a server under SELinux or AppArmor: modes, contexts and troubleshooting
- Measure a server's gap to a hardening baseline and prioritize the measures (ANSSI-BP-028, CIS)
- Harden a server's access and privileges: SSH, PAM, sudo, permissions and scheduling
- Harden boot, mounts and the local session: GRUB, nodev, nosuid, noexec, banners, dconf
- Harden the running kernel: persistent sysctl parameters and blocked modules
- Confine a service: mandatory access control (SELinux or AppArmor), then systemd sandboxing
-
Configure a server's network and troubleshoot it
Deliverablean interface, its routes and name resolution made persistent, the local firewall set, a fault located layer by layer
Also required, outside missions
Diagnose and repair a server
Missions that make it up
-
Bring a broken server back
Deliverablea repaired server whose services are restored and stay so after a reboot
Run and maintain a fleet
Missions that make it up
-
Grow a server's storage without downtime
Deliverablea volume extended online, a network share mounted, persistent mounts
-
Apply a change with a planned rollback
Deliverablea change applied after a snapshot or a reversible transaction, documented, and its rollback tested
-
Keep a server fleet up to date and under control
Deliverablea fleet updated without downtime, its drift detected, its recurring tasks automated and monitored
-
Monitor a service and act on alerts
Deliverablemetrics collected, a dashboard and actionable routed alerts
Also required, outside missions
Ensure continuity and capacity
Missions that make it up
-
Ensure a service's continuity and capacity
Deliverablea recovery plan proven by a drill, recovery objectives (RTO, RPO) met and anticipated capacity
-
Back up a server and prove it restores
Deliverablea scheduled off-machine backup and a timed restore, checked file by file
Run operations over time: on-call and documentation
Missions that make it up
-
Hold on-call and document operations
Deliverablean on-call rota and its escalation defined, every alert linked to its runbook, an incident handled through to recovery
Automate fleet administration
Missions that make it up
-
Configure a fleet as code
Deliverableservers configured by idempotent Ansible roles, replayed without drift
-
Replay a server's commissioning as code
Deliverablethe production server rebuilt by a playbook: inventory described, packages and repositories, services and scheduled tasks, accounts and keys, storage, files rendered from templates or edited, hardening; replayed with no change
- Describe a fleet in a static Ansible inventory: groups, variables and patterns
- Make Ansible tasks conditional and repeat them with when and loop
- Copy, fetch and archive files with Ansible idempotently
- Edit an existing configuration file with Ansible without rewriting it
- Drive a host's services, scheduled tasks, hostname and reboots with Ansible
- Manage accounts, groups, SSH keys and sudo rights with Ansible
- Harden a host with Ansible: firewall, SELinux and kernel parameters
- Partition, format and mount storage with Ansible, LVM included
- Generate a configuration file through Ansible from a Jinja2 template
- Install packages and declare repositories with Ansible across distributions
Also required, outside missions
Provide disposable, reproducible virtual machines
Missions that make it up
-
Build a disposable, reproducible virtualised environment
Deliverablea hypervisor whose hardware virtualisation is verified, virtual machines created from an image and configured from their first boot, connected to the network with a published service, destroyed then recreated identically
Also required, outside missions
The means
With which tools?
Choose your tools: the choice changes the lessons to read, never the responsibilities.
Automation language
Hypervisor
Going further
Specialisations
Optional, measured apart from the job.
Automate and tool up in Python
- Read and transform data (JSON, YAML, APIs)
- Write a tested command-line tool
- Manipulate lists, tuples, sets and slices in Python
- Process and generate text in Python: strings, regex, dates and Jinja templates
- Organize code into modules and publish a package on PyPI
- Manage Python versions, dependencies and installed tools (pyenv, pipx, Poetry)
- Test in isolation and across Python versions (unittest, mock, tox)
- Audit the quality and security of a project's code and dependencies
- Read, install and modify a small Python tool
- Run pytest tests, read a failure and fix a simple defect
Run containers
- Place and drive a container's execution layers: OCI runtime, engine and orchestrator
- Run containers, persist data and connect them
- Operate and troubleshoot Docker containers: lifecycle, logs, inspection and daemon
- Explain and inspect a Linux container's isolation: namespaces, cgroups, capabilities, seccomp
- Set up rootless Podman and explain its daemonless model
- Group containers into pods and replay a Kubernetes manifest locally
- Run Podman containers as systemd services with Quadlet
Diagnose a service backed by a relational database
Administer the network of servers and site
- Understand the local network: Ethernet, MAC and ARP
- Operate IPv6: link-local, SLAAC, NDP and dual-stack
- Understand and troubleshoot DHCP address assignment
- Segment a network with VLANs
- Capture and read network traffic
- Read an HTTP(S) exchange and troubleshoot an application error
- Troubleshoot email deliverability
- Inventory the exposed services of a host or a network
- Troubleshoot a TLS error and produce a certificate
Run Ansible across a production fleet
- Query structured output with JMESPath (AWS CLI, Azure CLI, Ansible)
- Control playbook execution: parallelism, async, delegation and inclusion
- Connect Ansible to a Windows fleet
- Discover a fleet's hosts automatically with an Ansible inventory plugin
- Handle a failed Ansible task: recover, ignore or stop the play
- Run a raw command through Ansible idempotently and report it correctly
- Download a verified artifact and talk to an HTTP API from a playbook
- Build an Ansible inventory during the play or with a custom script
- Check preconditions and synchronize a playbook's execution
- Assemble Ansible roles in a playbook
Manage a fleet with Chef (CINC)
- Write a Chef cookbook and converge it idempotently, in a container then on a VM
- Make a cookbook configurable and portable: attributes, templates, Ohai
- Structure a maintainable cookbook: recipes, custom resources, notifications, lint
- Test a cookbook before and after convergence: ChefSpec, InSpec, Test Kitchen, CI
- Lock cookbooks with Policyfiles and deliver them without a server
- Run a fleet with a CINC server: enrollment, search, policy groups, pull mode
- Measure and fix a server's compliance with InSpec and Chef
- Protect a Chef fleet's secrets: encrypted data bags and chef-vault
Manage a fleet with Salt
- Drive a fleet remotely with Salt: master, minions, keys and targeting
- Describe a server's desired state in idempotent Salt states
- Make states generic with grains, pillars, Jinja and managed files
- Coordinate a Salt fleet: multi-node orchestration, Salt SSH and Reactor
- Industrialize Salt: GPG secrets, states from Git, a hardened master, automatic enrollment
Configure and audit a fleet with Rudder
Run KVM and libvirt
Run Incus and migrate a fleet to it
- Operate Incus instances: OCI images, storage, profiles, projects and GPUs
- Secure an Incus server and its remote administration
- Troubleshoot an Incus VM stuck at boot
- Automate Incus with Ansible: connection plugin, provisioning and custom images
- Migrate to Incus: VMware VMs, an LXD installation, a physical or virtual machine
Run Proxmox VE
Trace and harden the kernel with eBPF
Harden an immutable server declaratively (NixOS)
Administer a self-hosted Git forge (Forgejo)
- Set up Forgejo on PostgreSQL behind a TLS proxy, reachable over HTTPS and SSH, then configure mail, LFS and sign-ups
- Govern access to Forgejo: organisations, teams and permissions, sign-in through an OIDC provider with an enforced second factor, and account support from the command line
- Monitor Forgejo through its logs and Prometheus metrics, fire an alert and diagnose a database outage
- Secure a Forgejo instance: webhooks kept off the internal network, brute force banned with fail2ban, a break-glass administrator account, scoped tokens and signed commits
- Back up Forgejo, copy the encrypted backup off the machine, restore it on a blank stack and write the recovery runbook
- Maintain Forgejo and upgrade it: scheduled tasks, doctor and quotas, an upgrade rehearsed on a copy with validation criteria and rollback from the backup
What the site does not cover yet
Monitoring: taught by the Observability training, whose labs run on Minikube; knowing how to run containers (container.run) is therefore a prerequisite. A container-free path (node_exporter and Prometheus under systemd) is being prepared.