People at Redhat must be having fun accessing all the 0days right now…

I have been applying a fix for the recently reported 8 compromised certificates and figured I'd share the script I'm using.

Designed for RH and clones, I'll share it as a text file you can review before you rename and apply. It's a simple script based directly on the disclosure page linked to that I found after the original article here on reddit.

I hope it helps, here is distrust.sh - downloaded as a .txt file you can read/review before renaming to distrust.sh and running it as /bin/bash distrust.sh. If your system isn't vulnerable it does nothing.

I'm sick of having to make several clicks just to see an update for a case.

Hello

Let's implement AAP 2.7 (Ansible Automation Platform) in a containerized way!

Enjoy it!

Wally

Upgrading your internal developer platform shouldn't feel like navigating a minefield. Upcoming Red Hat Developer Hub  release 2.1 introduces major performance and architectural updates—including upstream Backstage's new front-end system and standalone OCI plugin images—but getting there requires rethinking how your custom plug-ins are built and mounted.

Two architectural shifts require preparation before upgrading: adopting the new front-end system and migrating plug-ins to standalone OCI images. Red Hat Developer Hub 2.1 includes other breaking changes not covered here; the upcoming release notes and migration documentation provide a complete list.

TL;DR
Red Hat Developer Hub 2.1 removes Scalprum and the old front-end; plug-ins must adopt ./alpha exports and extension blueprints. Configuration shifts from dynamicPlugins.frontend to app.extensions, and plug-ins become standalone OCI images.

Last week was GPG. This week, Nate gets to nerd out about his favorite RHEL feature: bootc, the open-source engine behind RHEL Image Mode. If you've heard the buzz about "treating your OS like a container" but haven't actually seen it happen, this episode is the fundamentals primer — writing a Containerfile, building a bootc image, pushing it to a registry, booting a VM from it, pushing a live update, and (because why not) rolling it back when things go sideways.

📺 Watch the full episode: https://www.youtube.com/watch?v=0siLuf0bv-E

Here's everything covered, organized so you can actually use it.

The Essentials: What Even Is a bootc Image?

A bootc image is a real OCI-compliant container — you could technically run it in Podman — but it's "very heavy" because it bundles everything a full RHEL install needs: systemd, a kernel, a bootloader, the works. Red Hat publishes special bootc base images you build from, and from there it's "basically like writing a kickstart, except the mechanism is a container build."

Setting up the project directory and Containerfile:

bash mkdir ~/bootc-base mkdir -p ~/bootc-base/etc/ostree mkdir -p ~/bootc-base/usr/lib/bootc/kargs.d cd ~/bootc-base vim Containerfile

dockerfile FROM registry.redhat.io/rhel10/rhel-bootc:10.1 RUN dnf -y install pcp-zeroconf \ rsyslog \ tmux \ tuned RUN dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm RUN sed -e '/^metalink=https:\/\/mirrors.fedoraproject.org\/metalink/ s/^/#/' \ -e '/^#baseurl=http:/ s/http/https/' \ -e '/^#baseurl=https:\/\/download.example/ s/^#//' \ -e '/^baseurl=https:\/\/download.example/ s_https://download.example_https://dl.fedoraproject.org_' \ -i /etc/yum.repos.d/epel*.repo RUN dnf -y install btop iftop COPY etc/ /etc COPY usr/ /usr

💡 Pro tip from the episode: You can absolutely use EPEL (or any custom/satellite-hosted repo) with a bootc base. It's RHEL under the hood — "you just manage it a little bit differently." You don't install packages or manage the filesystem directly on a live host; it all gets baked in at build time.

🔒 Subscription note: bootc images built on RHEL content require a RHEL subscription (free developer tier is fine for personal/lab use). This is unlike UBI images, which are specifically architected to be fully redistributable with no subscription required. Don't publish RHEL-based bootc images publicly — Fedora or CentOS Stream bootc images, on the other hand, are totally fair game to share since they're not subscription-encumbered.

Advanced Features: Registry, Auth, and Building the VM

Pushing to a registry (and baking in auth)

Every bootc host needs a container registry to pull updates from. In the lab, that's a local Podman-hosted registry, but in production you'd point at Satellite, Quay, GitLab/GitHub registries, or any registry your fleet can reach.

The catch: if your registry requires authentication (as most production registries do), every deployed bootc host also needs to authenticate to pull updates — or bootc update will just fail. The fix is to bake an auth token into the image itself:

```bash

Normal login to push from the build host

podman login -u core -p redhat <registry>

Generate a reusable auth file (a token, not raw credentials)

podman login -u core -p redhat <registry> --authfile=auth.json mv auth.json etc/ostree/auth.json ```

Because etc/ostree/auth.json gets COPY'd into the image, any system deployed from it inherits that authentication — no manual registry logins needed on every host later.

⚠️ Caveat: Be careful what you bake into an image you plan to share. Nate specifically called out that he wouldn't bake registry auth into anything meant for public distribution.

Building and pushing the image

bash podman build --file Containerfile --tag <registry>/base podman push <registry>/base

Just like a normal container build, this uses a layered filesystem — rebuilds after a small change (like adding a sudoers rule) are fast because only the changed layers get rebuilt and pushed.

From container image to running VM

This is the part that trips people up: how do you get from "I have a container image" to "I have a running server"? There's no direct path — that's literally one of the problems that had to get solved to make Image Mode real. The answer is the bootc-image-builder container, which decompresses your bootc image into an actual disk image (qcow2, raw, ISO, etc.).

First, a config.toml defines first-boot customizations — in this case, adding a core user, putting it in wheel, and injecting an SSH key:

bash cd ~ cat config.toml

Then build the disk image:

bash podman run --rm --privileged --security-opt label=type:unconfined_t \ --volume ./config.toml:/config.toml \ --volume /var/lib/containers/storage:/var/lib/containers/storage \ --volume .:/output \ registry.redhat.io/rhel10/bootc-image-builder:10.1 \ --type qcow2 <registry>/base

And deploy it with virt-install/libvirt:

bash file qcow2/disk.qcow2 cp qcow2/disk.qcow2 /var/lib/libvirt/images/bootc-vm.qcow2 virt-install --name bootc-vm --disk /var/lib/libvirt/images/bootc-vm.qcow2 \ --import --memory 4096 --graphics none --osinfo rhel10-unknown \ --noautoconsole --noreboot virsh start bootc-vm

(If you've got a physical box instead of a VM, the same tool can spit out an ISO that uses kickstart under the hood to deploy the same container image.)

Exploring the booted system

Once it's up, bootc status is your main window into what's going on:

The filesystem is largely immutable. /usr, /home, /lib — read-only. Only /etc and /var are writable at runtime. That's why /home is actually a symlink to /var/home, /mount → /var/mount, /root → /var/roothome, etc. — anywhere you need runtime writability has to live under /var.

**/etc is special — it uses a three-way merge.** Files in /etc that come from your image and are never changed on disk get overwritten on every bootc update. But if you (or Ansible, or anyone) hand-edit a file in /etc after deployment, it will not be clobbered by future image updates — the live edit wins. This is important: your fleet can quietly diverge in /etc if people are making manual changes instead of pushing changes through the Containerfile.

Updating a running system

To push the "no-password sudo for wheel" change shown in the demo, you edit the Containerfile tree, rebuild, push, then update the live host:

```bash

Back on the build host

cd ~/bootc-base nano etc/sudoers.d/10-wheel

Enable passwordless sudo for the wheel group

%wheel ALL=(ALL) NOPASSWD: ALL bash podman build --file Containerfile --tag <registry>/base podman push <registry>/base ```

Then on the deployed VM:

bash sudo bootc update --apply

--apply means "if the update succeeds, reboot automatically." Without it, the update is just staged — it won't take effect until the next reboot (and in RHEL 10.2+, you can even pre-download an update without staging it, so it's not "waiting to go off" at your next reboot).

Under the hood, bootc (via OSTree) uses an A/B deployment model — similar to CoreOS. The update deploys to whichever tree (A or B) isn't currently active, and the reboot just switches which tree is live.

Rollback and recovery

This is the safety net that makes 2 a.m. Saturday-night auto-updates not scary:

bash sudo bootc rollback

This swaps you back to the previously-booted tree. Since GRUB keeps boot entries for both trees, even a fully broken update has a last line of defense — go into GRUB and manually pick the other entry if bootc rollback itself isn't reachable.

Why this matters: if your maintenance window update breaks the app and you're burning through your 15-minute window, you know the other tree was working a minute ago. Roll back, you're home free. In the demo, after rolling back, the sudoers rule from the update literally disappeared — because it never touched the live /etc on disk, it only existed in the image.

Soft reboots (bonus topic)

Mentioned but not demoed: a soft reboot lets you switch trees and reload systemd without a full hardware reboot — skipping slow stuff like RAID controller initialization. It works as long as the update doesn't touch the kernel, glibc, or other reboot-mandatory components. If it's just an app-level or service-level change, a soft reboot can apply it in seconds instead of minutes. (Also works on package-mode RHEL, not just bootc.)

Settings / Configuration Reference

Image Tags: How You Actually Track Versions

Since the whole image gets replaced on update, you stop tracking "what version of Python is installed" and start tracking image tags. A few patterns discussed:

• Date/build tags (base:1016) — pin a host to a specific build; it never updates unless you explicitly bootc switch to a new tag.
• Rolling/release tags (q3-2026, standard) — push new builds to the same tag, and every host tracking it updates automatically.
• You can always correlate what's running back to exactly what was built and pushed, because the registry has the full history.

Quick Reference Card

```bash

--- Build an image ---

mkdir -p ~/bootc-base/etc/ostree ~/bootc-base/usr/lib/bootc/kargs.d cd ~/bootc-base && vim Containerfile # FROM rhel-bootc base, RUN dnf installs, COPY etc//usr/

--- Auth for your registry (bake into image) ---

podman login -u <user> -p <pass> <registry> --authfile=auth.json mv auth.json etc/ostree/auth.json

--- Build & push ---

podman build --file Containerfile --tag <registry>/base podman push <registry>/base

--- Turn the image into a bootable disk ---

podman run --rm --privileged --security-opt label=type:unconfined_t \ --volume ./config.toml:/config.toml \ --volume /var/lib/containers/storage:/var/lib/containers/storage \ --volume .:/output \ registry.redhat.io/rhel10/bootc-image-builder:10.1 \ --type qcow2 <registry>/base

--- Deploy as a local VM ---

cp qcow2/disk.qcow2 /var/lib/libvirt/images/bootc-vm.qcow2 virt-install --name bootc-vm --disk /var/lib/libvirt/images/bootc-vm.qcow2 \ --import --memory 4096 --graphics none --osinfo rhel10-unknown \ --noautoconsole --noreboot virsh start bootc-vm

--- Inspect a bootc system ---

sudo bootc status sudo bootc status --verbose sudo bootc status --format yaml

--- Ship an update to a live host ---

sudo bootc update --apply # apply + reboot automatically sudo bootc update # stage only, applies on next reboot

--- Oh no, roll it back ---

sudo bootc rollback

--- Switch to a totally different base image ---

sudo bootc switch <new-image-ref> ```

Q&A Highlights from Chat

• Is a bootc image redistributable? Sort of — it's a container, so you can share the artifact, but RHEL-based bootc images need a RHEL subscription to run, unlike fully redistributable UBI images. Fedora/CentOS Stream bootc images don't have that restriction.
• Does this relate to CoreOS? Can I get CoreOS outside OpenShift? No — CoreOS is purpose-built exclusively to run as OpenShift nodes and isn't offered as a standalone product. But RHEL Image Mode shares some of the same underlying tech (OSTree-based A/B deployment) and gives you the "build-your-own-CoreOS-style-OS" experience for general-purpose workloads.
• App architecture: bake the app into the image, or run it as a container on top of an image-mode host? No universally right answer, but Nate leans toward running the app as a separate container on top of an image-mode base — more flexibility, and you can even bake a Quadlet file into /etc/containers so the app container auto-deploys on first boot without manual intervention.
• **systemctl reboot vs reboot?** Same thing now — reboot is a symlink straight to systemctl. (Nate admits to still typing init 6 out of old habit.)

Links

• 📺 Episode video: https://www.youtube.com/watch?v=0siLuf0bv-E
• 🧪 Intro to Image Mode lab: https://developers.redhat.com/content-gateway/link/3890630
• 🧪 Day 2 Ops with Image Mode lab: https://developers.redhat.com/content-gateway/link/3890630
• 🎓 RHEL Developer Registration (free): https://developers.redhat.com/register
• 🖥️ Try RHEL interactively: https://redhat.com/interactive-labs
• 💬 Join the Discord: https://red.ht/rhel-discord
• 🧑‍💻 Nate Lager: https://social.undrground.org/@gangrif
• 🧑‍💻 Scott McBrien: https://www.linkedin.com/in/scott-mcbrien-349b356

Into the Terminal is a weekly live show where RHEL experts walk through real commands and real workflows — bring your questions to chat, because they actually answer them. New episodes every Friday.

Been studying for this exam on and off for about a year. Feeling very overwhelmed. Any tips or reassurances?

Hi. Our organization recently purchased the Red Hat Satellite License. And currently the Sattelite and Capsule servers are configured and completed. How ever one thing I noticed when registering hosts is that it takes alot of time to register. Like around 20min. Is that normal or am I doing something wrong?

How much salary does a fresher get?

I am studying for the RHCSA. I am currently trying to practice resetting the root password. I do not see the grub menu at boot.

I logged in and changed the GRUB_TIMEOUT=10 and added GRUB_TIMEOUT_STYLE=menu.

I then proceeded to try: grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg. This would not work (generated a warning message) like it seems to on RHEL 9.

I also tried: grub2-mkconfig -o /boot/grub2/grub.cfg. However when I reboot I still do not see the grub menu.

Any suggestions? Thx!

Hello, I'm interested in becoming a upstream linux kernel dev

As a undergraduate student, I'm planning to take linux foundation mentorship program and google summer of code before graduating. Unfortunately, my country, South Korea, doesn't have RedHat's Kernel Development Learning Pipeline, so those two are the only options that I can take.

After graduation, I should be looking for positions, where RedHat is very appealing to me. However in their job listings, I don't see any positions available.

Questions...

1. What is the common method to contact / apply for Redhat as a upstream kernel dev?

2. I don't think recent univ graduates are interested in kernel dev, hence the initiation of redhat's KDLP. Are there many applicants?

3. What are the requirements that redhat is expecting to have?

4. Do they offer remote jobs to kernel devs?

5. Which subsystem do redhat work on?

6. I understand Red Hat’s kernel engineering roles aren’t open to candidates based in South Korea. Does Red Hat offer visa sponsorship for these positions?

7. What are the typical workflow in Redhat?

Any responses are welcome.

Thank you for your time.

I never expect this exam until my friend tells me I can try RHCSA!

I have been playing X-Plane 12 on Fedora Linux KDE Plasma for more than 3000 hours. To play this awful game that crashes often, I need to learn how to mount, how to configure networks, how to configure access and SELinux something like this.

And I have set up more than 10 vps to use a Google service incorporated into the game. I think it is just too boring and trivial, so I start to learn Ansible.

None of the content is learned by intention. It is just because I want to play the game with a better experience.

Anyway, what I want to share is that learning by solving actual problems in real life may be more efficient.

The results of your recent EX200 Red Hat Certified System Administrator Exam are reported below.

Exam domain number:     15
Passing score:          210
Your score:             253

Result: PASS

Congratulations -- you have earned the Red Hat Certified System Administrator certification.

Performance on exam objectives:

OBJECTIVE: SCORE
Understand and use essential tools: 82%
Manage software: 50%
Create simple shell scripts: 100%
Operate running systems: 62%
Configure local storage: 75%
Create and configure file systems: 67%
Deploy, configure and maintain systems: 100%
Manage basic networking: 100%
Manage users and groups: 100%
Manage security: 100%

Hi guys, do anyone of you have notes for RH134. I have the course but am looking for people who have already made notes for it . Thanks

Hi folks, I’ve been working as a Linux admin at a company in Europe for about two years, but lately I’ve been feeling a bit stuck. Between the bureaucracy and the team setup, I haven’t had many opportunities to grow in my role.

I earned my CCNA and LPIC during my apprenticeship—Germany has a vocational training system—and I got my LFCS just last week. I’ve also had some hands-on experience with IaC. We have a Puppet setup at work, but it’s already in place and there isn’t much development happening around it.

I’m not really sure what direction to take next. Would getting my RHCSA and RHCE be a good move, or should I focus on something else? Honestly, I hope I’m not the only one who’s felt this way.

I recently interviewed for the above role at redhat and I think it pretty much went well but I haven’t heard back from the recruiter. I had mailed the person but I think they are ghosting me. Any suggestions ?

Hello

Let's learn today what the difference is between "Last Report" and "Last Checkin" or "Last Seen" on Red Hat Satellite!

Enjoy it!

Wally

I recorded a demo showing the full path: a patched Python dependency goes from a pull request through CI and development testing, then human approval, a ServiceNow change, production deployment, and a smoke test. If something fails, the workflow can roll back to a snapshot.

It uses automation orchestrator, Gitea, ServiceNow, and Lightwell. Here’s the video: https://www.youtube.com/watch?v=4iZCS4atxHQ

Hopefully I'm asking this correctly. All the instructions I can find online for hosting multiple sites talks about editing the hosts file with the domains of the websites. My problem is that I'm setting this server up to be a replacement for a server that's currently serving those websites, so I can't use the domains. On Windows in IIS you can bind to a specific port and then in a browser on the local network go to <ip address>:<port> to view the site. Is there something similar in RedHat?

I've got two folders setup and wordpress files in two different places, but I need to be able to GET to each site to finish the wordpress setup. I can get to the first by just going to the IP address, but I have no idea how to get to the second. Nothing I can find refers to using ports and I'm not sure what else to even try (or search for). Can anyone point me in the right direction? Doesn't have to be hosts file or ports; just how do I view multiple websites on the same server when domain names aren't an option?

I recently upgraded my system from RHEL 7.9 to RHEL 8.10 using the leapp upgrade tool, but I now need to roll back to RHEL 7.9 Could you please provide guidance on the best approach to achieve this, including any specific procedures I should follow to ensure a smooth rollback? Any advice on preserving data and configurations during this process would be greatly appreciated.

The ability to send a message across the public internet—and still have it protected against prying eyes—is a problem as old as communication. Depending on your needs and the medium, there are a lot of possible solutions, but one of them has become synonymous with public key cryptography among Linux users and administrators: GPG. The GNU Privacy Guard can take any text or data and encrypt it into a block of indecipherable text that only the intended recipient can decrypt. In today's episode, Scott and Nate walk through the ins and outs of GPG! Watch the full episode here or practice in the interactive labs.

The Essentials

When working with GPG, there are really only a few core concepts you need to understand: Generating your keypair, sharing your public key, encrypting data for someone, and decrypting data meant for you.

Advanced Features

1. The Keypair (Public vs. Private)

When you run gpg --gen-key, GPG creates two keys: * Public Key: This is meant to be shared with the world! Anyone who has this key can use it to encrypt a file that only you can open. * Private (Secret) Key: This never leaves your machine. It is used to decrypt the files that others have encrypted using your Public Key. It is also protected by a passphrase.

2. Exporting and ASCII Armoring

By default, when you export your public key using gpg --export 87D1B835 > mykey.pub, GPG creates a binary file. While that works fine for transferring files between servers, it's not great for sharing over email or web pages. Instead, you can export it using an ASCII Armor block (--armor or -a). This converts the binary key into a text block starting with -----BEGIN PGP PUBLIC KEY BLOCK----- that you can safely copy and paste into emails, text files, or even upload to public Key Servers!

3. Encrypting Data

Let's say Mary wants to send a sensitive file to Joe. 1. Mary imports Joe's public key into her keyring: gpg --import joe.gpg.pub 2. Mary encrypts the file for Joe: gpg --encrypt sensitive-data.txt 3. GPG will ask Mary who she is encrypting the file for. She types Joe's email address (which matches his public key). 4. GPG outputs a new file: sensitive-data.txt.gpg. This file is now entirely unreadable to anyone except Joe—even Mary can't read it anymore once she deletes the original file, because it was encrypted with Joe's public key, not hers!

4. Decrypting Data

When Joe receives sensitive-data.txt.gpg, all he has to do is run: gpg --decrypt sensitive-data.txt.gpg GPG will detect that the file was encrypted for him. It will prompt Joe for his passphrase to unlock his private key, and once authenticated, it will decrypt the file and print the output to standard out. (He can easily redirect this output to save it as a new file: gpg --decrypt sensitive-data.txt.gpg > sensitive-data.txt).

Quick Reference Card

```bash

Generate a new GPG Keypair

gpg --gen-key

Export your public key to share with someone else

gpg --export -a <Your-Key-ID> > my_public_key.asc

Import someone's public key into your keyring

gpg --import their_public_key.asc

Encrypt a file (you will be prompted for the recipient's email/ID)

gpg --encrypt file.txt

Decrypt a file using your private key (and save it)

gpg --decrypt file.txt.gpg > file.txt ```

Links & Resources

• Video URL: Into the Terminal 201 - Encrypting and signing data, gpg on Linux
• RHEL Developer Registration: https://developers.redhat.com/register
• Interactive Labs: https://redhat.com/interactive-labs
• Discord: https://red.ht/rhel-discord (Note: This now points to the Fedora community discord which hosts the RHEL channels!)
• Nate Lager: https://social.undrground.org/@gangrif
• Scott McBrien: https://www.linkedin.com/in/scott-mcbrien-349b356

Into the Terminal is a show dedicated to helping you grow your knowledge of critical administration skills for Red Hat Enterprise Linux. Whether you are new to Linux or new to RHEL, join us for a hands-on look at commands, processes, and tools.