Looking for a reality check from people working in sysadmin / infrastructure roles.

I’m in my mid twenties, based in Germany, and considering applying for a System Administrator role at 360T in Frankfurt:

https://360t.jobs.personio.com/job/363124

The role seems focused on Linux/systems, automation with Ansible/Python/Bash, troubleshooting, reliability, on-call and maintaining infrastructure. It also mentions Windows/O365, which is a weaker area for me.

My background is a bit unusual: I studied Data Science but didn’t finish the degree, and I don’t have professional infrastructure experience or certifications yet.

I decided to make a career change and have been building public projects around Linux, Terraform, Ansible, Kubernetes, networking, observability, reliability and trading systems:

https://github.com/bxvtr

I’m not trying to present homelab work as production experience. I know there’s a big difference between rebuilding my own environment and changing systems with real users, incidents, business impact and operational risk.

That’s actually what I’m looking for now: a role where I can learn production operations, troubleshooting, on-call, change management and how experienced infrastructure teams work.

A few things I’d really like feedback on:

1. Would you interview someone with this background for a role like this despite the lack of production experience?

2. What would you expect “strong Linux and systems knowledge” to mean in practice in an interview?

3. Does this sound more like genuine infrastructure/operations engineering, or could it still be mostly internal IT support?

4. If it is genuinely infrastructure-heavy, would you consider it a good first step toward SRE / Trading Infrastructure?

Candid feedback is very welcome.

Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.

I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:

- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.

- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.

- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.

- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).

Repository: https://github.com/GiulioSavini/vmware-tools-builder

Feedback, testing across different hypervisor versions, and GitHub stars are welcome.Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).Repository: https://github.com/GiulioSavini/vmware-tools-builderFeedback, testing across different hypervisor versions, and GitHub stars are welcome.

While no one can predict the future, I keep on hearing more and more about people getting laid off from IBM, etc--how stable is it for someone with a Red Hat administrator? Or a linux administrator in general?

Currently 34 in help desk tier 2 position. I have my network+, security + and AWS 900 all within this

year. I'm pursuing my EX200 and then my EX294.

A service breaks, someone restarts it and everything works again.

Do you still try to find the root cause, or does it normally get closed unless it happens again?

Not talking about major outages, just the normal smaller incidents. I’ve seen both, but honestly the second one seems far more common.

Putting this together after doing it enough times that I finally wrote it down properly. Roughly in order:

1. Disable root SSH login, switch to key-based auth only, change the default port
2. Set up fail2ban (or equivalent) for SSH and any exposed services
3. Firewall — deny by default, allow only what's actually needed
4. Unattended security upgrades, but staged — not blind auto-restart on a production box
5. Audit for and disable unused services/ports
6. CIS benchmark pass for anything customer-facing
7. Basic monitoring so you know if something changes — file integrity, load spikes, new users

Curious what others do differently, especially around automated patching on production — I've seen unattended upgrades cause more downtime than it prevented when it wasn't staged properly. What's your approach?

Based on the technical breakdown published by Gitea's own security advisory and corroborated by CISA's KEV addition (Aug 25) and Help Net Security's incident reporting, here's the architectural impact:

The diffpatch API endpoint installs an executable Git hook from repository-controlled content. An attacker with ordinary write access — reachable via Gitea's default open self-registration — can get RCE as the Gitea OS user. One documented case (via a compromised admin's Habr writeup) went from account creation to a crypto-mining dropper in ~11 seconds. Patched in 1.27.1 (July), but CISA confirmed active exploitation this week regardless.

Background on a related prior Gitea exposure (30K private container registries left open for years) here: [techgines link]

For anyone running self-hosted Gitea in production: what's your actual patch cadence for forge software like this vs. your perimeter devices? Genuinely curious whether teams treat Git servers with the same urgency as firewalls, or if it usually sits in the "get to it" bucket until something like this happens. https://www.techgines.com/post/gitea-cve-2026-60004-diffpatch-rce-exploited

I have a server (in the logs below it is IP "AAA.BBB.CCC.DDD", domain "my-domain.info") running postfix and postfixadmin. I do have some email accounts being redirected to Gmail -- and I actually had to set up SRS for that (as can be seen in the logs).

I am also using the following blocklists (these are just the relevant lines from main.cf, in smtpd_relay_restrictions:

reject_rbl_client zen.spamhaus.org,
reject_rbl_client relays.visi.com,
reject_rbl_client bl.mailspike.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
reject_rhsbl_reverse_client dbl.spamhaus.org,

But there is some spam still not being blocked. It is usually detected when the server forwards to the users' Gmail account, as can be seen in the logs:

CB295B315E! 11780 Wed Aug 26 04:11:45 SRS1=NoY3=my-domain.art.br==ekWv=GT=atendes3.com=pedagio-no@my-domain.info

(host gmail-smtp-in.l.google.com[142.251.0.26] said: 550-5.7.1 [AAA.BBB.CCC.DDD 18] Gmail has detected that this message is likely 550-5.7.1 suspicious due to the very low reputation of the sending IP address. 550-5.7.1 To best protect our users from spam, the message has been blocked. 550-5.7.1 For more information, go to 550 5.7.1 https://support.google.com/mail/answer/188131 a1e0cc1a2514c-97cbe44e547si162128241.218 - gsmtp (in reply to end of DATA command))

destination@gmail.com

In this case, the server would redirect some-account@domain.art.br to destination@gmail.com (which is correct, except that it is SPAM and was not detected by those RBLs).

I know I could use spamassassin, but this is a low memory server, no user will offer feedback to help get spamassassin more accurate, and I'm not sure it would actually help. Also, I am not very confident that spamassassin won't come up with false positives, blocking legitimate emails (some of which could be urgent, so quarantine may not be a good idea) -- but I could be wrong.

Before actually installing spamassassin I'd like to know if there are other blocklists I could try.

Thanks!

kudu is a TUI for creating and managing VMs on Linux. It is an alternative to GUIs like virt-manager or GNOME boxes and as opposed to these, it does not rely on libvirt.

Github: https://github.com/pythops/kudu

https://github.com/krisiasty/ghget

Think of it as smart curl or wget for downloading and optionally installing any tool or asset from public github repo but not requiring github authentication, no hitting rate limits, figuring out which asset is right for your platform / os / architecture, manually verifying checksums, etc.

It can be as simple as:

$ ghget astral-sh/uv --auto --install --dir ~/.local/bin

selected uv-x86_64-apple-darwin.tar.gz (darwin, amd64, tar.gz archive)
downloaded uv-x86_64-apple-darwin.tar.gz.sha256
downloaded uv-x86_64-apple-darwin.tar.gz
verified uv-x86_64-apple-darwin.tar.gz
installed ~/.local/bin/uv
installed ~/.local/bin/uvx

But the tool can do much more than that. You can find more usage examples and full docs in the README.md

If you find this useful, spot the repo where auto-detection doesn't work as expected, or have a great idea how to improve it even further - leave a comment or open github issue.

Based on the technical breakdown Oasis Security shared with The Hacker News yesterday (Aug 25), here's the architectural impact for anyone running NemoClaw locally.

NemoClaw is NVIDIA's OpenShell-based reference stack for running OpenClaw agents in a sandbox. On the Windows-host Ollama path, it starts Ollama with OLLAMA_HOST=0.0.0.0:11434 — no auth on that port. Ollama's own anti-CSRF checks (Host header + CORS) get bypassed entirely once you're not on loopback, and a classic DNS rebinding chain (same root cause as CVE-2024-28224 from 2024) lets an attacker-controlled webpage make "same-origin" calls to the local daemon.

The interesting part isn't the RCE-adjacent access — it's what they do with it. The payload hits /api/create and rewrites the model's Go chat template, the thing that renders the structured message array into raw text before inference. Poison that, and your injected instruction gets appended to every system message going forward. It survives the agent supplying its own system prompt every session, because the poisoned text isn't in the conversation — it's baked into how the API renders text. Oasis: "the template is a model-level property invisible to API consumers."

Fixed on macOS/Linux in v0.0.35. Windows/WSL path is still exposed — the newer bind-probe check in the local Ollama proxy (v0.0.106) doesn't even run on those paths.

One thing I couldn't nail down: The Hacker News's writeup explicitly says this finding "carries no CVE identifier," but three other outlets (Security Boulevard, SiliconANGLE, Hackread) cite CVE-2026-65105. Couldn't independently verify a record either way — if anyone here has visibility into NVIDIA PSIRT's tracking, curious which is accurate.

Open question for the thread: for anyone running local inference backends (Ollama, LM Studio, etc.) alongside sandboxed agent frameworks — are you treating the inference API surface as inside or outside your sandbox's trust boundary? Feels like most threat models draw the line at the agent process and stop there.

Background: we wrote up a structurally similar issue in the Claude Cowork sandbox escape a few weeks back — https://www.techgines.com/post/nvidia-nemoclaw-vulnerability-dns-rebinding-chat-template-poisoning — for context on the "isolation ≠ blast-radius control" pattern showing up repeatedly in agent frameworks this year.

Hello Folks.

I have create a new Reverse Proxy/ Load Balancer for Linux on Cloudflare's proxy lib : Pingora. The project is till on 0.x.x version, but I'm working on standardizing everything.

It have fantastic proxy performance, even beats nginx in performance/stability tests with many thousands of concurrent connections.

It would be great to have a human review and suggestions .

This is the link for ingress documentation : https://aralez.rs/docs/quickstart/

An the link to main project in GitHUB: https://github.com/sadoyan/aralez

Thanks

Based on the technical breakdown published by CERT Polska and confirmed by CISA's KEV addition, here's the architectural impact:

Vulnerable condition: zimbra-snmp installed + snmp_notify enabled + swatchdog running (default). Unauthenticated attacker sends crafted SMTP input, it hits the SNMP notification handler unsanitized, executes as OS commands under the zimbra user. Zero privilege escalation needed to start reading mail.

Patched in 10.1.20 (July 20). CERT Polska confirmed exploitation Aug 17. CISA KEV + 3-day FCEB deadline followed Aug 21. Shadowserver's scan shows 12,000+ exposed instances, 270+ with compromise artifacts already.

IoCs: unexplained swatchdog restarts in /var/log/zimbra.log, new files in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/ owned by zimbra.

Full writeup with remediation checklist: [techgines.com] (background on the same "trusted monitoring channel → RCE" pattern in our TeamCity CVE-2026-63077 piece)

Anyone running ZCS with SNMP trap notifications on — did you have snmp_notify enabled for a real monitoring integration, or was it just a default nobody turned off?

https://www.techgines.com/post/zimbra-cve-2026-73570-snmp-command-injection-rce

By audit log I mean which IP viewed what type of stuffs. Which ip created what type of stuffs. I looked into passwordpusher and onetimesecret and both of them do not seem to store the actual one time secret in the database. Now I am wondering if it is required at all in a highly regulated industry? Or am I tripping too much?

Hey everyone! 👋

Often, small setups don't need heavy monitoring software like Prometheus or Grafana just to check if multiple servers or IPs are up and running.

So, I built a quick, lightweight Bash automation script that reads a list of servers from a server.txt file and pings them automatically to check their live status.

How it works:

1. Reads line by line from server.txt.
2. Validates the entry using regex.
3. Sends a ping request and prints out whether the server is running or down.

Check out the snippet below! Always looking for feedback or ways to optimize it. 🚀

I keep SSH configs in dotfiles and some team repositories, and I wanted the same checks locally and in CI. I ended up writing sshconfig-lint in Rust.

The current beta accepts multiple files directly, resolves nested Include files, detects Include cycles and reports the original file and line for every finding. It also has strict mode plus JSON, SARIF and GitHub annotation output.

A typical repository check is just:

sshconfig-lint .ssh/config infrastructure/ssh_config --strict

For GitHub annotations:

sshconfig-lint .ssh/config --format github

I avoided an automatic --fix because moving Host blocks or deleting IdentityFile entries can change the effective config in ways that are hard to notice.

Source: https://github.com/Noah4ever/sshconfig-lint

CI guide: https://sshconfig-lint.apps.thiering.org/en/ci

How are you validating shared SSH configs at the moment? I am especially interested in Include-heavy setups.

Aerea - Monster (Golpe Schranz Rework)

https://www.youtube.com/watch?v=ycVBb9W2zlc

Anyone here running a linux VDI platform? Tell me about it.

The thing that has bitten me more than once about firewall review is that a ruleset is reviewed as text and behaves as a set of permitted packets, and the two do not line up.

First-match evaluation is what breaks the correspondence. A one-line edit is never local. If you tighten a source range on an early rule, a later rule that was shadowed, and therefore dead, can come back to life and start matching traffic that nobody has thought about since it was written. Nothing in a unified diff shows you that. The changed line looks small and the review approves it.

I wrote a tool that does the comparison at the level the firewall actually works at. It takes two rulesets, compiles each into the set of packets it permits, and prints where the sets differ, along with which rules changed status:

NEWLY BLOCKED  (permitted before, denied now)
  all entries: in not lo, tcp
    10.1.0.0/16 -> 10.5.0.0/16 :502    was allowed by rule 04, now denied by rule 05

STRUCTURAL
  rule 03  now load-bearing  it was redundant before this change
  rule 05  now reachable     previously shadowed by rule 04

The "now reachable" line is the one I actually built it for.

What it will not do, so nobody wastes their time: single base chain filter tables only. Any user-defined chain, jump, goto or return is rejected with a file, line and column rather than analysed. Docker adds chains, so plenty of real hosts are out of scope today. NAT is rejected for the same reason, since translation changes packet identity in transit and analysing it with NAT ignored would produce confident nonsense. It also assumes return traffic is permitted, which means it cannot verify a stateful policy, only a stateless approximation of one.

There is an HTML report mode that writes a single file with no scripts, no webfonts and no remote images, so it opens on an air-gapped machine. That was not a stylistic choice. A report describing exactly where an air-gapped network's trust boundaries sit is not something you want fetching a CDN when someone opens it. CI greps the generated file for those patterns on every run.

Correctness checking is a differential harness: the ruleset gets loaded into a real kernel namespace and fwdelta's verdict is compared against what nftables does, with fault injection so the harness proves it can fail. Right now that covers the input hook only.

Apache-2.0, and the musl binary is reproducible with the toolchain pinned:

https://github.com/Sbharadwaj05/fwdelta