home.social

#rhel — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #rhel, aggregated by home.social.

  1. Spent 14 hours on my feet having conversations with #RedHat customers today. Back to my hotel, and glad to be off my feet. Sure is a nice view from my room though. #rhsummit #rhel #sysadmin

  2. Spent 14 hours on my feet having conversations with #RedHat customers today. Back to my hotel, and glad to be off my feet. Sure is a nice view from my room though. #rhsummit #rhel #sysadmin

  3. Spent 14 hours on my feet having conversations with #RedHat customers today. Back to my hotel, and glad to be off my feet. Sure is a nice view from my room though. #rhsummit #rhel #sysadmin

  4. Spent 14 hours on my feet having conversations with #RedHat customers today. Back to my hotel, and glad to be off my feet. Sure is a nice view from my room though. #rhsummit #rhel #sysadmin

  5. Spent 14 hours on my feet having conversations with #RedHat customers today. Back to my hotel, and glad to be off my feet. Sure is a nice view from my room though. #rhsummit #rhel #sysadmin

  6. RHEL Forever - starting this summer, you can buy a yearly extension to prolong regular 14yrs support of #RHEL. You can extend it indefinitely if you want to. Although every consequent extension will be slightly higher than the previous one.
    redhat.com/en/about/press-rele

  7. @zak So. I’m at the Red Hat Summit this week and there is discussion about something you might be interested in.

    bootc (the main tool for RHEL Image Mode) allows you to basically create your own immutable OS image. It’s sort of like… rolling your own distro but using tools similar to creating docker container images rather than compiling from scratch.

    The intent is of course virtualization - but you can deploy them on bare metal.

    docs.fedoraproject.org/en-US/b

    It may be a heavier lift than you want to mess with - but it’s pretty interesting nonetheless.

    #bootc #fedora #rhel #imagemode #RedHatSummit

  8. Linux zero-day “Dirty Frag” lets local users gain root on major distros by chaining kernel page-cache flaws with no race condition required 🐧⚠️
    Ubuntu, Fedora, RHEL and openSUSE remain unpatched, while temporary mitigations disable modules tied to IPsec VPN and AFS support 🔓

    🔗 bleepingcomputer.com/news/secu

    #TechNews #Linux #DirtyFrag #ZeroDay #CyberSecurity #Kernel #Ubuntu #Fedora #RHEL #OpenSUSE #Privacy #FOSS #Security #Infosec #OpenSource

  9. From waiting for #RHEL to release an update for #copyfail to waiting for RHEL to release an update for #dirtyfrag

    Time to change career and open a bar on a beach? 🤷‍♂️

  10. @[email protected] @[email protected]

    Don't get me wrong, I'm
    all too familiar with customers running (severely) back-rev systems.

    Back in 2019, I was helping a customer migrate from on-prem to
    #AWS. All of their component programs that they'd made us aware of were running on #RHEL 7. So, all the prep work we did was around RHEL 7. A few days before year's end, we get an email saying, "oh: we have some solutions hosted on RHEL 6 that we need to migrate, too". We had no repository services or AMIs conformant with their standard builds ready for that. So, there was a bit of a scramble to update the destination AWS accounts to be able to support their EL6-using solution.

    A few years later, the same customer re-engaged us to help them migrate to EL8. While we'd long since had EL8-based automation (etc.) built and, indeed, had already gotten EL9-based automation (etc.) ready to go, it was still utter chaos. Ultimately, they didn't start migrating to EL8 until patches for EL7 had become unavailable.

    Shit-show.

  11. New info and links on sketchesfromahomelab.com/artic

    - A patched kernel for RHEL systems is now available!
    - Added links to the original 2017 commit introducing the #CopyFail bug and to the patch fixing it. Also included a list of the Linux kernel versions containing the patch. Hopefully this will help those that compile their own kernels!
    - Added a link to GrapheneOS's analysis that Android is NOT vulnerable to Copy Fail due to its extensive use of SELinux and its prohibition on setuid/setgid binaries. I know a lot of people were concerned about Android devices, especially older ones, so this is welcome news.

    People needing more information about the patched RHEL kernel can go to:

    access.redhat.com/errata/RHSA-

    #copyfail #cve_2026_31431 #linux #security #rhel

  12. ¿No creeis que es un poco contradictorio hablar de soberania digital europea y certificar a RHEL (empresa norteamericana) para el sector publico español?
    #linux #rhel #ue #espana
    muylinux.com/2026/04/28/red-ha

  13. Fresh gist: mitigating CVE-2026-31431 ("Copy Fail") on RHEL 8/9/10 with a tiny Ansible playbook.

    It blacklists algif_aead via a kernel boot arg (initcall_blacklist=algif_aead_init), reboots only when needed, and asserts the mitigation actually stuck after reboot. Idempotent & safe to re-run.

    codeberg.org/Larvitz/gists/src

    #Ansible #RHEL #Linux #InfoSec #SysAdmin #DevOps #CVE #CVE_2026_31431 #copyfail

  14. New blog post: Ansible-Native Quadlets: Deploying a Mastodon Greeter Bot with containers.podman

    Hand-written Quadlet files are great for one host. For a small fleet, I want them in Ansible: templated config, registry login, Podman secrets, systemd handlers, SELinux labels, and repeatable deployment.

    The example: a tiny Mastodon welcome bot running as a Podman Quadlet-managed systemd service.

    blog.hofstede.it/ansible-nativ

    #Linux #Ansible #Podman #Quadlet #systemd #Mastodon #SelfHosting #RHEL

  15. Bash has a lot of shortcuts, a lot of them aren’t obvious, but you pick them up over the years. Watch Scott and Nate share their favorite command line tricks and shortcuts on this episode of Into the Terminal.

    youtube.com/live/alZMRigqChc

    #linux #linuxtips #sysadmin #redhat #rhel #bash #commandline

  16. Today's the day! I'm on stage this afternoon at LinuxFest Northwest.

    "Escaping the End-of-Life Nightmare: Lessons from the Linux Graveyard" 🪦

    Every Linux admin has a story. A server nobody touched for years. A distro that hit EOL while carrying something critical. A 2AM phone call that didn't have to happen.

    If you're in Bellingham, come find me.

    #LinuxFestNorthwest #LFNW #Linux #OpenSource #DevOps #SysAdmin #RHEL #RockyLinux

  17. Sengaja tulis ini pakai akun misskey biar gak kejedot limit karakter.

    Mengapa saya menggunakan dan menginstruksikan lingkungan yang berada dalam kendali saya menggunakan #podman bukan #docker dalam menjalankan #container

    Pertama, docker membutuhkan daemon (yang defaultnya berjalan sebagai root) sedangkan podman sifatnya daemonless. Disini ada single point-of-failure. Sehingga jika ada bug atau apa, docker akan lebih rentan bisa menganggu host. Selain itu hal ini mengharuskan user yang ingin menjalankan container harus tergabung dalam group docker. Berbeda dengan podman dimana container yang dijalankan akan menjadi child-process dari user yang menjalankan.

    Ada update pada runtime docker? Kita harus me-restart daemon docker dan artinya akan me-restart semua container yang berjalan.

    Docker (katanya) fokus pada masing-masing container dan mengandalkan tool docker-compose untuk membungkus beberapa container, sedangkan podman mengenal konsep pod secara native yang menyerupai konsep pada pengoperasian #kubernetes. Bahkan podman bisa membuat yaml kubernetes dari pod.

    Podman hanya kalah popular. Mungkin ini disebabkan karena docker adalah pelopor yang sukses. Mungkin anda akan berpikir kan banyaknya container-container yang tersedia adalah untuk docker seperti yang tersaji di Docker Hub. Tapi tahukah anda? Container image podman dan docker adalah sama, mengikuti standar OCI (Open Container Initiative). Jadi anda dapat menjalankan semua container image yang tersedia di Docker Hub dan container registry lain seperti #ghcr atau #quay dengan menggunakan podman.

    Integrasi container-container dengan sistem juga akan lebih sederhana (kalau anda sudah menyadarinya). Docker menggunakan mekanisme sendiri untuk start/stop/restart container. Sedangkan container pada podman bisa sangat terintegrasi dengan #systemd, apalagi sejak dikenalkannya #quadlet. Format file quadlet sangatlah identik dengan file unit servis systemd. Dengan penggunaan quadlet, anda dapat start/stop/restart dengan menggunakan systemctl nya systemd.

    PS: Penjelasan tadi adalah jawaban formal. Sebenarnya mengapa saya menggunakan podman adalah karena saya pengguna setia environment #Fedora dan #RHEL ✌✌✌✌✌
  18. Sengaja tulis ini pakai akun misskey biar gak kejedot limit karakter.

    Mengapa saya menggunakan dan menginstruksikan lingkungan yang berada dalam kendali saya menggunakan #podman bukan #docker dalam menjalankan #container

    Pertama, docker membutuhkan daemon (yang defaultnya berjalan sebagai root) sedangkan podman sifatnya daemonless. Disini ada single point-of-failure. Sehingga jika ada bug atau apa, docker akan lebih rentan bisa menganggu host. Selain itu hal ini mengharuskan user yang ingin menjalankan container harus tergabung dalam group docker. Berbeda dengan podman dimana container yang dijalankan akan menjadi child-process dari user yang menjalankan.

    Ada update pada runtime docker? Kita harus me-restart daemon docker dan artinya akan me-restart semua container yang berjalan.

    Docker (katanya) fokus pada masing-masing container dan mengandalkan tool docker-compose untuk membungkus beberapa container, sedangkan podman mengenal konsep pod secara native yang menyerupai konsep pada pengoperasian #kubernetes. Bahkan podman bisa membuat yaml kubernetes dari pod.

    Podman hanya kalah popular. Mungkin ini disebabkan karena docker adalah pelopor yang sukses. Mungkin anda akan berpikir kan banyaknya container-container yang tersedia adalah untuk docker seperti yang tersaji di Docker Hub. Tapi tahukah anda? Container image podman dan docker adalah sama, mengikuti standar OCI (Open Container Initiative). Jadi anda dapat menjalankan semua container image yang tersedia di Docker Hub dan container registry lain seperti #ghcr atau #quay dengan menggunakan podman.

    Integrasi container-container dengan sistem juga akan lebih sederhana (kalau anda sudah menyadarinya). Docker menggunakan mekanisme sendiri untuk start/stop/restart container. Sedangkan container pada podman bisa sangat terintegrasi dengan #systemd, apalagi sejak dikenalkannya #quadlet. Format file quadlet sangatlah identik dengan file unit servis systemd. Dengan penggunaan quadlet, anda dapat start/stop/restart dengan menggunakan systemctl nya systemd.

    PS: Penjelasan tadi adalah jawaban formal. Sebenarnya mengapa saya menggunakan podman adalah karena saya pengguna setia environment #Fedora dan #RHEL ✌✌✌✌✌
  19. Sengaja tulis ini pakai akun misskey biar gak kejedot limit karakter.

    Mengapa saya menggunakan dan menginstruksikan lingkungan yang berada dalam kendali saya menggunakan #podman bukan #docker dalam menjalankan #container

    Pertama, docker membutuhkan daemon (yang defaultnya berjalan sebagai root) sedangkan podman sifatnya daemonless. Disini ada single point-of-failure. Sehingga jika ada bug atau apa, docker akan lebih rentan bisa menganggu host. Selain itu hal ini mengharuskan user yang ingin menjalankan container harus tergabung dalam group docker. Berbeda dengan podman dimana container yang dijalankan akan menjadi child-process dari user yang menjalankan.

    Ada update pada runtime docker? Kita harus me-restart daemon docker dan artinya akan me-restart semua container yang berjalan.

    Docker (katanya) fokus pada masing-masing container dan mengandalkan tool docker-compose untuk membungkus beberapa container, sedangkan podman mengenal konsep pod secara native yang menyerupai konsep pada pengoperasian #kubernetes. Bahkan podman bisa membuat yaml kubernetes dari pod.

    Podman hanya kalah popular. Mungkin ini disebabkan karena docker adalah pelopor yang sukses. Mungkin anda akan berpikir kan banyaknya container-container yang tersedia adalah untuk docker seperti yang tersaji di Docker Hub. Tapi tahukah anda? Container image podman dan docker adalah sama, mengikuti standar OCI (Open Container Initiative). Jadi anda dapat menjalankan semua container image yang tersedia di Docker Hub dan container registry lain seperti #ghcr atau #quay dengan menggunakan podman.

    Integrasi container-container dengan sistem juga akan lebih sederhana (kalau anda sudah menyadarinya). Docker menggunakan mekanisme sendiri untuk start/stop/restart container. Sedangkan container pada podman bisa sangat terintegrasi dengan #systemd, apalagi sejak dikenalkannya #quadlet. Format file quadlet sangatlah identik dengan file unit servis systemd. Dengan penggunaan quadlet, anda dapat start/stop/restart dengan menggunakan systemctl nya systemd.

    PS: Penjelasan tadi adalah jawaban formal. Sebenarnya mengapa saya menggunakan podman adalah karena saya pengguna setia environment #Fedora dan #RHEL ✌✌✌✌✌
  20. Sengaja tulis ini pakai akun misskey biar gak kejedot limit karakter.

    Mengapa saya menggunakan dan menginstruksikan lingkungan yang berada dalam kendali saya menggunakan #podman bukan #docker dalam menjalankan #container

    Pertama, docker membutuhkan daemon (yang defaultnya berjalan sebagai root) sedangkan podman sifatnya daemonless. Disini ada single point-of-failure. Sehingga jika ada bug atau apa, docker akan lebih rentan bisa menganggu host. Selain itu hal ini mengharuskan user yang ingin menjalankan container harus tergabung dalam group docker. Berbeda dengan podman dimana container yang dijalankan akan menjadi child-process dari user yang menjalankan.

    Ada update pada runtime docker? Kita harus me-restart daemon docker dan artinya akan me-restart semua container yang berjalan.

    Docker (katanya) fokus pada masing-masing container dan mengandalkan tool docker-compose untuk membungkus beberapa container, sedangkan podman mengenal konsep pod secara native yang menyerupai konsep pada pengoperasian #kubernetes. Bahkan podman bisa membuat yaml kubernetes dari pod.

    Podman hanya kalah popular. Mungkin ini disebabkan karena docker adalah pelopor yang sukses. Mungkin anda akan berpikir kan banyaknya container-container yang tersedia adalah untuk docker seperti yang tersaji di Docker Hub. Tapi tahukah anda? Container image podman dan docker adalah sama, mengikuti standar OCI (Open Container Initiative). Jadi anda dapat menjalankan semua container image yang tersedia di Docker Hub dan container registry lain seperti #ghcr atau #quay dengan menggunakan podman.

    Integrasi container-container dengan sistem juga akan lebih sederhana (kalau anda sudah menyadarinya). Docker menggunakan mekanisme sendiri untuk start/stop/restart container. Sedangkan container pada podman bisa sangat terintegrasi dengan #systemd, apalagi sejak dikenalkannya #quadlet. Format file quadlet sangatlah identik dengan file unit servis systemd. Dengan penggunaan quadlet, anda dapat start/stop/restart dengan menggunakan systemctl nya systemd.

    PS: Penjelasan tadi adalah jawaban formal. Sebenarnya mengapa saya menggunakan podman adalah karena saya pengguna setia environment #Fedora dan #RHEL ✌✌✌✌✌
  21. Never assume that just because a server is Ubuntu or RHEL, that its filesystem is ext4 or XFS.

    Always verify with `df -hT` or `lsblk -f` before you start tuning mount options or disk quotas. Assumptions are the fastest way to break a perfectly good configuration (speaking from new experience). A two-second check ensures you are working with the right metadata before you begin the initialisation process.

    Verification over guesswork, every time.

    #linux #sysadmin #devops #rhel #ubuntu #archlinux #comptia #learning

  22. Two things I noticed:

    The microshift-olm package provices the Operator Lifecycle Manager, but apparently only a very limited subset. I could not get it working at all.
    github.com/openshift/microshif

    There are packages for ArgoCD, called microshift-gitops. Those install a part of ArgoCD. You get the repo-server, redis and the application-controller. But no WebUI. I have not found out yet, if I can still use the argocd CLI to connect to the cluster and e.g. sync an application, as it normally (AFAIK) relies on the web component being exposed via ingress, loadbalancer or port-forward. I'll report back if I get it working. Other than the missing WebUI, it does what ArgoCD is supposed to do: sync stuff into the cluster. Nice.

    #OpenShift #MicroShift #Kubernetes #DevOps #Linux #RHEL #HellYeah #SelfHosting

  23. Two things I noticed:

    The microshift-olm package provices the Operator Lifecycle Manager, but apparently only a very limited subset. I could not get it working at all.
    github.com/openshift/microshif

    There are packages for ArgoCD, called microshift-gitops. Those install a part of ArgoCD. You get the repo-server, redis and the application-controller. But no WebUI. I have not found out yet, if I can still use the argocd CLI to connect to the cluster and e.g. sync an application, as it normally (AFAIK) relies on the web component being exposed via ingress, loadbalancer or port-forward. I'll report back if I get it working. Other than the missing WebUI, it does what ArgoCD is supposed to do: sync stuff into the cluster. Nice.

    #OpenShift #MicroShift #Kubernetes #DevOps #Linux #RHEL #HellYeah #SelfHosting

  24. Dear Openshift and Kubernetes users,

    after my single-node OpenShift cluster broke for the third time (pods not coming up, no idea what went wrong this time), I reinstalled the machine and tried MicroShift.

    I overlooked the tiny detail in the documentation that there are subscription repos for RHEL10, but only packages for RHEL9. So I had to reinstall my machine after trying RHEL10 first.

    In general microshift seems to be an easy way to get a OpenShift-like "cluster" running on a single machine. I'll report back once I did some more thorough testing.

    #OpenShift #MicroShift #Kubernetes #DevOps #Linux #RHEL #HellYeah #SelfHosting

  25. Running your own identity provider is all fun and games until you're debugging OIDC token flows at 2 AM.

    If you want to deploy Keycloak 26 the right way - with proper network isolation, no plaintext passwords, and systemd-native declarative configs. I just published a new deep-dive.

    We're ditching compose files and building a production-ready, daemonless stack using Podman Quadlets and systemd.

    Read the full guide here: blog.hofstede.it/keycloak-26-o

    #Linux #Podman #Keycloak #systemd #DevOps #Containers #SelfHosted #RHEL #Security

  26. From last week's Linux Update newsletter: Joe Casad explores the @almalinux Build System, which lets you build, test, sign, and release packages from a single interface
    linux-magazine.com/Online/Feat

  27. If you want to test the new #Kafka source from the upcoming #syslog_ng release, there is now an easy way if you are on @opensuse / #SLES or @fedora / #RHEL (and compatibles). Just use my syslog-ng git snapshot repo:
    syslog-ng.com/community/b/blog

  28. If you want to test the new source from the upcoming release, there is now an easy way if you are on @opensuse / or @fedora / (and compatibles). Just use my syslog-ng git snapshot repo:
    syslog-ng.com/community/b/blog