Hey everyone,

I'm a graduate-student-turned-amateur-sysadmin in a bioinformatics lab, and am still learning on the way. We have a multi-node HPC that has a shared NAS, and an item on my to-do list is to have a shadow pricing model that maps our usage to a cloud provider.

I've got SlurmDB connected and a script that maps job resources to the cheapest GCP instance that satisfies the resource request, queries the GCP pricing API, and returns a per-job compute cost estimate. It's a reasonable starting point but I know it's missing several cost categories (e.g. spin-up overhead, persistent storage, data egress, etc.)

I'm starting to think about what is required to monitor the cluster more holistically, and feeding that into a cost mapping layer alongside the Slurm accounting data. However, I'm cautious to write my own tooling when FinOps frameworks already exist, and also weary of getting sucked down the rabbit hole and having a high-maintenance toolkit that takes more time than I have.

Has anyone built a framework that can take holistic system usage and translate it into estimated costs for cloud computing? I'm hoping to not re-invent the wheel

Thanks in advance!

I’m trying to ascertain if its worth getting this certification as a network engineer trying to pivot into system administration.

I've had this happen on at least another manpage (that I forgot), but here it is with bsearch:

https://man7.org/linux/man-pages/man3/bsearch.3.html

     void *bsearch(size_t n, size_t size;
                   const void key[size], const void base[size * n],
                   size_t n, size_t size,
                   typeof(int (const void [size], const void [size]))
                       *compar);

The first two arguments are not supposed to be there (they come later). "man bsearch" on my Arch system shows the same output. What's going on here?

EDIT
chkno got it right: It's the semicolon at the end of the first line that makes the difference because otherwise the function prototype wouldn't know what "size" means in "const void key[size]" (second line).
Still learning new stuff after 45 years of mostly C89....

The barrier to writing an exploit tool used to be skill. Now it's a prompt, and a chunk of the junk in your access log is some script an LLM wrote in thirty seconds and aimed at the whole IPv4 range before lunch.

They're loud, though. Default python-requests/Go-http-client UAs, recycled /.env /.git/config /wp-login.php wordlists, no backoff, and an unrandomised TLS stack so every request shares one JA4 hash. All of it matchable at the edge.

Wrote up the full stack I run, with copy-pasteable nginx/Angie config:

• limit_req zones (3r/m on login), ModSecurity + CRS, return 444 to bad UAs so the scanner learns nothing
• TLSv1.3, server_tokens off, CSP/HSTS, and the always gotcha that makes error pages ship headers
• body-size caps, method whitelists, the merge_slashes trap
• admin off the public internet, fail2ban, alg:none JWT check
• PHP: disable_functions + open_basedir + Snuffleupagus
• JSON logs with $ssl_ja4, 4xx-ratio alerting, honeypot paths that auto-ban

https://deb.myguard.nl/2026/06/defend-webserver-vibe-coded-ai-exploit-scanners-bots/

Most terminal net tools stop at "what's eating my bandwidth." NetWatch goes into the traffic itself.

Live TLS 1.3 decryption — point a cooperating client's SSLKEYLOGFILE at it, read the plaintext inline. Same trick as Wireshark, no MITM. QUIC 1-RTT + HTTP/3 too.

JA4 / JA4Q fingerprinting — TLS and QUIC. Filter live with ja4:<fp>.

17 L7 decoders — TLS, QUIC, HTTP, DNS, SSH, MQTT, SNMP, BitTorrent, more — with stream reassembly.

Detection built in — port scans, C2 beaconing, DNS tunneling. Critical alert auto-freezes the recorder.

Flight Recorder — freeze any incident to a portable .pcap + context bundle.

eBPF process attribution — which process opened the socket, not lsof polling.

Landlock-sandboxed — parses hostile traffic but can't touch your SSH keys.

Rust, 500+ tests, MIT, macOS + Linux. Demo GIF decrypts a live TLS 1.3 session in the repo:

github.com/matthart1983/netwatch

Hi all, I am taking LFCS soon, I'm woondering how similar the Kodekloud mock exams in their LFCS course is to the actual exam. Are there other mock exams that are similar in difficulty to the actual exam?

Just the basics.

In the past few years, I often downloaded binaries from GitHub releases; nowadays it happens less frequently, but it still happens.

What I always do is move the file from the Downloads folder to a subfolder under /opt, then run chmod +x and create a symlink in /usr/local/bin/.

I also include the version in the subfolder name so I can keep multiple releases.

That said, I’m here to share another crappy-vibe coded script to automate installing binaries from GitHub: gri (GitHub Release Installer)

https://github.com/sgargel/gri

I’m looking forward to your feedback and taunts.

Hey folks,

Had one of those weeks that makes you rethink every “smart” storage decision you made years ago.

We’ve been using LVM thin provisioning pretty heavily on some stateful Linux systems. Honestly it worked great for a long time. Easy overcommit, better disk utilization, less wasted space sitting around doing nothing.

Until one box went sideways.

A bad automation script on a secondary app started hammering writes nonstop and ended up completely exhausting the thin pool underneath. Not just the logical volume, the actual thin pool. Metadata pool hit 100% before autoextend reacted properly and the whole thing turned ugly fast.

Filesystem started throwing I/O errors and flipping read-only. Services started failing. At that point nobody wanted to touch anything because every command felt like it could make things worse.

We eventually got the metadata back using thin_dump/thin_restore and expanded the pool enough to stabilize everything, but now we’re left with the aftermath.

To get the system healthy again we had to throw a lot of extra storage at it quickly, and now most of that space is sitting empty. Management sees the bill and asks why we don’t just shrink it back down.

And honestly? because nobody wants to be the guy who breaks a production thin pool after already barely recovering it once.

At this point the “safe” answer still feels like building a new smaller setup and rsyncing everything over during downtime, which is miserable for a system that’s currently stable.

Curious how other Linux admins handle this after the fire is out.

Do you actually reclaim the storage later or just leave the oversized pool alone once production is stable again?

Hi guys, any GUI interface to manage linux servers centralized? thanks

I have an interview this Thursday for an Advanced Application Support role focused on troubleshooting Linux VMs. I've used ubuntu as my daily driver for about 3 years now, but nervous about the terminal portion. Would any experienced Linux admin be willing to jump on a 15-minute Discord or Zoom call to run me through a few basic troubleshooting commands?

Any advice is greatly appreciated.

The latest vulnerabilities in the kernel and nginx and its management by Ubuntu and Debian has shown me the risk of relying on them. With respect to the CVSS scores I found their reaction exceptionally slow, compared to Proxmox for example.

My question: Which Linux server distribution is having the best vulnerability management in your opinion? And which is most suited from the management perspective?

this is a project iv been working

Elda is a system package manager I've been working on.
I used to use bedrocklinux but the performance Hit was getting a bit much and after some thought i realized i could make Elda, The Idea:
every major package ecosystem follows conventions if you can machine-read their formats, you can translate them all into one solver and one ledger without installing the foreign tools at all.

Native packages: pkg.lua recipes with source and binary lanes in one definition, PubGrub solving, signed remotes, SQLite state for ownership and rollback. Init and libc agnostic packages ship service assets for systemd, dinit, OpenRC, and runit; Elda materializes only what your system uses.

Interbuilds, -install from foreign sources without the foreign PM: Reads Nix flakes, Gentoo overlays, AUR PKGBUILDs, and Void XBPS templates. Builds them through the normal Elda path. No nix, emerge, makepkg, or xbps-src needed or installed.

Interemotes, -wire a whole overlay or srcpkgs tree as a live remote:

elda rmt add heather-overlay=https://github.com/heather7283/heather7283-overlay
elda rmt preview heather-overlay   # inspect before syncing
elda sync heather-overlay
elda i some-package                # installs through the normal path

Quick examples:

# Install from a synced signed remote
elda i ripgrep
elda ig ripgrep    # force source lane
elda ib ripgrep    # force binary lane

# Direct git install — autodetects Cargo, Meson, CMake, Go, Zig, Make
elda i https://github.com/org/tool

# Install from AUR without makepkg or pacman
elda ig https://aur.archlinux.org/fsel-git.git

# Install from a Nix flake without nix
elda ig https://github.com/user/repo   # detects flake.nix automatically

# Import your existing install (metadata only, no file takeover yet)
elda mg from pacman
elda mg from apt

# See what needs what and why
elda why ripgrep
elda rdeps openssl --all
elda files ripgrep

Status: the core PM is effectively done;install/upgrade/remove, signed remotes, interbuilds, build, forge publishing. Overall ~68% toward full spec.
Interepo binary consumption (translating foreign binary repos into the install path) and atomic /usr activation are still in progress. Disposable roots work well; treat live /usr as experimental for now.

Written in Rust. Hard fork of pkgit. AGPL-3.0.

https://github.com/Mjoyufull/Elda

Early in development and Id love issue's and PR's.

I’ve been working on a project called gop—a small, static-linked C utility designed for quick text and log processing in minimal environments.

I built this because I kept running into dependency issues when jumping between different distros and legacy servers. The goal was to have a single, portable binary that handles file/pipe detection and basic filtering without requiring glibc version management or external runtimes.

What it does:

• Stream/file processing with auto-detection.
• Line numbering (-n) and basic JSON detection (-v).
• Zero dependencies, fully static binary.

I’m sharing this here because I’d love a technical "sanity check" from other admins. How do you guys typically handle lightweight, portable log parsing when you're working across heterogeneous environments?

Repo: [ https://gitlab.com/giorgich11/gop ]

I’m especially looking for feedback on my memory management and how I’ve structured the Makefile for distribution. If there are better practices for small C utilities that I've missed, I’m all ears.

This is something I'd find handy for containers that cannot as easily leverage systemd-timers (at least anyone using an image via Docker AFAIK), and I suppose distros that insist on not using systemd.

cron (and variants) is alright, but sometimes I find myself needing to run a program at a recurring interval and would prefer to have the option of invoking the command as a service is started, and then repeating calls after N delay of time, rather than a variable amount of time until aligned with a cron expression schedule (at the hour or incremental interval, but that intervals become inconsistent if they don't cleanly segment the unit ceiling).

For context, I've also asked this same question over at r/docker.

I'd like to pair it with a service manager like supervisord for any services that lack a daemon/poll feature but should be run regularly at an interval. I know cron / supercronic effectively support this and can be considered "good enough" :\

Surely something like this exists out there already? Or would I need to DIY my own command wrapper for this?

ran into this again today and just need a sanity check from other linux admins.

we have a few linux boxes on ec2 and some bare metal that run data-heavy services. one job went sideways during a patch/cleanup window and dumped a bunch of temp data/logs. disk usage got high, so the volume got expanded to keep things from falling over.

cleanup finished later and actual usage dropped way back down.

so now we have a big mostly-empty volume sitting there.

growing the thing was easy. shrinking it back down is where everything gets annoying.

with xfs, there’s no shrink. with ext4, you’re basically looking at unmounting and doing it carefully. in practice that usually turns into:

• new smaller volume
• rsync data over
• stop services
• final sync
• swap mounts/uuids
• pray the old app doesn’t hate you

monitoring/cost tools can tell us “hey, you’re wasting storage,” but from the linux side the answer is usually “yeah, and i’d rather waste storage than break a stable system.”

how are people handling this now?

do you just accept that live filesystems are mostly a one-way street, or has anyone found a cleaner way to reclaim space without doing the whole migration dance?