learn/CompTIA Linux+

Start here

What the CompTIA Linux+ exam is, where Linux came from and why it ended up everywhere, how to work through these lessons, how to set up a machine to practise on, and what is in the track.

Start here·Intro·9 min read·updated ·linux-plusorientation

What you will be able to do

  • Decide whether this exam is the right one for you to sit
  • Explain in one paragraph why Linux skills are worth certifying
  • Work through a topic the way it was designed to be worked through
  • Set up a virtual machine to practise on, and snapshot it before breaking it
  • Find the study plan, the coverage report, and the practice sets

This page teaches no Linux. It tells you what the exam is, why the subject is worth your evenings, how these lessons are built, how to get a machine to practise on, and what is in the track. The Linux starts on the next page.

What the CompTIA Linux+ exam is

A vendor-neutral certification covering the administration of Linux servers: managing them, securing them, automating them, and fixing them when they break. Vendor-neutral matters here. It is not a Red Hat exam or an Ubuntu exam, so it tests the split between distribution families rather than the habits of one.
Code XK0-006, also labelled V8
Questions Maximum of 90, multiple-choice and performance-based
Time 90 minutes
Passing score 720 on a scale of 100 to 900
Languages English
Delivery Pearson VUE, at a test centre or online through OnVUE
Valid for Three years, renewable with 50 CEUs
Recommended experience 12 months of hands-on work with Linux servers

Five domains, sorted here by weight rather than by number, because that ordering is the one that should decide where your time goes:

Domain Weight
1.0 System Management 23%
5.0 Troubleshooting 22%
2.0 Services and User Management 20%
3.0 Security 18%
4.0 Automation, Orchestration, and Scripting 17%

Two things follow from that table. Troubleshooting is within a point of the largest domain, and most study material treats it as a closing chapter; this track gives it fourteen topics. And automation is not a footnote: seventeen percent covers configuration management, orchestration, two languages, and version control.

The scale is not a percentage. 720 out of 900 is not 80 percent, because the scale starts at 100, and CompTIA does not publish how raw answers map onto it. Any tool showing you a scaled score, this site included, is approximating.

Performance-based questions drop you into a simulated tool or a real virtual machine and score the state you leave behind. They are why twelve months of hands-on experience is the recommendation rather than a formality, and they are the reason this site alone is not enough. More on that below.

Where Linux came from, and why it is everywhere

Worth five minutes, because it explains why the exam is shaped the way it is.

In 1983 the GNU Project set out to build a complete free operating system, and by the end of the decade had most of one: the compiler, the shell, the core utilities, the text tools. What it did not have was a working kernel.

In 1991 a student in Helsinki, Linus Torvalds, started a kernel as a personal project and released it under a licence that let anyone use, modify, and redistribute it, provided derivative work carried the same freedoms. The GNU tools and that kernel fit together, and the combination was a complete operating system that nobody owned.

That licensing decision is the whole story. Because no single company controlled it, hardware vendors, universities, and eventually every large technology company could adopt it, modify it for their own purposes, and contribute back. The result is a kernel developed at a scale that no single organisation funds.

Where it ended up:

  • All 500 of the world’s fastest supercomputers run Linux. Not most. All of them, and that has been true for years.
  • Cloud infrastructure runs on it. The instances, the hypervisors underneath them, and the container images inside them.
  • Containers are a Linux feature. Namespaces and cgroups are kernel facilities; Docker and Podman are interfaces to them. Container platforms on other operating systems run a Linux virtual machine to provide them.
  • Android is built on the Linux kernel, which is why the most common consumer operating system on earth is a Linux one.

For someone administering systems, the practical version is simpler: the servers are Linux, the pipelines run on Linux, the containers are Linux, and the security controls you are asked to validate are Linux controls. That is what makes the skill worth certifying, and it is why this exam leans on troubleshooting and automation rather than on trivia.

How to work through these lessons

Every topic has the same shape, so once you have read two you know where to look in the third:

Section What it is for
Before you read A question you cannot yet answer. Attempt it anyway.
Some words you will need The vocabulary the rest of the topic assumes
What breaks without this The consequence of not knowing it
Predict Captured output hidden behind a question. Answer first, then open.
If you already administer Linux Depth for readers who have done this before. Safe to skip.
Across distributions Where the RHEL and Debian families diverge
Prove it The commands that show the change took effect
What trips people up The failures you will actually hit, with the real error text
Work it through A scenario reasoned out on the page
Try it Optional, if you have a machine handy
Check yourself Retrieval questions, for next week rather than now
References Every source, with the date it was checked

The troubleshooting topics carry two more. For the exam is the compressed version worth taking into the test centre, and Where this sits places the topic against the objectives. Diagrams turn up wherever a concept is structural rather than in a section of their own.

Three habits make the difference between reading this and learning it.

Attempt the Before you read prompt. Getting it wrong is not a failure mode, it is the mechanism. An answer you guessed at and missed sticks better than one you were handed, and that is a measured effect rather than a motivational sentiment.

Commit before you open a Predict block. Some command output is hidden behind a question. Decide on your answer first. Output you have already been shown teaches you very little, and reading it feels productive, which is exactly the problem.

Answer last week’s Check yourself questions from memory before you reread anything. This is the step people skip, and it is the one carrying most of the benefit. Rereading feels like progress because the words come easily the second time. That feeling is fluency, not knowledge, and it is the most reliable way to walk into an exam confident and underprepared.

The three things alongside the topics

What it is for
Study plan Topics across weeks, each week’s reading returning the following week. Start here if you have a date booked.
Objective coverage Every objective, which topics cover it, how many questions target it. This is where you find gaps, including gaps in this site.
Full practice exam Weighted to the real domain percentages and timed. The readiness check, and where the exam-day technique lives.

Practice sets cover one domain at a time. They are useful for finding a weak area and deliberately not much use for anything else: a set where every question comes from the same domain never makes you choose an approach, so it flatters you.

This site is the reading half

Performance-based questions are scored on the state you leave a system in, and no amount of reading produces that. Reading gets you the understanding; a machine you can break and fix gets you the fluency.

This track does not simulate a terminal, and it should not. These do it better than a study site could:

Where What it is good for
SadServers Break-fix scenarios on real machines. The closest free thing to a Linux+ PBQ.
OverTheWire: Bandit Command-line fluency through puzzles. Builds the speed that keeps you inside the clock.
Linux Upskill Challenge Twenty days on a server you administer yourself. Builds the habit.

A virtual machine of your own beats all of them, because you can break it in ways a curated exercise will not. Any distribution on CompTIA’s recommended list will do: AlmaLinux, Debian, Fedora, openSUSE or SLES, Red Hat Enterprise Linux, Rocky, or Ubuntu.

Getting a machine to practise on

Do this before the next page. Most topics here end with a Try it section that assumes you have somewhere to type, and the exam assumes twelve months of doing exactly that.

Start with one distribution and add the second around topic 08. The exam is vendor-neutral and tests where the two families diverge, so you eventually want one of each: AlmaLinux or Rocky on the RHEL side, Debian or Ubuntu Server on the other. Which one you begin with matters far less than beginning.

How to run it depends on what you are sitting at:

Host What to use
Mac, Apple Silicon UTM, which is free and open source. Download the distribution’s arm64 image.
Mac, Intel UTM or VirtualBox
Windows VirtualBox, or Hyper-V if you have Pro or Enterprise
Windows, quick option wsl --install, with the caveat below
Linux virt-manager over KVM, which is already in your package manager
Nothing local The smallest instance any cloud provider sells

The final step of the virt-manager new virtual machine wizard, headed Create a new virtual machine, step 5 of 5, ready to begin the installation. Fields are listed down the dialog: a name, the operating system, an install method reading local CDROM or ISO, memory of 4096 MiB, four CPUs, and a storage path ending in a qcow2 file. A tick box offers to customise the configuration before install, a collapsed section is labelled network selection, and Cancel, Back and Finish buttons sit along the bottom.

The last screen of the wizard, in virt-manager. Every tool in the table above asks the same five things under different names: what to call it, which ISO to boot, how much memory, how many CPUs, and where the disk file goes. Nothing here is permanent, which is the part worth knowing before you start clicking. The example is installing something other than Linux, and it makes no difference to the fields. Photo by VulcanSphere, GPL v2 or later.

Two vCPUs, 2 GB of memory, and 20 GB of disk carry you through the whole track. Choose the server or minimal install rather than a desktop, because that is what the exam is written against and it boots in seconds.

WSL is the fast route and it cannot teach you everything. It runs a Microsoft kernel with no bootloader and no real disks attached by default, so the boot topic, most of the kernel module topic, and everything from disks through RAID will not behave. Use it for the shell, scripting, text processing, and permissions. Use a real virtual machine for the rest. If you go this way, systemd needs turning on deliberately: put [boot] and systemd=true into /etc/wsl.conf and run wsl --shutdown.

Take a snapshot the moment the install finishes, before you have done anything. This is the habit that makes the rest of the track work. You are about to deliberately break things: fill a disk, corrupt an fstab entry, lock an account out, misconfigure a firewall until you cannot reach the machine. All of that is the point, and it is only the point if getting back costs you thirty seconds rather than an evening. Snapshot again before any topic that changes system state.

One practical note. Work over ssh from your own terminal rather than in the hypervisor’s console window, because copy and paste works properly and scrollback survives. Topic 43 covers ssh properly; for now, ssh yourname@the-vm-address is the whole of it.

Running on arm64 changes nothing that matters here. Every distribution on that list publishes arm64 images, and the commands are identical.

References

Pictures. The screenshot on this page is a freely licensed file from Wikimedia Commons, downloaded and served from this site rather than linked across to somebody else’s server. It is unaltered.

Domain weightings and exam details are CompTIA’s published figures. The objectives document itself is copyright CompTIA and is not reproduced here.

Every topic in this track

Generated from the collection, so it cannot fall behind what is actually written. 81 topics so far.

  1. Start hereWhat the CompTIA Linux+ exam is, where Linux came from and why it ended up everywhere, how to work through these lessons, how to set up a machine to practise on, and what is in the track.Intro
  2. The terminal, and how a command worksWhat the black window actually is, what the prompt is telling you, and the three parts every command is built from. The first thing to learn, and the thing everything else assumes.Intro·1.5
  3. Getting help on any commandHow to answer your own questions about a command you have never seen, why the same name can have two completely different manual pages, and how to read a synopsis line.Intro·1.5
  4. Moving around the filesystemWhere you are, how to go somewhere else, and how to describe a location two different ways. Three commands that everything else in this track assumes you can already use.Intro·1.5, 2.1
  5. Linux fundamentals and the FHSWhere files actually live and why, what the usr-merge changed underneath you, and how to tell which distribution family you are on before you type a command that only works on half of them.Intro·1.1
  6. Reading and editing filesLook inside a file without opening an editor, then change one line and save it. Plus the four commands that create, copy, rename, and delete, one of which does not ask twice.Intro·1.5, 2.1
  7. Users, root and sudoWhy a machine you own tells you permission denied, who root is, and how to borrow root's authority for one command at a time without becoming a hazard.Intro·2.2, 3.3
  8. Reading and setting permissionsThe ten characters at the start of every ls -l line, what each one grants, how to change them in two different notations, and why the execute bit on a directory has nothing to do with running anything.Working knowledge·2.1, 3.3
  9. Installing softwareThere is no download button. Instead there is a signed catalogue your machine already trusts, three commands that do the same job on different distributions, and a good reason not to curl a binary off the internet.Intro·2.4
  10. How Linux bootsThe five stages between the power button and the login prompt, what each one hands to the next, and why knowing the order turns an unbootable machine from a mystery into a short list.Working knowledge·1.1
  11. The kernel and modulesWhy a Linux kernel can support tens of thousands of devices without being enormous, how drivers get loaded on demand, and the four commands for inspecting, loading, and refusing them.Working knowledge·1.2
  12. Hardware and device discoveryYou have been handed a server and no documentation. The commands that tell you what CPU, how much memory, which disks, which cards, and whether any of it is real hardware at all.Working knowledge·1.2
  13. Disks, partitions and filesystemsA new disk is attached and nothing can use it. Three separate steps stand between a lump of storage and a directory you can write to, and skipping any of them produces a different confusing error.Working knowledge·1.3
  14. Mounting and fstabThe filesystem exists and you still cannot save anything to it. What mounting actually does, the six fields of /etc/fstab, why you should never name a disk by its device, and the mount options that quietly override file permissions.Working knowledge·1.3
  15. LVMA partition's size is decided when you create it and changing it means moving data. LVM inserts a layer that makes size a runtime decision, and the one step everybody forgets is the one that makes it visible.Deep dive·1.3
  16. RAIDDisks fail. RAID is how a server keeps running through it, what each level costs you in capacity, and the commands for building an array, breaking one on purpose, and putting it back.Deep dive·1.3
  17. Network basics: addresses and routesTwo machines on the same desk cannot reach each other and both are configured. The four separate things every host needs, what a subnet mask actually decides, and why the answer is usually the third one.Intro·1.4
  18. Configuring networkingThe address is right, the machine works, and after a restart it is gone. Three different systems own network configuration depending on the distribution, and knowing which one is in charge is most of the job.Working knowledge·1.4
  19. Name resolution and DNSping 1.1.1.1 works and ping example.com does not, so the network is fine and something else is broken. Where a name actually gets turned into an address, in what order, and why dig and your application can disagree.Working knowledge·1.4
  20. Shell redirection and pipesA command printed four thousand lines and you needed six of them. Every program has one way in and two ways out, and once you can point those anywhere, small commands start doing large jobs.Working knowledge·1.5
  21. Text processingA log file has the answer somewhere in it. Six small commands that search, cut, count, and rewrite text, and the pipeline pattern that answers most questions you will ever ask of a log.Working knowledge·1.5
  22. The shell environmentThe same command, the same machine, and two different results depending on who runs it and how. What the environment is, how a command actually gets found, and which startup file runs when.Working knowledge·1.5
  23. Archiving and compressionArchiving and compressing are two different jobs that tar does in one command. What the flags mean, why the three compressors give wildly different sizes, and the extraction that scatters files across your home directory.Working knowledge·1.6
  24. Backup and restoreEvery organisation has backups. Rather fewer have restores. What the three backup types actually cost, the rsync flag that decides whether you copied a directory or its contents, and why a backup you have not restored is a hypothesis.Working knowledge·1.6
  25. VirtualizationSix servers on one box, each convinced it owns the hardware. What a hypervisor actually does, how a container differs from a virtual machine in one measurable way, and the four network modes that decide whether anyone can reach the thing.Working knowledge·1.7
  26. Links, hard and symbolicDelete a file and it is still there under another name. What a filename actually is, the two kinds of link and how they fail differently, and why half of /bin is a shortcut to somewhere else.Working knowledge·2.1
  27. Finding filesSomething exists on this server and nobody knows where. One command searches by name, size, age, owner, and permission, runs another command on what it finds, and is one flag away from deleting all of it.Working knowledge·2.1
  28. Managing users and groupsCreating an account is one command. Doing it so the person can work, the auditor is satisfied, and offboarding is not an archaeology project takes a few more, and one flag that silently destroys group memberships.Working knowledge·2.2
  29. Account files and attributesFour text files hold every account on the machine. What each field means, how a password is stored so that reading the file does not help, and the difference between an account that is locked and one that is closed.Working knowledge·2.2
  30. Processes and signalsA process is running, or sleeping, or dead but still listed. What the state letters mean, why kill is a poor name for a command that mostly asks politely, and the one state where even the unblockable signal does nothing.Working knowledge·2.3
  31. Job control and schedulingPutting a job in the background, keeping it alive after you disconnect, and handing it to something that will run it every night without you. Plus the five fields everyone gets wrong at least once.Working knowledge·2.3
  32. Packages, repositories and signingAdding a software source means deciding to trust whoever runs it, for every package they will ever ship you. How signing actually works, how to add a repository properly, and how to ask which package a file came from.Working knowledge·2.4
  33. Common network servicesA tour of the services a Linux server usually runs: what each is for, where its configuration lives on each family, and the order to check them in when something between the browser and the disk is not working.Working knowledge·2.4
  34. systemd units and servicessystemd replaced a pile of shell scripts with a dependency graph. What a unit is, the difference between start and enable that catches everybody once, and how to read a status output that is telling you more than it looks.Working knowledge·2.5
  35. systemd targets, timers and the journalWhat replaced runlevels, how a timer beats a crontab, and a log query language that answers questions the old text files could not. Plus the four commands that configure a machine's identity.Working knowledge·2.5
  36. Containers: the basicsA container is not a small virtual machine, and the difference is visible in one command. What an image is, what a container is, and the six commands that cover almost everything you will do with them.Working knowledge·2.6
  37. Container images, volumes and networksWhere a container's writes actually go, why that layer is thrown away on purpose, and how to keep the data that should survive. Plus building an image, and the caching rule that decides whether a rebuild takes two seconds or four minutes.Working knowledge·2.6
  38. Authentication and PAMEvery login and every password change on this machine is decided by a stack of small modules read top to bottom, in a file named for the service. The four module types, the control flags, how a stack short-circuits, and how to change one without locking everybody out.Deep dive·3.1
  39. Central identityLocal accounts stop working somewhere around the third server. LDAP as a directory you look things up in, Kerberos as tickets that never carry the password, and SSSD as the client that wires both into NSS and PAM.Deep dive·3.1
  40. Logging and auditingTwo logging systems run on every modern Linux machine, and auditd is a third thing that is not logging at all. Which to reach for, how to read a syslog selector, why unrotated logs fill a disk, and what auditd records that nothing else does.Working knowledge·3.1, 5.1
  41. Firewall concepts and netfilterEvery Linux firewall is the same kernel machinery underneath. The five points a packet passes through, why the first rule is nearly always about state, and the difference between a packet that bounces and one that vanishes.Working knowledge·3.2
  42. firewalld, ufw and nftablesfirewalld, ufw, and nftables all write to the same kernel engine. What differs is what counts as a rule and what survives a reboot. Zones, the runtime versus permanent split, ufw's ordered list, and saving an nftables ruleset.Working knowledge·3.2
  43. sudo in depthThe sudoers policy language field by field: who, where, as whom, and what. Why visudo exists, why a drop-in with a dot in its name is silently ignored, and why permitting vi, less, or a wildcard is the same as permitting root.Working knowledge·3.3
  44. SSH and secure remote accessSSH is two programs on two machines, each with its own configuration and each deliberately quiet about why it said no. Key pairs, the permission rules that silently refuse a good key, and reading the effective configuration instead of arguing about files.Working knowledge·3.3
  45. SELinuxSELinux is a second permission check that runs after the first one passes, and it does not care what the mode bits say. Contexts, labels, booleans, and how to read a denial instead of turning the whole thing off.Deep dive·3.3, 5.4
  46. Hardening a systemHardening is subtraction. Counting what is actually exposed, finding the programs that run as root no matter who starts them, making a file even root cannot edit, and the kernel switches worth setting.Working knowledge·3.3
  47. Password policy and MFALength, expiry, reuse, and lockout are four controls in four different places, and none of them is where people look first. chage, passwd -S, pam_pwquality, pam_faillock, a second factor, and why locked is not closed.Working knowledge·3.4
  48. Cryptography basicsHashing is not encryption and there is no way back. What is actually in the shadow file, what a salt is for, why MD5 is broken for one thing and not another, and what a signature proves that a checksum cannot.Working knowledge·3.5
  49. TLS certificates and ACMEA certificate is a public key with a name attached and somebody else's signature over both. Building a two-party PKI from nothing, watching verification fail and then succeed, and why a certificate that renews itself beats one a person remembers.Deep dive·3.5
  50. Encrypting data at restLUKS turns a disk into 16 megabytes of header and a lot of noise. Building an encrypted volume from nothing, what the header holds, why losing it loses everything, and why shred stopped working on SSDs.Working knowledge·3.5
  51. Compliance, auditing and integrityCompliance is a demand for evidence rather than assertion. CVE and CVSS, why a version-number scan is wrong on an enterprise distribution, benchmark scanning with OpenSCAP, and proving on disk that nothing has changed.Deep dive·3.6
  52. Your first shell scriptA script is a file containing the commands you already know. The shebang, the execute bit, arguments, and the two habits that separate a script that works from one that works on somebody else's machine.Intro·4.2
  53. Script control flowDecisions and repetition. Why the square bracket is a command rather than syntax, the numeric and string operators that are not interchangeable, and the loop that runs once when it should run never.Working knowledge·4.2
  54. Scripts that do real workFunctions, parameter expansion, argument parsing, and traps. The pieces that turn a working script into one you can hand to somebody else, and the four ways ordinary filenames break the naive version.Working knowledge·4.2
  55. Python for sysadminsWhen a shell script grows structure it cannot carry, Python takes over. The data types worth knowing, why indentation is syntax, and why the system refuses to let you pip install anything.Working knowledge·4.3
  56. Git: the basicsVersion control for people who administer systems rather than write software. The three places a file can be, what a commit actually contains, and the command that gets your work back after you thought you destroyed it.Intro·4.4
  57. Git branching and collaborationBranches, merges, and the conflict markers Git writes into your file when it cannot decide. Plus the difference between reset and revert, which decides whether you can safely undo something everybody else already has.Working knowledge·4.4
  58. Infrastructure as code conceptsDeclarative against imperative, what idempotence actually buys you, and why drift is the problem every configuration tool exists to solve. The vocabulary that makes Ansible, Puppet, and OpenTofu comprehensible before you touch any of them.Working knowledge·4.1
  59. AnsibleAnsible needs nothing installed on the machines it manages, which is most of why it won. Inventory, playbooks, modules, facts, and the changed count that tells you whether your automation is safe to run twice.Deep dive·4.1
  60. Puppet and OpenTofuPuppet converges a machine toward a description and keeps it there. OpenTofu creates infrastructure that did not exist and remembers what it made. Neither competes with Ansible, and knowing which question each answers is most of the value.Working knowledge·4.1
  61. CI/CD and GitOpsA pipeline is a script that runs on somebody else's machine and is trusted to be honest about failure. GitOps goes one step further and makes the repository the thing reality is compared against. Both ideas are simpler than the tooling around them suggests.Working knowledge·4.1
  62. OrchestrationOrchestration is what you reach for when containers have to find each other, survive a crash without you, and be replaced without downtime. Compose, Swarm, and the Kubernetes vocabulary the exam expects, and the ideas underneath, demonstrated on a real machine.Deep dive·4.1
  63. AI-assisted administrationAn assistant that writes shell, YAML, and regex is genuinely useful and is not accountable for what it produces. This is the review habit, the verification commands, the data governance question, and the prompt injection problem, written by one of these things, which is worth bearing in mind.Working knowledge·4.5
  64. How to troubleshootTroubleshooting is a method, not a talent. Symptom to hypothesis to a test that can only come out one way, changing one thing at a time, and reading the error message you were actually given rather than the one you expected.Working knowledge·5.2
  65. Monitoring conceptsMonitoring is the difference between finding out from a dashboard and finding out from a complaint. What to measure, what an SLO actually commits you to, how an agent reports, and why the alert nobody acts on is worse than no alert.Working knowledge·5.1
  66. Reading logs to find a causeLogs are not a wall of text to be scrolled. They are a queryable record with time, severity, and origin attached, and knowing four filters turns half an hour of scrolling into one command that returns six lines.Working knowledge·5.1
  67. Boot failures and recoveryBoot is a chain, and a failure anywhere in it leaves you with a different set of tools. Working out how far it got, editing the kernel command line from the boot menu, and getting a shell on a system that will not start one.Deep dive·5.2
  68. Filesystem and mount failuresOne error message covers a dozen unrelated causes, which is why mount failures feel arbitrary. Decoding what the message does and does not tell you, recovering a filesystem whose superblock is gone, and knowing when a repair tool is the wrong thing to reach for.Deep dive·5.2
  69. Disk space and inode problemsTwo commands answer the question differently because they are measuring different things. Learning which one to believe, and why a filesystem that is one percent full can refuse to create a file, is most of what disk-space troubleshooting is.Working knowledge·5.2
  70. Process and service failuressystemd knows whether it started a process. It does not know whether that process is doing its job, and the gap between those two facts is where a whole category of outage lives. Reading a failed unit, a restart loop, and an exit code that names its own cause.Working knowledge·5.2
  71. Hardware and kernel issuesHardware faults do not announce themselves politely. They arrive as kernel messages full of unfamiliar names, and the skill is deciding whether you are looking at a dying disk, a driver that never loaded, or software blaming the wrong thing.Deep dive·5.2
  72. Network connectivity troubleshootingNetwork faults feel arbitrary until you work the layers in order. Link, address, route, gateway, name, service, and the one distinction that decides where to look next: whether the far end refused you or said nothing at all.Deep dive·5.3
  73. DNS and routing problemsThe tool you use to test DNS is not the one your application uses, and that single fact explains most name resolution mysteries. Where lookups actually go, why a cache can serve a wrong answer for hours, and how routing faults masquerade as DNS ones.Deep dive·5.3
  74. Permission and access troubleshootingWhy a world-readable file still refuses to open, how to read the whole path instead of the last component, and the four causes that produce the same three words.Deep dive·5.4
  75. Security and service access problemsThe failures that survive a permissions check: a policy denying what the mode bits allow, a certificate that expired on a Sunday, a protocol both ends refuse to speak, and an account that is fine except for the one attribute nobody looked at.Deep dive·5.4
  76. CPU and memory performanceLoad average does not measure CPU, free memory is not the number you want, and a process that vanished at 3am was probably chosen deliberately by the kernel. The three things people misread most, demonstrated on a machine doing the work.Deep dive·5.5
  77. I/O and network performanceStorage and network problems present as application problems, because the application is where the waiting is visible. Reading iostat properly, separating latency from throughput, and knowing why a device at 60 percent utilisation can already be the bottleneck.Deep dive·5.5
  78. Where the time actually goesTopics 75 and 76 give you tools that say a machine is busy. None of them says which function it is busy in. Sampling against tracing, reading a profile, what a flame graph is really showing, and asking the kernel a question no tool has a flag for.Deep dive
  79. What a write actually guaranteesThis track covers filesystems, journals, LVM, RAID and backups, and never says what write() promises. It promises less than everybody assumes: the call returns while the data is still in memory, and four layers can still lose it.Deep dive
  80. How upstream becomes your distributionA scanner says your glibc is years out of date and your vendor says you are patched. Both are reading the same version number and only one of them is reading the changelog. What a release field carries, why distributions work this way, and what it does to vulnerability management.Working knowledge
  81. The system you cannot changeEvery capture in this track was taken on a machine whose /usr is read-only and whose root filesystem is a directory named after a hash. Image-based systems, what they move where, what they give up, and why servers are drifting this way.Deep dive