Hi,
I have installed subscription-manager which also installs subscription-manager-rhsm-certificates as a dependency, but the latter failed to install the certificates in /etc/rhsm and /etc/rhsm/ca. Both directories are empty.
As a result, I can’t register my server to subscription.rhsm.redhat.com.
Steps I’m following:
dnf install subscription-manager
subscription-manager register --username <username> --password <password> --auto-attach
Am I missing something?
Why are you installing the subscription manager into Alma in the first place? The SM is for RHEL subscriptions. I’ve just run dnf list subscription-manager subscription-manager-rhsm-certificates on both my host Alma 8.7 and the 9.1 VM. Both return the packages as available, but not installed.
The reason to register my server with RedHat is to use Insights.
As you mentioned, the package is available and I installed it, but the files that
subscription-manager-rhsm-certificates
suppose to install in /etc/rhsm are not installed.
Only if you are running RHEL. In AlmaLinux, the package has been debranded, meaning those rhel-related files have been removed.
@sigulete execute the command:
rpm -ql subscription-manager-rhsm-certificates
Does it show any certificates with paths in the output?
FYI, if you want to run the GNOME desktop on AL9, you need to install the subscription-manager package. The gnome-session daemon is activating the rhsm service via d-bus and failing so just terminates.
Sorry, but no. I normally use KDE, but just now have logged in using GNOME (taken from login screen gear wheel).
$ dnf list subscription-manager
Last metadata expiration check: 0:00:13 ago on Tue 14 Mar 2023 15:06:12 GMT.
Available Packages
subscription-manager.x86_64 1.29.30.1-1.el9_1.alma baseos
Note that it is available, but not installed. This is on a VM running Alpha 9.1 hosted by an Alpha 8.7 box.
Do run:
dnf rq --groupmember subscription-manager
dnf rq --whatrequires subscription-manager
I bet the package is not on groups that GUI environment pulls in nor required by any of the main gnome packages.
On a fairly vanilla system there is nothing:
$ dnf rq --groupmember subscription-manager
Last metadata expiration check: 2:34:15 ago on Tue 14 Mar 2023 15:06:12 GMT.
subscription-manager-1.29.30-1.el9.alma.x86_64
subscription-manager-1.29.30.1-1.el9_1.alma.x86_64
$ dnf rq --whatrequires subscription-manager
Last metadata expiration check: 2:34:39 ago on Tue 14 Mar 2023 15:06:12 GMT.
subscription-manager-plugin-ostree-0:1.29.30-1.el9.alma.x86_64
subscription-manager-plugin-ostree-0:1.29.30.1-1.el9_1.alma.x86_64
Don’t know if that helps
The first says that subscription-manager is not in any “yum group” (only the name of package, no name of any group).
Therefore, the “dnf group install xxx” type of thing that the installer does won’t install that package.
The second says that only when you do install ‘subscription-manager-plugin-ostree’, the ‘subscription-manager’ will be co-installed as dependency.
Now, we could follow the rabbit by checking the same things for subscription-manager-plugin-ostree, but there are enough holes elsewhere to get lost in.
If one has the subscription-manager already installed, then one can test what actually do depend on it with:
dnf remove subscription-manager
(One does not have to say ‘yes’ …)
Anyway, @gw666 has show where the:
did come from, since it does not seem to hold water – I have several AL9 and no subscriptions.
I think the problem is simply that AlmaLinux de-branded the packages (as explained by torcat). So the certificates shouldn’t be available in the first place.
Anyhow, I setup Insights in a different way:
dnf install subscription-manager
dnf install insights-client
I created a certificate directly in RedHat console (offline registration process)
Login - Red Hat Customer Portal
I installed the generated certificate in my server using subscription-manager
subscription-manager import --certificate=<path-to-certificate>
I setup BASIC authentication for Insights
vim /etc/insights-client/insights-client.conf
auto_config=FALSE
username=<your customer portal username>
password=<your customer portal password>
I registered to Insights
insights-client --register
Then I removed subscription-manager, which I don’t need any longer really
dnf remove subscription-manager
Yes, there is a note from RHEL dev:
being able to talk to subscription manager is a requirement of GNOME in RHEL 9
RHEL 9.
I have GNOME session in in AL9 right now. No subscription manager installed.
Granted, logs do show:
systemd[1611]: org.gnome.SettingsDaemon.Subscription.service: Scheduled restart job, restart counter is at 1.
systemd[1611]: Stopped GNOME subscription management service.
systemd[1611]: Starting GNOME subscription management service...
gsd-subman[2340]: Failed to start: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
systemd[1611]: org.gnome.SettingsDaemon.Subscription.service: Main process exited, code=exited, status=1/FAILURE
systemd[1611]: org.gnome.SettingsDaemon.Subscription.service: Failed with result 'exit-code'.
systemd[1611]: Failed to start GNOME subscription management service.
but that does not cause observable issues.
The subscription manager may be necessary in RHEL, because it populates the RHEL repository definitions (at least in RHEL 7). Access to Alma’s repositories does not require subscriptions.
So does the gnome-session process terminate for you at that point? The GNOME desktop should continue to run then. You might have seen that in my upstream bug report, I had started my GNOME session from vncserver script. It terminates after gnome-session ended.
Edit: My test system was AL9.1 ofc.
The gnome-session is not affected. Like I said, I do have GNOME session. (Both Wayland and X11 are usable.)
The org.gnome.SettingsDaemon.Subscription.service attempts to start five times, but then systemd gives up with that.
It could be that the vnc is more strict?
Just take a look at xstartup as generated from vncserver:
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
/etc/X11/xinit/xinitrc
# Assume either Gnome will be started by default when installed
# We want to kill the session automatically in this case when user logs out. In case you modify
# /etc/X11/xinit/Xclients or ~/.Xclients yourself to achieve a different result, then you should
# be responsible to modify below code to avoid that your session will be automatically killed
if [ -e /usr/bin/gnome-session ]; then
vncserver -kill $DISPLAY
fi
xinitrc just runs gnome-session, that process terminates and then the script kills VNC.
Does the process /usr/bin/gnome-session terminate for you or not? GNOME itself might continue to run without it.
I seem to have these, so “no^H^Hyes, terminates”?
$ ps axf | grep [g]nome-ses
1647 tty2 Ssl+ 0:00 \_ /usr/libexec/gdm-wayland-session --register-session gnome-session
1654 tty2 Sl+ 0:00 \_ /usr/libexec/gnome-session-binary
1707 ? Ssl 0:00 \_ /usr/libexec/gnome-session-ctl --monitor
1709 ? Ssl 0:00 \_ /usr/libexec/gnome-session-binary --systemd-service --session=gnome
1994 ? Ssl 0:00 \_ /usr/libexec/at-spi2-registryd --use-gnome-session
[EDIT] the /usr/bin/gnome-session is a shell script …
Oh yes, I was thinking of /usr/libexec/gnome-session-binary.
I still don’t understand why it doesn’t exit for you when it failed to activate the subscription-manager service. But I have only tried VNC or FastX sessions on AL9.
The facts are that
There must be quite many Alma GNOME users, even though part of community has “strong feelings” about GNOME.
If that default combo (GDM - GNOME - no subs) would crash, then there surely would be loud uproar among users. (Just like el8.6 update and Qt rebuild in el8.7&el9.1 had among KDE users.)
The VNC-GNOME combo … how common is it?