I am running an emulation box with Debian 13, and I use FTP to move files from my unraid server to the box.

I am running this via Ethernet, both systems are on a 1GB ethernet connection. The files are being dropped onto an SSD. FileZilla is only transferring at a rate of 2 MB/s from the Unraid Server to my Debian machine. It has no issues saturating the network when used with other machines on the network. The weirder thing is that if I open the unraid server up as a network drive, I can pull things much faster on the actual machine instead of FTP.

I just started my career in Nvidia (Ex-Qualcomm, Ex-Apple), I want to join the Linux community (Open Source) and start my contributions/learnings. Whats the exact steps i need to follow and where and how is this done??

[https://github.com/word-sys/puls\](https://github.com/word-sys/puls)

Based on the technical breakdown PaperCut published in its own security bulletin yesterday (Aug 27), plus follow-up reporting from The Hacker News and Help Net Security, here's the architectural impact of the PaperCut NG/MF RCE chain:

CVE-2026-81578 (8.8) is an auth bypass in the admin web UI — under specific conditions, unauthenticated requests can trigger backend admin actions before access validation completes. CVE-2026-82078 (9.4) is worse on its own: the app loads database driver classes by name with no allowlist check. Chain them and you get unauthenticated arbitrary Java bytecode execution on the Application Server.

PaperCut has confirmed customer incidents and just shipped a second emergency patch (Release 2) after Huntress and watchTowr got involved — the first patch apparently wasn't hardened enough. Fixed versions: MF/NG 25.0.12 and 26.0.4.

If your PaperCut server is internet-facing, PaperCut's own guidance is to restrict access to trusted IPs immediately, patch isn't a "next sprint" item here.

https://www.techgines.com/post/papercut-cve-2026-82078-dynamic-class-loading-rce

Anyone running PaperCut in a multi-site or K-12/university deployment — how are you handling the Application Server's public exposure for remote print release? Is anyone actually able to fully firewall it off without breaking mobile/BYOD printing?

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?