The root cause appears to have been a bad openSUSE 15.4 template on Azure. Rebuilding the VM with the openSUSE 15.3 template and upgrading that to 15.4 was successful. It seems that whatever in the bad template caused the problem with FQDN hostname assignment was also likely somehow causing the issue with the proxy functionality.
From: Paul-Andre Panon via Uyuni Users
Sent: Monday, January 23, 2023 2:37 AM
To: Paul-Andre Panon via Uyuni Users
Cc: Paul-Andre Panon
Subject: Uyuni Proxy not working properly as proxy
Caution: This email originated outside of Sierra Wireless.
Good morning,
I've got an Uyuni proxy which isn't functioning properly as proxy. It's installed on an Azure VM create using an Azure OpenSUSE 15 template. After applying all updates and registering it with Uyuni, I added the proxy pattern with zypper and ran /usr/sbin/configure-proxy.sh. I don't see any obvious errors in the configure-proxy.sh run (I'm using custom certificates signed by our internal CA and this is a re-run):
# /usr/sbin/configure-proxy.sh --answer-file=proxy-answers.txt.I3zAA
Requesting certificate from server. [1/20]
Certificate saved to: /etc/sysconfig/rhn/systemid
SUSE Manager Parent []:
Using CA Chain (from /etc/sysconfig/rhn/up2date): /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
HTTP Proxy []:
Traceback email []:
You will now need to either generate or import an SSL certificate.
This SSL certificate will allow client systems to connect to this Uyuni Proxy
securely. Refer to the Uyuni Proxy Installation Guide for more information.
Do you want to import existing certificates? [y]: y
Path to CA SSL certificate: [/root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT]: /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT
Path to the Proxy Server's SSL key: [/root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.key]: /root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.key
Path to the Proxy Server's SSL certificate: [/root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.crt]: /root/ssl-build/<UYUNIPROXYSERVER>/<UyuniProxyServer>.crt
Installing SSL certificates:
After changing the server certificate please execute:
$> spacewalk-service stop
cp: '/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT' and '/etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT' are the same file
$> spacewalk-service start
As the CA certificate has been changed, please deploy the CA to all registered clients.
On salt-managed clients, you can do this by applying the highstate.
SUSE Manager Proxy successfully deactivated.
SUSE Manager Proxy successfully activated.
Shutting down spacewalk-proxy...
Warning: Stopping tftp.service, but it can still be activated by:
tftp.socket
Done.
Loading repository data...
Reading installed packages...
'spacewalk-proxy-management' is already installed.
No update candidate for 'spacewalk-proxy-management-4.4.2-220400.1.1.uyuni2.noarch'. The highest available version is already installed.
Resolving package dependencies...
Nothing to do.
Loading repository data...
Reading installed packages...
The following 24 items are locked and will not be changed by any action:
Available:
plymouth plymouth-branding-openSUSE plymouth-branding-upstream plymouth-devel plymouth-dracut plymouth-lang
plymouth-plugin-fade-throbber plymouth-plugin-label plymouth-plugin-label-ft plymouth-plugin-script
plymouth-plugin-space-flares plymouth-plugin-throbgress plymouth-plugin-tribar plymouth-plugin-two-step plymouth-scripts
plymouth-theme-bgrt plymouth-theme-breeze plymouth-theme-breeze-plugin-breeze plymouth-theme-fade-in plymouth-theme-script
plymouth-theme-solar plymouth-theme-spinfinity plymouth-theme-spinner plymouth-theme-tribar
Nothing to do.
Do you want to use an existing ssh key for proxying ssh-push Salt minions ? [n]: n
Generating new SSH key for ssh-push minions.
Fetching public ssh-push key from .
Added public ssh-push key from to /var/lib/spacewalk/mgrsshtunnel/.ssh/authorized_keys.
sshd is already configured.
Create and populate configuration channel rhn_proxy_config_1000010094? [1]: 1
SUSE Manager username: [<UyuniAdminAcct>]: <UyuniAdminAcct>
Password:
Using server name
Pushing to channel rhn_proxy_config_1000010094:
Local file /etc/apache2/vhosts.d/ssl.conf -> remote file /etc/apache2/vhosts.d/ssl.conf
Local file /etc/rhn/rhn.conf -> remote file /etc/rhn/rhn.conf
Local file /etc/squid/squid.conf -> remote file /etc/squid/squid.conf
Local file /etc/apache2/conf.d/cobbler-proxy.conf -> remote file /etc/apache2/conf.d/cobbler-proxy.conf
Local file /etc/apache2/httpd.conf -> remote file /etc/apache2/httpd.conf
Open needed firewall ports...
running
Warning: ALREADY_ENABLED: suse-manager-proxy
success
success
Activate advertising proxy via SLP? [n]: n
Enabling Spacewalk Proxy.
Shutting down spacewalk-proxy...
Done.
Starting spacewalk-proxy...
Done.
Restarting salt-broker.
Some additional details:
1) Unlike other proxies I have set up, the config channel file /etc/jabberd/c2s.xml crated by the configure script for that proxy has an empty element
<id require-starttls="mu" pemfile="/etc/pki/spacewalk/jabberd/server.pem" realm="" register-enable="mu"> </id>
whereas the corresponding files for the config channels of the other proxies have the proxy name included between the start and end tags.
2) This server doesn't seem to register correctly with DDNS. I first used "hostnamectl set-hostname " but the fqdn wouldn't display when entering hostname -f after a reboot. Because it's in Azure, I used NETCONFIG_DNS_STATIC_SEARCHLIST= and NETCONFIG_DNS_STATIC_SERVERS= in /etc/sysconfig/network/config to add our domain and DNS servers to the Azure DHCP defaults and it appears to have the desired effect in /etc/resolv.conf. However, that wasn't enough in conjunction with realm/sssd registration (which has worked with the other Uyuni proxy servers I've set up) to have sssd and the network startup register the name via DDNS. I wound up running nsupdate with appropriate settings (update delete and update add for the fqdn) on a daily cronjob to get the DDNS registration to work, showing that there seems to be no networking block preventing it. Note that after/other than the nsupdate hack, sssd and AD authentication work fine.
What happens from the Uyuni client standpoint when trying to register with the bootstrap script from the proxy is that the client is properly downloaded and installed from the proxy, and the client registration goes through but appears to happen directly through the server (even though the HOSTNAME= shell variable in the context of the bootstrap script is the proxy server's name - confirmed with an echo statement). When looking at the client's properties on the server, it doesn't show any proxy being associated with it.
I'm therefore thinking that perhaps whatever is preventing sssd from getting the right name to register with DDNS perhaps is also causing related problems for the configure-proxy.sh script (or maybe the WSGI redirects or something else on the proxy?) and preventing the client from registering properly. I've been banging my head against the wall on this for quite a while, so I would appreciate any suggestions.
Thanks,
Paul-Andre
