Reporting on AL9?

Hi folks. Where can I post some findings about AL9? I’ve found some differences that I’m thinking are significant.


I guess you could put up a web page, or even open a thread here. I don’t think there’s a real official channel yet. The site has a blog and wiki. If what you’ve found is a bug that isn’t in RHEL, that site’s resources section shows

Well, just some behaviours that I’m not really sure are deliberate.

If you don’t feel they are really bugs, you could always mention them here, and see what people think.

I’m seeing that 9.0 and 8.6 behave differently in that in a script, using sudo filename requires a password in 9, and not in 8.6. It got me wondering which one was intended.

RHEL 8 and RHEL 9 (and hence Alma 8 and 9) are two entirely separate Linux distro’s. Being both created by Red Hat, they do have some similarities. The 8 was released in 2019 and the 9 in 2022. The entire point of new “major version” is to not be same old, same old.

Therefore, if RHEL 9 is different from RHEL 8, that is either by (Red Hat’s) design, or less likely by (their) mistake.

If Alma 8 differs from RHEL 8, or Alma 9 differs from RHEL 9, then the build of Alma (by the Alma team) might have made a mistake.

Now, for this specific example: sudo. On both 8 and 9 the sudo does require password. If in your Alma 8 you can run sudo without password, then you have configured it to do so. That is not a change in 9.

OK I know the goal of AL is to be 1:1, but I don’t know how much of all this is RHEL. Would this just be my user admin addition in /etc/sudoers? Just checked and they are the same.


Yes, but …

  • That is not the only method. One can, for example, use ssh keypairs for sudo authentication. (Haven’t tested on AL9 yet.) Since one can have Gnome session activate ssh key on login and act as ssh-agent, you have kind of SSO to access the session, sudo, and ssh servers. Downside: what if someone hacks into your Gnome session?
  • Do not edit the /etc/sudoers – add your entry into new file into directory /etc/sudoers.d/
    That way package updates that would touch the /etc/sudoers do not require merge with your custom config. (This method was available already in RHEL 7.) Neatly separate is clear.

This is on a single box, not through ssh. I have a script that uses sudo and I get asked for a password, probably for the first time I’ve seen it on multiple platforms. Not to say it’s wrong or right, just that it’s happening. My systems are headless. Thanks for the sudoers.d file inclusion.