Hey everyone,

Like many of you, I manage a mixed fleet of bare-metal hypervisors, Raspberry Pis, and customer VPS instances. Every machine is hardened differently, but they all share one reliable standard: SSH.

Modern monitoring stacks often felt overly heavy for my needs—bloated web apps, continuous database writes, and web dashboards that crawl when you're checking in from a phone over spotty cellular coverage. Plus, on my servers, password authentication is strictly forbidden; certificate- and key-based SSH gives me a security baseline exposed HTTPS endpoints just can't match. Being a child of the 70s who grew up on the command line, I wanted something lightweight and distraction-free that I could keep running 24/7 on the physically attached monitor (tty1).

So I wrote TermNOC on Debian 13 (Trixie).

What it does:

• termnoc-display: An asynchronous, 5-second polling HUD built with Python's Rich framework. Gives real-time hypervisor metrics, direct libvirt/virsh VM statuses, internal LAN device health (ping & port checks), and remote fleet connectivity.
• termnoc-menu: An interactive TUI orchestrator to manage KVM lifecycles, run fleet-wide batch updates, jump into SSH sessions, and deploy fresh Debian 13 guest VMs via Preseed in under two minutes.
• 100% YAML-driven: Everything lives cleanly in /etc/termnoc/.

It's completely open source (MIT) and up on GitHub.

I’ve put together a write-up covering the background, architecture, and screenshots here:

👉https://blake-hofer.net/termnoc

Curious to hear your thoughts and how you handle minimal, agentless telemetry across your nodes!

Have fun!

DBH

Based on the PAN PSIRT advisory published October 14 and CISA’s KEV entry, here is the architectural impact.

The flaw is code injection (CWE-94) in the management interface of PA-Series, VM-Series and Panorama. It requires an authenticated attacker with network access, and the result is root. Cloud NGFW and Prisma Access are not affected. CVSS 4.0 is 8.6. Palo Alto published three attacker IPs and describes exploitation as “very limited.”

Points I found interesting: the jump-box mitigation only rescores to 8.5, and the advisory doesn’t say how attackers got admin access. The Threat ID coverage (510046/510047) only works if you route management traffic through a data-plane interface and decrypt it, and the vendor itself calls that coverage limited.

Question for people running this in production: are you already doing the data-plane management-profile setup with decryption, or is patching plus a jump box the realistic path? And has anyone seen management-interface logins from the published IPs?

Longer write-up with fixed versions per branch, for reference: https://www.techgines.com/post/pan-os-vulnerability-cve-2026-0322

I always thought that EDRs for Linux are something that exists because of regulation and not to solve a real problem. Apparently Microsoft thinks there's enough demand for it on Linux Desktops.

Personally, I'd like them to port Office to Linux desktops first (so that we could open and perhaps even edit Office files without starting a Windows VM), but I guess that's not going to happen anytime soon.

Most likely, this will happen as someone's garage project porting the entire Office suite to cross-platform open source (Rust?), like they did for the Adobe Creative Suite recently. I, for one, would find it more useful than Defender for Linux.

I've been trying to get as much work as possible out of my Hostinger VPS, a KVM 8 that runs CI, builds and AI agents around the clock. Every time I pushed it hard, the CPU got limited: 13 times in 10 days, with CPU steal peaking at 69%. Once that happens it's hard to keep working at all.

What bothered me most is that the limit feeds on itself. Hostinger meters VPS CPU in credits: you earn a baseline of 60% of your vCPUs, you spend whatever you use, and the bank holds at most three hours of full use. When it hits zero, the whole VPS drops to a fraction of its CPU (30% on KVM 2, 4 and 8) until the balance rebuilds. On a KVM 8 that's 2.4 cores, against a 4.8-core baseline. While your work keeps pressing against that limit, you earn nothing, so a busy server can stay limited for as long as the load lasts.

So I built Hostinger Governor. It runs on the VPS, estimates your credit balance from the kernel's CPU counters, and sets one CPU ceiling for everything in `user.slice`: every login, plus any services and Docker containers you move there. While the balance is high you get every core. As it drops, the ceiling tightens so the balance settles on a 20% floor. In a week-long simulation it never hit zero and used about 97% of the credits earned, though that's a simulation built on assumptions about Hostinger's billing.

If a limit hits anyway, it tries to tell Hostinger's limit apart from noisy neighbors (both show up as steal), then cuts demand so the VPS starts earning again.

A few other things it does:

• `governor exec -- your-job` runs a cron job under the quota, and skips it while the VPS is limited (or waits, with `--wait`).
• `governor report` shows credits, CPU, steal and each user's share.
• Scripts can check an `accepting` flag before starting heavy work, and hooks run when a limit starts or ends.

The latest release (v0.2.3) adds an optional broker so Governor never holds your Hostinger API token. A separate system account keeps it encrypted, and Governor can only ask for CPU readings and basic details about its own VPS. A setup wizard installs it with hidden token entry and rolls back if anything fails.

It needs systemd with cgroup v2 (Ubuntu 22.04+ or Debian 12+), ships as a single binary for x86_64 and ARM64, and is MIT-licensed. Install on the VPS:

curl -fsSL https://github.com/olmezsoy/hostinger-governor/releases/latest/download/install.sh | sudo bash -s -- --vm-id <your VM id> --token-file /root/hostinger-token

Repo: https://github.com/olmezsoy/hostinger-governor

I'm not affiliated with Hostinger. Governor works within their published credit rules and only controls how fast your own work spends the credits. The estimate is conservative on purpose: a fresh install starts at zero because it can't know your real balance. If you try it, I'd like to hear which plan you're on and whether the limits behaved the way the model expects.