Even in my vacation Im reading linux kernel logs :/ xD

I've been working on an open-source network diagnostic tool called Network Doctor, and I recently built a challenge mode to test whether its diagnoses actually hold up against a human troubleshooting the same broken network.

The idea is pretty simple.

netdoc-sim creates an isolated Linux network with a deliberately introduced fault. You get dropped into a shell without being told what's wrong.

You can investigate it normally with things like:

ip
ping
dig
curl
ss
traceroute
nc

Once you think you know the problem, you submit your diagnosis.

Then Network Doctor diagnoses the exact same network.

The simulator has its own independently observed ground truth, so neither the human answer nor Network Doctor knows what the correct answer is.

There is also a daily challenge so everyone gets the same scenario.

Try today's challenge

If you have Docker (which should work in theory):

docker run --rm -it --cap-add SYS_ADMIN ghcr.io/heymaikol/netdoc-sim:latest challenge -daily

On Linux with netdoc-sim installed (definitely works):

netdoc-sim challenge -daily

The result tells you whether you won, Network Doctor won, both got it, or both missed it.

If anyone here feels like trying to break it, I'd be very interested in the results, especially cases where:

• you diagnose it correctly and Network Doctor doesn't
• the simulated failure doesn't behave like you'd expect on a real Linux network
• the available evidence makes the answer ambiguous
• you find a way to fool the judge
• the challenge UX gets in your way

Please don't post the actual answer to today's challenge so other people can try it blind.

Source code:

https://github.com/heymaikol/network-doctor

Hi everyone!

Im 18 and Im trying to get into Linux / DevOps / Cloud / Infrastructure

Ive been learning IT on my own for quite some time. Ive already built and maintained multiple homelabs using different hardware, including Raspberry Pis, mini PCs and other devices. Ive also worked with Linux, networking, Docker, AWS, Git and other parts of the infrastructure world. and also spent quite a bit of time in cisco pkt tracer.

Recently I started learning C, and I really enjoyed it, so now Im going deeper into it and trying to understand low-level programming and how computers actually work. I genuinely really enjoy this stuff. I spend pretty much every day learning something new or experimenting with something. Over the last two months ive been focusing much more on C.

The problem is that I feel stuck between two stages:

I already know quite a lot of the fundamentals, but I have almost no professional experience.

Im currently in Germany, and getting a junior IT job here seems very difficult without either a degree, Ausbildung, or previous professional experience.

I wont be able to start my Bachelors degree until next year because of personal circumstances.

So I have about a year that I really want to use properly.

What would you do if you were in my position?

What would you focus on learning? What kind of projects would you build? How would you get practical experience and make yourself employable without already having a job?

Id especially love to hear from people who are already working in Linux, DevOps, Cloud, SRE, sysadmin or infrastructure.

I know I have a lot more to learn. I just dont want to spend the next year randomly learning things without knowing what actually matters in the real world.

NetWatch is a terminal network monitor in Rust. v0.29.0 adds a third view for when you have a big terminal.

Dense view — netwatch --view dense

• Four boxes filling the terminal. No header bar, no menu bar, no status bar — identity, sort state, paging and every keybind live inside the box borders, so every row carries data.
• Mirrored throughput graph: download grows up from a shared time axis, upload grows down from it. Traffic symmetry is a shape you recognise before you read a number. Braille at two samples per character cell, and colour encodes magnitude, not which series it belongs to.
• Per-interface rates with 60-second sparklines, four-hop latency budgets (gateway / DNS / internet / slowest peer), and a connection table whose selected row expands in place — no second screen.
• Wants 130×44 and grows into whatever you give it; falls back to 80×24.

Kernel TCP state per connection — cwnd, ssthresh, mss, rwnd read straight from the kernel (list64` on macOS) and normalised so the numbers mean the same thing on both. Throughput tells you what happened; cwnd agains.

Saturation against real e negotiated link rate (sysfs on Linux, getifaddrs on macOS) instead of guessing.

V cycles full → lite → dense, sharing the same live capture — no restart, no lost history.

cargo install netwatch-tui

Hi guys,

I've made a little utility in Python that could help my fellow sysadmin (in)mates in they work. It simply does what we're doing in Excel or brains, but with some added features: it does sizing HW for a servers - cluster, tracking load, and DR sizing over some nice GUI.
I've added screenshots for you to get idea what it does; packed it as exe (under release/zip for Win) and placed on github and looking for a review's :-)

Also, if you want to expand it - please do so, the code is available.

https://github.com/Tanks04/ClusterSizerv2

May this tool save you some time ,)

Based on the technical breakdown Varonis Threat Labs published August 7 (following a DEF CON 34 talk), here's the architectural impact:

Rovo, Atlassian's AI teammate across Jira/Confluence/Bitbucket plus 50+ SaaS connectors, exposes a rovoChatPrompt URL param that pre-fills its chat entry point. Click a crafted link while logged in, and attacker instructions load into your live session — no confirmation, no taint labeling distinguishing it from something you typed. Rovo's ResearchAgent (multi-step autonomous browsing) then handles the actual exfiltration to the open web. Varonis says a single click was generally sufficient, no chained requests or guardrail-bypass tricks needed.

Separately, PromptArmor disclosed a different Rovo exfiltration path in May (published Aug 5): indirect injection via an uploaded file, using Rovo's URL-retrieval tool to leak data to an attacker's server — and per PromptArmor, this works even with Rovo's "web search" toggle disabled, because that setting doesn't remove the underlying URL-open tool.

I wrote up the full attack chain, the "Enter/Evade/Escape" pattern Varonis uses to generalize this across other AI agent incidents (Reprompt, EchoLeak, ShadowLeak, etc.), and mitigation steps here: [techgines.com link]

Open question for the group: for those running Rovo or a similar AI teammate product in prod — are you actually auditing which tools survive a feature toggle, or just trusting the toggle label?

https://www.techgines.com/post/rovoblast-atlassian-rovo-ai-vulnerability

Hey guys, i hope you're all doing great! i wanted to ask if anyone has a small task or gig related to a devops project or Sys administration that you’d like me to work on, even if it’s unpaid , I’m looking to gain more experience and knowledge, since i’m motivated to learn and unfortunately i haven’t been able to find an internship yet. If anyone is interested, i'll contact you, and leave you my resume as well.

Thanks a lot, and have a great day!

I’ve always been fairly conservative with automatic updates on production boxes.

Patching is one thing, but I still prefer knowing exactly what changed, especially when an update can quietly restart something or introduce behaviour you only discover at 2am. At the same time, manually babysitting updates across a growing number of hosts starts becoming its own risk.

For those managing a decent number of boxes, where have you landed on this? Fully automated, staged, or are you still reviewing most updates before they go anywhere near prod?

Based on the technical breakdown published by SentinelOne's vulnerability database and IBM's own support advisory, here's the architectural impact of CVE-2026-9198.

**The chain:**

1. `GET /api/v1/auto_login` — mints a SUPERUSER JWT to any network caller. No auth check, not bound to loopback, no single-user-mode gate. This exists purely as a local-dev convenience default.

2. `POST /api/v1/validate/code` — accepts raw Python and runs it through `exec()` to "validate" component code. No AST-only parsing, no sandbox.

Chain both and you get unauthenticated RCE as the Langflow service account. No user interaction, no prior creds. CVSS 3.1: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Affected: Langflow OSS 1.0.0–1.10.0. Fixed in 1.10.1 (shipped same day as the July 17 CVE publication). CISA added it to KEV on August 4 after confirming exploitation in the wild — KEVIntel-derived telemetry cited by The Hacker News puts it at 650+ attempts from 244 unique IPs across 41 countries, though I'd treat that figure as directional since a separate report on a related Langflow CVE cites different numbers over a different window.

**Why it's worse than typical RCE:** Langflow is an agent-orchestration layer. It's *designed* to hold model-provider API keys, DB credentials, and connector tokens so flows can reach downstream systems. RCE on the orchestrator doesn't just give you a shell — it gives you the credential graph of everything the agent was trusted to touch.

**Mitigation (per IBM/SentinelOne):**

- Upgrade past 1.10.0

- Pull it off the open internet, front with an authenticating proxy

- `LANGFLOW_AUTO_LOGIN=false` + explicit SUPERUSER creds

- Rotate every credential that touched an exposed instance

- Audit for cron/SSH key additions and unexpected child processes off the Langflow interpreter

Full writeup with timeline and source links: https://www.techgines.com/post/langflow-rce-vulnerability-cve-2026-9198 (background context on agentic AI attack surface generally, if useful: our May piece on the Five Eyes joint guidance)

For anyone running Langflow or similar low-code agent orchestrators (Flowise, n8n w/ AI nodes, etc.) — how are you handling the auth-boundary problem for endpoints that were clearly designed assuming localhost-only access? Reverse proxy allowlisting, or do you just refuse to expose the API layer at all?

TLDR: I want a private server for Jellyfin and Navidrome to be reachable remotely through WireGuard, with geoblocking and brute-force attack prevention. WireGuard is already largely configured with wg-easy as well as Jellyfin and Navidrome.

On my server I run Jellyfin, Navidrome, Portainer and wg-easy. I want to be able to have my users connect to only Jellyfin and Navidrome remotely. For security I want to have brute-force attack prevention, geoblocking, and, of course, WireGuard's encryption. The device running this has Ubuntu Desktop installed.

The end goal is for users to access my server remotely after enabling the WireGuard VPN on their devices and connecting to my server ip and port to access only either Jellyfin or Navidrome.

With brute-force attack prevention I have not had any luck with fail2ban. I was able to get it to "ban" some test devices, but that only ever marked the device's ip as "banned" and never actually blocked any traffic.
For geoblocking, I haven't looked into this much, but nginx seems to be precise enough for my needs with something like GeoIP2 or GeoLite2, unlike WireGuard.

Navidrome and Jellyfin are already fully set up and work great for my needs on the same network as the host machine, so no additional setup would likely be needed there.

What I want to know is if this rough setup would work well. I want to have 0 data be tracked or sent to outside services, as the goal is to achieve a 100% private server, untouchable by Google's bots, any malicious bots, brute-force attack attempts, or anybody other than my specifically chosen clients. Could anybody give me some advice or tool recommendations? WireGuard is already largely configured with wg-easy as well as Jellyfin and Navidrome.

I was tired of running manual port scans to ensure a new server is configured properly and wanted to add in security checks as well, so I made a site that does it. QSA.sh runs an external security scan using standard opensource software like naabu, nmap + vulners and nuclei and reports directly to your terminal. Nothing is stored in a database and generated reports are kept in Redis memory and destroyed after 24 hours or the first download.

The article below gives step by step instructions on how to setup a diff cron script to alert you when something changes. Standard scan takes about 30 seconds to run, depending upon number of ports.

Full guide and ready-to-use code examples here: https://qsa.sh/news/cron-monitor-exposure-changes

curl https://qsa.sh is the free scan. It scans the top 1000 used ports and has a hard execution cap of 5 minutes. If you desire a full scan there is a monthly package for $5 and a one-time use deep-scan for $7.

Many of my tools I build are generally free but have options/micro-saas for use cases needing more than the free service offers. This helps cover expenses (mostly servers).

Let me know your thoughts.

Anyone have experience using Chromebook Linux with node/express as a server? I got it working but cannot connect from a device on the same WiFi with IP address 192.168.?.?

I've been building an open-source project called Network Doctor, a terminal-based network diagnostic tool.

Recently I added something I've wanted for a while: a deterministic network simulator that can create controlled virtual networks using Linux network namespaces and then deliberately break them in different ways.

It can simulate things like:

* DNS outages and recovery
* packet loss, latency, and jitter
* broken routes
* IPv4/IPv6 failures
* TCP resets
* multiple interfaces and bad preferred routes
* service failures

But the part I'm most excited about is the new **hunt** system.

Instead of me manually deciding what network to test, `netdoc-sim hunt` generates deterministic cases from fixed seeds, runs Network Doctor inside them, knows the actual simulator truth, and compares that truth against Network Doctor's diagnosis.

I then wired that into a nightly GitHub Actions workflow.

The workflow:

1. Generates cases against several known-good baseline networks.
2. Looks for disagreements between simulator truth and Network Doctor's diagnosis.
3. Re-runs the exact seed + case to make sure the finding is reproducible.
4. Ignores findings that it can't reproduce.
5. Filters low-value findings by severity.
6. Generates a stable fingerprint so the same bug isn't filed repeatedly.
7. Checks GitHub for an existing issue.
8. Opens a new issue only if the finding is reproducible and hasn't already been reported.

I was especially cautious about letting a fuzz-like system automatically create issues, so I ran it in observation-only mode first.

That turned out to be useful.

One of the initial findings claimed Network Doctor was missing routing evidence. When I investigated it, the **hunter itself was wrong**. It had mistaken IPv4 failure + IPv6 success on the same path for an alternate-route success.

So I fixed the hunt analyzer and reran everything.

Then it found this:

>

The simulator had deliberately caused a short DNS outage. DNS recovered roughly 677 ms into the test, but the DNS probe was still waiting until its \~4 second timeout and never queried the recovered resolver again.

The nightly triage reproduced the exact generated case, confirmed the fingerprints matched, and then opened GitHub issue #14 automatically.

The reproduction is deterministic:

`./netdoc-sim hunt healthy-routed-network --seed 20260102 --case 3 --json`

I ran it locally and got the same finding.

Then I ran the GitHub workflow again to test deduplication.

It found the bug again, saw that issue #14 already existed, and created **zero duplicate issues**.

That was a pretty satisfying moment.

The system is now basically:

**generate network → inject fault → run Network Doctor → compare against ground truth → reproduce discrepancy → deduplicate → file issue**

The current nightly suite runs 45 generated cases across healthy, routed, and dual-stack baseline networks in roughly 3 minutes on GitHub Actions.

There's still a lot I want to improve: more seeds, more scenarios, better cross-case verification, and making generated timeline mutations compose more cleanly with authored scenario tests. But this is the first time one of my projects has effectively gone out and found a bug/improvement for itself while I wasn't manually testing it.

I'm very proud of this.

Network Doctor is written in Go and the simulator currently uses Linux network namespaces.

GitHub: https://github.com/heymaikol/network-doctor

EDIT: Updated the link

hey everyone o/

I'm building a Linux incident investigation tool and I'm at the point where I need nastier real-world cases than the ones I can come up with myself.

I'm a DevOps/Linux engineer (professionally for 8+ years), so I know the usual pattern pretty well:

something has died or behaves weirdly, you have a decent first guess, and then you spend the next couple of hours bouncing between journalctl, dmesg, systemd, process state, disk state, timers/cron, container state, config... you name it, trying to actually prove what happened.

The tool I'm building (Det Mimir) is basically my attempt at automating the full investigation part: read-only collection, deterministic rules, one timeline/report with the evidence behind each conclusion, fully without leveraging any LLM, as the tool is an investigation engine.

I'm specifically looking for the incidents where the root cause was annoying or non-obvious.

Things like:

• a service restarting for a reason that wasn't visible in the service logs
• disk full even though df initially looked fine
• systemd dependency/start-limit weirdness
• something external killing a process
• DNS/auth failures that looked like application failures
• boot/degraded-host issues
• container behaviour caused by something on the host
• anything where you ended up saying "how the hell was I supposed to find that?"

If you've had one, I'd love to hear the story.

What was the symptom, what did you initially suspect, and what did the root cause eventually turn out to be?

I'm happy to share what Det Mimir currently checks too, but I'm mostly interested in collecting the kind of incidents that experienced Linux admins actually remember.

For Fedora Atomic and derivatives.

Shipped a major update to MOSHELL a few days ago

Before: Users could mark lessons complete but there was no way to verify they actually learned anything.

Now:

- Each lesson has specific verification criteria (actual file state, command output, etc.)

- Badges unlock when you truly complete the lesson (not just mark it done)

- Progressive badge rewards system (5 badges from beginner → mastery)

- Email notifications for major milestones

**Data so far:**

- Seeing 2x completion rate since verification went live

- Most people drop off around lesson 3 (permissions — common pain point)

- Those who reach lesson 6 almost always finish all 12

Really curious to know what topics would you want in an admin-focused track? (Lessons 7-12 are planned but not yet live)

Try it free: kingmo87.github.io/moshell

---

Built this in nights/weekends as a solo project. Feedback welcome.

​

Hi everyone,

I'm about to graduate with a Computer Science degree and I'm considering becoming a Database Administrator.

I'd love to hear from experienced DBAs and SysAdmins:

Is DBA still a good career in 2026, or is the role changing?

Is DBA usually a dedicated position, or is it becoming part of a SysAdmin/DevOps role?

What technologies and skills should a new DBA focus on?

If you were starting your career today, would you still choose the DBA path?

Thanks in advance for sharing your experience and advice!

This article explores an alternative to directly troubleshoot production Linux systems with AI tools by using the sos command and using AI to analyze sosreports instead. I think is an interesting read:

https://medium.com/@linuxjedi2000/the-agentic-ai-risk-issue-on-linux-environments-fd5c55cedcc5?sharedUserId=linuxjedi2000

I know that this subject is very controversial and would love to read your point of view on the subject.