FranGarcia.me (Posts about rhel)

Reminder: Linux disk device names are not persistent or predictable

Fran Garcia — Sun, 06 Apr 2025 09:50:47 GMT

Repeat with me:

Linux disk device names are not persistent or predictable

These two Red Hat KCS notes provide lots of information:

https://access.redhat.com/solutions/3962551 - How to make disk letter /dev/sdX more likely to be consistent at each reboot
https://access.redhat.com/solutions/2975361#RHEL9_ASYNC - How are custom persistent names assigned for SCSI devices using udev in Red Hat Enterprise Linux 7 and later kernels?

... but TLDR: disk under /dev/sd* and /dev/vd* are not persistent nor guaranteed to be predictable in any newer kernel version.

DO:

Rely on filesystem's UUID for /etc/fstab mount settings (see blkid)
Use persistent names like: DM multipath, LVM device names, kernel persistent names (/dev/disk-by-*), or udev-assigned custom names.

DO NOT:

Try to create names in the /dev/sd* namespace.
Try to ensure /dev/sd* are consisent across machines, or even reboots of the same machine. They won't be.
Try to implement kernel or module options, they will fail.

If you find any software that tries to impose any logic into the /dev/sd* namespace, that software is buggy and must be rewritten accordingly.

Happy hacking!

Registering old RHEL systems into new Satellite versions

Fran Garcia — Mon, 24 Apr 2023 10:37:03 GMT

Sometimes you find out you need to register really ancient Red Hat Enterprise Linux systems into a new Satellite, but this poses a number of challenges, namely around support, and having the right tools in the system (subscription-manager, curl and others) available so the system can be successfully managed by Red Hat Satellite.

Supported Satellite client operating systems

Red Hat maintains a list of supported operating systems per version on Satellite here:

https://access.redhat.com/solutions/5607011 - What are the supported operating systems for hosts of Red Hat Satellite 6 ?

The reality is a bit more complex, as Red Hat only tests new Satellite versions with actively supported RHEL operating systems. For RHEL6, this means that the only tested combinations are those using RHEL 6.10 using the ELS (Extended Lifecycle Support) add-on.

For ancient RHEL 7.0 and RHEL 7.1 versions, it's even more complicated because curl lacks some cryptographic cyphers, which make connecting to Satellite impossible.

The workaround is to upgrade the relevant system packages to the latest version PRIOR to attempting to register the system into Satellite 6.x .

So here are some notes on how to accomplish that:

Registering RHEL 6 older than 6.10 are not supported with Satellite 6.10+. Registration does not work.

It is required to update the subscription-manager, rpm, and other components to those provided by RHEL 6.10 prior to onboarding the system into Satellite 6.12 .
This process might render the "subscription-manager" inoperable. It is recommended to perform a full backup of the system, and implement access to the RHEL 6.10 DVD prior to attempting this upgrade.
The RHEL 6.10 content can be made available via the RHEL ISO, or hosted in a web server or NFS server.
Red Hat Engineering does not certify a full list of packages that need to be upgraded. However, when testing the following list of packages seems to be sufficient to allow a successful registration:
yum upgrade -y "yum*" "subscription-manager*" "rpm" python-requests.noarch python-rhsm.x86_64 python-six.noarch python-urlgrabber.noarch python-urllib3.noarch openssl
More packages might be required depending on the installed packages in the managed system that needs to be migrated.

RHEL 7.0 and RHEL 7.1 cannot be registered with Satellite.

In a similar way to RHEL 6, RHEL 7.0 and RHEL 7.1 cannot connect to a new satellite because of openssl ciphers and because of subscription-manager components. Registration errors might include curl: (35) Peer reports incompatible or unsupported protocol version.
The problem can be solved by upgrading the following packages prior to registration. Packages should come from RHEL 7.9.
yum upgrade -y openssl curl "yum*" "subscription-manager*" "rpm" python-six python-rhsm
Again, this process might render the "subscription-manager" inoperable. It is recommended to perform a full backup of the system, and implement access to the RHEL 7.9 DVD prior to attempting this upgrade.
The RHEL 7.9 content can be made available via the RHEL ISO, or hosted in a web server or NFS server.

Happy Satellite-ing!

Configurar mDNS en RHEL6

Fran Garcia — Sun, 05 Aug 2012 21:03:00 GMT

Por alguna razón que no alcanzo a comprender, RHEL6 no incluye de forma predeterminada el paquete nss-mDNS necesario para que el DNS multicast funcione (Avahi/Zeroconf et al).

Aquí va una pequeña guía de instalación y configuración, incluyendo el repositorio externo EPEL:

[root@rhel6 ~]# yum install -y avahi avahi-tools  
[root@rhel6 ~]# yum install -y --nogpgcheck http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm  
[root@rhel6 ~]# yum install -y nss-mdns

Modificar en el /etc/nsswitch.conf :

# grep hosts /etc/nsswitch.conf  
hosts: files dns4_minimal [NOTFOUND=return] mdns4_minimal [NOTFOUND=return] dns

Y finalmente reiniciar DBus y Avahi-daemon:

[root@rhel6 ~]# chkconfig messagebus on  
[root@rhel6 ~]# chkconfig avahi-daemon on  
[root@rhel6 ~]# service messagebus restart  
Stopping system message bus: [FAILED]  
Starting system message bus: [ OK ]  
[root@rhel6 ~]# /etc/init.d/avahi-daemon restart  
Shutting down Avahi daemon: [FAILED]  
Starting Avahi daemon... [ OK ]

De esta forma, todos los dispositivos que estén directamente conectados en nuestra red local (VLAN) serán capaces de conocernos bajo el nombre rhel6.local , o el hostname que tengamos configurado y .local . Muy cómodo si no tenemos ningún servidor DNS en nuestra red o para dispositivos itinerantes :-)