That sounds simple enough, but even a minimal module produces a surprising amount of machinery around it: object files, metadata, exported and unresolved symbols, and a final .ko file that is quite different from an ordinary executable.

Here's a complete, working Linux kernel module. It's just twenty-two lines, seven of which are includes and metadata:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Chris Roy");
MODULE_DESCRIPTION("A minimal loadable kernel module");
MODULE_VERSION("0.1");

static int __init hello_init(void)
{
    pr_info("hello: loaded, module at %pS\n", hello_init);
    return 0;
}

static void __exit hello_exit(void)
{
    pr_info("hello: unloaded\n");
}

module_init(hello_init);
module_exit(hello_exit);

Compiled on the machine I'm writing this on, that produces a file of about 106,000 bytes. Strip the debug information out and the same module is 4,864 bytes. Ninety-five percent of what the build gave you isn't code.

Your total will differ from mine, and not by a predictable amount. Part of it is where you built: the debug information records the directory you compiled in, so a deeply nested path costs a few hundred bytes that a short one doesn't. Your compiler version and kernel configuration move it further. The proportion is what holds. The exact byte count is only what this machine produced.

That gap is a good place to start, because most kernel module tutorials show you the listing above, tell you to run make, and stop.

This one follows what the build actually produced, what your module already depends on before you wrote anything useful, and why the tutorial you found from 2014 no longer compiles.

Table of Contents

• What You Need

• The Smallest Module That Works

• The Makefile is Stranger Than it Looks

• What the Build Actually Did

• What's Inside a .ko File

• Your Hello World Already Depends on Three Things

• vermagic, and Why Your Module Refuses to Load

• Passing Parameters at Load Time

• Loading it, and Where the Output Goes

• Four Build Errors and What They Mean

• Why the Tutorial You Found Doesn't Compile

• Conclusion

• Epilogue

What You Need

To follow along here, you'll need a Linux machine you're willing to load code into, the headers for the kernel you're running, and a compiler.

On Debian or Ubuntu:

sudo apt install build-essential linux-headers-$(uname -r)

On Fedora, the equivalent is kernel-devel and kernel-headers, and on Arch it's the linux-headers package matching your kernel.

Check that the headers landed where the build expects them:

ls -d /lib/modules/$(uname -r)/build

That path is a symlink into the headers package, and its absence is the single most common reason a module build fails with an error that mentions nothing about headers.

Two things will stop you from loading a module even after it builds. Secure Boot rejects unsigned modules, and kernel lockdown blocks loading in confidentiality mode. Check both:

mokutil --sb-state
cat /sys/kernel/security/lockdown

On the machine here, Secure Boot is disabled and lockdown reports [none] integrity confidentiality, with the brackets marking the active mode. If yours shows Secure Boot enabled, you'll need to sign the module or disable Secure Boot in firmware before it will load.

I'm on Ubuntu 22.04 with kernel 5.15.0-190-generic and gcc 11.4. Your versions will differ, and the article says where that matters.

The Smallest Module That Works

Save the code from the beginning of this article as hello.c. Here it is again for reference:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Chris Roy");
MODULE_DESCRIPTION("A minimal loadable kernel module");
MODULE_VERSION("0.1");

static int __init hello_init(void)
{
    pr_info("hello: loaded, module at %pS\n", hello_init);
    return 0;
}

static void __exit hello_exit(void)
{
    pr_info("hello: unloaded\n");
}

module_init(hello_init);
module_exit(hello_exit);

Four things in it are doing real work.

module_init and module_exit register the functions the kernel calls when your module is loaded and unloaded. They aren't main. A module has no single entry point that runs and returns. It has hooks that fire on two specific events, and it does nothing in between unless something else calls into it.

__init and __exit are section markers. __init tells the kernel this code runs once and its memory can be freed afterward, which is why you'll see "Freeing unused kernel memory" in your boot log. __exit tells the build that this function is only needed if the module can be unloaded at all.

MODULE_LICENSE("GPL") isn't paperwork. The kernel checks it at load time, and a module declaring a non-GPL license is denied access to symbols marked EXPORT_SYMBOL_GPL, which is most of the interesting ones. Omit the macro entirely and the kernel taints itself and logs a complaint.

pr_info is the modern spelling of printk(KERN_INFO ...). It writes to the kernel ring buffer, not to your terminal, which trips up nearly everyone the first time.

The MODULE_AUTHOR, MODULE_DESCRIPTION, and MODULE_VERSION macros are metadata rather than behavior, and they end up in the file for modinfo to read. Leave them out and nothing breaks, but recent kernels warn at build time about a missing MODULE_DESCRIPTION, which is reason enough to write all three from the start.

The Makefile is Stranger Than it Looks

obj-m += hello.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

This looks like a Makefile, and mostly isn't one. obj-m += hello.o isn't a Make variable you invented. It's a declaration read by kbuild, the kernel's own build system.

The make -C line changes directory into the kernel headers and runs the kernel's build system there, passing M=$(PWD) to say "the module source is over here." Your Makefile is a thin wrapper that hands the job to a build system you didn't write and can't easily replace.

That indirection is why module builds fail in ways that seem unrelated to your code. You're not compiling against the kernel headers the way you compile against libc headers. You're running the kernel's build, on your file, with its flags and its rules.

What the Build Actually Did

Run make and read the output rather than skipping it:

make -C /lib/modules/5.15.0-190-generic/build M=/home/chris/lkm modules
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-190-generic'
  CC [M]  /home/chris/lkm/hello.o
  MODPOST /home/chris/lkm/Module.symvers
  CC [M]  /home/chris/lkm/hello.mod.o
  LD [M]  /home/chris/lkm/hello.ko
  BTF [M] /home/chris/lkm/hello.ko
Skipping BTF generation for /home/chris/lkm/hello.ko due to unavailability of vmlinux

Five steps, and only the first is the compile you expected.

CC [M] hello.o compiles your source. Ordinary.

MODPOST is the step worth knowing about. It scans your object file for symbols you referenced but didn't define, checks each one against the kernel's table of exported symbols, and fails the build if you used something the kernel doesn't offer you. It also generates hello.mod.c, a small file of glue containing your module's metadata.

CC [M] hello.mod.o compiles that generated glue, and LD [M] links it together with your object into the final .ko.

BTF [M] would attach type information used by tracing tools. Here it was skipped, because generating BTF needs the uncompressed vmlinux image and Ubuntu doesn't ship it by default. The build warns and continues, which is correct: BTF is useful, not required.

What's Inside a .ko File

A .ko is an ordinary ELF object with kernel-specific sections bolted on. Look at its metadata:

modinfo ./hello.ko

version:        0.1
description:    A minimal loadable kernel module
author:         Chris Roy
license:        GPL
srcversion:     39D86510C9FF65D797EAF90
depends:        
retpoline:      Y
name:           hello
vermagic:       5.15.0-190-generic SMP mod_unload modversions

All of that lives in one ELF section, stored as null-separated strings. You can read it straight out of the file:

objcopy -O binary --only-section=.modinfo hello.ko /dev/stdout | tr '\0' '\n'

Which brings us back to the number from the opening. The module is about 106,000 bytes on disk:

ls -l hello.ko
cp hello.ko /tmp/ && strip --strip-debug /tmp/hello.ko && ls -l /tmp/hello.ko

105984  hello.ko
  4864  /tmp/hello.ko

The actual module is under five kilobytes. Everything else is DWARF debug information the build keeps so that tools like crash and gdb can make sense of your code if it panics. When you load the module, the kernel doesn't load the debug sections, so the memory cost is the small number rather than the large one.

Your Hello World Already Depends on Three Things

This is the part I'd have wanted someone to show me first. Ask the object what it needs from the kernel:

nm -u hello.ko

U __fentry__
U _printk
U __x86_return_thunk

U means undefined: symbols your module references and the kernel must supply at load time.

_printk you can account for, since pr_info expands to it.

__fentry__ is a call the compiler placed at the top of every one of your functions, because the kernel is built with function tracing support. Every function you write in a module gets that hook whether you asked for it or not, and it's what lets ftrace instrument your code later without recompiling anything.

__x86_return_thunk is a Spectre mitigation. Your compiler replaced ordinary return instructions with a call to a thunk that avoids the speculative execution path the vulnerability relies on. It appears in a module that prints one line, because the mitigation applies to all kernel code on this machine, module or not.

Two of the three symbols in your hello world are infrastructure the machine imposed on you. That's a fair picture of what writing kernel code is like.

MODPOST verified all three exist before the link succeeded. Had you called a function the kernel doesn't export, the build would have failed there with an "undefined symbol" error rather than producing a module that fails at load.

vermagic, and Why Your Module Refuses to Load

Look again at that line from modinfo:

vermagic: 5.15.0-190-generic SMP mod_unload modversions

The kernel compares that string against its own before loading anything, and refuses on a mismatch. It covers the release, whether the kernel is SMP, whether module unloading is compiled in, and whether symbol versioning is on.

This is why a module built on one machine usually won't load on another, and why upgrading your kernel means rebuilding your modules.

There's no ABI stability guarantee inside the Linux kernel. Internal structures change between releases, and a module compiled against one layout that ran against another would corrupt memory rather than fail cleanly. Refusing to load is the kernel being careful.

It's also why DKMS exists. If you have VirtualBox, ZFS, or an NVIDIA driver installed, you already have a module being rebuilt this way. On the machine here:

modinfo vboxdrv | head -3

filename:       /lib/modules/5.15.0-190-generic/updates/dkms/vboxdrv.ko
version:        6.1.50_Ubuntu r161033 (0x00320000)
license:        GPL

Note the updates/dkms/ in that path. DKMS keeps the source and rebuilds the module each time you install a new kernel, which is the maintenance cost the vermagic check makes unavoidable.

Passing Parameters at Load Time

A module that always does the same thing is rarely what you want. module_param exposes a variable so its value can be set at load time. Save this as param.c alongside hello.c:

#include <linux/init.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("A module that takes parameters");

static char *who = "world";
static int times = 1;

module_param(who, charp, 0444);
MODULE_PARM_DESC(who, "who to greet");
module_param(times, int, 0644);
MODULE_PARM_DESC(times, "how many times to greet");

static int __init param_init(void)
{
    int i;

    for (i = 0; i < times; i++)
        pr_info("param: hello, %s\n", who);
    return 0;
}

static void __exit param_exit(void)
{
    pr_info("param: unloaded\n");
}

module_init(param_init);
module_exit(param_exit);

Add it to the Makefile, which takes a list:

obj-m += hello.o param.o

The three arguments are the variable, its type, and the permissions on the file that will represent it under /sys/module/<name>/parameters/. A mode of 0444 makes it readable and fixed once loaded. 0644 lets root write to that file and change the value while the module is running, which is useful. It's also how you introduce a race if the module reads the variable without expecting it to change.

charp is a char pointer, and the other common types are int, bool, long and charp arrays via module_param_array. Pass a type that doesn't match the variable and the build fails rather than misbehaving later.

MODULE_PARM_DESC puts the description into the module metadata, where modinfo finds it:

name:           param
parm:           who:who to greet (charp)
parm:           times:how many times to greet (int)

Set them at load time as name=value pairs:

sudo insmod ./param.ko who=kernel times=3

Anyone can read what parameters a module accepts before loading it, which is the main reason to bother with MODULE_PARM_DESC at all.

Loading it, and Where the Output Goes

sudo insmod ./hello.ko
sudo dmesg | tail -2
lsmod | grep hello
sudo rmmod hello

The pr_info output goes to the kernel ring buffer, so it appears in dmesg rather than your terminal. If dmesg refuses without root, that's kernel.dmesg_restrict, and sudo journalctl -k | tail reads the same messages through the journal.

The %pS in the format string prints a kernel pointer as a symbol name and offset instead of a raw address, which is how you get something readable out of a log line rather than a hexadecimal number.

lsmod reads /proc/modules and shows three columns: the module name, its size in memory, and a use count with the names of anything depending on it. A module with a non-zero use count can't be unloaded, which is the most common reason rmmod refuses.

One caution before you load anything. A bug in userspace crashes your program. But a bug here can take the machine down or corrupt a filesystem. Do this in a virtual machine the first several times. The cost of a snapshot is far lower than the cost of a corrupted disk.

Four Build Errors and What They Mean

These four account for most of the time people lose, and each says something specific once you know what to read.

No rule to make target 'modules'. Stop. The kernel headers are missing or the symlink at /lib/modules/$(uname -r)/build points nowhere. Install the headers package matching the exact kernel you're running, which is often not the newest one installed if you haven't rebooted since an update.

ERROR: modpost: "some_function" [hello.ko] undefined! You referenced a symbol the kernel doesn't export. Here's what that looks like from a real build:

ERROR: modpost: "this_symbol_does_not_exist" [bad.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:133: Module.symvers] Error 1

Retrying won't help. Either the function is internal to the kernel and never exported, or it's exported with EXPORT_SYMBOL_GPL and your module declares a non-GPL license. Check with grep the_symbol /proc/kallsyms, where a capital T in the second column means it's a global text symbol.

insmod: ERROR: could not insert module: Invalid module format: The build succeeded but vermagic doesn't match the running kernel. Compare modinfo ./hello.ko | grep vermagic against uname -r. Rebuilding against the correct headers fixes it.

insmod: ERROR: could not insert module: Operation not permitted: Usually Secure Boot rejecting an unsigned module, or lockdown in confidentiality mode. Check mokutil --sb-state and cat /sys/kernel/security/lockdown before assuming your code is at fault.

One more thing, which is easier to learn now than to debug later. Loading any out-of-tree module sets a taint flag on the kernel, which is recorded and reported in any subsequent oops or panic:

cat /proc/sys/kernel/tainted

The value is a bitmask. It reads 4096 on the machine here, which is bit 12, TAINT_OOT_MODULE, meaning an out-of-tree module has been loaded at some point.

Bit 13 is the neighboring one people confuse it with, TAINT_UNSIGNED_MODULE, which is what Secure Boot cares about.

The full list is in include/linux/panic.h in the kernel source. Kernel developers will ask you to reproduce a bug on an untainted kernel before they look at it, and this is the file that tells them whether you did.

Why the Tutorial You Found Doesn't Compile

Most module tutorials on the web predate several changes, and these are the ones that bite.

printk(KERN_INFO "...") still works, but pr_info is the current spelling and carries the log level for you.

init_module and cleanup_module as bare function names were the old convention. Use module_init and module_exit with your own names instead, which lets a file define both without collisions.

MODULE_LICENSE was once optional in practice. It's now load-bearing, since it gates access to GPL-only exported symbols.

The M= argument used to be spelled SUBDIRS=. That spelling was removed, and a tutorial using it fails with an error that doesn't mention SUBDIRS anywhere.

Header paths moved. Anything referring to /usr/src/linux predates the split into per-kernel headers packages and is old enough that the rest of it needs checking too. A smaller sign: <linux/module.h> has included <linux/moduleparam.h> for years, so a tutorial that carefully includes both is copying from something old, even though including both is harmless.

If a tutorial builds without warnings on your kernel, it's current enough. If it doesn't, the kernel version it targeted is usually printed in the first error.

Conclusion

You can now build a kernel module, read what the build produced, and explain every symbol it depends on.

More usefully, you know why it fails in the specific ways it does. A missing /lib/modules/$(uname -r)/build is a headers problem. A vermagic mismatch is a rebuild. An undefined symbol at MODPOST means the kernel doesn't export what you asked for, and no amount of retrying will change that.

There are a few directions to go from here. Register a /proc entry with proc_create and read from it, which is the smallest useful thing a module can do.

Read the kernel's own Module.symvers under /usr/src/linux-headers-$(uname -r)/ to see the table MODPOST checked against, which is 26,420 exported symbols on this machine and marks each one EXPORT_SYMBOL or EXPORT_SYMBOL_GPL.

Or trace your own module's functions, which works because of the __fentry__ hook that was there from the first build. There's no ftrace command to run. It's an interface under /sys/kernel/tracing, so you drive it by writing to files:

sudo sh -c 'echo hello_init > /sys/kernel/tracing/set_ftrace_filter'
sudo sh -c 'echo function > /sys/kernel/tracing/current_tracer'
sudo cat /sys/kernel/tracing/trace

On older systems, that path is /sys/kernel/debug/tracing instead. If you would rather not write to files by hand, trace-cmd wraps the same interface.

Epilogue

Everything above assumes you're allowed to do it, and that assumption is the part I find interesting. A loaded module runs with the same authority as the kernel itself. It can read any memory, patch any function, and ignore any policy the system thought it was enforcing, because by the time it runs there's nothing left above it to say no.

That makes module loading the one operation a permission model can't contain, which is why the kernel guards it with signatures and lockdown rather than with permissions.

I ran into that floor while working on a capability-backed desktop OS, one where a program's manifest is the whole of what it may do, and the Debian ecosystem still has to work underneath it. Modules are where that model stops being expressible, so working out exactly what the kernel checks before accepting one stopped being a detail and became a design constraint.

I write about systems and their mysteries at thechris.in.

without landlock:
  read /etc/hostname            ok
  read /tmp/secret.txt          ok
with landlock, /etc allowed:
  read /etc/hostname            ok
  read /tmp/secret.txt          FAILED (Permission denied)

There's no root, no container, no configuration file, and no daemon. The program asked the kernel to take away its own access to most of the filesystem, and the kernel obliged.

That's Landlock, which has been in the kernel since 2021 without most people noticing. This article builds that program from nothing, runs it, and then walks into the four surprises that catch people the first time.

Table of Contents

• What You Need

• Where Landlock Sits

• Three System Calls and No Library

• A Program That Restricts Itself

• Why no_new_privs is Mandatory

• Rulesets Intersect, They Never Widen

• What Your Children Inherit

• The exec Trap

• Wrapping a Program You Didn't Write

• Finding the Paths a Program Needs

• Which ABI Version You Have

• Conclusion

• Epilogue

What You Need

To follow along, you'll need a kernel of 5.13 or newer, the standard headers, and a C compiler. Nothing else, and notably not root.

grep landlock /sys/kernel/security/lsm
ls /usr/include/linux/landlock.h

The first command matters. Landlock can be compiled into a kernel and still be inactive, because Linux Security Modules have to be enabled at boot. On this machine, that file reads lockdown,capability,landlock,yama,apparmor.

If landlock is missing from yours, add lsm=landlock, to the front of the existing list in your kernel command line and reboot. Ubuntu has shipped it enabled since 22.04, and current Fedora and Arch kernels carry it too, but the grep above is the only answer that counts for your machine.

Everything below was run on kernel 5.15.0-190-generic under Ubuntu 22.04.5, compiled with gcc 11.4, as an ordinary user with no sudo anywhere.

Where Landlock Sits

Linux Security Modules are a framework, not a policy. The kernel calls out to LSM hooks at decision points, before opening a file, creating a process, or mapping executable memory, and whatever modules are loaded get to say yes or no.

SELinux and AppArmor are the two most people have heard of, and both are administrator tools: someone with root writes a policy, the system loads it, and your program lives inside whatever that policy says.

Landlock inverts that. It's the first LSM a process can apply to itself, without privilege, at runtime. You don't need to convince an administrator that your program deserves a policy. The program asks for less than it currently has, and the kernel narrows it.

That "asks for less" is the whole design. Landlock can only ever remove access. There's no call that grants you something you didn't already have, which is precisely why it's safe to expose to unprivileged processes.

Three System Calls and No Library

Landlock is three syscalls and glibc wraps none of them, so you call them directly through syscall():

static int create_ruleset(const struct landlock_ruleset_attr *attr)
{ return syscall(__NR_landlock_create_ruleset, attr, sizeof(*attr), 0); }

static int add_rule(int fd, const struct landlock_path_beneath_attr *pb)
{ return syscall(__NR_landlock_add_rule, fd, LANDLOCK_RULE_PATH_BENEATH, pb, 0); }

static int restrict_self(int fd)
{ return syscall(__NR_landlock_restrict_self, fd, 0); }

landlock_create_ruleset declares which kinds of access you intend to govern and returns a file descriptor representing the ruleset. landlock_add_rule adds an exception in the form of a directory you want to keep. Finally, landlock_restrict_self applies the whole thing to the calling process, permanently.

The handled_access_fs field in the ruleset attribute is the part people get backwards. It doesn't list what you're allowing. It lists the access types this ruleset is responsible for, and anything in that list is denied everywhere except the paths you explicitly add. Handle read access and you lose read access to the entire filesystem until you add rules back.

A Program That Restricts Itself

Here is the whole thing:

#define _GNU_SOURCE
#include <linux/landlock.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#define READ_RIGHTS (LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_READ_DIR)

static int create_ruleset(const struct landlock_ruleset_attr *attr)
{ return syscall(__NR_landlock_create_ruleset, attr, sizeof(*attr), 0); }

static int add_rule(int fd, const struct landlock_path_beneath_attr *pb)
{ return syscall(__NR_landlock_add_rule, fd, LANDLOCK_RULE_PATH_BENEATH, pb, 0); }

static int restrict_self(int fd)
{ return syscall(__NR_landlock_restrict_self, fd, 0); }

static int allow_read(int ruleset_fd, const char *path)
{
    struct landlock_path_beneath_attr pb = { .allowed_access = READ_RIGHTS };
    int rc;

    pb.parent_fd = open(path, O_PATH | O_CLOEXEC);
    if (pb.parent_fd < 0) { perror(path); return -1; }
    rc = add_rule(ruleset_fd, &pb);
    close(pb.parent_fd);
    return rc;
}

static void try_read(const char *path)
{
    int fd = open(path, O_RDONLY);

    if (fd < 0)
        printf("  read %-24s FAILED (%s)\n", path, strerror(errno));
    else
        { printf("  read %-24s ok\n", path); close(fd); }
}

int main(void)
{
    struct landlock_ruleset_attr attr = { .handled_access_fs = READ_RIGHTS };
    int ruleset_fd = create_ruleset(&attr);

    if (ruleset_fd < 0) { perror("landlock_create_ruleset"); return 1; }
    if (allow_read(ruleset_fd, "/etc") < 0) return 1;

    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); return 1; }
    if (restrict_self(ruleset_fd)) { perror("landlock_restrict_self"); return 1; }
    close(ruleset_fd);

    printf("with landlock, /etc allowed:\n");
    try_read("/etc/hostname");
    try_read("/tmp/secret.txt");
    return 0;
}

Build and run it:

gcc -Wall -o sandbox sandbox.c
echo "hunter2" > /tmp/secret.txt
./sandbox

with landlock, /etc allowed:
  read /etc/hostname            ok
  read /tmp/secret.txt          FAILED (Permission denied)

Two details in there matter. The rule refers to a directory by an open file descriptor rather than a path string, opened with O_PATH so you get a handle without needing read permission on the directory itself. And restrict_self takes effect immediately for the calling process, with no way to undo it.

Why no_new_privs is Mandatory

Take the prctl call out and the program stops working:

landlock_restrict_self -> Operation not permitted

That's EPERM, and it's deliberate. PR_SET_NO_NEW_PRIVS tells the kernel that this process and its descendants can never gain privileges through execve, which is what stops a sandboxed process from escaping by running a setuid binary.

Without that guarantee, a restricted process could exec sudo or any setuid program and step outside the restrictions you just applied. Landlock refuses to apply itself at all rather than offer a sandbox with that hole in it. Set no_new_privs first, every time.

Rulesets Intersect, They Never Widen

This is the property to get right. Apply a ruleset allowing /etc, then apply a second allowing /tmp, and ask what you can reach:

after first ruleset:  /etc=ok               /tmp=Permission denied
after second ruleset: /etc=Permission denied  /tmp=Permission denied

The second ruleset didn't add /tmp. It took away /etc, and left you with nothing.

Each restrict_self intersects with everything already applied. The first ruleset permitted /etc and denied the rest. The second permitted /tmp and denied the rest. What survives is the overlap of those two, which is empty.

So a Landlock sandbox is a ratchet. Every application can only tighten, never loosen, and there's no operation anywhere in the API that widens what a restricted process may do. If you need a process to have access to two directories, both rules go into one ruleset before you apply it.

That also means you can't change your mind. A long-running process that restricts itself early can't be granted more later, by itself or by anyone else, short of starting a new process.

What Your Children Inherit

Restrictions follow fork without asking:

parent:       /etc=ok   /tmp/secret.txt=Permission denied
forked child: /etc=ok   /tmp/secret.txt=Permission denied

The child inherits the parent's Landlock domain exactly and there's no flag to opt out. The same holds across execve, which is the point of no_new_privs: the new program starts already inside the sandbox the old one built.

This is what makes Landlock useful for wrapping something you didn't write. Restrict yourself, then exec the thing you want contained, and it runs inside your restrictions without knowing they exist.

The exec Trap

It also sets a trap. Take the program above, keep only /etc allowed, and try to exec anything:

allowed: /etc
execl(/usr/bin/cat) failed: Permission denied

Executing a binary requires reading it. This ruleset handles LANDLOCK_ACCESS_FS_READ_FILE, so the kernel checks whether /usr/bin/cat may be read, finds no rule covering /usr, and refuses before the program ever starts.

Add /usr to the same ruleset and it works:

allowed: /etc and /usr
devils-dell

The general lesson is that a Landlock sandbox has to include everything the process touches, and that set is larger than you think. Your binary, its interpreter, every shared library it loads, and any config it reads at startup. ldd on the binary is a good place to begin the list.

Wrapping a Program You Didn't Write

Inheritance across exec is what makes Landlock useful beyond your own code. Restrict yourself, then exec whatever you want contained, and it runs inside the sandbox without cooperating or even knowing.

A usable wrapper needs one addition to the program above. Handle LANDLOCK_ACCESS_FS_EXECUTE alongside the read rights, allow the system directories any binary needs, then allow whatever working directory the user asked for:

#define RIGHTS (LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_READ_DIR | \
                LANDLOCK_ACCESS_FS_EXECUTE)

static int add_path(int ruleset_fd, const char *path)
{
    struct landlock_path_beneath_attr pb = { .allowed_access = RIGHTS };
    int rc;

    pb.parent_fd = open(path, O_PATH | O_CLOEXEC);
    if (pb.parent_fd < 0)
        return -1;
    rc = syscall(__NR_landlock_add_rule, ruleset_fd,
                 LANDLOCK_RULE_PATH_BENEATH, &pb, 0);
    close(pb.parent_fd);
    return rc;
}

int main(int argc, char **argv)
{
    struct landlock_ruleset_attr attr = { .handled_access_fs = RIGHTS };
    const char *base[] = { "/usr", "/lib", "/lib64", "/bin", "/etc" };
    int fd, i;

    if (argc < 3) { fprintf(stderr, "usage: %s DIR CMD...\n", argv[0]); return 2; }

    fd = syscall(__NR_landlock_create_ruleset, &attr, sizeof(attr), 0);
    if (fd < 0) { perror("create_ruleset"); return 1; }

    for (i = 0; i < (int)(sizeof(base) / sizeof(*base)); i++)
        add_path(fd, base[i]);
    if (add_path(fd, argv[1]) < 0) { perror(argv[1]); return 1; }

    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); return 1; }
    if (syscall(__NR_landlock_restrict_self, fd, 0)) { perror("restrict_self"); return 1; }
    close(fd);

    execvp(argv[2], &argv[2]);
    fprintf(stderr, "%s: %s\n", argv[2], strerror(errno));
    return 1;
}

The loop ignores what add_path returns, so the same binary works on systems where /lib64 or /bin are absent or symlinked somewhere else. The directory the user named is checked, because a typo there should be an error now rather than a puzzling denial later.

Now cat and ls can see the working directory and nothing else:

mkdir -p /tmp/work && echo "project data" > /tmp/work/notes.txt

./llrun /tmp/work cat /tmp/work/notes.txt
./llrun /tmp/work cat /tmp/secret.txt
./llrun /tmp/work ls /home

project data
cat: /tmp/secret.txt: Permission denied
ls: cannot open directory '/home': Permission denied

Neither program was modified, recompiled, or asked for consent. bwrap and similar tools reach that outcome by building mount and user namespaces around the program. This gets there by asking one LSM for less, in about sixty lines, with nothing to install.

Finding the Paths a Program Needs

The hard part of any sandbox isn't the API. It's the list. Programs open far more than you expect, and a path you forget shows up as a failure somewhere deep in a run.

Two tools build the list for you. ldd gives the shared libraries, which must be readable or the program never starts:

ldd /usr/bin/cat

linux-vdso.so.1 (0x00007fff85f39000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4f61bb5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4f61e0a000)

strace gives everything else. Run the program unrestricted first and collect what it opens:

strace -e trace=openat cat /etc/hostname 2>&1 | grep -oE '"/[^"]+"' | sort -u

"/etc/hostname"
"/etc/ld.so.cache"
"/lib/x86_64-linux-gnu/libc.so.6"
"/usr/lib/locale/locale-archive"

Four paths for a program that prints one file, and only one of them is the file you asked for. The linker cache, the C library, and the locale archive are all mandatory, which is why the wrapper allows /usr, /lib and /etc before it allows anything you chose.

Once restricted, strace also tells you exactly what a denial was:

strace -f -e trace=openat ./llrun /tmp/work cat /tmp/secret.txt 2>&1 | grep EACCES

openat(AT_FDCWD, "/tmp/secret.txt", O_RDONLY) = -1 EACCES (Permission denied)

That's the loop. Run it, read the EACCES line, decide whether the path belongs in the ruleset or the program shouldn't be reaching for it, then repeat. Landlock logs nothing of its own on this kernel, so strace is the debugger. Kernels from 6.15 report denials through the audit subsystem, so check your version before hunting for a log that isn't there.

Which ABI Version You Have

Landlock has grown since 5.13, and features you read about may not exist on your kernel. Ask it directly:

int v = syscall(__NR_landlock_create_ruleset, NULL, 0,
                LANDLOCK_CREATE_RULESET_VERSION);

This machine reports 1, which is the original from 5.13 and offers thirteen filesystem access rights:

grep -oE "LANDLOCK_ACCESS_FS_[A-Z_]+" /usr/include/linux/landlock.h | sort -u

LANDLOCK_ACCESS_FS_EXECUTE      LANDLOCK_ACCESS_FS_MAKE_BLOCK
LANDLOCK_ACCESS_FS_MAKE_CHAR    LANDLOCK_ACCESS_FS_MAKE_DIR
LANDLOCK_ACCESS_FS_MAKE_FIFO    LANDLOCK_ACCESS_FS_MAKE_REG
LANDLOCK_ACCESS_FS_MAKE_SOCK    LANDLOCK_ACCESS_FS_MAKE_SYM
LANDLOCK_ACCESS_FS_READ_DIR     LANDLOCK_ACCESS_FS_READ_FILE
LANDLOCK_ACCESS_FS_REMOVE_DIR   LANDLOCK_ACCESS_FS_REMOVE_FILE
LANDLOCK_ACCESS_FS_WRITE_FILE

Later versions added file reparenting, truncation, network rules covering TCP bind and connect, and control over device ioctls. Each arrived in its own ABI bump, so a program that wants a newer right should query the version and degrade rather than assume. Passing a right the running kernel doesn't know about makes landlock_create_ruleset fail with EINVAL, which is a confusing error to debug if you haven't checked the version first.

Conclusion

You can now sandbox a process from inside itself, with no privileges and no configuration, and you know the four surprises. no_new_privs comes first or nothing applies. Rulesets intersect rather than accumulate, so build one ruleset with everything in it. Children inherit, which is a feature. And read restrictions break exec unless the binary's path is allowed too.

There are a few directions to go from here. Add LANDLOCK_ACCESS_FS_WRITE_FILE to handled_access_fs and make a program that can read widely but write to exactly one directory. Wrap a program you didn't write by restricting yourself and then calling execve. Or look at how strace reports the denials, which is the fastest way to build the list of paths a real program actually needs.

Epilogue

The interesting question about Landlock isn't what it does. It's what it can't express. A ruleset names paths, so the unit of authority is a location in the filesystem rather than a particular file you were handed. You can say this process may read below /etc. You can't say this process may read the one file the user just picked, and nothing else.

That gap is what I've spent the last while on, building a capability-backed desktop OS in which authority arrives as a handle to one object rather than a rule about a location, with the Debian ecosystem still working underneath. Landlock does a great deal of the work, and the places it stops are where the design gets interesting.

I write about systems and their mysteries at thechris.in.

systemd-analyze

On the laptop I'm writing this on, it says:

Startup finished in 5.855s (firmware) + 8.469s (loader) + 3.106s (kernel)
+ 12.181s (userspace) = 29.613s
graphical.target reached after 12.175s in userspace

Add those four and you get 29.611, not the 29.613 printed on the last line. That gap is real and it isn't a mistake: systemd-analyze truncates each phase for display while summing the underlying microseconds, so a couple of milliseconds hide in the rounding. It's a small thing, and it will save you an evening of hunting for a bug that isn't there.

Four numbers, and most people's mental model accounts for one of them. The kernel took three seconds. The bootloader before it took eight and a half, and the firmware before that took nearly six. Fourteen seconds of this machine's boot happened before Linux was running at all, and I chose a good part of it without noticing.

This article follows the Linux boot process the whole way through one real boot, from the firmware handing control to a bootloader to a login prompt on your screen. Everything here you can run yourself, and almost none of it needs root.

Table of Contents

• What you need

• The Linux boot process is four handoffs, not one

• Firmware, and the part Linux never sees

• The bootloader, and the five seconds you chose

• The kernel phase: three seconds to a working machine

• What the initramfs is, and the chicken-and-egg problem it solves

• PID 1, and where the other twelve seconds go

• Why systemd-analyze blame misleads you about boot time

• Reading the critical chain

• Why your Linux boot time will be different

• The login screen, and the handoff to you

• Conclusion

• Epilogue

What You Need

Any Linux machine running systemd, which covers Ubuntu, Debian, Fedora, Arch, and most things people install in 2026. A terminal. That's it.

The machine I'm measuring is Ubuntu 22.04.5 LTS running kernel 5.15.0-190-generic, booting in UEFI mode from an NVMe disk with an ext4 root filesystem, with systemd 249 as PID 1. Yours will differ, sometimes by a lot, and I'll say where to expect that.

One command needs root and one file is restricted on many systems. I'll flag both when we get there.

The Linux Boot Process is Four Handoffs, Not One

The word "boot" suggests a single process. But it's four, and they barely know about each other.

Firmware runs first, from a chip on the motherboard, and its job is to find something bootable and start it.

It then hands control to a bootloader and stops. The bootloader's job is to find a kernel, load it into memory along with an initial filesystem, and jump to it. It then stops.

The kernel brings up hardware, mounts a root filesystem, and starts exactly one userspace process. Then it stops being in charge, though it keeps servicing that process forever afterward.

That first process, PID 1, starts everything else.

Each handoff is one way. The firmware isn't sitting underneath Linux waiting to help. The bootloader is gone from memory. Hold onto that, because it explains why the four numbers in systemd-analyze are measured by different things and mean different things.

Firmware, and the Part Linux Never Sees

The 5.855 seconds attributed to firmware is the only figure here that Linux didn't measure itself, and you can read the exact source it came from:

cat /sys/firmware/acpi/fpdt/boot/bootloader_launch_ns

5855973785

That's 5.855973785 seconds, which is the 5.855 systemd-analyze reported, truncated for display. The firmware wrote it into an ACPI table called the Firmware Performance Data Table before handing over, and the kernel exposes the table's fields under that directory. Its sibling fills in the rest:

cat /sys/firmware/acpi/fpdt/boot/exitbootservice_end_ns

On this machine that reads 14325507185, or 14.325 seconds, which is firmware and bootloader combined and matches the two phases added together.

Here's the part that trips people up. The gate isn't UEFI, it's whether your firmware publishes an FPDT at all. Plenty of UEFI machines don't, virtual machines especially, and on those systemd-analyze reports no firmware phase and no loader phase either, starting its accounting at the kernel. Check for the table rather than for UEFI:

ls /sys/firmware/acpi/fpdt/boot/ 2>/dev/null || echo "no FPDT, so no firmware timing"

If that prints nothing, your firmware isn't reporting, and there's no way to recover the number from inside Linux.

Almost six seconds is a lot, and there isn't much you can do about it from inside Linux. It's memory training and device enumeration, plus whatever your vendor decided to run before handing over. On a laptop with fast storage this is often the single largest phase, which surprises people who spend their optimization effort on services.

The Bootloader, and the Five Seconds You Chose

Here's the number that changes how you read the whole output. The loader phase took 8.469 seconds, nearly three times what the kernel took. Almost none of that was work.

grep ^GRUB_TIMEOUT /etc/default/grub

On this machine:

GRUB_TIMEOUT="5"

Five of those 8.469 seconds are GRUB counting down and waiting for a keypress that never comes. That's a configuration choice, made once, probably by the installer, and then never revisited. If you've ever wondered why your machine feels slow to start despite good hardware, this is the first place to look, and it's the cheapest fix in this entire article.

While GRUB is waiting, it already knows what it's going to do. You can read the instructions it passed along:

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-5.15.0-190-generic root=UUID=b4d0343e-9df4-40a7-be97-dcd51bdbf553
ro splash intel_iommu=on vt.handoff=7

That single line is the entire contract between the bootloader and the kernel. BOOT_IMAGE is which kernel got loaded. root=UUID=... names the filesystem to mount, by UUID rather than device name so it survives disks being renumbered. ro says mount it read-only at first. splash asks for a graphical boot screen instead of scrolling text. intel_iommu=on enables the IOMMU, and vt.handoff=7 is Ubuntu passing the virtual terminal to the graphical stack without a flicker.

GRUB loads two files into memory: the kernel, and an initial filesystem image we'll come back to shortly. Then it jumps into the kernel and ceases to exist.

The Kernel Phase: Three Seconds to a Working Machine

Now Linux is running. The kernel decompresses itself, sets up memory management, brings up the CPUs, initializes drivers, and looks for a root filesystem.

Watch it happen, with timestamps measured from the moment the kernel started:

journalctl -k -b -o short-monotonic | head

[    0.000000] devils-dell kernel: microcode: microcode updated early to revision 0x100
[    0.000000] devils-dell kernel: Linux version 5.15.0-190-generic
[    0.000000] devils-dell kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-190-generic
[    0.000000] devils-dell kernel: KERNEL supported cpus:

Zero is when the kernel began executing, not when you pressed the power button. Everything before this point, all fourteen seconds of firmware and bootloader, is outside this clock entirely. That's the first thing to understand about kernel boot timestamps, and it's why dmesg output makes some machines look far faster than they are.

You may have reached for dmesg there and been refused:

dmesg: read kernel buffer failed: Operation not permitted

That's deliberate, and you can confirm it:

sysctl kernel.dmesg_restrict

Ubuntu sets kernel.dmesg_restrict = 1, which limits the kernel ring buffer to root because it leaks kernel addresses useful to an attacker. Use journalctl -k instead, which reads the same messages through the journal and works as an ordinary user.

One more detail from /proc/cmdline explains something people notice and rarely investigate. The kernel was told to mount the root filesystem ro, read-only, yet the system you're using now clearly writes to disk. Check what it looks like today:

findmnt -n -o SOURCE,FSTYPE,OPTIONS /

/dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro

It's read-write now, so something changed it. The root filesystem is mounted read-only first so that a filesystem check can run safely against it, since checking a filesystem while processes are writing to it is how you turn a small problem into a large one.

Once that check passes, userspace remounts the same filesystem read-write in place, and the errors=remount-ro option you can see there is the reverse promise: if the kernel hits a filesystem error later, it drops back to read-only instead of writing to something it no longer trusts.

Now find the exact moment the kernel stopped being alone:

journalctl -b -o short-monotonic | grep -m1 'systemd\[1\]'

[    3.152109] devils-dell systemd[1]: Inserted module 'autofs4'

3.15 seconds in, PID 1 logged its first line. That matches the 3.106 seconds systemd-analyze attributes to the kernel, and it's the handoff. From here the kernel does nothing on its own initiative. It answers system calls, and every decision about what runs next belongs to userspace.

What the initramfs is, and the Chicken-and-Egg Problem it Solves

There's a step hidden inside that three seconds, and it's the part of Linux boot that confuses people most.

The kernel needs to mount your root filesystem. To do that, it needs a driver for your storage controller and a driver for the filesystem, and possibly code to assemble a RAID array, open an encrypted volume, or activate LVM. Those drivers live in modules. The modules live on the root filesystem. Which the kernel can't mount yet.

The way out is a small filesystem the bootloader loads into memory alongside the kernel, complete in itself. Look at it:

ls -l /boot/initrd.img-$(uname -r)
lsinitramfs /boot/initrd.img-$(uname -r) | wc -l
lsinitramfs /boot/initrd.img-$(uname -r) | grep -c '\.ko'

Those paths and that tool are Debian and Ubuntu conventions. On Fedora the image is /boot/initramfs-$(uname -r).img and the tool is lsinitrd. On Arch it's usually /boot/initramfs-linux.img, read with lsinitcpio.

On this machine the image is 79,945,887 bytes, roughly 76 MB, holding 2,318 files of which 1,386 are kernel modules. It's a real, working, if minimal Linux system that exists to solve one problem: find and mount the actual root filesystem.

Once it succeeds, it does something unusual. It never exits. It swaps the real root into place, moves itself out of the way, and executes the real /sbin/init without ever starting a new process tree. PID 1 changes identity mid-flight and keeps its process ID.

If you use Arch or a minimal Fedora install, your initramfs may be a tenth of this size, because Ubuntu builds a generic one containing drivers for hardware you don't own so that the same image boots on any machine. That's a deliberate trade of size against portability, and lsinitramfs will show you what you're carrying.

PID 1, and Where the Other Twelve Seconds Go

The kernel finished at 3.1 seconds. The login screen appeared at 12.175 seconds of userspace. So what happened in between?

systemctl get-default
systemctl list-unit-files --no-legend | wc -l
systemctl list-units --type=service --state=running --no-legend | wc -l

graphical.target
472
44

systemd's model is that you name a goal and it works out the order. The goal here is graphical.target, which wants multi-user.target, which wants a working network, filesystems, logging, and dozens of other things.

There are 472 unit files installed on this machine and 44 services actually running. systemd builds a dependency graph from those and starts everything it can in parallel, waiting only where a real dependency exists.

That parallelism is why boot analysis is harder than it looks. Dozens of things are happening at once, and the total isn't the sum of the parts.

Why systemd-analyze blame Misleads You About Boot Time

The obvious next command is the wrong one, and the trap is worth walking into deliberately:

systemd-analyze blame | head -5

3min 48.947s fstrim.service
     44.548s plocate-updatedb.service
     13.953s apt-daily.service
      4.875s docker.service
      4.106s NetworkManager-wait-online.service

Read that against the total. Userspace took 12.181 seconds. The top entry claims three minutes and forty-nine. Both numbers are correct, and the contradiction is the whole point.

blame lists how long each unit took to start, for every unit systemd has started, whenever it started. It says nothing about whether the unit was on the path to your login screen. Check the top three:

systemctl show fstrim.service -p TriggeredBy -p WantedBy
systemctl list-timers fstrim.timer

TriggeredBy=fstrim.timer
WantedBy=
NEXT                        LEFT        LAST                        PASSED
Mon 2026-09-14 00:59:36 IST 4 days left Mon 2026-09-07 00:33:35 IST 2 days ago

WantedBy is empty, so nothing pulls it in at boot. It's triggered by a timer. It last ran two days ago and runs again in four.

plocate-updatedb.service and apt-daily.service are the same shape, triggered by their own timers.

The top three entries in blame, nearly five minutes of apparent boot time, contributed exactly nothing to how long you waited for a login prompt.

The first entry that's genuinely on the boot path is docker.service, fourth in the list, at 4.875 seconds.

I'd rather you take the general lesson than the specific one. A measurement that reports on a superset of what you care about will mislead you in proportion to how much of that superset is irrelevant. blame isn't broken. It answers a different question than the one people ask it.

Reading the Critical Chain

The command that answers the actual question is this one:

systemd-analyze critical-chain

graphical.target @12.175s
└─multi-user.target @12.175s
  └─docker.service @7.297s +4.875s
    └─network-online.target @7.295s
      └─NetworkManager-wait-online.service @3.188s +4.106s
        └─NetworkManager.service @3.151s +35ms
          └─network-pre.target @3.150s
            └─netfilter-persistent.service @1.377s +1.772s
              └─local-fs.target @1.374s

The @ is when a unit became active. The + is how long it took. Now the twelve seconds make sense: docker.service at 4.875 and NetworkManager-wait-online.service at 4.106 account for nearly nine of them, and they're serialized because Docker wants a working network before it starts.

NetworkManager-wait-online is the one to look at first on most desktops. It does what its name says, which is block until the network is actually up, and on a laptop associating with Wi-Fi that can be seconds of doing nothing. It exists so that services needing a network don't start before there is one. Whether you need that guarantee is a real question with a real answer, and it depends on what you run.

Two cautions about this output. It shows one chain, not every slow thing, so a unit that was slow but off the critical path never appears. And the @ times aren't a causal sequence you can read top to bottom. My own output has a Docker network mount timestamped at 11 seconds nested underneath a target that completed at 650 milliseconds, which looks impossible until you realize the tree shows dependency edges and not a sequence of events. Read the + values for cost and the structure for ordering constraints, and don't read the nesting as a chronology.

Why Your Linux Boot Time Will Be Different

Everything above is one boot on one machine, and the specific figures are worth less than the method. Before you compare yours to mine, know which parts move and why.

Firmware time varies more than anything else here, and it has almost nothing to do with Linux. A desktop with lots of RAM to train and a dozen USB devices to enumerate can spend fifteen seconds where this laptop spends six. If your firmware has a fast boot option, that option is what it sounds like: skipping enumeration steps, at the cost of not noticing hardware you plugged in.

Loader time is mostly your timeout, so it's mostly your decision. Kernel time moves with how much hardware you have and how much of the initramfs has to be unpacked and searched. This is why a distribution-generic initramfs like Ubuntu's costs more here than a host-specific one built for your machine alone. If your root filesystem is encrypted, some of what looks like kernel time is actually you typing a passphrase.

Userspace time is where your machine differs from mine most, because it reflects what you installed rather than what you own. Docker costs me nearly five seconds and would cost you nothing if you don't run it.

Run it a few times before drawing conclusions. Boot timing varies between runs on the same machine, and a single reading tells you less than you'd like.

The Login Screen, and the Handoff to You

The last step is the one you see:

systemctl status display-manager --no-pager | head -1
loginctl show-session $(loginctl | awk 'NR==2{print $1}') -p Type -p Class

● lightdm.service - Light Display Manager
Type=x11
Class=user

On this machine, the display manager is LightDM, started as part of graphical.target. It opens a session on a virtual terminal, draws the greeter, and waits.

Behind it, systemd has already created a seat and a session slot for whoever logs in. When you type your password, the display manager authenticates through PAM, systemd assigns the session, and your desktop environment starts as a user process.

That vt.handoff=7 from the kernel command line pays off here. It hands the virtual terminal to the graphical stack without the screen blanking and redrawing, which is the difference between a smooth boot and a flickering one.

From this point, the kernel is doing what it always does, which is answering system calls. If you want to follow what happens next, I wrote about that boundary in detail.

Conclusion

You can now account for your own boot, phase by phase, with numbers instead of guesses. On this laptop, 29.6 seconds breaks down as almost six seconds of firmware you can't control, eight and a half seconds of bootloader that's mostly a countdown you can delete, three seconds of kernel, and twelve seconds of userspace dominated by two services waiting on the network.

More usefully, you have a way to tell a real measurement from a plausible one. systemd-analyze blame looks authoritative and answers a question nobody asked. The critical chain answers the right question and still needs care, because its tree maps dependencies, not chronology.

A few directions from here. Set GRUB_TIMEOUT=1 and regenerate the config, with sudo update-grub on Debian and Ubuntu or sudo grub2-mkconfig -o /boot/grub2/grub.cfg on Fedora, then reboot and watch five seconds vanish. Run systemd-analyze plot > boot.svg and open it in a browser for the parallel view the text output flattens. Or look at whether NetworkManager-wait-online.service is earning its four seconds on your machine, which for most desktops it isn't.

Epilogue

The reason I went looking at any of this is that I'm building a Linux distribution with an Android-style permission model, where a program gets only the authority its manifest asks for rather than everything its user happens to have. That turns the boot sequence into a security question. Every process started before you log in runs with more authority than anything you launch afterward, and until I could name each one and say why it was there, I had no real way to argue about which of them deserved it.

You can find more of what I write at thechris.in.

#include <stdio.h>
#include <time.h>
#include <unistd.h>

int main(void)
{
    struct timespec ts;

    for (int i = 0; i < 3; i++)
        clock_gettime(CLOCK_MONOTONIC, &ts);

    write(1, "done\n", 5);
    return 0;
}

Both of those look like system calls. Both of them ask the kernel for something your program can't get on its own: the current time, and access to a file descriptor.

Now run it under strace, which reports every system call a process makes:

gcc -O0 -o mystery mystery.c
strace ./mystery 2>&1 | grep -c clock_gettime

The answer is 0.

The write() shows up immediately. The three clock_gettime() calls don't appear at all. Same program, same libc, same machine, and one of them never reaches the kernel.

By the end of this article you'll know every step between your write() and the code that runs inside the kernel, why the return trip is stranger than the way in, and why clock_gettime() gets to skip the whole thing.

Table of Contents

• What You Need

• What a System Call Looks Like from Userspace

• The Crossing

• Inside the Kernel: Finding the Handler

• The Return Trip, and the Truth About errno

• The System Call That Never Happens

• What the Boundary Costs

• Conclusion

• Epilogue

What You Need

You need an x86-64 machine running Linux, gcc, strace, and objdump. On Debian or Ubuntu that's build-essential, strace, and binutils. You also need to be comfortable reading C. You don't need to have written kernel code, and you won't build or install a kernel here.

Everything below runs on a normal user account, except for one optional tracing step that needs sudo.

Two warnings about scope. First, this article is about x86-64 only. ARM64 does the same job with different instructions and different register rules, and hedging every sentence for both would double the length and halve the clarity. Second, kernel internals move. I ran everything here on Linux 5.15 (Ubuntu 22.04, Intel Core i7-10750H), and I'll flag the places where newer kernels differ. Check your own version with uname -r.

What a System Call Looks Like from Userspace

Let's start with a correction that matters: write() isn't a system call. It's an ordinary C function in your C library. That function makes a system call on your behalf, and the difference between those two things is where most confusion about the kernel begins.

You can prove it by cutting libc out and making the call yourself.

On x86-64, a system call has a fixed convention. You put the number of the call you want in rax, and its arguments in rdi, rsi, rdx, r10, r8, and r9, in that order. Then you execute a single instruction called syscall.

The numbers aren't something you memorise. They live in a header on your machine:

grep -E "__NR_(write|getpid|clock_gettime) " /usr/include/x86_64-linux-gnu/asm/unistd_64.h

On this machine:

#define __NR_write 1
#define __NR_getpid 39
#define __NR_clock_gettime 228

So write is call number 1. Here's that call written by hand, with no libc wrapper involved:

static long raw_write(int fd, const void *buf, unsigned long count)
{
    long ret;

    __asm__ volatile (
        "syscall"
        : "=a" (ret)                   /* the result comes back in rax */
        : "a" (1L),        /* rax = 1, the syscall number for write */
          "D" ((long)fd),  /* rdi = first argument                  */
          "S" (buf),       /* rsi = second argument                 */
          "d" (count)      /* rdx = third argument                  */
        : "rcx", "r11", "memory"
    );

    return ret;
}

Compile and run it and your bytes turn up on standard output, with nothing from libc anywhere in the path.

Look at that last line, the clobber list. It tells the compiler rcx and r11 are going to be destroyed. I didn't add that for safety. It's a fact about the hardware, and it quietly explains something odd about the convention above.

C functions on x86-64 pass their fourth argument in rcx. System calls pass theirs in r10 instead. Every explanation that says "because that's the convention" stops one step too early. The real reason is that the syscall instruction overwrites rcx as part of doing its job. The kernel couldn't receive a fourth argument there even if it wanted to, so the ABI routed around its own hardware.

This is the first sign that this boundary isn't a function call wearing a costume. Different mechanism, different rules, and the hardware got there first.

You can see the instruction itself in your compiled binary:

objdump -d --no-show-raw-insn raw_write | grep -B2 -A2 syscall

The instruction is right there:

    118b:	mov    -0x28(%rbp),%rdx
    118f:	syscall
    1191:	mov    %rax,-0x8(%rbp)

Three lines: load a register, execute one instruction, and store what came back. Everything else in this article happens between line two and line three.

The Crossing

When the CPU executes syscall, it does something no ordinary jump can do: it changes the privilege level of the processor. Your code runs in what x86 calls ring 3. Kernel code runs in ring 0.

The instruction does three things, in order:

1. It saves the address of the next instruction in your program into rcx. That's the return address, and it's why rcx gets clobbered.

2. It saves the CPU flags into r11.

3. It loads a new instruction pointer, code segment, and stack segment from three special CPU registers.

That third step is the important one. The new instruction pointer doesn't come from your program. It comes from a machine-specific register called LSTAR, and the kernel wrote that register during boot.

That's the security property the whole design rests on. Userspace triggers the transition. Userspace doesn't get to pick where it lands. There's one door, the kernel installed it, and it opens on entry_SYSCALL_64 in arch/x86/entry/entry_64.S.

Notice what the instruction does not do. It doesn't consult the interrupt descriptor table or push an exception frame. Older systems reached the kernel through int 0x80, a software interrupt with all of that machinery attached, and it was slow. The syscall instruction exists because this path was worth building dedicated hardware for.

Becoming the Kernel

Arriving at entry_SYSCALL_64 isn't the same as being ready to run kernel code. At the instant of arrival the CPU is in ring 0, but it's still using your stack and your register state. The kernel has to fix that before it can safely do anything.

Three things happen, and all three are the kernel establishing trust in a machine it is already running on:

1. swapgs

The kernel keeps a per-CPU pointer in the GS register so it can find its own data structures. While you were running, GS held whatever your program put there. A single instruction, swapgs, exchanges it for the kernel's value. The kernel documentation is unusually blunt about this one, calling it fragile and warning that it must nest perfectly. Get it wrong in either direction and you have a very bad afternoon ahead of you.

2. The stack switch

Your stack pointer is a value your program chose, so the kernel can't trust it. It stashes your rsp and switches to a kernel stack it allocated for this thread.

3. Building pt_regs

The kernel then pushes your saved registers onto that new stack in a specific order, forming a C struct called struct pt_regs. pt_regs is your process, frozen. Every debugger that inspects a stopped process, every signal handler that modifies the context it returns to, and every system call handler reads its arguments out of that struct.

There may be a fourth step. If your CPU is vulnerable to Meltdown, the kernel also swaps page tables here, because on those chips the kernel's memory can't safely stay mapped while your code runs.

That swap isn't free. It's why system calls got measurably slower in 2018, and why some of the numbers later in this article would look different on a machine three years older.

You can check whether your machine pays that cost:

cat /sys/devices/system/cpu/vulnerabilities/meltdown

The test machine here reports Not affected, because its generation of silicon has the fix in hardware. An older laptop will report Mitigation: PTI, and every system call it makes is doing extra work at exactly this point.

Look through the other files in that directory while you're there. Each one is a mitigation that this boundary may be paying for.

Inside the Kernel: Finding the Handler

The kernel is now running on its own stack with your registers safely captured. It calls a C function, do_syscall_64, and hands it two things: your pt_regs, and the system call number you left in rax.

Dispatch is short enough to describe completely. The kernel checks that your number is within range, clamps it, and jumps to the matching handler:

if (likely(nr < NR_syscalls)) {
    nr = array_index_nospec(nr, NR_syscalls);
    regs->ax = x64_sys_call(regs, nr);
}

Two things in there need explaining.

array_index_nospec is a Spectre mitigation. A plain bounds check isn't enough on a speculating CPU, because the processor may run ahead and touch memory past the end of the table before the check resolves. This helper forces the index to be clamped in a way speculation can't skip.

x64_sys_call is where a lot of older explanations are now wrong, including some still near the top of search results. They'll tell you the kernel indexes an array of function pointers called sys_call_table. That was true for many years and is no longer how dispatch works. Since kernel 6.9, x64_sys_call is a generated switch statement of direct calls.

The reason is a chain of consequences. Spectre mitigations made indirect calls through function pointers expensive, because each one has to go through a retpoline.

A switch of direct calls avoids that cost entirely. The table still exists, because tracing tools use it, but the hot path no longer reads it. On my 5.15 kernel the older table-based dispatch is still in place, which is exactly why naming your kernel version in an article like this one matters.

Where the Handler Comes From

The handler for write is named __x64_sys_write, and you won't find that name written anywhere in the kernel source. It's generated by a macro:

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, size_t, count)

SYSCALL_DEFINE3 means "a system call taking three arguments". The macro expands into two functions: the real implementation, and a thin wrapper named __x64_sys_write that takes a single struct pt_regs * and pulls the arguments out of it.

That indirection is deliberate. Rather than trusting whatever userspace happened to leave in the argument registers, the kernel unpacks exactly the values it expects from the frozen struct it built itself. It's the same defensive instinct as array_index_nospec, applied to the shape of the function call.

You don't have to take any of this on faith. ftrace, the kernel's built-in tracer, will show you the handler running.

This needs a root shell rather than sudo on each line, because the filter that keeps the output readable refers to the shell's own process ID:

sudo -i
cd /sys/kernel/tracing

echo 0 > tracing_on
echo $$ > set_ftrace_pid              # trace only this shell
echo function_graph > current_tracer
echo __x64_sys_write > set_graph_function

echo 1 > tracing_on
echo "trigger a write" > /dev/null    # the call we want to catch
echo 0 > tracing_on

head -40 trace

Without that set_ftrace_pid line, you'll trace every write on the machine, which on a running desktop is far too much output to read.

Here's the result on the test system, lightly trimmed:

 9)               |  __x64_sys_write() {
 9)               |    ksys_write() {
 9)               |      __fdget_pos() {
 9)   0.124 us    |        __fget_light();
 9)   0.363 us    |      }
 9)               |      vfs_write() {
 9)               |        rw_verify_area() {
 9)               |          security_file_permission() {
 9)               |            apparmor_file_permission() {
 9)   0.264 us    |              aa_file_perm();
 9)   0.457 us    |            }
 9)   0.644 us    |          }
 9)   0.857 us    |        }
 9)   0.083 us    |        write_null();
 9)               |        __fsnotify_parent() {
 9)   0.107 us    |          fsnotify();
 9)   1.383 us    |        }
 9)   2.813 us    |      }
 9)   3.449 us    |    }
 9)   3.720 us    |  }

Read that from the outside in and you have the whole descent in twenty lines.

__x64_sys_write is the generated wrapper. It calls ksys_write, the real implementation. That looks up your file descriptor with __fdget_pos, then hands off to vfs_write, the virtual filesystem layer, which is where the kernel stops caring what kind of thing you're writing to.

Then security_file_permission calls into AppArmor, because this machine runs Ubuntu. On a SELinux system something else sits there. Either way it's a security module deciding whether you're allowed to do this. On every write. Every one.

write_null is the payoff, and it's there by accident: the command above wrote to /dev/null, so that's the actual driver, the one whose whole job is throwing your bytes away. Point the same write at a file on disk and a filesystem function shows up in that slot instead. Nothing above it moves.

The whole thing took 3.7 microseconds, and the timings on the right tell you where it went.

When you're done, put the tracer back:

echo nop > current_tracer
echo > set_graph_function
echo > set_ftrace_pid

If /sys/kernel/tracing doesn't exist on your system, try /sys/kernel/debug/tracing instead.

The Return Trip, and the Truth About errno

The handler finishes and returns a number. That number goes into rax, and rax is the only thing your program gets back.

Which raises a question that is rarely asked directly: if the kernel can only return one value, how does it report what went wrong as well as that something went wrong?

The answer is that it doesn't have a separate channel. The kernel returns errors as small negative numbers in the same register as the result. A successful write of 24 bytes returns 24. A write to a closed descriptor returns -9, because EBADF is error number 9.

Now put that together with the fact that errno exists, and something doesn't add up. errno is a variable in your process. The kernel doesn't write to your variables.

Here's the test. Set errno to zero, make a raw system call that's guaranteed to fail, and look at both values:

#include <stdio.h>         /* fprintf, stderr */
#include <errno.h>         /* errno */

/* raw_write() is the function from the previous section */

errno = 0;

long ok  = raw_write(1, "written via raw syscall\n", 24);
long bad = raw_write(999, "x", 1);          /* not an open descriptor */

fprintf(stderr, "ok = %ld\n",  ok);
fprintf(stderr, "bad = %ld\n", bad);
fprintf(stderr, "errno = %d\n", errno);

Running it:

written via raw syscall
ok = 24
bad = -9
errno = 0

There it is. The kernel returned -9, and errno never moved.

errno is a libc invention. When you call the normal write(), the wrapper checks whether the return value is a small negative number. If it is, it negates it, stores the result in errno, and returns -1 to you. The -1-and-check-errno pattern every C programmer learns is a convention built entirely in userspace, on top of a kernel interface that works a completely different way.

Once you've seen this, a familiar bug class makes more sense. errno is only meaningful immediately after a failed call, because it's just a variable that the last wrapper to fail happened to write to.

Two Ways Out

Getting back to userspace has a fast path and a slow path.

The fast path is sysret, the mirror of syscall: it restores your instruction pointer from rcx and your flags from r11 and drops back to ring 3 in a few cycles.

The slow path is iret, the general-purpose return-from-interrupt instruction. It's significantly slower, and the kernel uses it when sysret can't be trusted. The entry code's own comments explain why: sysret has trouble with non-canonical addresses due to bugs in both AMD and Intel CPUs, so whenever something might have changed your saved state, the kernel forces the safe path. A debugger reaching in through ptrace and changing your registers is the usual culprit.

Before either instruction runs, the kernel does the housekeeping it deferred. It checks for pending signals and delivers them. It checks whether the scheduler wants the CPU back, and if so, your process stops here and something else runs.

Which means a system call isn't only a request for service. It's one of the main places your process can simply stop running. You asked to write five bytes. On the way back the kernel gets to reconsider everything about you, including whether you should continue at all.

The System Call That Never Happens

Now back to the mystery from the opening.

Look at your own process's memory map:

cat /proc/self/maps | tail -4

which ends with:

7fff32f97000-7fff32f9b000 r--p  [vvar]
7fff32f9b000-7fff32f9d000 r-xp  [vdso]

Two regions you never asked for. Neither came from your program or your libraries. The kernel put them there, in every process on the system.

[vdso] stands for virtual dynamic shared object. It's a small, complete shared library (real ELF, with a symbol table) that the kernel maps into every address space. And because the kernel tells each process where it put it, you can dump your own copy and take it apart:

#include <stdio.h>
#include <sys/auxv.h>      /* getauxval, AT_SYSINFO_EHDR */
#include <unistd.h>        /* getpagesize */

int main(void)
{
    void  *vdso = (void *)getauxval(AT_SYSINFO_EHDR);   /* the kernel tells us where */
    size_t len  = 2 * getpagesize();                    /* the mapping is two pages  */

    FILE *f = fopen("vdso.so", "wb");
    fwrite(vdso, 1, len, f);
    fclose(f);

    printf("vDSO was mapped at %p\n", vdso);
    return 0;
}

AT_SYSINFO_EHDR lives in <sys/auxv.h>. Leave that header out and you don't get a polite warning about it: the build stops with AT_SYSINFO_EHDR undeclared.

Run that, then read its symbol table like any other library:

./dump_vdso && objdump -T vdso.so | grep __vdso

and out comes:

__vdso_gettimeofday
__vdso_clock_gettime
__vdso_clock_getres
__vdso_time
__vdso_getcpu

There's the answer. clock_gettime is in that list.

When you call clock_gettime(), libc calls into the vDSO. That code is written by kernel developers and shipped with the kernel, but it executes in ring 3, as part of your process. It reads the current time out of the [vvar] page (a read-only page the kernel keeps updated) and returns.

There's no privilege change, syscall instruction, entry point, stack switch, or pt_regs. And that means there's nothing for strace to see, because strace works by watching the boundary, and this call never goes near it.

That's the whole trick. The kernel took a handful of operations that are called constantly, need no privileges to read, and only ever return information the kernel is willing to publish – and it published them.

That last constraint explains why the list is so short. write() can never work this way, because it has to change state that belongs to the kernel. Reading the clock does not. So the clock, the time of day, and the current CPU number moved out to where the caller already is.

What the Boundary Costs

Everything above is mechanism. Here's the price, measured.

The benchmark compares a call that definitely traps against one that definitely does not. For the first, use syscall(SYS_getpid). Going through the thin syscall() wrapper guarantees a real crossing:

/* Excerpt. Needs <unistd.h>, <sys/syscall.h> and <time.h>, plus a now()
   helper returning seconds as a double, and ITERATIONS defined above. */

double a = now();
for (long i = 0; i < ITERATIONS; i++)
    sink += syscall(SYS_getpid);

double b = now();
for (long i = 0; i < ITERATIONS; i++)
    clock_gettime(CLOCK_MONOTONIC, &ts);

On the test machine, two million iterations of each:

real system call (getpid):   106.9 ns/call
vDSO call (clock_gettime):    17.2 ns/call
ratio:                          6.2x

Roughly six times, and getpid is about as cheap as a system call gets. It reads one field and returns. Which means almost none of that 107 nanoseconds is the work. It's the privilege change, swapgs, the stack switch, pt_regs going up and coming back down, plus whatever mitigations your particular CPU insists on along the way.

Now the caveat, because it matters more than the number.

That 107 nanoseconds is close to a best case. Check what this machine reported earlier: Not affected for Meltdown, so it never does the page-table swap. Its Spectre mitigation is Enhanced IBRS, which is handled in silicon rather than by retpolines in software. This CPU is skipping two of the most expensive things a crossing can involve.

So run the benchmark yourself, and read your own mitigation files alongside it:

grep . /sys/devices/system/cpu/vulnerabilities/*

If yours says Mitigation: PTI, your crossings are doing strictly more work than the ones measured here, and your number should be higher. Older silicon can be dramatically worse.

Treat the ratio as the durable result and the absolute number as one reading from one machine. The figure moves with your CPU, your kernel, and whichever mitigations you happen to be carrying. Run it a few times while you're there. The spread between runs on this laptop was about fifteen percent, which tells you roughly how much to trust any single number, including mine.

One more result from the same run corrects a widely repeated claim. getpid() through normal libc costs the same as the raw syscall(SYS_getpid). glibc used to cache the process ID to avoid the trip, and stopped years ago, because keeping the cache correct across fork and namespace changes was worse than paying the hundred nanoseconds.

Six times sounds abstract until you attach it to something. A program making a million small read() calls spends about a tenth of a second on nothing but crossings. This is the pressure behind a lot of modern kernel interface design: io_uring exists so that submitting a thousand operations can cost one crossing instead of a thousand. Batching syscalls, buffering writes, and using sendfile() instead of a read-write loop are all the same optimisation: not doing less work, just crossing the boundary fewer times.

Conclusion

You can now follow a system call the whole way. You've seen the syscall instruction in your own binary, watched a bad file descriptor come back as -9 while errno stayed at zero, pulled the vDSO out of your own address space and read its symbol table, and measured what the crossing costs on your own CPU.

More usefully, you have a mental model that keeps paying out. When you read that io_uring reduces syscall overhead, you know exactly what overhead means. When a profile shows time in entry_SYSCALL_64, you know what that function does. When strace shows nothing, you know to check the vDSO before doubting the tool.

There are a few directions to go from here. Run the ftrace recipe and follow __x64_sys_write down into the filesystem layer. Read arch/x86/entry/entry_64.S: it's heavily commented and much more approachable than its reputation suggests. Or check /sys/devices/system/cpu/vulnerabilities/ on an older machine and work out what each mitigation is costing you at this boundary.

Epilogue

I'm currently experimenting with an OS design on top of the Linux kernel that would bring an Android-style permissions and capabilities model to a desktop OS while trying to be 100% compatible with the Debian ecosystem. This has led to some really interesting research lately. This article is a product of that research.

I'll be writing more about the Linux kernel before I move on to formal verification, as in the DO-178C and DO-333 world where avionics software has to qualify the tools that check it. Usually that means Viper, Why3, Z3 and friends.

In the meantime, I also write about systems that have to survive contact with reality at thechris.in, including a companion piece to this one, on what it means to build on an abstraction whose cost you can measure but never see.

You can deploy it in different hosting environments, which gives you the flexibility to choose a deployment model that fits your needs.

Choosing the right hosting option is an important part of any Odoo deployment. It affects factors such as performance, security, maintenance, scalability, and long-term operational costs.

Your team can either self-host Odoo on your own infrastructure or use a managed hosting provider to handle server management. Each approach offers different levels of control, flexibility, and operational responsibility.

In this article, you'll learn about the different ways to host Odoo, including how to set up a basic self-hosted deployment. You'll also compare self-hosted and managed hosting and explore the advantages and limitations of each approach.

By the end, you'll have a better understanding of which hosting model best fits your business and technical requirements.

What We'll Cover:

• What Are Your Odoo Hosting Options?

• Self-Hosted Odoo

• Managed Odoo Hosting

• Self-Hosted vs Managed Hosting

• How to Choose the Right Option

• Key Factors to Consider Before Choosing

• Conclusion

What Are Your Odoo Hosting Options?

Odoo can be hosted in different ways depending on your organization's needs. The main difference between these options is who manages the infrastructure and day-to-day maintenance. In most cases, businesses choose between two hosting models:

1. Self-Hosted Odoo: With a self-hosted deployment, you install and manage Odoo on infrastructure that you control, such as a virtual private server (VPS), dedicated server, cloud virtual machine, or on-premises server. This approach gives you greater control over the environment, but your team is also responsible for maintaining and securing it.

2. Managed Odoo Hosting: With managed hosting, a hosting provider manages the infrastructure and handles routine maintenance tasks. This allows your team to focus on using Odoo for business operations instead of managing servers.

The following sections examine both hosting models in more detail, including their benefits, limitations, and ideal use cases. You'll also learn how to set up a basic self-hosted Odoo deployment and what to consider before choosing a hosting option.

Self-Hosted Odoo

Self-hosting Odoo means deploying and managing the application on infrastructure that you control, such as a virtual private server (VPS), dedicated server, cloud virtual machine, or an on-premises server.

With this approach, your organization is responsible for installing, configuring, maintaining, and securing both Odoo and the infrastructure.

Benefits of Self-Hosting

Self-hosting gives you greater control and flexibility over your deployment. Some of the key benefits include:

• Complete control over the hosting environment.

• Freedom to choose your operating system, database configuration, and hosting provider.

• Support for custom modules, integrations, and server configurations.

• Flexibility to optimize performance based on your workload.

• Greater control over scaling and infrastructure resources.

Challenges of Self-Hosting

Along with greater control comes additional responsibility. When you self-host Odoo, you are responsible for:

• Installing software updates and security patches.

• Managing backups and disaster recovery.

• Monitoring server performance and application availability.

• Troubleshooting infrastructure and application issues.

• Securing the server against potential threats.

Organizations should ensure they have the necessary technical expertise before choosing this deployment model.

Who Should Choose Self-Hosted Odoo?

Self-hosted Odoo is a good choice for:

• Developers and DevOps teams.

• Organizations with in-house IT administrators.

• Businesses that require extensive customization.

• Teams that need complete control over their infrastructure.

• Organizations with specific security or compliance requirements.

How to Self Host Odoo

The following steps show how to deploy Odoo using Docker Compose, PostgreSQL, and Traefik. Traefik acts as the reverse proxy and handles HTTPS certificates for your domain.

Prerequisites

• Linux server with 2 vCPU and 4 GB RAM.

• Docker and Docker Compose installed.

• Domain name with an A record pointing to the server.

• Inbound TCP traffic allowed on ports 80 and 443.

Prepare the Project Directory

Create a directory for the Odoo deployment:

mkdir ~/odoo

Navigate to the project directory:

cd ~/odoo

Create directories for persistent Odoo data, PostgreSQL data, custom addons, and Let's Encrypt certificates:

mkdir -p odoo-data postgres-data addons letsencrypt

Set the ownership of the Odoo data and addons directories to the user used by the Odoo container:

sudo chown -R 100:101 ~/odoo/odoo-data ~/odoo/addons

Create the environment file:

nano .env

Add the following configuration. Replace the domain, email address, and passwords with your own values.

DOMAIN=odoo.example.com 
LETSENCRYPT_EMAIL=admin@example.com 

POSTGRES_DB=postgres 
POSTGRES_USER=odoo 
POSTGRES_PASSWORD=STRONG_DATABASE_PASSWORD 

ODOO_DB_HOST=db 
ODOO_DB_PORT=5432 
ODOO_DB_USER=odoo 
ODOO_DB_PASSWORD=STRONG_DATABASE_PASSWORD

ODOO_ADMIN_PASSWORD=STRONG_ADMIN_PASSWORD

Save and close the file.

Create the Docker Compose Configuration

Create the Docker Compose file like this:

nano docker-compose.yml

Add the following configuration:

services:
  traefik:
    image: traefik:v3.7
    container_name: traefik
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt
    restart: unless-stopped

  db:
    image: postgres:15
    container_name: odoo-db
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    restart: unless-stopped

  odoo:
    image: odoo:19.0
    container_name: odoo
    depends_on:
      - db
    environment:
      HOST: ${ODOO_DB_HOST}
      PORT: ${ODOO_DB_PORT}
      USER: ${ODOO_DB_USER}
      PASSWORD: ${ODOO_DB_PASSWORD}
    command:
      - "--admin-passwd=${ODOO_ADMIN_PASSWORD}"
    volumes:
      - ./odoo-data:/var/lib/odoo
      - ./addons:/mnt/extra-addons
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.odoo.rule=Host(`${DOMAIN}`)"
      - "traefik.http.routers.odoo.entrypoints=websecure"
      - "traefik.http.routers.odoo.tls=true"
      - "traefik.http.routers.odoo.tls.certresolver=letsencrypt"
      - "traefik.http.services.odoo.loadbalancer.server.port=8069"
    restart: unless-stopped

Start the services in detached mode:

docker compose up -d

Verify that all services are running:

docker compose ps

Check the Odoo logs:

docker compose logs odoo --tail=50

Configure PostgreSQL

Check the privileges of the odoo PostgreSQL role:

docker exec -it odoo-db psql -U odoo -d postgres -c "\du"

Confirm that the odoo role has the Create DB attribute.

If the attribute is missing, grant it using the PostgreSQL administrator account.

docker exec -it odoo-db psql -U postgres -d postgres -c "ALTER ROLE odoo CREATEDB;"

Verify the privilege again:

docker exec -it odoo-db psql -U odoo -d postgres -c "\du"

Access and Configure Odoo

Open https://odoo.example.com in your browser, replacing the domain with your own.

Then click Create Database.

Enter the master password from ODOO_ADMIN_PASSWORD in your .env file. Enter a database name, such as odoo. And enter the administrator email and password.

Select your language and country and click Create Database. Odoo creates the database and opens the dashboard. Log in with your administrator credentials.

Managed Odoo Hosting

Managed Odoo hosting is a deployment model where a hosting provider manages the underlying infrastructure and routine maintenance tasks. Instead of provisioning and maintaining servers yourself, you rely on the provider to manage the hosting environment, allowing your team to focus on using Odoo for day-to-day business operations.

Managed Odoo hosting is available through Odoo itself using Odoo.sh, as well as through third-party providers such as CloudPepper and RoseHosting. The level of server access, customization, maintenance, and infrastructure management varies between providers, so it's important to review what each provider includes before choosing a service.

Benefits of Managed Hosting

Managed hosting simplifies Odoo deployment by reducing the effort required to maintain the underlying infrastructure. Depending on the provider and plan, common benefits may include:

• Faster deployment without extensive server setup.

• Assistance with software updates and security maintenance.

• Automated backups and disaster recovery options.

• Infrastructure monitoring and performance management.

• Technical support for infrastructure-related issues.

• Easier scaling as business requirements grow.

Limitations of Managed Hosting

While managed hosting offers convenience, it also comes with certain trade-offs. Organizations should consider the following:

• Limited control over the underlying server environment.

• Fewer customization options compared to self-hosting, depending on the provider.

• Provider-specific restrictions on server access or configurations.

• Recurring hosting or subscription costs.

• Dependence on the provider for certain maintenance and infrastructure tasks.

Who Should Choose Managed Odoo Hosting?

Managed Odoo hosting can be a good choice for:

• Small and medium-sized businesses.

• Organizations without dedicated IT or DevOps teams.

• Teams that want to reduce the effort of managing infrastructure.

• Businesses looking for a faster and simpler deployment.

• Organizations that prefer a low-maintenance hosting solution.

Self-Hosted vs Managed Hosting

Both self-hosted and managed hosting allow you to deploy and run Odoo. The right choice depends on your organization's technical expertise, operational requirements, customization needs, and budget. The following table compares the key differences between the two hosting models.

Self-hosting is a good choice for organizations that need greater control and customization, while managed hosting is better suited for teams that want to reduce the effort of managing infrastructure and focus on business operations. The right option depends on your technical expertise, operational requirements, customization needs, and long-term business goals.

How to Choose the Right Option

Choosing between self-hosted and managed Odoo hosting depends on your organization's technical expertise, business requirements, budget, and how much time your team can dedicate to managing infrastructure.

Choose Self-Hosted Odoo If

Self-hosting may be a better fit if you:

• Have an in-house IT or DevOps team with Linux and cloud administration experience.

• Need full control over the server environment.

• Require extensive customization or third-party integrations.

• Have specific security, compliance, or performance requirements.

• Are prepared to manage updates, backups, monitoring, and troubleshooting.

Choose Managed Odoo Hosting If

Managed hosting may be a better fit if you:

• Want to deploy Odoo without managing the underlying infrastructure.

• Don't have dedicated IT or DevOps resources.

• Prefer a provider to handle routine maintenance and infrastructure management.

• Want to reduce the operational work involved in maintaining servers.

• Prefer a low-maintenance solution that allows your team to focus on business operations.

The right hosting model depends on how much control your organization needs and how much infrastructure management it is prepared to handle. Consider your technical skills, customization requirements, budget, and long-term business needs before making a decision.

Key Factors to Consider Before Choosing

Choosing the right hosting option involves more than comparing features or costs. Consider the following factors before deciding how to host Odoo.

• Budget: Consider both the initial and ongoing costs. Self-hosting requires infrastructure and maintenance, while managed hosting usually involves recurring hosting fees in exchange for less infrastructure work.

• Technical Expertise: Consider whether your team has the skills to install, maintain, secure, and troubleshoot Odoo. If you don't have dedicated IT or DevOps resources, managed hosting may be easier to maintain.

• Customization: If you need custom modules, third-party integrations, or specific server configurations, check whether your hosting option supports them. Self-hosting generally provides more control over customization.

• Security and Compliance: Consider your security policies, data protection requirements, and any industry regulations that apply to your organization. Also determine which security responsibilities belong to your team and which are handled by the hosting provider.

• Scalability: Consider how your Odoo deployment may grow over time. Your hosting environment should be able to support increases in users, data, and workloads.

• Maintenance and Support: Decide whether your team is prepared to manage updates, backups, monitoring, and troubleshooting or whether you would prefer a provider to handle these responsibilities.

Consider these factors together rather than focusing on a single one. The right hosting solution should match your organization's technical skills, business requirements, budget, and long-term plans.

Conclusion

Choosing the right hosting model is an important part of planning a successful Odoo deployment. Self-hosting offers greater control, flexibility, and customization, while managed hosting reduces the effort required to maintain the infrastructure.

Each approach has its own advantages, and the best choice depends on your organization's technical expertise, business requirements, and long-term goals.

Before making a decision, evaluate factors such as your budget, customization needs, security requirements, scalability, and the resources available to manage the deployment. By selecting the hosting model that aligns with your priorities, you can build a reliable and maintainable foundation for running Odoo.

If you'd like to read more hands-on deployment tutorials and technical documentation, visit my portfolio at docs.abdultalha.dev. You can also connect with me on LinkedIn to follow my latest articles and open-source work.

For years, that list of constraints was the reason people dismissed it. But in 2026, it's the reason Chrome OS might be the most correctly designed operating system for what's coming.

The security architecture treats the endpoint as untrusted by default. The containerized Linux environment gives developers a full headless stack without compromising the host. And an upcoming OS-level rewrite, Aluminium, puts Google's on-device AI models directly into the kernel.

This article covers security architecture, the container-based developer environment, cloud-streamed creative tools via AWS NICE DCV, cloud gaming, and what Aluminium OS means for on-device AI.

Here's what we'll cover:

1. Security-First Architecture in an Era of AI-Powered Threats

2. A Headless Linux Stack That's More Flexible Than It Looks

3. AWS NICE DCV Changes the Creative Tools Conversation

4. Cloud Gaming Works

5. Aluminium OS: On-Device Models on Google's Own Architecture

6. Where This Lands

Security-First Architecture in an Era of AI-Powered Threats

Threat actors are getting better tools. Models like Mythos are lowering the barrier for generating convincing phishing campaigns, crafting polymorphic malware, and automating social engineering at scale.

Traditional operating systems present exactly the attack surface these tools target: writable system files, user-installable executables, patches that sit uninstalled for weeks because someone clicked "remind me later."

Chrome OS sidesteps most of this by design. The root filesystem is read-only and cryptographically verified on every boot through a process called Verified Boot.

If anything has modified the OS files since the last verified state, whether that's malware, a compromised package, or a rogue AI agent that decided to start deleting system files, the device detects it at startup and either self-corrects or refuses to boot.

Persistence across reboots isn't difficult. It's architecturally impossible through software alone.

Updates happen silently. While you're working, the system downloads the next OS version to an inactive partition. On your next reboot, it pivots to the updated version. No prompts, no deferred patches, no exposure window.

Major updates ship every four to six weeks. Security patches land every two to three weeks. The gap between vulnerability discovery and remediation is measured in days.

Chrome OS consistently doesn't appear in the top 50 products by CVE count in the NIST vulnerability database. Windows and the Linux kernel sit near the top every year. When AI is actively being weaponized to find and exploit vulnerabilities faster than humans can patch them, a read-only, verified, automatically updated endpoint is a different category of security posture.

The tradeoff is trust. Chrome OS's security model means trusting Google as the root authority for your entire computing stack: updates, certificate trust, telemetry. Organizations with strict data sovereignty requirements should weigh that dependency carefully.

A Headless Linux Stack That's More Flexible Than It Looks

Chrome OS is a text-based operating system. There's no native GUI layer. Stop and sit with that for a second, because it's the thing that makes people dismiss Chrome OS and also the thing that makes it work.

The entire graphical interface you interact with IS the Chrome browser. The Ash shell, Chrome's window manager, is the desktop. You don't install applications onto it the way you install .exe files on Windows or drag .app bundles into a macOS Applications folder. If it isn't running in a browser tab, an Android VM, or a Linux container, it doesn't run. That restriction is what keeps the host locked down, and it's what makes everything else possible.

Under the hood, Chrome OS runs a minimal virtual machine called Termina through crosvm, Google's Rust-based VM monitor.

Inside Termina, LXD manages Linux containers. The default container, penguin, is a Debian environment with a special trick: it bridges GUI-based Linux applications directly into the Chrome OS desktop through a Wayland proxy called Sommelier. Install VS Code, GIMP, or LibreOffice in penguin and they show up in your Chrome OS app launcher, running in windows alongside your browser tabs. For a lot of developers, penguin alone covers the daily workflow.

But Termina gives you more than penguin. Through the LXD layer you can spin up independent containers that are fully isolated operating systems: Arch, Alpine, Ubuntu, whatever you need.

These aren't attached to the GUI bridge. They run headless, natively, with their own systemd, their own package managers, their own persistent state. Need a clean Ubuntu environment to test a deployment script without touching your main setup? lxc launch and you're there. Need to blow it away? lxc delete and it's gone. No orphaned files on the host, no cross-contamination between environments.

The key distinction from Docker is that LXD runs system containers (full OS emulation) rather than application containers. You get background services, persistent daemons, the works. You can also run Docker inside any of these LXD containers if you need application-level containerization on top of that.

Snapshot your entire environment with lxc snapshot before a risky dependency install and roll back instantly if something breaks. That kind of safety net is broader than version control alone: it captures your full OS configuration, not just code.

Pair this with browser-native tools like GitHub Codespaces, Google Colab, AWS CloudShell, or vscode.dev, and the terminal handles your local tooling while the browser handles everything else.

AI coding assistants like Claude and Gemini already operate natively in the browser. The distance between "cloud IDE" and "local IDE" keeps shrinking.

There are friction points: no custom kernel modules inside Crostini. Nested KVM requires Intel Gen 10+ processors. VPN routing into the Linux container from the Chrome OS host can be a headache, with WireGuard requiring userspace workarounds inside the container.

But none of these break the core architecture for cloud-native work. They're just worth knowing about before you commit.

AWS NICE DCV Changes the Creative Tools Conversation

One of the longest-standing arguments against Chrome OS has been the absence of professional creative software. There's no Premiere, no DaVinci Resolve, no Blender, no Ableton. For years, this was a dead-end conversation.

AWS NICE DCV (Desktop Cloud Visualization) reopens it. DCV is a high-performance remote display protocol that streams GPU-accelerated desktop sessions from EC2 instances to any device, including a Chromebook running the browser-based DCV client. It supports OpenGL, Vulkan, and DirectX rendering, with adaptive encoding that adjusts to network conditions. On AWS, the DCV license is free. You pay only for the EC2 compute time.

Netflix engineers use DCV to stream content creation applications to remote artists. Volkswagen runs 3D CAD simulations across their engineering division through it. A VFX studio called RVX used it to deliver visual effects for HBO's The Last of Us, streaming Nuke, Maya, Houdini, and Blender to artists distributed across Europe from servers in Iceland. Their team said it was the best remote experience they'd ever worked with.

So: a Chromebook connected to a g5.xlarge EC2 instance (one A10G GPU) can run Blender, DaVinci Resolve, or any other GPU-accelerated creative application with full hardware acceleration. The rendering happens in the data center. DCV streams the pixels. The creative professional gets a responsive, high-fidelity workspace on a $400 machine that couldn't locally render a single frame.

The constraints are connectivity and cost. You need sustained bandwidth (25+ Mbps for 1080p work, more for 4K multi-monitor setups) and leaving a GPU instance running around the clock adds up. But for studios and professionals who already budget for high-end workstations, the math often pencils out, especially when you factor in zero local hardware maintenance and the ability to scale GPU power on demand.

Cloud Gaming Works

GeForce NOW survived where Stadia failed because it made a better business decision: bring your own games. Connect your existing Steam, Epic, or Ubisoft library and stream from NVIDIA's server-side hardware. The Ultimate tier now runs on RTX 5080-class infrastructure. 4K at 120fps with ray tracing, on a fanless Chromebook.

Chrome OS has a structural advantage as a cloud gaming client. GeForce NOW runs natively in the Chromium browser via WebRTC, and users consistently report less micro-stuttering and tighter input handling than the standalone Windows desktop app. Under good network conditions, measured total latency runs 13 to 14ms, with sub-3ms ping documented near datacenter proximity. That's below human perceptual threshold for most game types.

Anti-cheat systems like Easy Anti-Cheat and Riot Vanguard are a non-issue in this model. They run on the server where the game executes, not on your local endpoint. On-device gaming isn't viable on Chrome OS and likely never will be. The architecture isn't designed for it, and even projects attempting to bridge local GPUs hit bottlenecks in the container layers. Cloud gaming is the path, and it works.

The limiting factors are network-dependent. Latency spikes above 500ms on bad connections make fast-twitch games unplayable, and NVIDIA's 100-hour monthly cap on the Ultimate tier has drawn criticism. But cloud gaming on Chrome OS has crossed the line from novelty to daily-driver viable for most use cases.

Aluminium OS: On-Device Models on Google's Own Architecture

The most consequential near-term development for Chrome OS is Project Aluminium, a ground-up rewrite that replaces the current Chrome OS foundation with a native Android kernel. Not another bolted-on compatibility layer: a new operating system built on Android 16, designed to run Android applications natively with direct hardware acceleration instead of routing them through the resource-heavy ARCVM virtual machine that currently eats CPU cycles on even basic app launches.

The AI story is the real story. Aluminium is being built with Gemini models integrated directly into the OS: the file system, the application launcher, the window manager.

Google serving their own proprietary models on their own devices, using an architecture optimized specifically to run them, is a level of vertical integration that no other OS vendor has in the pipeline. Apple has the silicon advantage for local inference. Google has the model-to-OS integration advantage. Those are competing theses about where AI compute should live, and both are worth taking seriously.

The rollout timeline from court documents and leaked roadmaps puts a trusted tester program on select hardware in late 2026, premium tablets by early 2027, and general consumer availability in 2028. Chrome OS Classic gets maintained through existing support obligations until 2033 or 2034.

The launch won't be perfect. Google's track record on platform transitions gives the community earned skepticism. But the ability to iterate a natively AI-integrated OS on hardware they control is the kind of capability that compounds over time.

Where This Lands

Two years ago, calling Chrome OS a serious platform for development or creative work would have been a stretch. Today you can run a full Debian environment with systemd daemons, snapshot your workspace, stream Blender from a GPU-backed data center, play AAA games at 4K on hardware you don't own, and do all of it from a verified, read-only endpoint that patches itself while you sleep.

The remaining gaps are real. But they're concentrated in workflows that are themselves moving to the cloud. Chrome OS was designed around assumptions about computing that used to be premature. They're not premature anymore.

Most people think Jupyter is just for Python and data science stuff, but apparently you can run Rust in one, too.

In this tutorial, we’ll be taking a look at:

1. What is EvCxR?

2. How to Install the Rust Jupyter kernel

3. How to run your first Rust code in a notebook

4. Handy Tips and Tricks

5. Common Issues and Solutions

6. When NOT to Use Jupyter for Rust

Friendly Disclaimer: This tutorial assumes you know the basics of both Rust and Jupyter. If you break something, that's on you, mate 🙂.

So without further ado, let's jump in.

What is EvCxR?

EvCxR (pronounced "Evaluator" to my fellow linguists’ horror) is a Rust REPL and Jupyter kernel. It's basically the magic that lets you run Rust code interactively in Jupyter notebooks instead of the traditional compile-run-debug cycle.

The name stands for "Evaluation Context for Rust", and it’s an open source project actively maintained on GitHub. Here are a few things that make this terribly named tool absolutely brilliant:

1. Interactive development: It lets you test Rust snippets without creating a whole project 🧪

2. Prototyping: You can quickly try out ideas before committing to a full implementation 💡

3. Data visualisation: And yes, you can even plot charts with Rust (more on that later) 📊

How to Install the Rust Jupyter kernel

Prerequisites

Before we dive into the installation, make sure you have these sorted:

1. A Linux System: Or at least, Windows Subsystem for Linux (There’s a little note below for Windows users.)

2. The Rust toolchain: You can get it from rustup.rs if you haven't already

3. Jupyter: Install via pip – pip install jupyter

4. Patience: This might take a minute or two ⏱️

Once you’ve got all that, we can get rusty (pun intended).

Note: If you’re using Windows, you’ll need to do a little extra to get started. Here’s the quick rundown:

1. Go to https://visualstudio.microsoft.com/visual-cpp-build-tools/

2. Download and run the installer

3. Select "Desktop development with C++"

4. Install it (it's large, ~5GB)

Step 1: Install EvCxR

Open your terminal and run this command:

cargo install evcxr_jupyter

Now go grab a cup of joe ☕. This will take a few minutes as Cargo downloads and compiles everything. And don't panic if it seems stuck. Rust compilation is thorough but not particularly fast.

If you get any errors about missing system libraries, you might need to install some dependencies. On Ubuntu/Debian, try:

sudo apt install jupyter-notebook jupyter-core python-ipykernel
sudo apt install cmake

On macOS with Homebrew:

brew install cmake jupyter

Step 2: Install the Jupyter Kernel

Once the installation finishes, you’ll need to register the EvCxR kernel with Jupyter:

evcxr_jupyter --install

You should see output that looks something like this at the end:

Installation complete

Step 3: Launch Jupyter and Create a Rust Notebook

Let’s test out our baby. Fire up Jupyter:

jupyter notebook

Your browser should open automatically (if it doesn't, copy the URL from the terminal).

In the Jupyter interface:

1. Click New in the top right

2. Select Rust from the dropdown (or "evcxr" depending on your version)

3. A new notebook opens

Welcome to interactive Rust! 🦀

Step 4: Write Your First Rust Code

Let's start with a classic:

println!("Hello my fellow Rustaceans! 🦀");

Hit Shift + Enter to run the cell. You should see the output appear below the cell. Simple as that.

Note that notebooks execute code at the top level, so you don’t have to wrap it around the main() function. If you still want to do that, you’re going to have to call it like this:

fn main(){
    println!("Hello my fellow Rustaceans! 🦀");
}
//Calling the function
main()

Now let's try something more interesting:

fn fibonacci(n: u32) -> u32 {
    match n {
        0 => 0,
        1 => 1,
        _ => fibonacci(n - 1) + fibonacci(n - 2)
    }
}

for i in 0..10 {
    println!("fibonacci({}) = {}", i, fibonacci(i));
}

Run it and watch the Fibonacci sequence appear.

fibonacci(0) = 0
fibonacci(1) = 1
fibonacci(2) = 1
fibonacci(3) = 2
fibonacci(4) = 3
fibonacci(5) = 5
fibonacci(6) = 8
fibonacci(7) = 13
fibonacci(8) = 21
fibonacci(9) = 34

Handy Tips and Tricks

Functions aren’t the only things that behave differently when using Rust in notebooks. Here are a few other things you might want to keep in mind:

Variables Persist Between Cells

Unlike traditional Rust compilation, variables you define in one cell stick around for the next cells:

let mut counter = 0;

Then in the next cell:

counter += 1;
println!("Counter: {}", counter);

The output would be:

Counter: 1

This is great for building up complex examples step by step.

You Can Use External Crates

Add dependencies with the :dep command in one cell:

:dep serde = { version = "1.0", features = ["derive"] }
:dep serde_json = "1.0"

Then use them normally in the next:

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize, Debug)]
struct Person {
    name: String,
    age: u32,
}

let person = Person {
    name: "Amina".to_string(),
    age: 24,
};

let json = serde_json::to_string(&person).unwrap();
println!("{}", json);

Output:

{"name":"Amina","age":24}

Pretty neat, huh?

Visualisation Support

You can even create graphs. To get started, install the plotters crate:

:dep plotters = { version = "0.3", default-features = false, features = ["evcxr", "all_series", "bitmap_backend", "bitmap_encoder"] }

Then create a simple sine graph:

use plotters::prelude::*;

let root = SVGBackend::new("sine_wave.svg", (640, 480)).into_drawing_area();
root.fill(&WHITE).unwrap();

let mut chart = ChartBuilder::on(&root)
    .caption("Sine Wave", ("Arial", 20))
    .margin(5)
    .x_label_area_size(30)
    .y_label_area_size(30)
    .build_cartesian_2d(-3.14..3.14, -1.2..1.2)
    .unwrap();

chart.configure_mesh().draw().unwrap();

chart.draw_series(LineSeries::new(
    (-314..314).map(|x| {
        let x = x as f64 / 100.0;
        (x, x.sin())
    }),
    &RED,
)).unwrap();

root.present().unwrap();
println!("Plot saved to sine_wave.svg");

Output:

A word on plotting: You can actually display plots directly inline in your notebook. But if you're using WSL with VSCode (like I do), inline plotting may not work properly due to rendering issues on the notebook interface. That’s why I used it as an svg file that I can easily view in my text editor.

Checking Types

Not sure what type something is? Use :vars. This shows all variables and their types:

let x = vec![1, 2, 3];

:vars

Output:

Variable	    Type
       x	Vec<i32>

Common Issues and Solutions

Compilation Errors Everywhere

If you're getting weird compilation errors, remember:

• Each cell is compiled separately

• You might need to reimport things in each cell

Slow Execution

The first time you run code in a session, it's slow due to the compilation overhead. Subsequent runs are faster. If it's really slow, you might want to:

• Use release mode: :opt 2

• Reduce dependency features to only what you need

• Consider if Jupyter is the right tool for your use case

Dependencies Not Loading

If a crate won't load:

• Make sure the version exists on crates.io

• Check your internet connection (it needs to download)

• Try specifying features explicitly

• Clear the cargo cache if things get really wonky: rm -rf ~/.evcxr

When NOT to Use Jupyter for Rust

Jupyter notebooks are great for learning and experimenting, but they're not always the best choice in:

• Production code: Use proper projects with cargo

• Performance-critical code: The overhead isn't worth it

• Large applications: Notebooks get very messy, very fast

• Team collaboration: Version control with notebooks is quite the nightmare

Stick to notebooks for prototyping and quick experiments. For anything serious, fire up your favourite editor and create a proper Rust project.

Conclusion

Let's summarise what you've learned:

1. How to install the EvCxR Jupyter kernel

2. How to create and run Rust notebooks

3. How to use external crates in notebooks

4. Tips and tricks for interactive Rust development

Jupyter notebooks make Rust more accessible for learning and experimentation. Give it a go next time you want to try out a quick Rust snippet without the ceremony of creating a full project. And with that, we've come to the end of this tutorial.

Cheers.

Resources

1. EvCxR GitHub Repository

2. Rust Book

3. Jupyter Documentation

Acknowledgements

Thanks to Anuoluwapo Victor, Chinaza Nwukwa, Holumidey Mercy, Favour Ojo, Georgina Awani, and my family for the inspiration, support and knowledge used to put this post together.

And thanks to the EvCxR project maintainers for making this possible, the Rust community for being awesome, and to anyone reading this for wanting to learn. You inspire me daily.

The Nix language is a specialized, purely functional programming language. It’s used by the Nix package manager to build packages and the NixOS operating system for declarative system configuration and software packaging.

Unlike traditional Linux distributions, NixOS utilizes the Nix programming language to describe the entire system, including packages, services, users, networking, and even the bootloader – all of which are defined through a declarative configuration. This approach enables NixOS to generate complete system profiles, allowing for reproducible deployments, atomic upgrades, and easier system rollbacks.

In simpler terms, in NixOS, you can configure your programs, services, and users, and install new system-wide packages or applications directly within the configuration.nix file – which you can then share directly with others.

Also, if anything goes wrong with your current NixOS generation during the system build time, you can roll back to a previous NixOS generation (after switching to a new generation – more on this below).

In this tutorial, I’ll explain in detail what NixOS is, how it works, its benefits, and how to set it up on your machine or laptop in a beginner-friendly way.

Table of Contents:

1. Prerequisites

2. What is a Declarative Configuration?

   • Why is the Declarative Approach (Declarative Configuration) used in NixOS?

   • What Are Reproducible Systems?

3. How Does NixOS Work?

4. What Are the Benefits of Using NixOS?

5. When Would NixOS Not Be the Best Choice?

6. How to Set Up NixOS and the Nix Package Manager on Your Laptop

7. How to Install a Package in NixOS?

8. FAQ

9. Conclusion

Prerequisites

To work with NixOS and the Nix package manager, there are no specific prerequisites if you have at least a couple years of experience with Ubuntu, Debian, or any other distribution. Having some basic knowledge of the Nix language is a plus.

What is a Declarative Configuration?

In the declarative approach, we use a file (such as a YAML, JSON, or Nix) to describe the configuration for hardware and software components, such as systems, networking, users, boot loader, services (like with systems), and more, in one file.

NixOS uses the configuration.nix file for its declarative configuration. By default, the configuration.nix file looks like this:

# /etc/nixos/configuration.nix

{ config, pkgs, ... }:
{

  imports = [
      ./hardware-configuration.nix
   ];

  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  networking.hostName = "nixos"; # Define your hostname.

  # Enable networking
  networking.networkmanager.enable = true;

  # Set your time zone.
  time.timeZone = "Asia/Kolkata";

  # Select internationalisation properties.
  i18n.defaultLocale = "en_IN";

  i18n.extraLocaleSettings = {
    LC_ADDRESS = "en_IN";
    LC_IDENTIFICATION = "en_IN";
    LC_MEASUREMENT = "en_IN";
    LC_MONETARY = "en_IN";
    LC_NAME = "en_IN";
    LC_NUMERIC = "en_IN";
    LC_PAPER = "en_IN";
    LC_TELEPHONE = "en_IN";
    LC_TIME = "en_IN";
  };

  # Enable the X11 windowing system.
  services.xserver.enable = true;

  # Enable the GNOME Desktop Environment.
  services.xserver.displayManager.gdm.enable = true;
  services.xserver.desktopManager.gnome.enable = true;

  # remove preinstall or  unused package in gnome
  environment.gnome.excludePackages = with pkgs; [ gnome-tour gnome.gnome-music nixos-render-docs  ];
  services.xserver.excludePackages = with  pkgs; [ xterm ];

  # Configure keymap in X11
  services.xserver.xkb = {
    layout = "us";
    variant = "";
  };

  # Enable sound with pipewire.
  sound.enable = true;
  hardware.pulseaudio.enable = false;
  security.rtkit.enable = true;
  services.pipewire = {
    enable = true;
    alsa.enable = true;
    alsa.support32Bit = true;
    pulse.enable = true;
  };

  # Define a user account. Don't forget to set a password with ‘passwd’.
  users.users.officialrajdeepsingh = {
    isNormalUser = true;
    description = "officialrajdeepsingh";
    extraGroups = [ "networkmanager" "wheel" "docker" ];
    packages = with pkgs; [
      google-chrome
    ];
  };

  # Enable automatic login for the user.
  services.xserver.displayManager.autoLogin.enable = true;
  services.xserver.displayManager.autoLogin.user = "officialrajdeepsingh";

  # Workaround for GNOME autologin: https://github.com/NixOS/nixpkgs/issues/103746#issuecomment-945091229
  systemd.services."getty@tty1".enable = false;
  systemd.services."autovt@tty1".enable = false;


  services.openssh = {
      enable = true;
      settings = {
        PasswordAuthentication = true;
      };
  };
  system.stateVersion = "23.05"; # Did you read the comment?
}

You can edit the configuration.nix file to easily enable NGINX and Git using NixOS options. NixOS options let you choose whether to turn features on or off and configure how they should work.

# /etc/nixos/configuration.nix

services.nginx.enable = true;
programs.git.enable = true;

....

Every time you modify the configuration.nix file to apply changes to NixOS, you’ll need to build your NixOS using the following command:

sudo nixos-rebuild switch

The nixos-rebuild command generates a new NixOS generation based on your configuration file. This generation is a complete, immutable snapshot of your system's configuration (packages, services, settings) that’s created every time you run that nixos-rebuild command.

The switch flag helps to build and activate the new generation at the same time, and make it the default boot in NixOS.

After a system update, if the new generation isn’t desirable, you can roll back or switch to a previous generation using the nixos-rebuild switch --rollback command. For example, if I’m currently on generation 22, which is the default boot, and I don't like this generation, I can use the rollback flag to switch back to generation 21 in NixOS.

The NixOS rollback feature helps you test new functions and features to see if they work properly when you install new applications or programs on NixOS.

Why is the Declarative Approach (Declarative Configuration) used in NixOS?

The Declarative Approach is particularly useful because it allows you to share your NixOS configuration file with other developers using GitHub and GitLab. By using the configuration.nix file, other developers can build the same system or machine (making it reproducible).

This approach also helps you manage configurations because all your settings are in one place, making it easy to adjust them at any time.

What Are Reproducible Systems?

This concept of reproducibility is important. In NixOS, we can achieve reproducibility using the configuration.nix file. For example, when two developers use the same NixOS configuration file on their machines, they can achieve highly reproducible and consistent system setups.

This is one feature that makes NixOS so useful for developers, teams, CI/CD, servers, and DevOps. With NixOS, you can avoid the common issue of "it doesn't work on my machine."

How Does NixOS Work?

NixOS works differently compared to traditional Linux distributions. In traditional Linux distros, such as Ubuntu and Debian, you can use the apt command to install a new application or program in your distro, like this:

sudo apt install git # Install git package

sudo apt install nodejs # Install node.js package

sudo apt install npm  # Install NPM package

But as we discussed above, NixOS uses a declarative configuration approach that’s immutable, reproducible, and portable.

This means that you can’t install any packages or programs like Git, Chrome, Firefox, Node, Deno, Bun, and so on using the apt, dkpg, or pacman commands (as NixOS uses its own package manager, Nix).

Instead, you edit the configuration.nix file and mention your package and program, such as Node.js, NGINX, or Git in the file and rebuild your NixOS using the nixos-rebuild command.

# /etc/nixos/configuration.nix

services.nginx.enable = true;
programs.git.enable = true;

environment.systemPackages = [
  pkgs.nodejs_24
];

Again, this creates a new generation every time you modify the NixOS configuration and run the nixos-rebuild command in your system.

To understand in more detail how NixOS works, check out this more in-depth tutorial.

What Are the Benefits of Using NixOS?

There are many benefits to using NixOS over a traditional distro, some of which I’ve already mentioned. Let’s summarize them here:

1. Declarative configuration: All settings for your system, including programs, applications, and services, are written in a single configuration file rather than being installed manually.

2. Instant rollbacks: There's no need to worry about breaking your system. If something goes wrong during an update, you can easily revert to the previous version.

3. Safe updates: Updates either complete successfully or don’t apply at all, ensuring your system never ends up in a half-broken state.

4. Reproducible systems: With the same configuration, you can recreate the same system every time, eliminating issues like "it doesn’t work on my machine."

5. No dependency conflicts: Multiple versions of applications can coexist without issues, allowing different programs such as Node.js and Python to operate together seamlessly.

6. Extensive package ecosystem: The Nix Packages collection comprises thousands of up-to-date packages maintained by the NixOS community.

7. Setting up a new machine: Copy your configuration file, rebuild the system, and complete the setup in just a few minutes, whether for a laptop or a server.

8. Immutable system: The design of an immutable system keeps core system paths unchanged. This prevents accidental alterations and enhances reliability, as core components become read-only and cannot be modified after the initial build.

When Would NixOS Not Be the Best Choice?

There are various situations where NixOS may not be the best choice for you. Here are some of the main issues:

1. NixOS has a steep learning curve, particularly for beginner and intermediate developers.

2. It doesn’t offer a simple one-click installation solution for applications and programs on your machine or laptop.

3. You can’t install system-wide applications or programs without editing the NixOS configuration files and rebuilding the system.

4. NixOS lacks a larger community and readily available tutorials compared to Ubuntu, and its documentation is not very beginner-friendly – so you may need to rely on your own resources.

How to Set Up NixOS and the Nix Package Manager on Your Laptop

Now we’re ready to dive in and set up NixOS. But what you need to install depends on your operating system:

• On macOS or Windows, you’ll install Nix, the package manager. This lets you use Nix to install and manage software on your existing operating system. You don’t install NixOS itself on macOS or Windows.

• On Linux, installing NixOS means installing a new OS (it’s like installing Ubuntu or Debian).

Because NixOS is a full operating system, you’ll need to install it on a fresh machine or partition, which will typically erase existing data during installation unless you set up dual-booting.

And remember, while NixOS is a Linux distribution, it works differently (than Ubuntu or Debian, for example) because the entire system is configured declaratively using Nix.

Install Nix Package Manager

The following command helps you to install the Nix language and the Nix Package Manager on macOS and Windows (via WSL).

# Windows: Multi-user installation (recommended)
sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install) --daemon

# Windows: Single-user installation
sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install) --no-daemon

# MacOS:
sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install)

If you’re a newcomer, before running the command I recommend watching this tutorial on YouTube and checking out the official documentation.

Install NixOS

You can install the NixOS distro with a Linux command. Before proceeding, make sure you meet the following requirements:

• A USB drive (8 GB or more)

• A second computer (to create the USB)

• A backup of your data (installation can erase the disk)

• An internet connection (Wi-Fi or Ethernet)

There are multiple steps for installing NixOS on your machine or laptop. You can check out the following tutorial, which describes in detail how you can install NixOS on your machine very easily.

How to Install a Package in NixOS

NixOS has a large registry of active packages, with 120,000 packages available. Every package you install from the stable channel is built reproducibly and reviewed by the Nix community, so you shouldn’t encounter any issues.

Installing a new package on NixOS using the Nix Package Manager is quite simple. First, visit the NixOS Packages Search site.

Then just search for the package that you’re looking for. In our case, we’ll search for Neovim – and then just type the package name in the search input and hit enter.

Copy the resulting code it shows, and paste it into your configuration.nix file:

# /etc/nixos/configuration.nix

environment.systemPackages = [
  pkgs.neovim # add inside file.
];

Then rebuild your NixOS using the sudo nixos-rebuild switch command. Remember that you’ll need to do this whenever you make changes to the configuration.nix file.

Demo (How to Install Neovim in NixOS)

FAQ

Is NixOS only for advanced users?

No, NixOS can be a great fit for anyone. Due to its steeper learning curve, beginners may struggle at first – but once you understand it, I bet you’ll love it.

Why is the Nix language so weird?

Nix is purely functional and is designed for reproducible builds. It’s not a general-purpose language and is rather a configuration language. You’ll only need 10–15% of the language for daily use.

How is NixOS different from Ubuntu / Arch?

Let’s compare some important NixOS features with other distros:

Can I use NixOS for development?

Yes, NixOS is an excellent distro for:

• Frontend development (Node, Bun, Deno)

• Backend development (Go, Rust, Python)

• Consistent development environments across machines

• CI/CD reproducibility

Is NixOS good for daily use?

Yes – NixOS has an initial learning phase that can be difficult, but once you get past it, you can use NixOS on your work laptops, servers, home PCs, and development machines.

Should I learn NixOS as a beginner developer?

To be honest, if you want quick results, NixOS may not be for you. But if you're aiming for long-term mastery, you will definitely like NixOS.

Does NixOS work on macOS and Windows?

Yes, you can use Nix and the Nix Package Manager on macOS and Windows, and they work well. You can install and package software using the Nix configuration file as mentioned in this tutorial.

Conclusion

I think that NixOS is the best Linux distro – but it’s not super beginner-friendly. Still, I prefer it because it’s a powerful and reliable distro that’s designed for users who value control, reproducibility, and safety.

Managing the entire system through declarative configuration enables consistent setups, safe upgrades, and easy rollbacks. This makes it especially suitable for developers, DevOps engineers, and infrastructure-focused teams.

Just keep in mind that NixOS is not for everyone. Its learning curve and configuration-driven workflow can be steep for beginners, casual users, or those who want quick, click-and-install convenience. So check it out and decide if it’s right for you and your team.

To Learn more beginner tutorials on NixOS, check out the NixOS publication on Medium.

• What is Declarative Configuration in NixOS? Understanding Declarative vs Imperative Approaches

• Understand the difference between Home Manager vs Nix Flake in NixOS?

• Why did I choose NixOS, and what are the advantages and disadvantages of using NixOS?

The error message failed to authenticate via web browser: Too many requests have been made in the same timeframe. (slow_down) appeared on my terminal, while on the web browser, it indicated that the authentication was successful.

I googled and found some workarounds that I tried, but only one worked like a charm!

After finally solving the tricky authentication issue for GitHub CLI on WSL2, I've put together this guide. It's a complete walkthrough for a solution that works, covering everything from a smooth installation to ongoing management.

Table of Contents

• Prerequisites

• How to Install GitHub CLI on WSL2

• How to Authenticate GitHub CLI on WSL2 with Your GitHub Account

• How to Upgrade GitHub CLI on WSL2

• How to Uninstall GitHub CLI on WSL2

• How to Revoke GitHub CLI Access on GitHub

• Final Words

Prerequisites

Before getting started, ensure that you have these installed on your Windows machine:

• WSL2

• A Linux distro

• Windows PowerShell

• Windows Terminal (optional)

To follow the instructions in this article, you can use Windows PowerShell terminal as an administrator.

Alternatively, if you have Windows Terminal installed, you can use the Linux terminal by clicking the ‘down arrow’ icon at the top and selecting the distro.

How to Install GitHub CLI on WSL2

You can use the installation process described here if you use Ubuntu, Debian, or Raspberry Pi OS (apt) distros. For other distros other than those mentioned here, you can walk through the installation process that's available on the GitHub CLI official docs.

To install GitHub CLI in WSL2:

1. Run this command:

    (type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)) \
        && sudo mkdir -p -m 755 /etc/apt/keyrings \
        && out=$(mktemp) && wget -nv -O$out https://cli.github.com/packages/githubcli-archive-keyring.gpg \
        && cat $out | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \
        && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \
        && sudo mkdir -p -m 755 /etc/apt/sources.list.d \
        && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \
        && sudo apt update \
        && sudo apt install gh -y
   

2. Type your Linux password when you get prompted.

3. Ensure the GitHub CLI is installed by running gh --version command. If the installation is successful, you should see something like this in your terminal:

    gh version 2.76.2 (2025-07-30)
    https://github.com/cli/cli/releases/tag/v2.76.2
   

How to Authenticate GitHub CLI on WSL2 with Your GitHub Account

Before you can use GitHub CLI, you must first authenticate it. You will get an HTTP 401: Bad credentials (https://api.github.com/graphql) error message if you run any GitHub CLI command without authenticating.

To authenticate GitHub CLI with your GitHub account:

1. Run the gh auth login command in your terminal.

2. You will receive several prompts, and you need to choose the methods you prefer. Here’s what I selected in each prompt:

    ? Where do you use GitHub? GitHub.com
    ? What is your preferred protocol for Git operations on this host? HTTPS
    ? How would you like to authenticate GitHub CLI? Login with a web browser
   

   After answering all prompts, you should get the message to copy a one-time code as shown below. You don’t need to copy the code at this point.

    ! First copy your one-time code: XXXX—XXXX
   

3. Press ‘Enter’. It automatically opens the "Device Activation" page on your browser.

4. Click the green ‘Continue’ button.

   

   GitHub should ask you to enter the code displayed on your terminal, as shown in the screenshot below. But here’s the trick! Don’t paste any code, and don’t close the browser. Let’s first get back to your terminal.

   

   Now you might get this error message on your terminal:

    grep: /proc/sys/fs/binfmt_misc/WSLInterop: No such file or directory
    WSL Interopability is disabled. Please enable it before using WSL.
    grep: /proc/sys/fs/binfmt_misc/WSLInterop: No such file or directory
    [error] WSL Interoperability is disabled. Please enable it before using WSL.
   

5. Press Ctrl + C to stop the process if it's still running, or let it stop by itself. Once it's stopped, you should see this message:

    failed to authenticate via web browser: Too many requests have been made in the same timeframe. (slow_down)
   

6. Run the gh auth login command again and repeat the process to select the methods of your choice. This time, when it asks you to press ‘Enter’, don’t press it.

7. Copy the latest code and return to the "Device Activation" page that you left open in your browser.

8. Paste the code that you copied and click the green ‘Continue’ button.

9. Click the green ‘Authorize github’ button after GitHub redirects you to the “Authorize GitHub CLI” page. You should now see the message “Congratulations, you're all set!”

10. Get back to your terminal and press ‘Enter’. Doing so triggers these actions:

    • It automatically opens a new “Device Activation” page in your browser. You can safely ignore this.

    • In the terminal, you first see the error message as in step 4. Don’t do anything and wait for a little bit. Then, you get:

        ✓ Authentication complete.
        - gh config set -h github.com git_protocol https
        ✓ Configured git protocol
        ! Authentication credentials saved in plain text
        ✓ Logged in as YOUR-GITHUB-USERNAME
        ! You were already logged in to this account
      

And GitHub CLI is now successfully authenticated!

Credit goes to username “ikeyan” on GitHub for their GitHub CLI authentication solution!

How to Upgrade GitHub CLI on WSL2

It’s always a good practice to regularly check for package and dependency updates, and upgrade to the newest version when it’s available — this includes GitHub CLI. To check for updates and upgrade the version of GitHub CLI:

1. Run the sudo apt update command in your terminal. This command fetches the list of available updates.

2. Type your Linux password when you get prompted.

3. If you need to upgrade your GitHub CLI, run sudo apt install gh. This command installs the newest version of GitHub CLI.

4. Type your Linux password when you get prompted.

Now your GitHub CLI has the newest version.

How to Uninstall GitHub CLI on WSL2

If one day you feel like you don’t need to use GitHub CLI anymore, you can uninstall it by following these steps:

1. Run the sudo apt remove gh command in your terminal.

2. Type your Linux password when you get prompted.

3. Press ‘Y’ to continue the uninstall process.

GitHub CLI is now uninstalled from your WSL environment.

How to Revoke GitHub CLI Access on GitHub

After uninstalling the GitHub CLI, you might think your account access is gone, but it's not. The authentication you granted is still active. If you don't plan on using the CLI again, it's a good practice to revoke this access.

Here's how to do it directly from your GitHub account:

1. On your GitHub account, click your profile picture on the top right and click ‘Settings’.

   

   2. On the left side bar, find ‘Integrations’ and click ‘Applications’.

      

   3. Click the ‘Authorized OAuth Apps’ tab on top.

      

   4. Find GitHub CLI and click the ‘three dots’ icon next to it.

   5. Click ‘Revoke’.

      

   6. Confirm it by clicking the ‘I understand, revoke access’ button.

Now, GitHub CLI doesn’t have access to your GitHub account.

Final Words

🖼️ Credit cover image: undraw.co

Thank you for reading! Last, you can find me on X and LinkedIn. Let's connect! 😊

You can use RHEL's task scheduling capabilities in scenarios like automating system maintenance (for example, log rotation or backup operations), managing routine administrative tasks (like user account cleanup or security updates), or orchestrating complex workflows in enterprise environments. These scheduling tools are essential for maintaining system health and ensuring that critical operations run without manual intervention.

For system administrators, think of task scheduling as the backbone of automated system management, enabling you to set up processes that run reliably in the background while you focus on more strategic initiatives. Its power lies in its flexibility and reliability, making it an indispensable skill for anyone managing Linux systems in production environments.

In this tutorial, you’ll learn how to schedule tasks in Red Hat Enterprise Linux using various built-in tools and techniques. This content is part of Schedule Future Tasks, which is Chapter 2 of the Red Hat System Administration (RH134) course. RH134 is a fundamental course for the Red Hat Certified System Administrator (RHCSA) certification, one of the most respected credentials in the Linux administration field.

This hands-on tutorial provides practical experience with the scheduling concepts covered in the RH134 curriculum, giving you the skills needed to automate tasks effectively in enterprise RHEL environments.

Here's what we'll cover:

• How to Schedule a One-time Job with 'at'

• How to Manage 'at' jobs

• How to Schedule Recurring User Jobs with 'crontab'

• How to Manage User 'crontab' Entries

• How to Schedule Recurring System Jobs with cron Directories

• How to Configure systemd Timers for Recurring Tasks

• How to Manage Temporary Files with systemd-tmpfiles

Prerequisites

This tutorial is designed to be beginner-friendly! You just need basic familiarity with using the Linux command line. If you can navigate directories and run simple commands, you're ready to start.

For those looking to deepen their RHEL knowledge, the RHEL Skill Tree offers comprehensive hands-on labs including RH124, RH134, RH294, and other courses for RHCSA and RHCE certifications.

Don't worry if you're new to Red Hat Enterprise Linux – I'll explain everything step by step, and these concepts work on most Linux distributions too.

How to Schedule a One-time Job with 'at'

First, let’s learn how to schedule a job to run once at a future time using the at command. The at command is useful for executing commands that don’t need to be run repeatedly. We will schedule a simple job, inspect its details, and then remove it.

In this tutorial, we will work directly on the local system to learn task scheduling. You’ll execute all commands in your current terminal environment.

Let's schedule a job to print the current date and time into a file named ~/myjob.txt in your home directory. We'll schedule it to run 3 minutes from now:

at now + 3 minutes << EOF
date > ~/myjob.txt
EOF

The warning: commands will be executed using /bin/sh message is normal. The job N at ... output indicates the job number and the scheduled execution time. Make a note of the job number, as you will need it later.

Next, let's schedule another job interactively. This method is useful for entering multiple commands or more complex scripts. We will schedule a job to append "Hello from at job!" to ~/at_output.txt 5 minutes from now:

at now + 5 minutes

After typing the command and pressing Enter, you will see an at> prompt. Type your command and then press Ctrl+d to finish:

at > echo "Hello from at job!" >> ~/at_output.txt
at > Ctrl+d

To view the jobs currently in the at queue, use the atq command. This command lists all pending at jobs for the current user.

atq

The output will show the job number, the scheduled time, the queue, and the user who scheduled it.

You can inspect the commands that a specific at job will run using the at -c command followed by the job number. Replace N with one of the job numbers you noted earlier.

at -c N

This command will display the shell script that at will execute for that job. You should see the date > ~/myjob.txt or echo "Hello from at job!" >> ~/at_output.txt command within the output.

Finally, to remove a scheduled at job, use the atrm command followed by the job number. Let's remove the first job we scheduled. Replace N with the job number of your first job.

atrm N

After removing the job, you can use atq again to verify that it is no longer in the queue.

atq

You should now only see the second job (if it hasn't executed yet) or an empty queue if both jobs have been removed or executed.

This completes the first step of scheduling one-time jobs with the at command.

How to Manage 'at' jobs

Now, let’s delve deeper into managing at jobs, including scheduling jobs with different queues and verifying their execution. Understanding at queues can be useful for prioritizing tasks or separating different types of one-time jobs.

We will continue working on the local system to explore more advanced at job management features.

The at command allows you to specify a queue using the -q option. Queues are single letters from a to z. Queue a is the default, and jobs in queues a through z are executed with decreasing niceness (priority). Queue a has the highest priority, and queue z has the lowest. Queue b is reserved for batch jobs.

Let's schedule a job in queue g (a lower priority queue) to run in 2 minutes. This job will create a file named ~/queue_g_job.txt with a timestamp:

at -q g now + 2 minutes << EOF
date > ~/queue_g_job.txt
EOF

You will see output similar to job N at .... Note down this job number.

Next, let's schedule another job, this time in queue b (batch queue), which is typically used for jobs that can run when system load is low. This job will append "Batch job executed!" to ~/batch_job.txt. We'll schedule it to run 4 minutes from now:

at -q b now + 4 minutes << EOF
echo "Batch job executed!" >> ~/batch_job.txt
EOF

Again, note down the job number.

To see all pending jobs, including those in different queues, use atq.

atq

You should now see both jobs listed, with their respective queue letters (g and b).

Now, wait for your scheduled jobs to execute. Wait for at least 5 minutes to allow all jobs to complete. You can check if the files created by your at jobs exist and contain the expected content.

Check ~/queue_g_job.txt:

cat ~/queue_g_job.txt

You should see a date and time string.

Check ~/batch_job.txt:

cat ~/batch_job.txt

You should see "Batch job executed!".

If the files are not present or empty, it might mean the jobs haven't executed yet, or there was an issue with the command. You can re-check atq to see if they are still pending.

How to Schedule Recurring User Jobs with 'crontab'

Next, you’ll learn how to schedule recurring tasks for a specific user using crontab. Unlike at jobs, which run once, cron jobs run repeatedly at specified intervals. This is ideal for routine maintenance, data backups, or generating reports.

We will continue working on the local system to learn about user crontab management.

The crontab command allows users to create, edit, and view their own cron jobs. Each user has their own crontab file.

To edit your crontab file, use the crontab -e command. This will open your crontab file in the default text editor (usually vim).

crontab -e

Vim editor instructions:

• Press i to enter insert mode (you'll see -- INSERT -- at the bottom)

• Use arrow keys to navigate

• To save and exit: Press Esc to exit insert mode, then type :wq and press Enter

• To exit without saving: Press Esc, then type :q! and press Enter

Inside the editor, you will add a new line to define your cron job. A cron entry has five time-and-date fields, followed by the command to be executed. The fields are:

• Minute (0-59)

• Hour (0-23)

• Day of Month (1-31)

• Month (1-12)

• Day of Week (0-7, where 0 or 7 is Sunday)

You can use * as a wildcard to mean "every" for a field, or / to specify step values (for example, */5 for every 5 minutes).

Let's schedule a job that appends the current date and time to a file named ~/my_cron_log.txt every minute. This will allow us to quickly observe the cron job in action.

Follow these steps in Vim:

1. Press i to enter insert mode

2. Add the following line to the crontab file:

* * * * * /usr/bin/date >> ~/my_cron_log.txt

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

You should see a message indicating that a new crontab has been installed:

crontab: installing new crontab

To verify that your cron job has been successfully added, you can list your crontab entries using the crontab -l command:

crontab -l

You should see the line you just added:

* * * * * /usr/bin/date >> ~/my_cron_log.txt

Now, wait for a minute or two to allow the cron job to execute at least once. You can check the current time to see when the next minute mark will occur:

date

After waiting for at least two minutes to allow the cron job to execute a couple of times, check the content of the ~/my_cron_log.txt file.

cat ~/my_cron_log.txt

You should see one or more lines, each containing a date and time, indicating that your cron job has executed.

Mon Apr 8 10:30:01 AM EDT 2025
Mon Apr 8 10:31:01 AM EDT 2025

How to Manage User 'crontab' Entries

Now you will learn more advanced techniques for managing user crontab entries, including editing existing jobs, adding multiple jobs, and understanding special cron strings. Effective crontab management is crucial for automating routine tasks.

We will continue working on the local system to explore advanced crontab management techniques.

Let's start by adding a new cron job. This job will append "Hello from cron!" to ~/cron_messages.txt every two minutes.

Open your crontab for editing:

crontab -e

In Vim:

1. Press i to enter insert mode

2. Add the following line to the crontab file:

*/2 * * * * echo "Hello from cron!" >> ~/cron_messages.txt

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

Verify that the entry is added:

crontab -l

You should see the newly added line.

Now, let's add another cron job that runs daily at 08:00 AM. This job will record the disk usage of your home directory to ~/disk_usage.log.

Open your crontab for editing again:

crontab -e

In Vim:

1. Press i to enter insert mode

2. Add the following line below the previous one:

0 8 * * * du -sh ~ >> ~/disk_usage.log

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

Verify that both entries are present:

crontab -l

You should now see both cron jobs listed.

cron also supports special strings that can simplify common schedules. These include @reboot, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly. For example, @hourly is equivalent to 0 * * * *.

Let's add a job that runs hourly and records the system uptime to ~/uptime_log.txt.

Open your crontab for editing:

crontab -e

In Vim:

1. Press i to enter insert mode

2. Add the following line:

@hourly uptime >> ~/uptime_log.txt

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

Verify all three entries:

crontab -l

You should now see all three cron jobs.

To demonstrate the effect of these jobs, we will wait for a short period. Since the jobs are scheduled at different intervals, we won't see all of them execute immediately, but we can verify the setup.

Wait for at least 3 minutes to allow the */2 job to run at least once.

Check the ~/cron_messages.txt file:

cat ~/cron_messages.txt

You should see at least one "Hello from cron!" message.

Hello from cron!

The ~/disk_usage.log and ~/uptime_log.txt files might not be created yet, depending on the current time, as they are scheduled for daily and hourly execution, respectively. The important part is that their entries are correctly configured in your crontab.

How to Schedule Recurring System Jobs with cron Directories

In this step, you will learn how to schedule recurring system-wide tasks using cron directories. Unlike user crontab entries, which are specific to a user, system cron jobs are managed by the root user and affect the entire system. These are typically used for system maintenance, log rotation, and other administrative tasks.

We will continue working on the local system to explore system-wide cron job configuration.

System-wide cron jobs are defined in /etc/crontab or by placing scripts in specific directories:

• /etc/cron.hourly/: Scripts in this directory run once an hour.

• /etc/cron.daily/: Scripts in this directory run once a day.

• /etc/cron.weekly/: Scripts in this directory run once a week.

• /etc/cron.monthly/: Scripts in this directory run once a month.

These directories are processed by the run-parts utility, which executes all executable files within them.

To manage system cron jobs, you need root privileges. Since the labex user has sudo access, we can use sudo for the required commands.

Let's create a simple script that logs a message to the system log. We will place this script in /etc/cron.hourly/ to make it run hourly.

First, create the script file /etc/cron.hourly/my_hourly_script:

sudo nano /etc/cron.hourly/my_hourly_script

Add the following content to the file:

#!/bin/bash
logger "Hourly cron job executed at $(date)"

Save and exit the editor (Ctrl+o, Enter, Ctrl+x in nano).

Next, you need to make the script executable. Without execute permissions, run-parts will ignore it.

sudo chmod +x /etc/cron.hourly/my_hourly_script

Now, let's verify that the script is executable:

ls -l /etc/cron.hourly/my_hourly_script

You should see x in the permissions, for example: -rwxr-xr-x.

Since cron.hourly jobs run once an hour, we can't wait for a full hour to verify its execution in this tutorial. But we can manually trigger the run-parts command for the hourly directory to simulate its execution.

sudo run-parts /etc/cron.hourly/

This command will execute all executable scripts in /etc/cron.hourly/. The script we created uses the logger command to write messages to the system log.

In a real RHEL system, you would be able to check the system logs using journalctl or /var/log/messages to verify that the script executed successfully.

This completes the system cron job management step. The script will remain in place and would execute hourly in a real system environment.

How to Configure systemd Timers for Recurring Tasks

Next, you will learn about systemd timers, which are a modern alternative to cron for scheduling tasks on Linux systems. systemd timers offer more flexibility and better integration with the systemd ecosystem.

systemd timers work in conjunction with systemd service units. A timer unit (.timer file) defines when a task should run, and a service unit (.service file) defines what task should be executed.

We will continue working on the local system to explore systemd timer configuration.

You will need root privileges to create systemd unit files in system directories. Since the labex user has sudo access, we can use sudo for the required commands.

Let's create a simple service that logs a message to a file. We will place this service unit file in /etc/systemd/system/ which is where custom service units are typically stored.

Create the service unit file /etc/systemd/system/my-custom-task.service:

sudo nano /etc/systemd/system/my-custom-task.service

Add the following content to the file:

[Unit]
Description=My Custom Scheduled Task

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo "My custom task executed at $(date)" >> /var/log/my-custom-task.log'

Save and exit the editor (Ctrl+o, Enter, Ctrl+x in nano).

Next, create the timer unit file /etc/systemd/system/my-custom-task.timer. This timer will activate our service every 5 minutes.

sudo nano /etc/systemd/system/my-custom-task.timer

Add the following content to the file:

[Unit]
Description=Run My Custom Scheduled Task every 5 minutes

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

[Install]
WantedBy=timers.target

Save and exit the editor.

Explanation of OnCalendar:

• *:0/5 means "every 5 minutes".

  • * for year, month, day, hour (any value).

  • 0/5 for minute, meaning starting at minute 0, every 5 minutes (0, 5, 10, ..., 55).

In a typical systemd environment, you would now run systemctl daemon-reload to make systemd aware of the new unit files, and then systemctl enable --now my-custom-task.timer to start the timer.

Let's verify the existence of the created files:

ls -l /etc/systemd/system/my-custom-task.service
ls -l /etc/systemd/system/my-custom-task.timer

You should see output indicating that both files exist.

To simulate the execution of the service, you can manually run the command defined in ExecStart:

sudo /bin/bash -c 'echo "My custom task executed at $(date)" >> /var/log/my-custom-task.log'

Now, check the log file to see the output:

sudo cat /var/log/my-custom-task.log

You should see the message you just logged:

My custom task executed at Tue Jun 10 06:54:40 UTC 2025

This completes the systemd timer configuration step. The service and timer unit files will remain in place for reference.

How to Manage Temporary Files with systemd-tmpfiles

Now you’ll learn how to manage temporary files and directories using systemd-tmpfiles. This utility is part of systemd and is responsible for creating, deleting, and cleaning up volatile and temporary files and directories. It's commonly used to manage /tmp, /var/tmp, and other temporary storage locations, ensuring that old files are removed periodically.

We will continue working on the local system to explore systemd-tmpfiles configuration.

You will need root privileges to configure systemd-tmpfiles. Since the labex user has sudo access, we can use sudo for the required commands.

systemd-tmpfiles reads configuration files from /etc/tmpfiles.d/ and /usr/lib/tmpfiles.d/. These files define rules for creating, deleting, and managing files and directories.

Let's create a custom configuration file to manage a new temporary directory. We will create a directory /run/my_temp_dir and configure systemd-tmpfiles to clean files older than 1 minute from it.

Create the configuration file /etc/tmpfiles.d/my_temp_dir.conf:

sudo nano /etc/tmpfiles.d/my_temp_dir.conf

Add the following content to the file:

d /run/my_temp_dir 0755 labex labex 1m

Explanation of the line:

• d: Specifies that this entry defines a directory.

• /run/my_temp_dir: The path to the directory.

• 0755: The permissions for the directory.

• labex labex: The owner and group for the directory.

• 1m: The age after which files in this directory should be deleted (1 minute).

Save and exit the editor (Ctrl+o, Enter, Ctrl+x in nano).

Now, let's tell systemd-tmpfiles to apply this configuration. The --create option will create the directory if it doesn't exist.

sudo systemd-tmpfiles --create /etc/tmpfiles.d/my_temp_dir.conf

Verify that the directory has been created with the correct permissions and ownership:

ls -ld /run/my_temp_dir

You should see output similar to:

drwxr-xr-x 2 labex labex 6 Jun 10 06:55 /run/my_temp_dir

Next, let's create a test file inside this new temporary directory:

sudo touch /run/my_temp_dir/test_file.txt

Verify the file exists:

ls -l /run/my_temp_dir/test_file.txt

Now, we need to wait for more than 1 minute for the file to become "old" according to our configuration. Wait for at least 70 seconds (1 minute and 10 seconds).

After waiting for more than 1 minute, we will manually run systemd-tmpfiles with the --clean option to trigger the cleanup process based on our configuration.

sudo systemd-tmpfiles --clean /etc/tmpfiles.d/my_temp_dir.conf

Finally, check if the test_file.txt has been removed:

ls -l /run/my_temp_dir/test_file.txt

You should get a "No such file or directory" error, indicating that systemd-tmpfiles successfully cleaned up the old file.

This completes configuring the systemd-tmpfiles. The configuration file and temporary directory will remain in place for reference.

Summary

In this tutorial, you learned how to schedule and manage one-time tasks using the at command, including scheduling jobs interactively and non-interactively, viewing the at queue with atq, and deleting pending jobs with atrm. You also learned how to schedule recurring user-specific tasks using crontab, including how to edit, list, and remove cron jobs, and you learned the cron syntax for specifying execution times.

We also demonstrated how to schedule system-wide recurring tasks by placing scripts in standard cron directories (/etc/cron.hourly, /etc/cron.daily, etc.) and how to create custom cron jobs in /etc/cron.d.

Finally, you explored advanced task scheduling with systemd timers, learning to create and enable service and timer units for recurring tasks, and how to manage temporary files and directories using systemd-tmpfiles for automated cleanup.

This comprehensive tutorial provided practical experience in managing diverse task scheduling needs on RHEL systems, from simple one-off commands to complex recurring system processes.

To practice the operations from this tutorial, try the interactive hands-on lab: Schedule Tasks in Red Hat Enterprise Linux.

A common problem faced in networking is losing connectivity after modifying the network settings, which leads to an inability to access the system. This usually happens due to a misconfigured IP address, incorrect settings, and a poor understanding of network interface configurations.

In this article, we’ll guide you through understanding these network interface configurations, setting up and managing network interfaces on Linux, checking available interfaces, configuring static and dynamic IP addresses, and best practices to consider when setting up network interfaces. At the end of this article, you’ll have a solid foundation in network interfaces.

Table of Contents

• What are Network Interfaces?

• Types of Network Interfaces in Linux

• Why Network Interfaces Matter

• How to List Network Interfaces in Linux

• How to Configure Network Interfaces in Linux

• How to Set Up a Network Bridge in Linux

• Best Practices for Configuring Network Interfaces in Linux

• Conclusion

What are Network Interfaces?

A network interface is a connection point within the Linux system that allows communication with other devices within the network. It is how the Linux kernel links the software side of the network with the hardware side. Linux systems provide many network interfaces that help to facilitate communication between the system and other external networks.

Linux network interfaces are essential for troubleshooting, configuration, management, and optimization of networking tasks. Understanding what they are and how they work allows you to optimize your server networking and security.

Types of Network Interfaces in Linux

Network interfaces can be classified into two main categories: physical and virtual network interfaces.

Physical Network Interfaces

Physical network adapters are the hardware components of the network interface that connect the system to a physical network. These physical networks include Wi-Fi and Ethernet. These adapters, commonly called Network Interface Cards (NIC), can be identified by their device names, such as wlan0 and eth0. They include the following:

1. Ethernet Interface (eth0, eth1, and so on)

   Ethernet interface is used for wired connections via an Ethernet card and helps configure high-speed networking. It can be used in data centres and servers.

2. Wi-Fi interface (wlan0, wlan1, and so on)

   This represents a wireless network adapter, and it enables wireless connectivity via Wi-Fi networks to the servers.

Virtual Network Interfaces

Virtual network interfaces are software-based interfaces managed by the Linux operating system. They integrate network virtualization technologies like Docker or KVM. There are several virtual network interfaces, and the most common ones include:

• Loopback interface: This is a special interface that allows a system to communicate internally. It is permanently assigned the IP address 127.0.0.1, referred to as the localhost.

• Bridge Interface: They are used to connect multiple network interfaces. It is useful for virtualization environments (for example, Linux KVM, Docker networking).

• Tunnel Interface: This is used for VPNs and networking tunnels. It helps to facilitate the passage of encrypted network traffic.

Why Network Interfaces Matter

Network interfaces form an essential component of a Linux system. It enables communication between devices and the internet, and properly configuring these interfaces provides the following benefits:

Seamless connectivity: Network interfaces allow devices to communicate over local networks and the internet, enabling proper data exchange between servers and networks.

Proper network management: Administrators can configure network interfaces by creating, managing, and assigning static or dynamic IPs and optimizing traffic flow.

Improved security: Administrators can configure network interfaces with firewalls and VPNs to secure data and prevent unauthorized access.

It provides support for virtualization and containerization: Virtual network interfaces provide proper communication between virtual machines, Docker containers, and other physical servers. This makes them essential for creating and managing DevOps environments.

How to List Network Interfaces in Linux

You can check the available network interfaces within the Linux environment using the following commands.

1. Using the ip command:

   To list all network interfaces and their status, you can use the ip link show command. It displays details about the network interfaces, like the name, status, and MAC address.

2. Using the ifconfig command

   To list all network interfaces, use this command: ifconfig -a. The command also displays details about the network interfaces and their current state.

3. Using nmcli for NetworkManager-controlled systems

   To check the status of all network interfaces managed by NetworkManager, run:

   nmcli device status.

4. Using the /sys/class/net/ directory

   To list all network interfaces, run ls /sys/class/net/ This command is useful for scripting and automation because it provides a reliable way to check available interfaces programmatically.

How to Configure Network Interfaces in Linux

Network interface configuration is essential for managing Linux servers and workstations. Understanding this configuration will help ensure smooth connectivity within your systems. This section will give you the correct information on configuring network interfaces.

Assign a Static IP Address

A static IP address ensures the device maintains the same IP after each reboot. This is particularly useful for servers and devices that need consistent addressing. To assign a static IP address, the NetworkManager Command Line Interface (nmcli) provides a command-line utility to configure the network interface as shown below.

nmcli connection modify eth0 ipv4.addresses 192.168.1.100/24   # set a static IPv4 address and subnet mask

nmcli connection modify eth0 ipv4.gateway 192.168.1.1          # define the default gateway

nmcli connection modify eth0 ipv4.dns "8.8.8.8 8.8.4.4"        # configure primary and secondary DNS servers

nmcli connection modify eth0 ipv4.method manual                # switch the interface from DHCP to manual mode

nmcli connection up eth0                                       # bring the interface down and up to apply changes

These commands set a fixed IP, gateway, and DNS on eth0, switch the interface to manual mode, and restart it so the new settings take effect. The settings persist across reboots because they are stored by NetworkManager

Assign a Temporary IP Address

The ip command lets you configure interfaces dynamically (not persistent across reboots):

ip addr add 192.168.1.100/24 dev eth0     # assign 192.168.1.100/24 to interface eth0 (temporary)

ip route add default via 192.168.1.1      # set the default gateway to 192.168.1.1

These two commands give eth0 the IP 192.168.1.100/24 and point all outbound traffic to the gateway 192.168.1.1. The settings last only until the next reboot or interface reset.

Assign an IP Address with ifconfig (deprecated)

Older systems still ship with ifconfig and route. These commands are also temporary.

ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up  # assign 192.168.1.100/24 to eth0 and bring it up

route add default gw 192.168.1.1 eth0                # set the default gateway to 192.168.1.1 via eth0

Note: Prefer ip or nmcli on modern systems.

Enable DHCP with nmcli

A DHCP-assigned address lets the network hand out an IP address automatically.

nmcli connection modify eth0 ipv4.method auto   # switch eth0 to use DHCP for automatic addressing

nmcli connection up eth0                        # restart the connection so the new DHCP setting takes effect

To renew or request a lease directly:

dhclient eth0   # manually request or renew an IP address via DHCP on interface eth0

These commands set eth0 to use DHCP, restart the link so the change takes effect, and (optionally) trigger an instant lease renewal.

Assign Multiple IP Addresses to One Interface

A network interface can have multiple addresses assigned to it, making it applicable to host multiple services on a single interface.

Using IP command (Temporary Assignment)

ip addr add 192.168.1.101/24 dev eth0   # add an extra IPv4 address to eth0 (temporary)

ip addr add 2001:db8::1/64 dev eth0     # add an IPv6 address to eth0 (temporary)

These two commands attach an extra IPv4 and an IPv6 address to eth0 until the interface resets or the system reboots

Persistent Configuration (Netplan)

Edit the /etc/netplan/01-netcfg.yaml file:

network:

  version: 2

  renderer: networkd

  ethernets:

    eth0:

      addresses:

        - 192.168.1.100/24

        - 192.168.1.101/24

        - 2001:db8::1/64

After editing the file, run sudo netplan apply to make the additional addresses stick across reboots.

How to Set Up a Network Bridge in Linux

A network bridge allows multiple interfaces to act as a single network segment, which is useful in virtualization (KVM, Docker).

Using brctl (bridge-utils package)

brctl addbr br0                       # create a new bridge interface named br0

brctl addif br0 eth0                  # add physical interface eth0 to the bridge

ip addr add 192.168.1.100/24 dev br0  # assign an IP address to the bridge, not to eth0

ip link set br0 up                    # bring the bridge interface online

These commands create bridge br0, attach eth0 to it, give the bridge its own IP, and bring it online.

Using nmcli (for NetworkManager-managed systems)

nmcli connection add type bridge ifname br0                       # create a new bridge named br0

nmcli connection modify br0 bridge.stp no                         # turn off Spanning Tree Protocol

nmcli connection add type bridge-slave ifname eth0 master br0     # attach physical interface eth0 to br0

nmcli connection up br0                                           # bring the bridge online so settings take effect

This sequence builds the same bridge through NetworkManager, disables STP for faster convergence, links eth0 as a slave, and activates the bridge so guests can reach the network.

Best Practices for Configuring Network Interfaces in Linux

Make Your Configurations Persistent

One of the mistakes network engineers make in Linux networking is making changes that do not persist after rebooting. While specific commands can modify the network settings temporarily, they do not save these changes permanently.

To ensure that these network settings survive server reboots, modify system configuration files such as /etc/network/interfaces. Once you ensure that all changes are persistent, there will be no unexpected disruptions when a system restarts.

Assign Static IPs for Servers

Static IP addresses are the best for servers and critical infrastructure. Unlike DHCP addresses, which can change over time, static IP addresses are more stable and reliable. For services like web hosting and database management, static IPs play a key role, as IP addresses do not need to change.

Secure Your Network Interfaces

Network interfaces are the entry points into a system, so if they are misconfigured, they could pose a considerable security risk. To reduce attacks, administrators should turn off all unused network interfaces by modifying the configuration file to prevent automatic activation. Additionally, you should use firewall tools to control the traffic that tries to reach the system.

Monitor Your Network Interfaces

As a system administrator, monitoring network interfaces helps prevent downtime and ensure proper network reliability. You can check the status of your network interfaces by running commands like link show or if-config -a. You can also monitor them in real time using tools like Netstat. Monitoring your systems ensures that network issues are detected early enough, reducing downtime and improving network stability.

Constantly Update Network Packages

You must constantly update network management tools and drivers because it helps to implement security patches and other performance improvements, as outdated network packages can cause security vulnerabilities. There are specific network-related packages such as network-manager, bridge-utils and iproute2.

Conclusion

Setting up network interfaces in Linux is a fundamental skill every system administrator should have. Whether configuring static IP addresses or enabling DHCP, understanding these concepts will ensure that your systems are stable and have proper connectivity. Implementing best practices like monitoring traffic and securing the network interface gives you the best results. As you continue working with Linux, you can experiment with different configurations to deepen your understanding of network interfaces.

You’ll learn how you can get information related to your OS (operating system), kernel, CPU, memory, processes, disks, networks, and installed software. You’ll explore the commands and their outputs in detail.

Table of Contents

• Why It's Important to Understand Your Linux System

• How to Get Your OS & Kernel Information in Linux

• How to Get Your CPU Information in Linux

• How to Get Your Memory Information in Linux

• How to Get Your Disk & Filesystem Information in Linux

• How to Get Your Hardware Information in Linux

• How to Get Your Network Interfaces & Status Information in Linux

• How to Get Your Software & Services Information in Linux

• How to Get Your Logs & Dmesg In formation in Linux

• How to Get Your Security/User Audit Information in Linux

• Visually Appealing Commands

• Conclusion

Why It's Important to Understand Your Linux System

System Administration

System administrators need to have an understanding of the system so they are able to:

• Manage users, groups, and permissions effectively.

• Configure services like web servers, databases, and so on.

• Automate repetitive tasks with scripts and cron jobs.

Troubleshooting

When the system is in a problematic state, a solid understanding of the system specification and configuration helps you to:

• Identify and resolve system errors quickly.

• Analyze system logs and monitor performance.

• Diagnose network and hardware issues.

Security Auditing

If you are in a security related role, knowing your system in depth helps you to:

• Monitor logs for unauthorized access.

• Configure firewalls and security policies.

• Detect and remove malicious processes or software.

Performance Optimization

If you know how to gather information related to system resources, you can measure them and create a projection for the future use. You can also:

• Tune system parameters for better efficiency.

• Monitor resource usage (CPU, memory, disk, I/O).

• Eliminate bottlenecks and optimize workloads.

Proactive Maintenance

It is a good practice to be able to prevent issues before they occur. Once you know your system well, you can:

• Schedule regular updates and backups.

• Ensure system reliability and uptime.

Understanding your Linux system gives you greater control, enhances system stability, and improves your overall effectiveness as a system administrator or power user.

In the next section, we’ll discuss some essential commands for gathering system information.

How to Get Your OS & Kernel Information in Linux

uname -a Command

uname -a provides full kernel information:

uname -a
Linux ip-172-31-90-178 6.8.0-1024-aws #26-Ubuntu SMP Tue Feb 18 17:22:37 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Here is what each part means in the above command:

• Linux: The kernel name.

• ip-172-31-90-178: The network hostname of the system.

• 6.8.0-1024-aws: The kernel version and AWS-specific build.

• #26-Ubuntu: The kernel build number.

• SMP: Symmetric Multi-Processing, indicating that the kernel is compiled for multiple processors.

• Tue Feb 18 17:22:37 UTC 2025: The date and time when the kernel was compiled.

• x86_64 x86_64 x86_64: The machine hardware name (architecture), processor type, and platform type, all indicating 64-bit x86 architecture.

• GNU/Linux: The operating system name.

Based on this output, I’m running on an AWS EC2 instance with a 64-bit Ubuntu Linux distribution using a kernel that was specifically built for AWS infrastructure.

uname -r and uname -s Commands

The uname -r and uname -s commands specify the kernel version and OS type information:

uname -r
6.11.0-25-generic

uname -s
Linux

cat /etc/os-release Command

The cat /etc/os-release command provides distribution information:

cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

Here is what each part means in the above command:

• PRETTY_NAME="Ubuntu 24.04.2 LTS": The user-friendly name of the distribution including version and LTS (Long Term Support) designation.

• NAME="Ubuntu": The name of the Linux distribution.

• VERSION_ID="24.04": The version number of the Ubuntu release (Year/Month format).

• VERSION="24.04.2 LTS (Noble Numbat)": The complete version information including:

  • 24.04: Major version (released April 2024)

  • .2: Point release number

  • LTS: Long Term Support

  • Noble Numbat: The release codename

• VERSION_CODENAME=noble: The codename for this Ubuntu release ("Noble").

• ID=ubuntu: The machine-readable name of the operating system.

• ID_LIKE=debian: Indicates that Ubuntu is based on Debian Linux.

• HOME_URL, SUPPORT_URL, BUG_REPORT_URL, PRIVACY_POLICY_URL : Various official URLs for Ubuntu resources.

• UBUNTU_CODENAME=noble: Reiterates the codename of this Ubuntu release.

• LOGO=ubuntu-logo: Specifies the logo identifier for the distribution.

This output shows that I’m running Ubuntu 24.04.2 LTS (codenamed "Noble Numbat"), which is a Long Term Support release of Ubuntu. Being an LTS version means it will receive security updates and support for an extended period (typically 5 years for Ubuntu LTS releases).

hostnamectl Command

hostnamectl shows the hostname, OS, and kernel info:

hostnamectl
 Static hostname: ip-172-31-90-178
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: ec272830b6dca2da0d11e41b292cfc99
         Boot ID: dd12f48ff01b44a796991d99ce1bcfde
  Virtualization: xen
Operating System: Ubuntu 24.04.2 LTS              
          Kernel: Linux 6.8.0-1024-aws
    Architecture: x86-64
 Hardware Vendor: Xen
  Hardware Model: HVM domU
Firmware Version: 4.11.amazon
   Firmware Date: Thu 2006-08-24
    Firmware Age: 18y 9month 1w 2d

In the above command, here is what each part means:

• Static hostname: "ip-172-31-90-178": This is the permanent hostname of the system, stored in /etc/hostname.

• Icon name: "computer-vm": A symbolic icon identifier for the system, used by some desktop environments.

• Chassis: "vm": Indicates this is running in a virtual machine environment.

• Machine ID: "ec272830b6dca2da0d11e41b292cfc99": A unique identifier for this system, stored in /etc/machine-id.

• Boot ID: "dd12f48ff01b44a796991d99ce1bcfde": A unique identifier that changes with each system boot.

• Virtualization: "xen": Shows that this system is running on Xen virtualization (common for AWS instances).

• Operating System: "Ubuntu 24.04.2 LTS": The current OS distribution and version.

• Kernel: "Linux 6.8.0-1024-aws": The current Linux kernel version, specifically an AWS-optimized kernel.

• Architecture: "x86-64": The CPU architecture of the system.

• Hardware Vendor: "Xen" Hardware Model: "HVM domU": Indicates this is a Xen HVM (Hardware Virtual Machine) domain user instance.

• Firmware Details:

  • Version: 4.11.amazon: This is the version of the firmware/BIOS specifically customized for AWS environments.

  • Date: Thu 2006-08-24: This is the release date of the firmware. The date might seem old (2006) but this is normal for AWS instances.

  • Age: 18y 9month 1w : This shows how old the firmware is relative to the current date calculated from the firmware date (2006) to now (2025). While the firmware seems old, it is still maintained and secure.

This overall output shows that I’m running Ubuntu 24.04.2 LTS on an AWS EC2 instance using Xen virtualization. The system is using an AWS-optimized kernel and is configured as a HVM (Hardware Virtual Machine) instance.

How to Get Your CPU Information in Linux

lscpu Command

lscpu shows CPU architecture, cores, threads, and virtualization information:

lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          46 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   1
  On-line CPU(s) list:    0
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Xeon(R) CPU E5-2686 v4 @ 2
                          .30GHz
    CPU family:           6
    Model:                79
    Thread(s) per core:   1
    Core(s) per socket:   1
    Socket(s):            1
    Stepping:             1
    BogoMIPS:             4599.99
    Flags:                fpu vme de pse tsc msr pae mce cx8 
                          apic sep mtrr pge mca cmov pat pse3
                          6 clflush mmx fxsr sse sse2 ht sysc
                          all nx rdtscp lm constant_tsc rep_g
                          ood nopl xtopology cpuid tsc_known_
                          freq pni pclmulqdq ssse3 fma cx16 p
                          cid sse4_1 sse4_2 x2apic movbe popc
                          nt tsc_deadline_timer aes xsave avx
                           f16c rdrand hypervisor lahf_lm abm
                           pti fsgsbase bmi1 avx2 smep bmi2 e
                          rms invpcid xsaveopt
Virtualization features:  
  Hypervisor vendor:      Xen
  Virtualization type:    full
Caches (sum of all):      
  L1d:                    32 KiB (1 instance)
  L1i:                    32 KiB (1 instance)
  L2:                     256 KiB (1 instance)
  L3:                     45 MiB (1 instance)
NUMA:                     
  NUMA node(s):           1
  NUMA node0 CPU(s):      0
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          KVM: Mitigation: VMX unsupported
  L1tf:                   Mitigation; PTE Inversion
  Mds:                    Vulnerable: Clear CPU buffers attem
                          pted, no microcode; SMT Host state 
                          unknown
  Meltdown:               Mitigation; PTI
  Mmio stale data:        Vulnerable: Clear CPU buffers attem
                          pted, no microcode; SMT Host state 
                          unknown
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Vulnerable
  Spectre v1:             Mitigation; usercopy/swapgs barrier
                          s and __user pointer sanitization
  Spectre v2:             Mitigation; Retpolines; STIBP disab
                          led; RSB filling; PBRSB-eIBRS Not a
                          ffected; BHI Retpoline
  Srbds:                  Not affected
  Tsx async abort:        Not affected

Here is a brief explanation of the output above:

1. Basic CPU Info

• Architecture: x86_64 (64-bit)

• CPU Model: Intel Xeon E5-2686 v4 (2.3 GHz)

• Cores/Threads: 1 core, 1 thread (no Hyper-Threading)

• Physical CPU (Socket): 1

2. Performance & Features

• Cache Sizes:

  • L1: 32 KiB (data) + 32 KiB (instructions)

  • L2: 256 KiB

  • L3: 45 MiB (large, typical for Xeon)

• Flags: Supports AVX, AES, SSE4.1/4.2 (useful for encryption/vector ops).

3. Virtualization

• Hypervisor: Running on Xen (full virtualization).

• Virtualization Support: Yes (Intel VT-x).

4. Security (Vulnerabilities)

• Meltdown/Spectre: Mostly mitigated (PTI, Retpolines).

• MDS/MMIO: Vulnerable (no microcode fixes).

• Spec Store Bypass: Vulnerable (no mitigation).

5. NUMA (Memory)

• Single NUMA node (no multi-processor complexity).

The output shows that my machine is a single-core Intel Xeon (in a virtualized/cloud environment) with large L3 cache but has some unpatched CPU vulnerabilities.

cat /proc/cpuinfo Command

cat /proc/cpuinfo provides more in-depth details about the CPU:

cat /proc/cpuinfo 
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 79
model name    : Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
stepping    : 1
microcode    : 0xd000404
cpu MHz        : 2299.998
cache size    : 46080 KB
physical id    : 0
siblings    : 1
core id        : 0
cpu cores    : 1
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm pti fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_stale_data bhi
bogomips    : 4599.99
clflush size    : 64
cache_alignment    : 64
address sizes    : 46 bits physical, 48 bits virtual
power management:

nproc Command

nproc shows the core count:

nproc
1

The above command output shows there is one available processor.

How to Get Your Memory Information in Linux

free -h Command

You can use the free -h command to know the total/used/free RAM:

free -h
               total        used        free      shared  buff/cache   available
Mem:           957Mi       406Mi       218Mi       920Ki       522Mi       551Mi
Swap:             0B          0B          0B

Here is a breakdown of the output shared above:

• total: The total amount of physical memory (RAM) or swap space available on the system.

• used: The amount of memory currently being used by applications and the system. Calculated as: total - free - buffers - cache.

• free: The amount of memory that is completely unused.

• shared: Memory that may be simultaneously accessed by multiple programs.

• buff/cache: Combines two types of memory:

  • Buffers: Memory used for block device I/O buffering.

  • Cache: Memory used for file system page cache - This memory can be reclaimed when needed by applications.

  • available: It includes the 'free' memory plus memory that can be reclaimed from buff/cache. This is the most important column for determining if you have enough memory.

vmstat Command

vmstat stands for Virtual Memory Statistics, a tool to monitor system performance. It provides information about memory usage, CPU activity, Processes, Disk I/O and Swap usage.

You can also use vmstat to extract live information. Here is how you can do that:

vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 238264  46120 489056    0    0     3     8   23    0  0  0 82  0 18  0
 0  0      0 238264  46120 489060    0    0     0     0  240  120  0  1 98  0  1  0
 0  0      0 238264  46120 489060    0    0     0     0  239  124  0  0 98  0  2  0
 0  0      0 238264  46120 489060    0    0     0     0  199  101  0  0 95  0  5  0
 0  0      0 238264  46120 489060    0    0     0     0   36   25  0  0 78  0 22  0

Here is what the above command is doing:

1. Captures 5 snapshots of system performance.

2. Each snapshot is taken 1 second apart, giving near real-time insights.

3. Displays key metrics about:

   • Memory usage (free, buffered, cached).

   • CPU activity (user, system, idle, waiting).

   • Processes (running, blocked).

   • Disk I/O (blocks read/written).

   • Swap usage (if swapping is happening).

Note that, you can replace the interval and number of snapshots accordingly.

Here’s a detailed breakdown of the output above:

• Procs:

  • r: Number of processes waiting for run time.

  • b: Number of processes in uninterruptible sleep

• Memory (in KB):

  • swpd: Amount of virtual memory used

  • free: Amount of idle memory

  • buff: Memory used as buffers

  • cache: Memory used as cache

• Swap:

  • si: Memory swapped in from disk (KB/s)

  • so: Memory swapped out to disk (KB/s)

• IO:

  • bi: Blocks received from a block device (blocks/s)

  • bo: Blocks sent to a block device (blocks/s)

• System:

  • in: Number of interrupts per second

  • cs: Number of context switches per second

• CPU (percentages):

  1. us: Time spent running user code

  2. sy: Time spent running system code

  3. id: Time spent idle

  4. wa: Time spent waiting for IO

  5. st: Time stolen from a virtual machine

  6. gu: Time running guest code (virtual CPU)

From the output, you can see that my system:

• Has very low CPU usage (high idle percentage)

• Has no swap being used (swpd = 0)

• Has about 99MB free memory

• Shows minimal IO activity

• Is running in a virtualized environment (notice the st (stolen) time column has non-zero value

The first line shows averages since the last reboot, while subsequent lines show the real-time statistics for each second.

cat /proc/meminfo Command

cat /proc/meminfo shows detailed memory stats:

cat /proc/meminfo
MemTotal:         980384 kB
MemFree:          245100 kB
MemAvailable:     585896 kB
Buffers:           46184 kB
Cached:           393672 kB
SwapCached:            0 kB
Active:           141404 kB
Inactive:         356376 kB
Active(anon):      47672 kB
Inactive(anon):    29300 kB
Active(file):      93732 kB
Inactive(file):   327076 kB
Unevictable:       36528 kB
Mlocked:           27152 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         94488 kB
Mapped:            97936 kB
Shmem:               920 kB
KReclaimable:      95396 kB
Slab:             148672 kB
SReclaimable:      95396 kB
SUnreclaim:        53276 kB
KernelStack:        2444 kB
PageTables:         3224 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      490192 kB
Committed_AS:     508912 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        9988 kB
VmallocChunk:          0 kB
Percpu:            14848 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
Unaccepted:            0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:       71680 kB
DirectMap2M:      976896 kB

Here is a detailed breakdown of the output shared above:

• Total Memory and Available Memory:

  • MemTotal: Total physical RAM available.

  • MemFree: Completely unused memory.

  • MemAvailable: Memory available for new applications.

• Memory Caches and Buffers:

  • Buffers: Memory used for block device I/O buffering.

  • Cached: Memory used for file system cache.

  • SwapCached: Memory pages stored in both RAM and swap.

• Active vs Inactive Memory:

  • Active: Recently used memory.

  • Inactive: Less recently used memory.

  • Active(anon): Recently used anonymous memory.

  • Active(file): Recently used file-backed memory.

• Swap Information:

  • SwapTotal: Swap space configured.

  • SwapFree: Swap space available.

  • Zswap: Compressed swap in RAM.

• Other Important Metrics:

  • Dirty: Memory waiting to be written to disk.

  • Mapped: Files mapped into memory.

  • Slab: Kernel data structures cache.

  • CommitLimit: Total memory available for allocation.

  • Committed_AS: Total memory currently allocated.

A healthy memory usage is indicated by a good amount of available memory, active caching mechanisms in place and no memory pressure (no swap usage needed).

How to Get Your Disk & Filesystem Information in Linux

tree -d -L 1 Command

tree -d -L 1 shows the file system details from the folder it is executed in. To find the complete file system details, run it from the root / folder:

tree -d -L 1
.
├── bin -> usr/bin
├── bin.usr-is-merged
├── boot
├── dev
├── etc
├── home
├── lib -> usr/lib
├── lib.usr-is-merged
├── lib64 -> usr/lib64
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin -> usr/sbin
├── sbin.usr-is-merged
├── snap
├── srv
├── sys
├── tmp
├── usr
└── var

25 directories

The command output of tree -d -L 1 shows a directory tree structure with the following options:

• -d: Shows only directories (ignores files)

• -L 1: Limits the depth of the tree to one level (only shows the immediate subdirectories)

• df -h: mounted filesystems and usage:

    df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/root        29G  2.6G   26G   9% /
    tmpfs           479M     0  479M   0% /dev/shm
    tmpfs           192M  908K  191M   1% /run
    tmpfs           5.0M     0  5.0M   0% /run/lock
    /dev/xvda16     881M  144M  676M  18% /boot
    /dev/xvda15     105M  6.1M   99M   6% /boot/efi
    tmpfs            96M   12K   96M   1% /run/user/1000
  

  The above output from the df -h command shows the following disk space usage information:

  • Filesystem: The name of the mounted filesystem/device.

  • Size: Total size of the filesystem.

  • Used: Amount of space used.

  • Avail: Amount of space available.

  • Use%: Percentage of space used.

  • Mounted on: The mount point where the filesystem is attached

lsblk Command

lsblk stands for ‘list block devices’ and shows information about all available block devices like hard drives, SSDs, and so on.

lsblk
NAME     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0      7:0    0 26.3M  1 loop /snap/amazon-ssm-agent/9881
loop1      7:1    0 73.9M  1 loop /snap/core22/1748
loop2      7:2    0 44.4M  1 loop /snap/snapd/23545
loop3      7:3    0 50.9M  1 loop /snap/snapd/24505
loop4      7:4    0 73.9M  1 loop /snap/core22/1963
loop5      7:5    0 27.2M  1 loop /snap/amazon-ssm-agent/11320
xvda     202:0    0   30G  0 disk 
├─xvda1  202:1    0   29G  0 part /
├─xvda14 202:14   0    4M  0 part 
├─xvda15 202:15   0  106M  0 part /boot/efi
└─xvda16 259:0    0  913M  0 part /boot

The output above shows the following details:

• NAME: Device name.

• MAJ:MIN: Major and minor device numbers.

• RM: Removable flag (1 for removable, 0 for fixed).

• SIZE: Device size.

• RO: Read-only flag (1 for read-only, 0 for read-write).

• TYPE: Device type (disk, part for partition, loop for loop device).

• MOUNTPOINTS: Where the device is mounted.

fdisk -l Command

fdisk -l shows all disk devices and their partitions on your system:

Disk /dev/xvda: 30 GiB, 32212254720 bytes, 62914560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E3478E01-32E3-4FC2-8E79-1BCCDE89C2D7

Device        Start      End  Sectors  Size Type
/dev/xvda1  2099200 62914526 60815327   29G Linux filesystem
/dev/xvda14    2048    10239     8192    4M BIOS boot
/dev/xvda15   10240   227327   217088  106M EFI System
/dev/xvda16  227328  2097152  1869825  913M Linux extended boot

The above output shows the partition information for the the main system disk (/dev/xvda) which is 30 GiB in size and has four partitions:

• /dev/xvda1: 29G Linux filesystem (main system partition).

• /dev/xvda14: 4M BIOS boot partition.

• /dev/xvda15: 106M EFI System partition (for UEFI boot).

• /dev/xvda16: 913M Linux extended boot partition.

mount Command

mount shows all currently mounted filesystems in the format: device/source "on" mount_point "type" filesystem_type (mount_options), displaying where and how each filesystem is attached to your system's directory tree.

Here is an example line from the output of mount:

/dev/xvda1 on / type ext4 (rw,relatime,discard,errors=remount-ro,commit=30)

Some common mount options you’ll see are:

• rw: Read-write access.

• ro: Read-only access.

• nosuid: Disable SUID/SGID bits.

• nodev: Prevent device file interpretation.

• noexec: Prevent execution of binaries.

• relatime: Update access times relatively.

du -sh * Command

du -sh * provides a summary of the disk usage for each file and directory in the current directory (good for finding disk hogs):

du -sh *
4.0K    file1.txt
8.0K    file2.txt
12K     directory1
20K     directory2

How to Get Your Hardware Information in Linux

lshw Command

The lshw command provides detailed information about the computer's hardware configuration. It can report:

• Memory configuration.

• Firmware version.

• Mainboard configuration.

• CPU version and speed.

• Cache configuration.

• Bus speed and more.

It's particularly useful for system administrators and users who need to gather detailed hardware information. The command can output information in various formats including HTML, XML, JSON, or plain text.

Here is a portion of the output from lshw:

*-pci
          description: Host bridge
          product: 440FX - 82441FX PMC [Natoma]
          vendor: Intel Corporation
          physical id: 100
          bus info: pci@0000:00:00.0
          version: 02
          width: 32 bits
          clock: 33MHz
        *-isa
             description: ISA bridge
             product: 82371SB PIIX3 ISA [Natoma/Triton II]
             vendor: Intel Corporation
             physical id: 1
             bus info: pci@0000:00:01.0
             version: 00
             width: 32 bits
             clock: 33MHz
             capabilities: isa bus_master
             configuration: latency=0

lspci Command

lspci displays information about all PCI (Peripheral Component Interconnect) buses and devices connected to your system.

lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)

From the output, we can see that:

• Each line starts with a bus:device.function address (like "00:00.0")

• Following the address is the device class and the specific hardware details:

  • A Host bridge (Intel 440FX), which manages communications between the CPU and other components.

  • An ISA bridge (Intel PIIX3), for legacy device support.

  • An IDE interface for storage devices.

  • An ACPI bridge for power management.

  • A VGA graphics controller (Cirrus Logic).

  • A Xen Platform Device (this suggests you're running in a Xen virtualized environment).

The command is particularly useful for:

• Troubleshooting hardware issues

• Verifying hardware detection

• Finding hardware details for driver installation

• Checking system configuration

How to Get Your Network Interfaces & Status Information in Linux

ip a Command

ip a displays information about all network interfaces on your system:

ip -a
1: lo: <LOOPBACK,UP,LOWER_UP>
- This is the loopback interface (localhost)
- MTU (Maximum Transmission Unit) is 65536 bytes
- IP address: 127.0.0.1/8 (IPv4)
- IPv6 address: ::1/128

2. Network Interface (enX0):
enX0: <BROADCAST,MULTICAST,UP,LOWER_UP>
- This is your main network interface
- MTU is 9001 bytes
- MAC address (link/ether): 12:16:a6:d3:b3:61
- IPv4 address: 172.31.90.178/20
- IPv6 address: fe80::1016:a6ff:fed3:b361/64 (Link-local)

Here are the key elements in the output:

• Interface state (UP/DOWN).

• MAC address (link/ether).

• IPv4 and IPv6 addresses.

• Network scope (host, global, link).

• Address validity lifetime (valid_lft).

• Broadcast address (brd).

ip r Command

ip r shows the system’s routing table:

ip r
default via 172.31.80.1 dev enX0 proto dhcp src 172.31.90.178 metric 100 
172.31.0.2 via 172.31.80.1 dev enX0 proto dhcp src 172.31.90.178 metric 100 
172.31.80.0/20 dev enX0 proto kernel scope link src 172.31.90.178 metric 100 
172.31.80.1 dev enX0 proto dhcp scope link src 172.31.90.178 metric 100

The above ip r output shows my system's routing table with the following routes:

• Default Route (Gateway):

  • Default via 172.31.80.1: All traffic not matching other rules goes through this gateway.

  • Using interface enX0.

  • Configured via DHCP.

  • Source IP: 172.31.90.178.

• Local Network:

  • 172.31.80.0/20: Local subnet (covers IPs from 172.31.80.0 to 172.31.95.255)

  • Directly connected to enX0 interface

  • Kernel-managed route (proto kernel)

  • For packets originating from 172.31.90.178

• DHCP Route:

  • Direct route to DHCP server (172.31.80.1)

  • Via interface enX0

All routes have a metric of 100, which determines route priority (lower values are preferred).

netstat -tuln shows active listening ports:

netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN     
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
udp        0      0 127.0.0.54:53           0.0.0.0:*                          
udp        0      0 127.0.0.53:53           0.0.0.0:*                          
udp        0      0 172.31.90.178:68        0.0.0.0:*                          
udp        0      0 127.0.0.1:323           0.0.0.0:*                          
udp6       0      0 ::1:323                 :::*

How to Get Your Software & Services Information in Linux

Installed packages

You can check installed packages with dpkg -l, apt list --installed (Debian/Ubuntu). Here is a snippet from the output:

vim-common/noble-updates,noble-security,now 2:9.1.0016-1ubuntu7.8 all [installed,automatic]
vim-runtime/noble-updates,noble-security,now 2:9.1.0016-1ubuntu7.8 all [installed,automatic]
vim-tiny/noble-updates,noble-security,now 2:9.1.0016-1ubuntu7.8 amd64 [installed,automatic]
vim/noble-updates,noble-security,now 2:9.1.0016-1ubuntu7.8 amd64 [installed,automatic]

Service status

systemctl list-units --type=service lists the services. You can also use systemctl status <service> and replace <service> with the one you want.

Here’s the output for cron.service:

systemctl status cron.service
● cron.service - Regular background program processing daemon
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-05-14 19:46:58 UTC; 2 weeks 5 days ago
       Docs: man:cron(8)
   Main PID: 625 (cron)
      Tasks: 1 (limit: 1129)
     Memory: 1.7M (peak: 4.7M)
        CPU: 20.890s
     CGroup: /system.slice/cron.service
             └─625 /usr/sbin/cron -f -P

Jun 03 09:25:01 ip-172-31-90-178 CRON[121748]: pam_unix(cron:session): session closed for user root
Jun 03 09:35:01 ip-172-31-90-178 CRON[121817]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jun 03 09:35:01 ip-172-31-90-178 CRON[121818]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 03 09:35:01 ip-172-31-90-178 CRON[121817]: pam_unix(cron:session): session closed for user root
Jun 03 09:45:01 ip-172-31-90-178 CRON[122050]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jun 03 09:45:01 ip-172-31-90-178 CRON[122051]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 03 09:45:01 ip-172-31-90-178 CRON[122050]: pam_unix(cron:session): session closed for user root
Jun 03 09:55:01 ip-172-31-90-178 CRON[122318]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jun 03 09:55:01 ip-172-31-90-178 CRON[122319]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 03 09:55:01 ip-172-31-90-178 CRON[122318]: pam_unix(cron:session): session closed for user root
lines 5-21/21 (END)

Processes

ps aux shows all processes with their respective status:

ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  1.4  22556 13952 ?        Ss   May14   0:35 /usr/lib/systemd/systemd --system --deserialize=63
root           2  0.0  0.0      0     0 ?        S    May14   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        S    May14   0:00 [pool_workqueue_release]
root           4  0.0  0.0      0     0 ?        I<   May14   0:00 [kworker/R-rcu_g]
root           5  0.0  0.0      0     0 ?        I<   May14   0:00 [kworker/R-rcu_p]
root           6  0.0  0.0      0     0 ?        I<   May14   0:00 [kworker/R-slub_]
.
.
.

Here's an explanation of each column in the ps aux output:

• USER: The owner of the process

• PID: Process ID number

• %CPU: CPU usage percentage

• %MEM: Memory usage percentage

• VSZ: Virtual Memory Size in kilobytes (total program size)

• RSS: Resident Set Size in kilobytes (actual memory used)

• TTY: Terminal associated with the process ('?' means no terminal)

• STAT: Process state code:

  • S: Sleeping

  • R: Running

  • I: Idle

  • Z: Zombie

  • T: Stopped

  • s: Session leader

  • <: High priority

  • N: Low priority

• START: Time when the process started

• TIME: Cumulative CPU time used

• COMMAND: The command with all its arguments

top and htop Commands

top or htop can be used for live usage overview, and for showing a dynamic view of system performance and running processes. Here's what it displays:

• System Overview:

  • System uptime and number of logged-in users.

  • Load average values for the last 1, 5, and 15 minutes.

  • Total number of processes and their states (running, sleeping, stopped, zombie)

• Resource Usage:

  • CPU usage breakdown (user, system, idle, etc.).

  • Memory usage (total, free, used, cached).

  • Swap space usage

  • Process List:Shows a sorted list of running processes (by default sorted by CPU usage)For each process, displays:

    • Process ID (PID).

    • User who owns the process.

    • CPU and memory usage.

    • Process priority and nice value.

    • Memory usage details (virtual, resident, shared).

    • Process status.

    • Running time.

    • Command name.

    top - 10:04:25 up 19 days, 14:17,  1 user,  load average: 0.00, 0.00, 0.00
    Tasks: 104 total,   1 running, 103 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni, 88.0 id,  0.0 wa,  0.0 hi,  0.0 si, 12.0 st 
    MiB Mem :    957.4 total,    247.3 free,    366.1 used,    533.7 buff/cache     
    MiB Swap:      0.0 total,      0.0 free,      0.0 used.    591.3 avail Mem 

        PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                              
          1 root      20   0   22556  13952   9728 S   0.0   1.4   0:35.08 systemd                                              
          2 root      20   0       0      0      0 S   0.0   0.0   0:00.16 kthreadd                                             
          3 root      20   0       0      0      0 S   0.0   0.0   0:00.00 pool_workqueue_release                               
          4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_g                                      
          5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_p                                      
          6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-slub_                                      
          7 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-netns                                      
         10 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/0:0H-events_highpri                          
         12 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-mm_pe                                      
         13 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_rude_kthread                               
         14 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_tasks_trace_kthread

The top command updates this information regularly (by default every 3 seconds) and is commonly used for:

• Monitoring system performance

• Identifying resource-intensive processes

• Troubleshooting system slowdowns

• Getting a quick overview of system health

  You can also interact with top while it's running using various keyboard commands (like 'k' to kill a process, '1' to see cpu cores, etc.).

How to Get Your Logs & Dmesg In formation in Linux

Based on the system configuration, a number of logs are generated. These can be audit logs, system logs, cron logs, and so on. They all carry useful information. Here are some commands that you can use to view logs:

• dmesg | less: Kernel ring buffer (hardware issues, boot messages)

• journalctl -xe: Recent critical logs (systemd systems)

• /var/log/syslog or /var/log/messages: General system logs

How to Get Your Security/User Audit Information in Linux

whoami shows the current user’s username.

whoami
ubuntu

id shows detailed information about a user's identity on the system.

id
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),4(adm),24(cdrom),27(sudo),30(dip),105(lxd)

Let's break down the output:

• User ID (uid): uid=1000(ubuntu) means the user ID is 1000, with username "ubuntu"

• Primary Group ID (gid): gid=1000(ubuntu) means the primary group ID is 1000, named "ubuntu"

• Supplementary Groups (groups): The user belong to the following groups:

  • ubuntu (1000): Your primary group.

  • adm (4): For system monitoring tasks.

  • cdrom (24): For accessing CD-ROM devices.

  • sudo (27): Allows you to execute commands with superuser privileges.

  • dip (30): For managing dial-up connections.

  • lxd (105): For managing LXD containers.

The id command is useful for checking user and group IDs, verifying group memberships, troubleshooting permissions issues and confirming sudo access.

who displays information about users currently logged into the system:

who
ubuntu   pts/0        2025-06-03 08:45 (39.43.159.5)

The output breakdown is shown below:

• Username: "ubuntu"

• Terminal: "pts/0" (pseudo-terminal)

• Login time: "2025-06-03 08:45"

• Remote host: "(39.43.159.5)" - the IP address from where the connection was made

• w- shows who is logged in and what they are doing:

w
 10:21:46 up 19 days, 14:35,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
ubuntu   pts/0    39.43.159.5      08:45   44:56   0.00s  0.02s sshd: ubuntu [priv]

Here is the result breakdown:

First line:

• 10:21:46: Current system time

• up 19 days, 14:35: System uptime (how long the system has been running)

• 1 user: Number of users currently logged in

• load average: 0.24, 0.05, 0.02: System load averages for the past 1, 5, and 15 minutes

  • Numbers below 1.0 indicate low system load

  • Higher numbers indicate more system load/stress

Second line shows the column headers for the user information below:

• USER: Username.

• TTY: Terminal device being used.

• FROM: Remote host from where the user is connected.

• LOGIN@: Time when the user logged in.

• IDLE: Time since the user's last activity.

• JCPU: CPU time used by all processes attached to the tty.

• PCPU: CPU time used by the current process.

• WHAT: Current process/command being run.

last shows a history of user logins and system reboots:

last
ubuntu   pts/1        39.43.159.5      Tue Jun  3 10:15 - 10:17  (00:02)
ubuntu   pts/0        39.43.159.5      Tue Jun  3 08:45   still logged in
ubuntu   pts/0        39.43.159.5      Tue Jun  3 05:23 - 08:29  (03:06)
ubuntu   pts/0        39.43.159.5      Sun Jun  1 06:32 - 12:24  (05:52)
ubuntu   pts/0        39.43.159.5      Thu May 22 05:39 - 05:58  (00:18)
ubuntu   pts/0        139.135.32.93    Wed May 21 14:45 - 14:47  (00:01)
ubuntu   pts/0        139.135.32.93    Wed May 21 11:58 - 13:49  (01:51)
ubuntu   pts/0        39.43.159.5      Wed May 21 05:05 - 05:12  (00:06)
ubuntu   pts/0        39.43.159.5      Tue May 20 18:41 - 21:45  (03:04)
ubuntu   pts/0        39.43.159.5      Thu May 15 06:12 - 06:12  (00:00)
ubuntu   pts/0        39.43.159.5      Thu May 15 06:05 - 06:12  (00:07)
ubuntu   pts/0        18.206.107.27    Wed May 14 20:06 - 20:08  (00:01)
ubuntu   pts/0        182.185.185.39   Wed May 14 19:48 - 19:50  (00:01)
reboot   system boot  6.8.0-1024-aws   Wed May 14 19:46   still running

wtmp begins Wed May 14 19:46:47 2025

Each line shows:

• Username (in this case, all logins are from 'ubuntu' user).

• Terminal device (pts/0 indicates a pseudo-terminal, typically used for SSH connections).

• Remote host IP address (where the connection came from).

• Login time and date.

• Logout time or status.

• Session duration in parentheses.

sudo -l shows what the current user can do with sudo.

sudo -l
Matching Defaults entries for ubuntu on ip-172-31-90-178:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
    use_pty

User ubuntu may run the following commands on ip-172-31-90-178:
    (ALL : ALL) ALL
    (ALL) NOPASSWD: ALL

This output indicates that the 'ubuntu' user has:

• Full sudo access (can execute any command)

• No password requirement for sudo commands

• Complete administrative privileges on the system

Visually Appealing Commands

In this section you’ll learn about two commands that display the information we have seen before in a presentable and aesthetic form.

neofetch - displays system info along with the distribution logo:

btop displays dynamic stats with different modes:

Conclusion

Thank you for reading the article until the end. If you found it helpful, consider sharing it with others.

Stay Connected and Continue Your Learning Journey!

I read every message, come say hi 👋

1. Connect with me on:

   • LinkedIn: I share content related to Linux, Cyber security and DevOps. Leave a recommendation on LinkedIn and endorse me on relevant skills.

   • Discord community: Hang around with other devs or share your accomplishments.

   • X: I share pre-launch updates and some behind the scenes.

2. Get access to exclusive content: For one-on-one help and exclusive content go here.

My articles are part of my mission to increase accessibility to quality content for everyone. Each piece takes a lot of time and effort to write. This article will be free, forever. If you've enjoyed my work and want to keep me motivated, consider buying me a coffee.

Thank you once again and happy learning!

You can use Wireshark in scenarios like troubleshooting network performance issues (for example, slow connections or dropped packets), investigating suspicious activity (like detecting malware or unauthorized access), or learning how protocols like HTTP, TCP, or DNS function in real-world environments.

For beginners, think of it as a window into the invisible world of network communication, revealing what’s happening behind the scenes when you browse the web, send an email, or stream a video. Its power lies in its ability to provide granular insights, making it an indispensable tool for network administrators, cybersecurity enthusiasts, and anyone curious about how networks operate.

In this tutorial, you will learn how to use Wireshark display filters to analyze network traffic and spot potential security threats. Wireshark is a powerful network protocol analyzer that can capture and dissect network packets, which is crucial for cybersecurity professionals.

Here’s what we’ll cover:

• How to Start Wireshark and Analyze Network Traffic

• How to Work with Network Capture Files

• Understanding the Wireshark Interface

• Understanding and Applying Basic Display Filters

• Advanced Filtering Techniques

• Analyzing Security-Related Traffic

• Analyzing Sample Traffic and Generating New Traffic

Prerequisites

Before we start, you'll need to know Linux Basic Syntax. You can learn it through this Linux Skill Tree.

Don't worry if you're new to Wireshark – I’ll explain everything as we go.

How to Start Wireshark and Analyze Network Traffic

In this step, we're going to start using Wireshark. First, you'll learn how to launch it. Then, you'll either capture network traffic or use a provided sample file for analysis. Understanding the Wireshark interface is crucial, as it helps you view and analyze packet data.

Installing Wireshark on Ubuntu 22.04

Before you can start using Wireshark, you need to install it. Open a terminal window and run the following commands:

sudo apt update
sudo apt install wireshark -y

Launching Wireshark

To start Wireshark, you need to open a terminal window. You can do this by clicking on the terminal icon in the taskbar or by pressing Ctrl+Alt+T. Once the terminal is open, you'll use a command to start Wireshark. In the terminal, type the following command and press Enter:

wireshark

This command tells your system to start the Wireshark application. After a few seconds, Wireshark will open. You should see a window similar to the one shown below:

How to Work with Network Capture Files

For this part of the tutorial, you have two options:

Option 1: Use the Provided Sample File

# Download a sample packet capture file with mixed traffic
wget -q https://s3.amazonaws.com/tcpreplay-pcap-files/smallFlows.pcap -O /home/labex/project/sample.pcapng

# Make sure the user has access to the file
chmod 644 /home/labex/project/sample.pcapng

I’ve prepared a sample capture file for you at /home/labex/project/sample.pcapng. This file contains a variety of network traffic that you can analyze.

To open this file:

1. In Wireshark, go to File > Open

2. Navigate to /home/labex/project/sample.pcapng

3. Click "Open"

The file will load in Wireshark, showing various packets that have been captured previously.

Option 2: Capture Your Own Traffic

If you prefer to capture your own traffic:

1. In the Wireshark main window, look for the list of available network interfaces.

2. Find the eth1 interface. In this lab environment, eth1 is the main network interface we'll use for capturing packets.

3. Double-click on eth1. This action immediately starts the packet capture process.

4. Generate some network traffic by opening a new terminal and running:

    curl www.google.com
   

5. Once you've captured enough packets (aim for at least 20-30 packets), click the red square "Stop" button in the Wireshark toolbar.

Understanding the Wireshark Interface

The Wireshark interface is divided into three main panels, each with a specific purpose:

1. Packet List (top panel): This panel shows all the packets that have been captured in the order they were received. It gives you a quick overview of the captured traffic.

2. Packet Details (middle panel): When you select a packet in the top panel, this middle panel shows the details of that packet in a hierarchical format. It breaks down the packet's structure, showing information like the source and destination IP addresses, protocol types, and more.

3. Packet Bytes (bottom panel): This panel displays the raw bytes of the selected packet in hexadecimal format. It's useful for in-depth analysis, especially when you need to look at the exact data being transmitted.

To see how these panels work together, click on different packets in the top panel. You'll see the corresponding details and raw bytes update in the middle and bottom panels.

Understanding and Applying Basic Display Filters

In this step, we're going to explore display filters in Wireshark. Display filters are essential tools when it comes to analyzing network traffic. They help you focus on specific types of packets instead of having to sift through all the captured data.

By the end of this section, you'll know what display filters are, why they're useful, and how to apply basic ones to isolate specific types of network traffic.

What Are Display Filters?

When you're analyzing network traffic, looking at every single captured packet can be overwhelming. You usually want to focus on specific types of packets. That's where Wireshark display filters come in. They allow you to show only the packets that meet certain criteria. This makes the analysis process much more efficient because you're not wasting time on irrelevant data.

Display filters in Wireshark use a special syntax. This syntax enables you to filter packets based on various attributes such as protocols, IP addresses, ports, and even the content of the packets. Understanding this syntax is key to effectively using display filters.

Filter Toolbar

Take a look at the top of the Wireshark window. You'll notice a text field. It might be labeled "Apply a display filter..." or simply show "Expression...". This is the place where you'll enter your display filters. Once you enter a filter and press Enter, Wireshark will use that filter to show only the relevant packets.

Basic Protocol Filters

Let's start with a simple example. Suppose you want to view only HTTP traffic. HTTP is the protocol used for web browsing. To do this, you'll enter a filter in the filter toolbar. Type the following filter and then press Enter:

http

After you apply this filter, Wireshark will only display HTTP packets. All other packets will be temporarily hidden. You'll notice that the filter bar turns green when you apply a valid filter. This is a visual indication that your filter is working correctly.

The output should now show only packets related to HTTP traffic. This typically includes web requests (when you ask a website for information) and responses (when the website sends you the information). If you don't see any HTTP traffic in the sample file, you can try different protocols that might be present, such as TCP, UDP, or DNS:

tcp

Or try generating more HTTP traffic by running the curl command in a terminal:

curl www.google.com

IP Address Filters

Next, let's filter traffic based on IP addresses. An IP address is like a unique identifier for a device on a network. First, look at your packet list. You'll see columns labeled "Source" and "Destination". These columns show the IP addresses of the devices sending and receiving the packets.

Once you've identified an IP address that appears frequently in your capture (for example, let's say you see 192.168.1.1), you can use it to create a filter. Type the following filter in the filter toolbar to see only packets from that source:

ip.src == 192.168.3.131

You can replace 192.168.3.131 with an IP address that you actually see in your capture. After applying this filter, only packets with that source IP address will be shown.

If you want to see all the packets again, you can clear the current filter. Just click the "Clear" button (X) on the right side of the filter bar.

Port Filters

Many network services operate on specific ports. A port is like a door on a device that allows specific types of network traffic to enter or leave. For example, HTTP typically uses port 80.

To filter packets by port number, you can use the following filter:

tcp.port == 80

This filter will show both incoming and outgoing packets that use TCP port 80. You might also try other common ports like 443 (HTTPS) or 53 (DNS) depending on what's available in your capture.

Combining Filters

You can make your filters more powerful by combining them using logical operators like and and or. For example, if you want to show only HTTP traffic that uses port 80, you can use the following filter:

http and tcp.port == 80

Try applying different combinations of filters and observe how the displayed packets change. Remember, before trying a new filter, you can either clear the previous one by clicking the "Clear" button or modify the existing filter directly in the filter bar to build upon it.

Advanced Filtering Techniques

In this part, we'll explore how to create more sophisticated filters for detailed network traffic analysis. As a beginner, you might wonder why we need advanced filtering. Well, in real-world scenarios, network capture files can be extremely large, filled with all kinds of traffic. Advanced filtering techniques are like a powerful magnifying glass for security professionals. They help us quickly pick out the suspicious or important traffic from the sea of data in these large capture files.

Complex Filters with Multiple Conditions

Wireshark gives you the ability to build complex filters by combining multiple conditions. This is very useful when you want to be more precise in your traffic analysis. Let's start by creating a filter to find HTTP GET requests.

http.request.method == "GET"

This filter is designed to display only HTTP packets that contain GET requests. When you apply this filter, you'll see packets that are requests sent to web servers. The reason we use this filter is that GET requests are a common type of HTTP request used to retrieve data from a server. By isolating these requests, we can focus on the data retrieval activities in the network.

If your sample file doesn't contain HTTP GET requests, try this alternative filter to find TCP SYN packets which indicate connection attempts:

tcp.flags.syn == 1

Now, let's make our filter more specific. We'll add a port condition:

tcp.port == 80 and http.request.method == "GET"

This new filter shows only HTTP GET requests that occur on the standard HTTP port (80). The standard HTTP port is widely used for unencrypted web traffic. By adding this port condition, we're narrowing down our search to only those GET requests that are using the typical HTTP communication channel.

Filtering Based on Packet Size

Network attacks often involve packets with unusual sizes. Attackers might use large or small packets to hide malicious data or to disrupt the normal functioning of the network. To filter based on packet size, we use a specific syntax:

tcp.len >= 100 and tcp.len <= 500

This filter displays TCP packets with a payload length between 100 and 500 bytes. You can adjust these values according to your needs. For example, if you suspect that an attack involves larger packets, you can increase the upper limit. By filtering based on packet size, we can identify abnormal traffic patterns that might indicate an attack.

Filtering Based on Specific Content

You can also filter traffic based on specific content within packets. This is very useful when you're looking for traffic related to a particular website or service. For example, let's find HTTP traffic related to a specific website.

http.host contains "google"

This filter shows only HTTP traffic where the host header contains "google". You can replace "google" with any domain you're interested in analyzing. The host header in an HTTP request tells the server which website the client is trying to access. By filtering based on the host header, we can focus on the traffic related to a specific domain.

If your sample file doesn't have HTTP traffic with host headers, try this more general content filter:

frame contains "http"

Using the "contains" Operator for Text Searching

The contains operator is a handy tool for searching for specific text strings in packets. It allows us to look for certain keywords within the packet data.

frame contains "password"

This filter shows packets containing the word "password" anywhere in the packet data. This can be very helpful for detecting possible security issues. For example, if passwords are being sent in clear text (which is a big security risk), this filter can help us spot those packets.

Or try this filter:

frame contains "login"

Negating Filters

Sometimes, you might want to see all the traffic except for certain types. That's where the not operator comes in.

not arp

This filter hides all ARP packets. ARP (Address Resolution Protocol) is used to map IP addresses to MAC addresses in a local network. Sometimes, ARP traffic can be very common and might clutter your analysis. By using the not operator, you can exclude this type of traffic and focus on other more relevant packets.

Saving and Applying Filter Bookmarks

If you find yourself using certain filters frequently, you don't have to type them in every time. You can save them as bookmarks. Here's how:

1. Enter a filter in the filter bar. This is where you type in the filter expressions we've been learning about.

2. Click the "+" button on the right side of the filter bar. This button is used to save the current filter as a bookmark.

3. Give your filter a name and click "OK". Naming the filter makes it easy to identify later.

Once you've saved your filter, you can apply it by clicking on its name in the filter dropdown menu. This saves you time and effort, especially when you're doing repeated analysis.

Exporting Filtered Packets

After you've filtered your traffic to show only the packets of interest, you might want to save just these packets to a new file. This is useful for sharing specific findings with colleagues or for further analysis. Here's how you do it:

1. Apply your desired filter. Make sure you've set up the filter to show only the packets you want to save.

2. Click on File > Export Specified Packets. This option allows you to export a specific set of packets.

3. Make sure "Displayed" is selected in the Packet Range section. This ensures that only the packets that are currently visible (that is, the ones that match your filter) are exported.

4. Choose a filename and location. This is where you decide where to save the new capture file and what to name it.

5. Click "Save". This creates a new capture file containing only the packets that matched your filter.

Analyzing Security-Related Traffic

In this step, we're going to focus on using Wireshark filters for security analysis. Security analysis is crucial in the world of cybersecurity as it helps us spot potentially malicious activities in network traffic. By the end of this section, you'll be able to identify various types of security threats using specific Wireshark filters.

Identifying Port Scanning Activities

Port scanning is a common technique used by attackers to gather information about a target system. Attackers use it to find open ports on a network, which they can then exploit.

To detect potential port scanning, we look for a large number of connection attempts from a single source to multiple ports.

Let's use a specific filter to identify such activities. Try this filter in Wireshark:

tcp.flags.syn == 1 and tcp.flags.ack == 0

This filter shows SYN packets without the ACK flag. In a TCP connection, the SYN packet is the first one sent to initiate a connection, and the ACK packet is used to acknowledge the connection. When we see a lot of SYN packets without ACK from one source to different destination ports, it's a strong indication of port scanning.

Detecting Suspicious DNS Traffic

DNS tunneling and other DNS-based attacks are becoming more common. These attacks use the DNS protocol to hide malicious activities, such as data exfiltration or command and control communication. To detect such attacks, we need to look for unusual DNS traffic.

Use this filter to examine DNS queries:

dns

Once you apply this filter, look for unusually long domain names or a high volume of DNS requests to the same domain. These could be signs of data exfiltration or command and control communication.

Identifying Password Brute Force Attempts

Password brute force attacks are a common way for attackers to gain unauthorized access to services like SSH or FTP. In a brute force attack, the attacker tries multiple password combinations until they find the correct one.

To detect potential brute force password attempts, we can filter for failed login attempts. Use this filter:

ftp contains "530" or ssh contains "Failed"

This filter shows FTP and SSH packets that contain common failure response messages. If you see multiple failures from the same source, it may indicate a brute force attempt.

Analyzing HTTP Error Responses

Web application attacks often generate HTTP error responses. Attackers may try to exploit vulnerabilities in web applications, and these attempts can result in error responses from the server.

Filter for these error responses with:

http.response.code >= 400

This filter shows HTTP response packets with status codes of 400 or higher. All these status codes represent error responses. By examining these packets, we can identify attempted web exploits.

Finding Clear-Text Credentials

Transmitting credentials in clear text is a major security risk. If an attacker intercepts these credentials, they can gain unauthorized access to the system.

To detect clear-text credentials, use this filter:

http contains "user" or http contains "pass" or http contains "login"

This filter helps us find HTTP traffic that might contain login information. Carefully examine the packets that match this filter to identify potential security risks.

Analyzing Sample Traffic and Generating New Traffic

Now that you've learned various security-focused filters, it's time to put your knowledge into practice. You can either analyze the provided sample file or generate and analyze new traffic.

Analyzing the Sample File

If you're using the provided sample file (/home/labex/project/sample.pcapng), try applying some of the security filters we've discussed to identify any interesting patterns:

tcp.flags.syn == 1 and tcp.flags.ack == 0

Look for patterns that might indicate scanning, suspicious connections, or other security concerns.

Generating and Analyzing New Traffic

Alternatively, open a new terminal window. In this window, we'll generate some HTTP traffic with multiple requests. Run the following commands:

for i in {1..5}; do
  curl -I www.google.com
  sleep 1
done

These commands send five HTTP HEAD requests to www.google.com with a one-second interval between each request.

Next, go to Wireshark and apply this filter to find all HTTP requests:

http.request

This filter will show all the HTTP requests in the captured traffic.

Look through these packets to identify patterns of normal HTTP traffic. Notice the headers, the frequency of requests, and other details.

Finally, try to create a filter that can distinguish normal HTTP browsing from automated scanning tools. For example:

http.request and !(http.user_agent contains "Mozilla")

This filter shows HTTP requests that don't have browser user agents. Since most normal web browsing is done using browsers with Mozilla in the user agent, requests without it might indicate automated tools rather than normal browsing.

By practicing these security-focused filtering techniques, you'll develop the skills needed to quickly identify suspicious traffic in real-world network captures.

Conclusion

In this tutorial, you have learned how to use Wireshark display filters for network traffic analysis and potential security threat identification.

You began by either working with a provided sample capture file or capturing live network traffic and familiarizing yourself with the Wireshark interface. Then, you mastered basic display filters to isolate specific traffic types according to protocols, IP addresses, and ports. You also advanced your skills with complex filtering techniques, combining multiple conditions and searching for specific content. Finally, you applied these skills in security analysis scenarios to detect suspicious activities such as port scanning, credential exposure, and potential attacks.

These Wireshark filtering skills are crucial for efficient network troubleshooting and security analysis. By quickly isolating relevant packets from large captures, you can greatly reduce the time required to identify and respond to network issues and security incidents.

As you keep practicing with Wireshark, you will gain an intuitive understanding of network protocols and traffic patterns, enhancing your overall cybersecurity capabilities.

To practice the operations from this tutorial, try the interactive hands-on lab: Analyze Network Traffic with Wireshark Display Filters

Managing users in RHEL is kind of like that. You decide who gets in, what they can do, and how much control they have. Without proper management, things can get messy fast—like that friend who somehow DJs when no one asks.

So, let’s dive into user management and ensure your Linux system stays organized, secure, and drama-free! 🚀

Table Of Contents

1. What is a User in Linux?

   • Understanding sudo in User Management

2. User Management Commands in Linux

   • How to Add a User

   • How to Check if a User is Created

   • How to Assign a Password

   • How to Switch Users

   • Understanding Groups in Linux

   • How to Modify Users

3. Final Words

What is a User in Linux?

A user in Linux is an account that allows someone (or a process) to interact with the system. Since Linux is a multi-user operating system, multiple users can exist on the same system, each with their own settings, files, and permissions. Users can have different levels of permissions, which determine what they can access or modify on the system.

Linux categorizes users into three main types based on their roles and privileges:

1. Privileged Users: These users have unrestricted access to the entire system. They have the highest level of permissions and can perform any operation on the system. They can install/remove software, modify system files, create/manage users, and even delete everything. These users are also called root users.

2. System Users: The system creates these users to run background processes or services. They can’t login like a normal user. Their sole purpose is to manage system operations like databases, web servers and scheduled tasks.

3. Normal Users: These are the everyday users created by administrators or during system installation. They have their home directory and can store personal files and settings. They can’t modify system files but can execute tasks within their permission scope.

Understanding sudo in User Management

The sudo (Superuser Do) command allows a regular user to execute administrative tasks with elevated privileges. Since user management tasks—such as adding, modifying, or deleting users—require root access, normal users must use sudo before these commands.

Note that the following commands are executed as the root user. If you are using a normal user account, you must prefix them with sudo to perform user management tasks.

Now let’s see how we manage users on RHEL.

User Management Commands in Linux

How to add a user

To create a new user account, use following command:

Syntax:

useradd [user_name]

Example:

useradd Tanishka # Root user
sudo useradd Tanishka # Normal user

Once you create a user, you can verify its existence in the /etc/passwd file. This file stores essential user account information (but not passwords, despite the name).

How to check if a user is created

To confirm the user entry in /etc/passwd, use one of the following methods:

1. View the file using cat or grep

cat /etc/passwd # Displays entire file content
grep Tanishka /etc/passwd # Displays information about Tanishka user only

2. Use id command:

The id command is used to display a user’s UID (User ID), GID (Group ID), and the groups they belong to. It helps in verifying user information and checking permissions.

id Tanishka
# Displays user id of Tanishka,
# hence verifying user has been created

Let’s understand what’s going on in the /etc/password fields. Each line in /etc/passwd represents a user account and contains seven fields separated by colons (:):

username:x:UID:GID:comment:home_directory:shell

How to Assign a Password

Once an account is created, it’s essential to assign a password to the account. Otherwise, that account can’t be logged in through a GUI login interface. To give a password to a user account, user this command:

Syntax:

passwd [user_name]

Example:

passwd Tanishka

You will be prompted to enter the password. Enter the password and you’re all set! Even though user information is stored in /etc/passwd file, actual information about the password is stored in the /etc/shadow file (weird, I know…).

To see the content of the /etc/shadow file, use this command:

cat /etc/shadow

Each line in /etc/shadow represents a user account password and contains nine fields separated by colons (:):

username:password:lastchg:min:max:warn:inactive:expire:reserved

To change password aging information, you use the chage (short for change age) command like this:

Syntax:

chage [OPTIONS] [user_name]

Example:

chage -l tanishka # Lists the current password aging information
chage -m 10 tanishka # Sets the minimum days to change password
chage -M 10 tanishka # Sets the maximum days password must be changed
chage -W 7 tanishka # Sets the number of days before the password expires that the user will be warned to change the password
chage -I 10 tanishka # Sets the number of days after password expiration that the account will be disabled if not logged in
chage -E 2025-12-31 tanishka # Sets the date when the user account will expire 
chage -d 2024-12-25 tanishka # Sets the last password change date

Now that you have learned to create users and assign passwords, you need to know how to switch between users. Let’s see that now.

How to Switch Users

The su (Substitute User) command allows you to switch from one user to another without logging out of the current session.

Syntax:

su - [user_name]

Example:

su - Tanishka # Switches to Tanishka user

• su stands for "substitute user" (or "switch user").

• The - (hyphen) loads the target user's full environment, including their shell, path, and profile settings (similar to logging in as that user).

• If no username is provided, it switches to the root user by default.

To return to original or root user, simply enter ‘exit’.

Understanding Groups in Linux

Just like a party where guests can belong to different social circles, Linux groups allow users to be part of different permission levels. Groups help manage file access, system privileges, and administrative controls efficiently.

Linux has two types of groups:

1. Primary Group:

• Every user has one primary group.

• When a user creates a new file, it belongs to their primary group.

• It is usually named the same as the username.

2. Secondary Groups:

• A user can belong to multiple secondary groups.

• These groups provide additional permissions beyond the primary group.

• Users can be assigned to various secondary groups to access shared resources.

To check a user’s group membership:

id [user_name]

This displays the user’s UID, primary group (GID), and any secondary groups they belong to.

To add a new group:

groupadd [group_name]

How to Modify a User

Sometimes, you might need to update user details, such as changing usernames, user IDs, group memberships, home directories, or login shells. You use the usermod command to modify existing user accounts while preserving their files and configurations.

Syntax:

usermod [OPTIONS] [user_name]

Let’s break down the different options available for modifying user accounts.

1. Change the username

If you want to rename an existing user, use the -l option:

Syntax:

usermod -l new_username old_username

Example:

usermod -l tanishkamakode tanishka

This renames tanishka to tanishkamakode. Just keep in mind that the home directory remains the same (/home/tanishka), so you might need to rename it manually.

To rename the home directory as well, use:

mv /home/tanishka /home/tanishkamakode

2. Change the user id:

Each user has a unique User ID (UID). If you need to change it, use -u.

Syntax:

usermod -u new_UID user_name

Example:

usermod -u 2001 tanishka

This changes tanishka's UID to 2001. Before you do this, you’ll want to make sure that no other user has the same UID. This is important.

If the user owns files under the old UID, you should update them after changing the UID.

3. Change the primary group

Every user belongs to a primary group. To change it, use -g.

Syntax:

usermod -g new_group user_name

Example:

usermod -g developers tanishka

This changes tanishka's primary group to developers. Just keep in mind that usermod -g developers tanishka removes the user from all secondary groups. To avoid that, just make sure you check and re-add secondary groups as needed.

Also, the group must exist beforehand. To create a group, run this command:

Syntax:

groupadd [group_name]

Example:

groupadd developers

Now, to check tanishka’s group, do the following:

id tanishka

4. Add to a secondary group

A user can belong to multiple secondary groups. Use -G to assign them.

Syntax:

usermod -G group1,group2 user_name

Example:

usermod -G linux,docker tanishka

This adds tanishka to the sudo and docker groups. Just keep in mind that this replaces any existing secondary groups that the user might already belong to. To add groups without removing the current ones, use -aG (append to groups) like this:

usermod -aG linux,docker tanishka

5. Change the home directory:

You can change a user’s default home directory using -d.

Syntax:

usermod -d /new/home_directory user_name

Example:

usermod -d /home/tani tanishka

This sets tanishka's home directory to /home/tani, but it does not move existing files. To move them, add the -m option:

usermod -d /home/tani -m tanishka

After moving the home directory, just make sure you’ve updated file ownership.

6. Change the login shell:

The default shell for a user can be changed using -s.

Syntax:

usermod -s /new/shell user_name

Example:

usermod -s /bin/zsh tanishka

This changes tanishka's default shell to zsh. Common shells include:

• /bin/bash (default)

• /bin/sh

• /bin/zsh

• /usr/sbin/nologin (to disable login)

With usermod, you can fine-tune user settings to match system requirements. Always check changes using:

id tanishka
grep tanishka /etc/passwd

Final Words

In this article, we explored the fundamentals of user management in RHEL, a crucial aspect of system administration. We started with creating and managing users, then moved on to handling groups.

If you're new to Linux and want to build a strong foundation, check out my first tutorial on Basic Linux Commands, where I cover essential commands every beginner should know. You can also read my second tutorial on Vim to learn how to navigate and edit text efficiently in this powerful editor. These articles will complement what you’ve learned about user management here.

Keep practicing these commands, and soon they’ll become second nature to you. Mastery comes with repetition, so continue experimenting and applying these fundamentals in real-world scenarios.

Stay tuned for more articles. Get ready to take your RHEL skills to the next level.

Let’s connect!

For devs, text editors are the ultimate multitools, shaping how we create, manage, and transform raw data into meaningful output.

While modern editors like VS Code and Sublime Text have gained popularity for their sleek interfaces, there’s something timeless about the simplicity and power of classic tools.

Loved by some and feared by others, Vim is a text editor that has stood the test of time. Born from its predecessor Vi, Vim (Vi Improved) offers unparalleled speed, versatility, and control.

In this tutorial, you’ll learn what makes Vim so special. We’ll explore its commands, text filtering, and string manipulation capabilities to help you harness its true power.

What we’ll cover:

1. Text Editors in Linux

2. How to Open the Vim Editor

3. Modes in Vim

4. Basic Vim Commands

5. Cut, Copy, Paste, and Delete Commands

6. Search and Replace Commands

7. How to Read Files using more and less

8. Text Filters

9. Text Summarization Tool: wc

Text Editors in Linux

Linux provides a variety of text editors, each designed for different types of users – from beginners to advanced developers.

Editors like Nano are great for newcomers who need a simple, user-friendly experience in the terminal. Nano displays helpful commands at the bottom of the screen, making it easy to navigate without a steep learning curve.

Gedit, the default editor for the GNOME desktop environment, offers a clean, graphical interface ideal for basic text editing. On the other hand, Kate caters to KDE desktop users and provides a more feature-rich experience, with multiple windows, syntax highlighting, and an integrated terminal.

Emacs is a versatile and highly customizable editor that can be turned into an entire development environment, ideal for power users who want more than just a text editor.

VS Code and Atom are modern, graphical editors that offer a rich set of features, including extensions, debugging tools, and Git integration, making them favorites among developers.

Why Do Many Devs Prefer Vim?

Despite the wide range of text editors available in Linux, Vim stands out as the preferred choice for many users, especially those who need a lightweight, fast, and highly efficient editing environment.

Vim, an improved version of the classic Vi editor, is available on nearly every Linux distribution and can be used in both graphical and terminal-based environments. Its popularity stems from its exceptional speed and efficiency.

Vim is entirely keyboard-driven, allowing you to perform complex editing tasks quickly without the need for a mouse. This makes it incredibly useful for remote work, where you may have to rely on minimal system resources.

The power of Vim lies in its modal editing system, which separates the text input and command modes, which you’ll learn soon. This lets you execute precise actions with a few keystrokes. Whether you're navigating a file, searching for a string, or performing complex text manipulations, Vim enables you to do it all without taking your hands off the keyboard.

Because Vim (or Vi) is pre-installed on most Linux systems, it’s often the go-to option for developers and system administrators, who rely on its ubiquity and powerful features. In short, Vim’s combination of speed, versatility, and efficiency makes it the editor of choice for many Linux users looking to boost their productivity.

How to Open the Vim Editor

Opening a file in Vim is straightforward and efficient. To start editing any file, simply use the following command in your terminal:

vim [filename]

Here, replace [filename] with the name of the file you want to open. If the file doesn't exist, Vim will create a new file with that name. Once executed, Vim will open the file and allow you to start editing right away.

Example:

vim data.txt # A file that doesn't exist yet, so Vim creates a new file named data.txt

When you execute the command vim data.txt, Vim opened a new file named data.txt because a file with this name did not previously exist in the current directory. In Vim, this is indicated by the message at the bottom of the editor, which reads: data.txt [NEW]

If the file you want to edit already exists, you can open it in Vim by using the same command. You’ll be able to see its contents and make edits as needed. If you don’t see the [New] message at the bottom (as shown for new files), it confirms the file already exists.

Modes in Vim

Vim has several modes, but the most commonly used ones are:

• Normal Mode (Command Mode) – Used for navigation and executing commands.

• Insert Mode – Used for typing and editing text.

When you open a file in Vim, it starts in Command Mode by default. This mode allows you to navigate, execute commands, and perform various operations without directly modifying the text. To edit the text in the file, you need to switch to Insert Mode.

What is Command Mode?

Command Mode is the default mode in Vim. In this mode, you can navigate through the file using the arrow keys and cut, copy, paste, or delete the content and execute commands like saving or quitting.

To switch to Command Mode from any other mode, press the Esc key.

Example: If you are in Insert Mode and need to return to Command Mode to save or navigate, press Esc.

In the above image, "hello.txt" 1L, 1B” indicates that the file hello.txt is open and is currently in Command Mode, which is the default mode when you open Vim. 1L Represents 1 line in the file (currently the file is empty, so there’s just one blank line). 1B Represents 1 byte (the file is currently empty)

What is Insert Mode?

Insert Mode allows you to edit or type text in the file, similar to a traditional text editor. You can insert new lines, modify existing text, and make changes directly.

Press i while in Command Mode. This switches to Insert Mode and places the cursor at the current position, allowing you to start typing.

In the above image, “—INSERT—” indicates that the editor has been switched to Insert Mode, allowing you to type and edit text directly in the file.

Quick glance: When you open a file, always check the bottom of the terminal to determine your current mode. If the bottom line displays file-related information, you are in Command Mode. If the bottom line explicitly says -- INSERT --, you are in Insert Mode. If you want to go from Command Mode to Insert Mode: Press i. And from Insert Mode to Command Mode: Press Esc.

Basic Vim Commands

Below are some essential commands to help you manage files efficiently in Vim.

Note: Before using these commands, ensure you're in command mode by pressing Esc.

1. Save Changes

To save the changes made to a file, use the following command:

:w

This writes (saves) the current file without exiting Vim.

2. Save Changes and Quit

If you're done editing and want to save changes and exit Vim simultaneously, use:

:wq

This command writes the changes and then quits the editor.

3. Quit Without Saving Changes

If you wish to exit without saving any changes, you can use:

:q

This command will close the file if no changes have been made since the last save.

4. Force Quit Without Saving Changes

In case you've made changes to the file but want to exit without saving them, you can force quit with:

:q!

The ! overrides any unsaved changes and closes the file immediately.

Cut, Copy, Paste, and Delete Commands (Plus Others)

How to Position the Cursor for Text Manipulation

Before using any of the commands listed below (copy, cut, paste, and delete), it's important to understand where to place the cursor.

• Copy (Yank), Cut, Delete: For most operations, the cursor needs to be placed at the starting point of the text you want to act upon. This means if you're copying or cutting a word, place the cursor at the beginning of the word. If you're working with a line, the cursor should be anywhere on that line. For paragraph-based operations, position the cursor anywhere within the paragraph.

• Paste: The text will be pasted at the cursor's current position. So, ensure your cursor is placed where you want the copied or cut content to appear.

For example, Let’s say I have a file.txt that has the following content -

# file.txt
Hey readers,  
In this blog, we're learning Vim. This file is for demonstration purposes,
where we'll explore various editing commands like cut, copy, paste, and delete. Let's dive in!  

Vim is a powerful text editor that comes pre-installed on most Unix-based systems.
Mastering Vim can significantly boost your efficiency as a developer.  

To start with, let's learn some basic navigation and text manipulation commands.
Stay tuned as we break down each command with examples!

All the commands mentioned below will use this file as reference to explain examples.

1. Copy (Yank)

In Vim, copying is called "yanking." Use the following commands to copy text. The cursor's position is important to ensure the correct text is copied.

2. Cut (Change)

Cutting in Vim is known as "changing" the text. The cut operation replaces the text. Just like with copying, the cursor's position is important when using cut commands.

3. Paste

To paste the copied or cut text, use the following commands. The pasted text will appear at the current cursor position.

4. Delete

Deleting text in Vim allows you to remove unwanted text while remaining in command mode. The cursor must be positioned correctly to delete the intended text. Once deleted, you can still paste the deleted text to a new location.

5. Other Useful Commands

Note that Delete removes text but doesn’t store it in the system clipboard by default. The text goes into Vim’s unnamed register, meaning it can be pasted within Vim but not outside it. Cut explicitly stores text in the clipboard so you can paste it outside Vim as well.

Search and Replace Commands

Vim provides powerful search and replace functionality that allows you to find specific words or patterns and replace them efficiently. Understanding how to search and replace text is key to improving your productivity when editing large files.

Below is a breakdown of the various search and replace commands in Vim.

Search Commands

• Search Forward (/): When you want to search for a word or pattern below the cursor, use the / command. This will search forward in the file.

• Search Backward (?): Similarly, if you want to search for a word or pattern above the cursor, use the ? command. This will search backward in the file.

After performing a search, you can navigate through the search results:

• n: Go to the next match in the same direction (forward if /, backward if ?).

• N: Go to the previous match in the opposite direction (backward if /, forward if ?).

Replace Commands

Once you've located the word or pattern you want to replace, Vim provides several commands for replacing text.

Here’s an example:

In Vim, the /Tanishka pattern searches for an exact, case-sensitive match of the word "Tanishka."

To replace "Tanishka" with another word, like "Linux," you can use the substitution command like this: :s/Tanishka/Linux:

By default, this command replaces only the first occurrence of "Tanishka" in the line where the cursor is located.

If you want to replace all occurrences of "Tanishka" in the same line, you need to add the g (global) flag after the replacement string like this: :s/Tanishka/Linux/g.

This ensures that every instance of "Tanishka" in the current line is replaced with "Linux."

Similarly, the % symbol is used to specify the entire file when performing a substitution. Here's how it works in combination with the substitution command:

1. Replace the first occurrence in each line of the file:

   • :%s/Tanishka/Linux: This command replaces only the first occurrence of "Tanishka" in each line of the file.

2. Replace all occurrences in the entire file:

   • :%s/Tanishka/Linux/g: The addition of the g (global) flag ensures that all occurrences of "Tanishka" in every line of the file are replaced with "Linux."

How to Read Files using more and less

The cat command

The cat command is often used to read file content.

For example:

cat file.txt # Displays content of file

While the cat command is a straightforward tool for viewing file contents, its simplicity often falls short when working with large files or when precise navigation is required. That’s where the more and less commands come into play, offering enhanced functionality for viewing and navigating text efficiently.

The more Command

The more command allows you to view files one screen at a time, making it a significant upgrade from cat when dealing with large files. But it comes with limitations in terms of backward navigation and advanced features.

Here’s the syntax for more:

more [FILENAME]

And here’s an example:

more file.txt # Displays content of file.txt one page at a time

Keys used while viewing:

1. Spacebar: Moves forward by one page

2. Enter: Moves forward by one line

3. b: Moves back by one page

4. q: Quit and exit file content

The less Command

The less command is often considered a superior alternative to more due to its advanced navigation capabilities and flexibility. Unlike more, less allows both forward and backward navigation, making it ideal for reviewing large files or logs.

Here’s its syntax:

less [FILENAME]

And here’s an example:

less file.txt # Displays content of file.txt one page at a time

Keys used while viewing:

1. Spacebar: Moves forward by one page

2. Enter: Moves forward by one line

3. b: Moves back by one page

4. Up/Down arrow key: Moves up or down by one line

5. q: Quit and exit less

The only major difference between the more and less commands is that the less command allows bidirectional navigation, so it’s typically more convenient to use.

Text Filters

A text filter in Linux is a command-line utility that processes text data by modifying, extracting, or formatting it before outputting the result.

Horizontal filters

Horizontal filtering focuses on extracting, manipulating, or displaying specific lines of a file or command output. Common tools include head, tail, and grep.

1. head: The head command displays the first few lines of a file. By default, it shows the first 10 lines. Here’s its syntax:

    head [OPTIONS] [FILENAME]
   

   And here’s an example of how to use it:

    head file.txt # Displays first ten lines from file.txt
    head -n 5 file.txt # Displays first five lines from file.txt
   

2. tail: The tail command displays the last few lines of a file. By default, it shows the last 10 lines. Here’s its syntax:

    tail [OPTIONS] [FILENAME]
   

   And here’s an example:

    tail file.txt # Displays last ten lines from file.txt
    tail -n 5 file.txt # Displays last five lines from file.txt
   

3. grep: The grep command searches for patterns within a file or input. It filters out lines that match a given pattern. Here’s its syntax:

    grep [OPTIONS] [PATTERN] [FILENAME]
   

   Options:

   • -i: Case-insensitive search.

   • -v: Invert the match (exclude matching lines).

   • -n: Show line numbers of matches.

Example

    grep Tanishka data.txt # Displays lines that have 'Tanishka' in them
    grep -i Tanishka data.txt # Displays lines that have 'Tanishka' irrespective of case
    grep -v Tanishka data.txt # Displays lines that do not have 'Tanishka' in them
    grep -n Tanishka data.txt # Displays lines that have 'Tanishka' in them along with number line

Vertical Filters

1. cut: The cut command displays selected parts of lines from each file based on delimiters, byte positions, or character fields. Here’s its syntax:

    cut [OPTION] [FILENAME]
   

   It also comes with various options:

   • -c: Extract specific characters.

   • -b: Extract specific bytes.

   • -d: Specify a custom delimiter (default is tab).

     • cut -d ":" -f 2 file.txt → Second field separated by :.

   • -f: Extract specific fields.

     • cut -d "," -f 1,3 file.csv → Fields 1 and 3 from a CSV.

Example:

    cut -c 1-10 Sample.txt # Displays characters from position 1 to 10
    cut -c 5 Sample.txt # Displays character at position 5
    cut -c 3,5 Sample.txt # Displays characters from position 3 and 5 only
    cut -d " " -f 1 Sample.txt # Displays first field separated by a space
    cut -d " " -f 2 Sample.txt # Displays second field separated by a space
    cut -d " " -f 3 Sample.txt # Displays third field separated by a space
    cut -d " " -f 1-3 Sample.txt # Displays first to third fields separated by a space
    cut -d " " -f 1,3 Sample.txt # Displays first and third fields separated by a space
    cut -d ":" -f 5 /etc/passwd # Displays fifth field separated by : in /etc/passwd

Text Summarization Tool: wc

The wc (word count) command is used to display the number of lines, words, characters, or bytes in a file or input. It is a simple yet powerful utility you can use to summarize text content.

Here’s its syntax:

wc [OPTION] [FILENAME]

And here are its options:

• -l: Displays the number of lines.

• -w: Displays the number of words.

• -c: Displays the number of bytes.

• -m: Displays the number of characters (useful for multibyte characters).

• -L: Displays the length of the longest line.

Example:

wc Sample.txt # Displays line count, word count, and byte count in Sample.txt
wc -w Sample.txt # Displays number of words in Sample.txt
wc -l Sample.txt # Displays number of lines in Sample.txt
wc -L Sample.txt # Displays number of characters in longest line in Sample.txt

wc -c Sample.txt # Displays number of bytes in Sample.txt (Actual storage size)
wc -m Sample.txt # Displays number of characters in Sample.txt (Actual number of characters regardless of enoing)

# ABCD😄
wc -c above.txt # "ABCD" = 4 bytes + "😄" = 4 bytes. 4 + 4 = 8 bytes
wc -m above.txt # "ABC" = 4 + "😄" = 1 byte. 4 + 1 = 5 bytes

Final Words

In this article, we covered the basics of using Vim, a powerful and flexible text editor. We started with how to open a file in Vim and then you learned about its modes. You also learned how to navigate through files, edit text, and use features like search and replace to save time. We also explored a helpful summarization tool.

If you're new to Linux and want to build a strong foundation, check my previous article where I cover the basics of Linux, including essential commands and tips for beginners. It’s a perfect starting point to complement what you’ve learned about Vim here!

Keep practising these commands, and soon they'll become second nature to you. Mastery comes with repetition, so continue experimenting and applying these fundamentals in real-world scenarios.

Stay tuned for more articles. Get ready to take your RHEL skills to the next level.

Let’s connect!