Concepts·LPIC-2

LPIC-2 exam format and topic weights

LPIC-2 is 201-450 and 202-450, both required, each 60 questions in 90 minutes and scored 200-800 with 500 to pass. 201 is the machine - kernel, storage, capacity, startup. 202 is the services you install and configure. This guide explains why that second half needs a lab rather than a book, and introduces the three machines every later page runs on.

Start Here Guide 1 of 29 Intermediate

PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
Block devicesone 50 GB disk
TimeAbout 14 min

Exam structure and topic weights are LPI's published objectives for 201-450 and 202-450, linked below. Nothing here is derived from this site's practice questions - a question bank is edited, and a guide quoting one goes quietly out of date.

Two service hosts and a client. Every service here is proven from a machine that is not running it.
Server Name	IP Address	OS	Roles	CPU	RAM	HDD
LPIC2-A01	192.168.0.78	Ubuntu 26.04 LTS	Primary service host - BIND, Apache, Samba, Postfix. Topic 204 RAID runs on loop devices; this machine has no spare disk	2 Core	4 GB	50 GB
LPIC2-B01	192.168.0.79	AlmaLinux 10.2	Second service host - nginx, NFS, DNS secondary, and the other family's spelling of each service	2 Core	4 GB	50 GB
LPIC2-C01	192.168.0.80	Ubuntu 26.04 LTS	Client - resolves, mounts and connects, so every service is proven from a machine that is not running it	2 Core	4 GB	50 GB

This guide includes

Use this before booking either LPIC-2 paper. This matters because installed, enabled and running are three different questions - and a unit can be disabled and active at the same time.

meeting the three machines, and why there are three
finding the nineteen services a machine with no services still runs
separating installed, enabled and running, on a unit that is disabled and active at once

Before you start

The three machines, and why there are three
Two servers of different families, and a client that serves nothing.
bash Example session
```
$. /etc/os-release; echo "$PRETTY_NAME  $(uname -r)"; echo "--- the primary service host"Ubuntu 26.04 LTS  7.0.0-30-generic--- the primary service host$. /etc/os-release; echo "$PRETTY_NAME  $(uname -r)"; echo "--- the RPM-family service host"AlmaLinux 10.2 (Lavender Lion)  6.12.0-211.7.3.el10_2.x86_64--- the RPM-family service host$. /etc/os-release; echo "$PRETTY_NAME  $(uname -r)"; echo "--- the client, which runs no service"Ubuntu 26.04 LTS  7.0.0-30-generic--- the client, which runs no service
```
Note
This is the only Linux path on this site about SERVICES rather than a machine. BIND, Apache, nginx, Samba, NFS, Postfix - almost none of it overlaps RHCSA or LFCS, and all of it has to be configured rather than recognised.

Which is why the third machine exists. A service tested only with dig @localhost or curl localhost has not been tested - it has been observed talking to itself. The client proves three things at once that a local test cannot: that the service is listening on a reachable address rather than loopback, that no firewall is in the way, and that whatever ACL the service has permits somebody other than the server.

Two families, because the spellings differ. The service is named on one and bind9 on the other, httpd against apache2, with configuration in different directories and different default document roots. LPI examines the service, not one distribution's packaging of it - so a page showing only one family has taught half the objective.

AlmaLinux stands in for the RPM family. Everything here behaves identically on Rocky and RHEL; where it would not, the guide says so.

Expected resultUbuntu 26.04 LTS twice and AlmaLinux 10.2 once, on kernels 7.0.0-30-generic and 6.12.0-211.7.3.el10_2.

Success conditionYou know which machine each command on this path ran on.

What a machine with no services still runs

Nineteen services, and not one of them is on the syllabus.

bash Example session

$systemctl list-units --type=service --state=running --no-pager | head -8  UNIT                        LOAD   ACTIVE SUB     DESCRIPTION  chrony.service              loaded active running chrony, an NTP client/server  cron.service                loaded active running Regular background program processing daemon  dbus.service                loaded active running D-Bus System Message Bus  getty@tty1.service          loaded active running Getty on tty1  ModemManager.service        loaded active running Modem Manager  multipathd.service          loaded active running Device-Mapper Multipath Device Controller  networkd-dispatcher.service loaded active running Dispatcher daemon for systemd-networkd$sudo -n ss -tlnp | head -5; echo "--- and this is everything it offers the network"State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcessLISTEN 0      4096   127.0.0.53%lo:53        0.0.0.0:*    users:(("systemd-resolve",pid=607,fd=17))LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1266,fd=3),("systemd",pid=1,fd=169))LISTEN 0      4096      127.0.0.54:53        0.0.0.0:*    users:(("systemd-resolve",pid=607,fd=19))LISTEN 0      4096            [::]:22           [::]:*    users:(("sshd",pid=1266,fd=4),("systemd",pid=1,fd=170))--- and this is everything it offers the network

Note

Nineteen running services and nothing the 202 paper asks about. These are the machine keeping itself alive: a clock, a scheduler, a message bus, a login prompt. Every service on this path is added on top of that baseline.

Running is not the same as listening. Most of those 19 talk to the kernel or to each other over a socket in the filesystem and offer nothing to the network at all. ss -tlnp is the list that matters for security, and here it is one entry - sshd.

Which makes the attack surface easy to state, and it is worth knowing what it looks like before you start adding to it. After the DNS guide there will be a second entry; after a web guide, a third. Each one is a decision.

ModemManager and multipathd on a virtual machine with neither a modem nor multipath storage is the normal state of a general-purpose distribution image. They cost almost nothing and are the kind of thing a hardening exercise removes - which is Topic 212 territory.

Expected resultchrony, cron, dbus, getty, ModemManager, multipathd, networkd-dispatcher - 19 running services - and sshd the only thing listening beyond loopback.

Success conditionYou know what the baseline is before you add anything to it.

Installed, enabled, running - three different questions
A unit that is disabled and active at the same time.
bash Example session
```
$systemctl show sshd -p FragmentPath -p UnitFileState -p ActiveState 2>/dev/null; systemctl show ssh -p FragmentPath -p UnitFileState -p ActiveState 2>/dev/nullActiveState=activeFragmentPath=/usr/lib/systemd/system/ssh.serviceUnitFileState=disabledActiveState=activeFragmentPath=/usr/lib/systemd/system/ssh.serviceUnitFileState=disabled$systemctl show ssh -p After -p Wants --no-pager 2>/dev/null | tr ' ' '\n' | head -6; echo "--- ordering and dependency are different things"Wants=sshd-keygen.serviceAfter=systemd-journald.socketnss-user-lookup.targetssh.socketsysinit.target-.mount--- ordering and dependency are different things
```
Note
Disabled and active at once is not a contradiction. enabled means "start at boot"; active means "running now". This one is running because it is SOCKET-ACTIVATED: ssh.socket holds port 22 and starts the service on the first connection. Disabling ssh.service therefore stops nothing, which is a genuinely confusing first encounter.

Which is the distinction every service question on this path turns on. systemctl start runs it now; enable makes it start at boot; enable --now does both. A service you started and did not enable disappears at the next reboot, and that is the single most common way a lab exercise looks finished and is not.

After is ordering; Wants is dependency. After=network.target says "if both are starting, start me second" - it does NOT ask for the network. Wants= pulls another unit in. Getting these backwards produces a unit that starts too early and fails in a way that looks intermittent.

FragmentPath tells you which file is in force, and /usr/lib/systemd/system/ means it is the vendor's. An override in /etc/systemd/system/ would show there instead - which is where systemctl edit puts your changes so a package update cannot overwrite them.

Expected resultActiveState=active with UnitFileState=disabled - and a Wants on sshd-keygen.service with After naming sockets and targets.

Success conditionYou can tell whether a service will come back after a reboot.

Troubleshooting

A unit is running and will not come back after a reboot.

Why: Installed, enabled and running are three different questions. A unit can be ActiveState=active while UnitFileState=disabled - started by hand, or pulled in by something else.

Fix:Ask all three: systemctl is-active, systemctl is-enabled, and the package query. systemctl list-dependencies --reverse <unit> shows what pulled it in.
A machine described as having no services is running dozens.

Why: chrony, cron, dbus, getty, ModemManager, multipathd and the network stack are the base system, not services anyone chose.

Fix:Learn the baseline so you can spot what is added. systemctl list-units --type=service --state=running on a fresh host is the reference to compare against.
Revision treats LPIC-2 as one exam.

Why: 201-450 and 202-450 are separate papers, booked and scored independently, each 60 questions in 90 minutes.

Fix:Prepare and sit one at a time. Note the practice pool on this site is roughly three quarters 201 material, so a proportional mock says far more about that paper than the other.

Official sources

← All LPIC-2 guides