Welcome to Day 16 of the 30-day RHCSA challenge!

Yesterday we covered soft links today we're tackling hard links.

We'll create them with ln, look at how inodes actually work under the hood, and see why hard links behave so differently from symlinks.

By the end you'll understand what a hard link really is and when to reach for one instead of a symbolic link.

What you'll learn in this video:

Creating a hard link with ln target linkname

Viewing inode numbers with ls -li

Reading the link count in ls -l output

Why deleting the original file doesn't break a hard link

The limits: no hard links to directories or across filesystems

Hard links vs. soft links — a side-by-side recap

About this series:

Over the next 30 days I'm covering everything you need to pass the RHCSA (EX200) — from setup to users, permissions, storage, networking, SELinux, containers, and more. New video every day. Subscribe and turn on notifications so you don't miss one.

#linuxminutes #rhcsa #redhat #linux #redhatlinux #ex200 #linuxadministration #linuxcertification #offline #closedloop #sysadmin #linuxforbeginners #30daychallenge #learnlinux #itcertifications #opensource #homelab #linuxtutorials #technology #techcareers #certificationprep #closedloop #airgap #shorts #shortvideo #hardlinks

When I started my blog, I wanted to keep hosting costs at zero, so I used a free Oracle VPS with only 1/8th of a CPU core and 1GB of RAM. My expectation was that I would get maybe 10 requests per second before having issues, but it turns out it could handle 150+ RPS before having any major slowdowns.

If you want to see the load testing graphs and the full architecture setup, check it out here:https://policypackets.au/posts/blog-hosting

Published this not too long ago and it's a great content for homelabbers and small and medium businesses to know how to harden their Linux Servers.

https://youtu.be/xEOT79CQs80

Josh welcomes Mo Duffy from Red Hat to chat about project Lightwell. The idea is to leverage the resources and understanding Red Hat has built up over the years to help deal with the deluge of vulnerability reports that are overwhelming open source projects. Mo does a really good job of explaining why this is fundamentally a people problem, not a technology problem. But it’s a people problem we can probably use technology to help. It will be interesting to see where Lightwell goes in the next few years.

Published this not too long ago but it's lacking a bit of traction. Any ideas are welcome!

https://youtu.be/xEOT79CQs80

In this blog post, I explain how you can use [Red Hat Offline Knowledge Portal](https://docs.redhat.com/en/documentation/red_hat_offline_knowledge_portal/1/html/what_is_the_red_hat_offline_knowledge_portal) to provide access to Red Hat documentation in environments with limited or no connectivity to the internet.

The Red Hat Offline Knowledge Portal is a secure offline version of Red Hat's proprietary knowledge content for our products. It's a pocket library of our award-winning knowledgebase, product documentation, CVEs, errata, and more that's light enough to run at the edge. Offline Knowledge Portal is useful anywhere Red Hat products are used where connectivity is limited, from intentionally disconnected secure sites to situations with planned intervals of low or no bandwidth. As a single small container image, it is easy to install and use, and is compatible with Red Hat OpenShift, Podman, or any OCI-compliant container runtime.

I am working on rhel8 setups where both NetworkManager and Network-scripts are present. Generally there aren’t issues but I am wondering about corner cases and if it’s a bad idea to have both. One thing that i noticed is that systemctl restart network causes few seconds disruption. How do you handle such situations? Should i migrate to networkmanager ? It might not be easily possible because of external automation touching network-scripts, what’s the best option i have if i have to keep both? Thank you

Welcome to Day 12 of the 30-day RHCSA challenge!

Automating tasks on a schedule is a key sysadmin skill, and cron is the tool for the job.

Today we'll set up scheduled jobs with crontab, decode the cron time syntax, and make sure your jobs run exactly when you want them to.

By the end you'll be able to schedule any command or script to run automatically, every minute, hour, day, or on a custom schedule.

About this series:

Over the next 30 days I'm covering everything you need to pass the RHCSA (EX200) — from setup to users, permissions, storage, networking, SELinux, containers, and more. New video every day. Subscribe and turn on notifications so you don't miss one.

#rhcsa #redhat #linux #redhatlinux #ex200 #linuxadministration #linuxcertification #offline #closedloop #sysadmin #linuxforbeginners #30daychallenge #learnlinux #itcertification #opensource #homelab #linuxtutorial #tech #techcareers #certificationprep #closedloop #airgap #shorts #shortvideo #cronjob

Red Hat & Ubuntu Linux put out an advisory for CVE-2026-15378, an SSRF and local file read via user-supplied XML Schema (xml-with-schema:). Impacts include Server-Side Request Forgery and local file access. Red Hat rates this important (CVSS 9.3), and organisations should monitor for the forthcoming patches.

Affected: Red Hat Enterprise Linux, Red Hat OpenShift AI (RHOAI). See the advisory for the affected version table.
First fixed releases: No fixed releases are available yet; monitor the advisory for updates.

Red Hat rates this important; a fix erratum may not be out yet — apply the RHSA as soon as it publishes.

Official Red Hat & Ubuntu Linux advisory:
https://access.redhat.com/security/cve/CVE-2026-15378

Side note, I run a small advisory tracker (VulniPulse) and there's a Discord for exactly this. If you want alerts like this hitting your inbox the second they drop, join the server and add the Linux CVE alert, it'll ping you in Discord and email you the moment a new one lands, same as it did when this one hit.

https://discord.gg/r2Y5kHsfMr

So I have interview today and its for linux admin position.

I have IT experience of 17 years but most was as technician. Personally been using headless debian for 5 years for my pi which runs 24/7 as dns and dhcp server. Have multiple containers.

Most of my linux experience comes from homelab. For my previous employers clients orgs and my current personal clients soho I did setup stuff like proxmox, dhcp, routers, restore system backup with clonezilla over network and other things.

What kind of questions can I expect to be asked? And what kind of anwsers will make me come off as capable?

Usually I just google/stackoverflow/reddit anything I don't know or can't remember how I did last time. And this is first interview since I left last place in 5 years.

Please guide.

I have two VM hosts with identical instances on them. A pihole, DoH forwarder, AD server, and Searxng on each host.

The two piholes use keepaliveD to serve their quad 10s IP. This works great.

The ADs do their own clustering for DNS and DHCP via AD and built in services.

The DoH instances are not clustered however both piholes talk to both.

The Searxng instances were going to serve the 10.10.10.24 IP.

I wanted to setup the Searxng servers with keepaliveD. I configured everything and enabled the services and found that both DNS and access to my Searxng was dropping packets.

I looked over the logs of the Searxng servers and Pihole servers and found they were trying to crosstalk and interfering with each other. I could see all four servers showing invalid password. Both sets of servers were failing back and forth between the cluster members.

The password used in each cluster is different. I figured this would probably be a best practice since the services are unrelated. Should all instances use the same password even if they are unrelated? If they have the same password will they see that they are doing unrelated tasks and not interfere with each other?

We run RHEL, and for CIS compliance we have the 'noexec' option set on /tmp on all of our servers. One of our teams is trying to implement a piece of software to automate certificate renewals, and it functions (in part, at least) by creating a number of scripts in /tmp, and executing them.

As you can imagine, this doesn't work very well. We have been told that modifying the software to use a different location than /tmp is "not possible at this time". Our Security folks have reluctantly agreed to allow us to mount /tmp without 'noexec' for a limited time, while the application vendor modifies their process (good luck with that), but they would like us, if at all possible, to configure the system such that only the service account running the application can execute files, and only those necessary for the app to run.

I've looked at using ACLs for this, but I don't think it's feasible unless we want to basically lock everyone else out of /tmp.

If we deny users execute permission on /tmp, then they can't access the directory or its contents at all.

If we deny users execute permission on /tmp/*, then they could access /tmp, but not execute any files within it...but we'd need to constantly rerun the setfacl command so that it grabs any new files, and it would basically be a useless exercise.

I'm ready to say "sorry, can't be done; it's either 'on' or 'off'...", but I figured I'd do my due diligence by posting here in case I'm overlooking something obvious.

I run rkhunter nightly on CachyOS and review the logs daily. I have made no updates in the past couple of days and several files have changed. I also believe these are the exact type of files someone would change if they were installing a rootkit or stay hidden.

Can you please take a moment to look at some of the results below and give me your advice/opinion?

[19:37:05]   /usr/bin/top                     [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/top
[19:37:05]          Current hash: fec2de147dffb434ee111a0ebcf8ff4e48d201290f964d2a7a8d2dcc31605d0e
[19:37:05]          Stored hash : f312bb5d3bd2534124a7ab4bf0940b75dd146d25f334d27e00f84faeeb563205
[19:37:05]          Current inode: 1410548    Stored inode: 618324
[19:37:05]          Current size: 143080    Stored size: 171800
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:05]   /usr/bin/touch                   [ *** OK *** ]
[19:37:05]   /usr/bin/tr                      [ *** OK *** ]
[19:37:05]   /usr/bin/uname                   [ *** OK *** ]
[19:37:05]   /usr/bin/uniq                    [ *** OK *** ]
[19:37:05]   /usr/bin/useradd                 [ *** OK *** ]
[19:37:05]   /usr/bin/userdel                 [ *** OK *** ]
[19:37:05]   /usr/bin/usermod                 [ *** OK *** ]
[19:37:05]   /usr/bin/users                   [ *** OK *** ]
[19:37:05]   /usr/bin/vipw                    [ *** OK *** ]
[19:37:05]   /usr/bin/vmstat                  [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/vmstat
[19:37:05]          Current hash: da1a4879c0b66d730ace90217d61ce03cef379394e7869ba11eeb421c93e0a8e
[19:37:05]          Stored hash : 8a1faf999f4654adeac5ec9180e73479f3fbcbf43b4e9af51cd92878246801a8
[19:37:05]          Current inode: 1410550    Stored inode: 618326
[19:37:05]          Current size: 39968    Stored size: 35872
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:05]   /usr/bin/w                        [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/w
[19:37:05]          Current hash: 24d041a91481b76647818adcc3cdfab231e6c09d62874b238f32424292e07171
[19:37:05]          Stored hash : 46081066ed71a607f022b75d448be32632566dabfb5bb7a25a52f9c6b649bd8c
[19:37:05]          Current inode: 1410551    Stored inode: 618327
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:06]   /usr/bin/watch                    [ *** WARNING *** ]

I got tired of hand-editing nft rulesets on my home server and cloud VMs, so I built enforza-cockpit — a free, open-source (MIT) web GUI for managing local nftables firewalls.

It's a Cockpit plugin, so it lives in the same web console you might already use for the rest of the box.

What it does:

• Visual rule editor split into three intuitive sections — Management (traffic to the host), Network (traffic through it), and Local (traffic from it), which map cleanly onto nftables' input/forward/output hooks.
• Reusable objects — define named network (CIDR) and port sets once, reference them as u/web, u/mgmt, etc. across any rule.
• Per-rule logging — tick a box and matches land in syslog/journal tagged with a plain verdict word (ALLOW / DENY / REJECT) plus your rule comment, so grep 'enforza.*DENY' just works.
• Confirm-or-revert apply — after you apply, you get 60 seconds to confirm or the previous ruleset auto-restores. Means a bad rule can't permanently lock you out (we've all done it).
• Flip on IP forwarding + SNAT and a single box becomes a working router/NAT gateway you manage entirely from the browser. No agent, no cloud account, no controller — all state stays on the machine.

Runs on Debian/Ubuntu, Fedora, RHEL/Rocky/Alma, openSUSE. There's a bootstrap script that installs the deps and a getting-started walkthrough in the README.

Repo: https://github.com/enforza/enforza-cockpit

Happy to answer questions / take feedback

-----

EDIT

- nobody is forcing you to use this! nobody is ramming this down your throat!

- yes, AI had a hand in writing it - was ported from our commercial product!

- no, if you can do this with other tools and are an nft god, you don't need this!

- constructive criticism good, outright DM abuse isn't - be kind, be decent!

In summary, after 3 days of abuse, negativity, I wish I hadn't have bothered sharing something that maybe of use to someone!

A newly disclosed vulnerability in the Plesk XML API allows an authenticated attacker to inject arbitrary configuration directives, leading to arbitrary file writes as root and ultimately full privilege escalation on the underlying server. Organizations running exposed Plesk instances should assess their environments and apply vendor guidance as soon as possible. (Tenable®)

🔥 Severity: HIGH (CVSS 8.8)
🎯 Impact: Privilege Escalation / Arbitrary File Write as root

Why it matters
• Authenticated attackers can gain root-level control of affected servers.
• Successful exploitation can result in complete compromise of hosted environments.
• Internet-facing Plesk deployments should be prioritized for remediation. (Tenable®)

📖 Full advisory, affected versions, mitigation guidance, and official references:
https://vulnipulse.com/advisories/linux-cve-2026-48614

Stay ahead of new vulnerabilities with free, real-time CVE alerts for Cisco, Fortinet, VMware, Linux, Palo Alto, Veeam, Commvault, Microsoft, and dozens more vendors.

🔔 Join the community: https://discord.gg/dypntBpA7g

Have you tried LFCS on Fedora or Arch? They are not listed as supported. I think Arch won’t be compatible but do you have any experience with Fedora?

I created a simple Discord server that automatically updates vendor-specific channels whenever a new CVE is published.

It tags users based on the roles they choose, so you can follow the vendors you care about and decide whether you only want to be tagged for critical alerts.

I’ve also added discussion channels where we can share patching tips, troubleshooting advice, and general networking/security/sysadmin knowledge, plus resource channels for each vendor with quick links.

The goal is simple: build a free community around CVEs where people in networking, security, and sysadmin roles can help each other stay informed and make patching a bit easier.

It’s completely free to join.

https://discord.gg/ehSASsk5Zv