Containers for Linux admins: Podman and Docker basics

Steps 1 to 7 run on rocky01 as student; only package installs, the firewall and linger need sudo. Step 8 runs on ubu01. Both VMs need internet access to reach docker.io.

Nginx from Lesson 56 keeps port 80 on rocky01, so the containers use 8080 and 8081.

1Install Podman and see how it runs

Run this:

sudo dnf install -y podman
podman --version
podman info --format '{{.Host.Security.Rootless}} {{.Host.NetworkBackend}} {{.Host.RootlessNetworkCmd}} {{.Store.GraphDriverName}} {{.Host.OCIRuntime.Name}}'
grep student /etc/subuid /etc/subgid

You should see something like this:

podman version 5.8.2
true netavark pasta overlay crun
/etc/subuid:student:524288:65536
/etc/subgid:student:524288:65536

You’re rootless, container networks are handled by netavark with pasta for rootless ports, images sit on overlayfs and crun starts the processes. The subuid and subgid lines were added when student was created; a user without them can’t run rootless containers, which is the first thing to check for a service account made by hand.

✅ Checkpoint: podman info prints “true” as the first word and student has a 65536-ID range in both files.

2Pull an image by its full name

Run this:

podman pull docker.io/library/nginx:alpine
podman images

You should see something like this:

Trying to pull docker.io/library/nginx:alpine...
Getting image source signatures
Copying blob 9824c27679d3 done   |
Copying blob 6d79cc6084d4 done   |
Copying blob 5f6ee5a7a4a8 done   |
Copying config 5e7abcdd2021 done   |
Writing manifest to image destination
5e7abcdd20216bbeedf1369529564ffd60f830ed3540c477938ca580b645dff5
REPOSITORY               TAG         IMAGE ID      CREATED      SIZE
docker.io/library/nginx  alpine      5e7abcdd2021  3 weeks ago  52.6 MB

Each “blob” is one layer of the image, checked against its digest as it arrives. The tag alpine moves whenever the Nginx team publishes a new build, so at work you’d pin a version tag or the digest for anything that must not change under you.

✅ Checkpoint: podman images lists docker.io/library/nginx with the alpine tag.

3Run a container and look at it

Run this:

podman run -d --name web1 -p 8080:80 docker.io/library/nginx:alpine
podman ps
curl -s http://localhost:8080/ | grep '<title>'
podman logs web1 2>&1 | tail -n 3
podman exec web1 sh -c 'id -u; hostname'

You should see something like this:

3f2a9c81d4b7e0c55a1f9d0e8b6c2a47d13e9f05b8c7a6d4e2f1b0c9a8d7e6f5
CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS        PORTS                 NAMES
3f2a9c81d4b7  docker.io/library/nginx:alpine  nginx -g daemon o...  4 seconds ago  Up 4 seconds  0.0.0.0:8080->80/tcp  web1
<title>Welcome to nginx!</title>
2026/10/27 07:02:08 [notice] 1#1: start worker processes
2026/10/27 07:02:08 [notice] 1#1: start worker process 30
2026/10/27 07:02:08 [notice] 1#1: start worker process 31
0
3f2a9c81d4b7

-d runs it in the background and prints the full container ID, -p 8080:80 publishes container port 80 on host port 8080. The container’s logs are Nginx’s own stdout and stderr, kept by conmon. Times are UTC because the image has no time zone set.

Inside, the shell runs as UID 0 and the hostname is the short container ID.

✅ Checkpoint: curl shows the “Welcome to nginx!” title and podman ps lists web1 as Up.

4See rootless from the host side

Run this:

podman top web1 user huser pid hpid comm
ps -o user:12,pid,cmd -p 3412,3439,3440

You should see something like this:

USER        HUSER       PID         HPID        COMMAND
root        student     1           3412        nginx
nginx       524388      30          3439        nginx
nginx       524388      31          3440        nginx
USER           PID CMD
student       3412 nginx: master process nginx -g daemon off;
524388        3439 nginx: worker process
524388        3440 nginx: worker process

The same three processes appear twice: PID 1, 30 and 31 inside, 3412, 3439 and 3440 on rocky01. Container root is student on the host, and the nginx user (UID 101 inside) is 524388, which is 524288 + 100 from the subuid range. ps on the host shows no name for 524388 because no account has that UID, which is the point. Use the HPID numbers from your own podman top in the ps command; ps -C nginx would also list the Lesson 56 Nginx, whose master runs as root.

✅ Checkpoint: podman top shows a HUSER of student for PID 1 and 524388 for the workers.

5Serve your own page from a volume with :Z

Create a folder with a page and mount it read-only into a second container:

mkdir -p ~/saatweb
echo '<h1>SaatShop status: all good</h1>' > ~/saatweb/index.html
podman run -d --name web2 -p 8081:80 -v ~/saatweb:/usr/share/nginx/html:ro,Z docker.io/library/nginx:alpine
curl -s http://localhost:8081/
ls -ldZ ~/saatweb

You should see something like this:

b81c06e4f2d95a7310c8e4d2a6f9b1c37e05d8a2f4c6b9e1d3a5c7f9e2b4d6a8
<h1>SaatShop status: all good</h1>
drwxr-xr-x. 2 student student system_u:object_r:container_file_t:s0:c241,c907 24 Oct 27 12:34 /home/student/saatweb

:ro makes the mount read-only inside, so a compromised Nginx can’t change your page. :Z relabelled the folder to container_file_t with two MCS categories (c241,c907) that only this container gets, so another container can’t read it. Now remove both test containers; the image stays for the next steps:

podman rm -f web1 web2
podman ps -a

web1
web2
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES

✅ Checkpoint: curl on 8081 printed your own heading, ls -Z shows container_file_t, and podman ps -a is empty.

6Turn it into a service with Quadlet

Write the Quadlet file, check what systemd will get, then start it:

mkdir -p ~/.config/containers/systemd
cat > ~/.config/containers/systemd/saatweb.container <<'EOF'
# ~/.config/containers/systemd/saatweb.container  (SaatVedha Linux course, Lesson 57)
[Unit]
Description=SaatShop status page (rootless Podman)

[Container]
Image=docker.io/library/nginx:alpine
ContainerName=saatweb
PublishPort=8080:80
Volume=/home/student/saatweb:/usr/share/nginx/html:ro,Z

[Service]
Restart=always

[Install]
WantedBy=default.target
EOF
/usr/libexec/podman/quadlet -dryrun -user | grep '^ExecStart='
systemctl --user daemon-reload
systemctl --user start saatweb.service
systemctl --user status saatweb.service --no-pager | head -n 4
podman quadlet list

You should see something like this:

ExecStart=/usr/bin/podman run --name saatweb --replace --rm --cgroups=split --sdnotify=conmon -d -v /home/student/saatweb:/usr/share/nginx/html:ro,Z --publish 8080:80 docker.io/library/nginx:alpine
● saatweb.service - SaatShop status page (rootless Podman)
     Loaded: loaded (/home/student/.config/containers/systemd/saatweb.container; generated)
     Active: active (running) since Tue 2026-10-27 12:38:51 IST; 3s ago
 Invocation: 6c1e0b9a2f4d47e8b3a5c7d9e1f20a4b
NAME               UNIT NAME        PATH ON DISK                                              STATUS          APPLICATION
saatweb.container  saatweb.service  /home/student/.config/containers/systemd/saatweb.container  active/running

The dry run shows the exact podman run line the generator wrote: --replace and --rm mean every start gets a fresh container from the image, which is how containers are meant to live. “generated” in the Loaded line tells you this unit came from Quadlet, so you edit the .container file, never the .service. The [Install] section is what makes it start at boot; systemctl --user enable doesn’t work on generated units.

✅ Checkpoint: saatweb.service is active (running) and podman quadlet list shows it as active/running.

7Keep it running after logout and reboot, and open the port

Run this:

sudo loginctl enable-linger student
loginctl show-user student --property=Linger
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload

Linger=yes
success
success

Reboot rocky01 and, without logging in on it, run this on ubu01:

curl -s http://rocky01.saatlab.test:8080/
curl -s http://rocky01.saatlab.test/health.php

You should see this:

<h1>SaatShop status: all good</h1>
OK db=up orders=5

With linger on, systemd starts student’s user manager at boot, which starts saatweb.service from the [Install] section. The firewall port was needed because pasta listens on 8080 like any normal program. SaatShop from Lesson 56 on port 80 came back too, so both stacks live side by side.

✅ Checkpoint: After a reboot with nobody logged in, ubu01 gets the status page from port 8080 and “OK db=up” from port 80.

8A short look at Docker on ubu01

On ubu01, install Ubuntu’s Docker package and run a test image:

sudo apt install -y docker.io
docker --version
sudo docker run --rm docker.io/library/hello-world 2>/dev/null | head -n 3

You should see something like this:

Docker version 29.1.3, build 29.1.3-0ubuntu4

Hello from Docker!
This message shows that your installation appears to be working correctly.

Here a root daemon, dockerd, did the work, and you needed sudo. Many guides tell you to run sudo usermod -aG docker student to drop the sudo. Look at what any member of that group could then do, no sudo asked:

sudo docker run --rm -v /etc:/host-etc:ro docker.io/library/alpine head -n 1 /host-etc/shadow

You should see something like this:

root:*:20746:0:99999:7:::

The container’s root is the host’s root here, so mounting /etc gives it the password hashes, and mounting / read-write would give it the whole server. That’s why the docker group is treated as root in audits. Now see what happens to the firewall from Lesson 34:

sudo docker run -d --name ufwtest -p 8090:80 docker.io/library/nginx:alpine
sudo ufw status | head -n 6

Then on rocky01:

curl -sI http://10.10.10.21:8090/ | head -n 1

You should see something like this:

HTTP/1.1 200 OK

ufw allows only SSH (and syslog from rocky01), yet port 8090 answered. Docker writes its own NAT rules that send the traffic to the container before ufw’s INPUT rules ever see it, and Docker’s own documentation says the two are incompatible. Publish on 127.0.0.1 (for example -p 127.0.0.1:8090:80) when only the server itself needs the port.

Clean up and stop Docker so it doesn’t hold memory on ubu01:

sudo docker rm -f ufwtest
sudo systemctl disable --now docker.service docker.socket

✅ Checkpoint: You saw the shadow line through a container and port 8090 answer through ufw, and docker.service is now inactive.