I Found Out Way Too Late That screen Is “Vintage” in RHEL 8… and I Survived to Tell the Tale

 Recently, I needed to run some commands in the background and, like a true terminal veteran, I thought: “Perfect, I’ll just use screen.” Ah, the innocence. 😅

Turns out, on RHEL 8, screen is basically ancient, because according to Red Hat, it “uses obsolete code.” Of course! And I’m only finding this out now, when I actually need it? Perfect timing, as always.

After reading it in a RedHat KN, I couldn't believe it.

I reminded myself  tmux. And honestly… it’s not bad at all. Even has more tricks than screen.

Here’s a mini tutorial to get you out of trouble:

Install tmux

dnf install tmux

Create a new session

tmux new -s my_session

• my_session → session name

Detach while keeping everything running

Ctrl + b  →  d

Reattach to a session

tmux ls
tmux attach -t my_session

Run a command directly in the background

tmux new -d -s my_session 'my_command'

Useful commands inside tmux

• Create a new window: Ctrl + b → c

• Switch window: Ctrl + b → n (next) / p (previous)

• Close window: exit or Ctrl + d

💡 Tip: If you were using screen -S name -d -m command, in tmux it’s:

tmux new -d -s name 'command'

Pretty much the same, but without feeling like you’re using a digital fossil.

---

Moral of the story: sometimes technology evolves faster than our sysadmin ego. And yes, laughing at yourself is mandatory when you realize your beloved screen is “retro” and the modern world answers to tmux. 😂

RHEL Booting into an Old Kernel? Here’s the Fix

 On my RHEL 8.10 system, I noticed that even though the latest kernel was installed, the server kept booting with an older one.

The Cause

GRUB was configured to use the last saved kernel entry (saved_entry) instead of automatically picking the most recent kernel.

The Solution

The fix was simple: edit the GRUB configuration and tell it to always boot the first entry (which is the newest kernel).

1. Open /etc/default/grub and set:

   GRUB_DEFAULT=0
   

2. Regenerate the GRUB configuration:

   • BIOS:

     grub2-mkconfig -o /boot/grub2/grub.cfg
     

   • UEFI:

     grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
     

3. Reboot the server:

   reboot
   

After that, the system automatically boots into the latest installed kernel every time. 🚀

Mounting Azure Blob Storage on Linux with a Service Principal Securely

 Historically, the most common way to mount Azure Blob Storage as a file system on Linux has been using the storage account key. However, this method presents two significant security risks:

1. The account key grants full access to all containers and resources, breaking the principle of least privilege.

2. The key must be stored in a plain text configuration file, which is a poor security practice.

The modern and recommended solution is to use an Azure AD Service Principal (SPN) in conjunction with BlobFuse, Azure's FUSE driver.

The Secure Alternative: Service Principal and RBAC

By using a Service Principal, you can:

• Apply Role-Based Access Control (RBAC) to assign granular permissions, such as the Storage Blob Data Contributor role, which only allows access to blob data, not account management.

• Avoid exposing the master account key.

• Enable key rotation or use certificates for even greater security.

The BlobFuse Twist on Linux

The main difference when using a Service Principal with BlobFuse is how the client secret is handled. Unlike other parameters, the secret is not included in the .cfg configuration file.

The configuration file (.cfg) only requires the following data:

accountName <storage-account-name>
authType SPN
containerName <container-name>
servicePrincipalClientId <client-id-of-the-service-principal>
servicePrincipalTenantId <tenant-id>

The client secret must be injected as an environment variable named AZURE_STORAGE_SPN_CLIENT_SECRET.

AZURE_STORAGE_SPN_CLIENT_SECRET="xxxxxxxxxxxx"

This prevents the secret from being exposed in a plain text file that could be accessible to other users on the system.

Practical Example on Ubuntu

To ensure the secret is available to BlobFuse when the system boots (for instance, if you're using an entry in /etc/fstab), the most straightforward way is to add the environment variable to /etc/environment.

1. Define the Secret

Edit the /etc/environment file and add the variable at the end:

sudo nano or vi /etc/environment

Add this line:

AZURE_STORAGE_SPN_CLIENT_SECRET="aaffEERR~3_LyAI..."

Note: By default, /etc/environment is world-readable. For stricter security, consider using a private systemd EnvironmentFile with chmod 600 permissions.

2. Create the BlobFuse Configuration File

Create a configuration file (e.g., storage.cfg) and ensure it only contains the Service Principal IDs and account information, without the secret.

accountName myblobaccount
authType SPN
containerName mycontainer
servicePrincipalClientId 12345678-abcd-efgh-1234-567890abcdef
servicePrincipalTenantId abcdef12-3456-7890-abcd-efgh12345678

3. Mount the Container

Now you can mount the container using the blobfuse command or by configuring an entry in /etc/fstab. BlobFuse will automatically pick up the secret from the environment variable.

With the AZURE_STORAGE_SPN_CLIENT_SECRET variable defined, simply run:

sudo blobfuse /path/to/mountpoint --config-file=/path/to/storage.cfg

If you're using /etc/fstab, the entry would look like this:

/path/to/storage.cfg /mnt/mycontainer blobfuse defaults,allow_other 0 0

Conclusion

Using a Service Principal to mount Azure Blob Storage on Linux with BlobFuse is a much more secure practice than using the account key. By keeping the client secret as an environment variable, you strengthen security and align with Azure AD and RBAC best practices, avoiding the exposure of sensitive credentials in configuration files. This "quirk" in the configuration is, in fact, a key security feature.