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 [<UyuniMasterServer.fqdn>]: <UyuniMasterServer.fqdn>

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 <UyuniMasterServer.fqdn>.

Added public ssh-push key from <UyuniMasterServer.fqdn> 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 <UyuniMasterServer.fqdn>

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

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 <proxy.fqdn>” 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