About your case, I think that you can ask your firewall team to open the salt ports to the Uyuni, or you will have to remove and bootstrap the client again.

Best Regards,

Strahil Nikolov

On Thu, Jul 15, 2021 at 10:24, Paul-Andre Panon
<paul-andre.panon@avigilon.com> wrote:

Hi,

We’ve got an Ubuntu 20.04 system which is set up to connect to the Uyuni server through a standard Squid proxy. It can do most typical client patching tasks against the Uyuni server fine: apt-get update, apt-get upgrade, etc. . I didn’t try pushing packages from the Uyuni side recently, though it used to work before inserting the web proxy. However the server is no longer checking in. It is in a DMZ so connections from the system to the Uyuni server are blocked except through the web proxy. This approach/mechanism worked with a traditional client config Ubuntu client and Spacewalk, where rhn_check was used to check in.

Looking at the documentation, it looks like I should have set up and used a different activation key that used push via ssh.
https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/contact-methods-saltssh.html
Is there any way to convert a standard salt client into the salt-ssh contact method? Is there a recommended way to get myself out of the hole I’ve dug myself into here? I’ve got to think I’m not the first person with a system that needs to move into a DMZ after setup and needs a contact method change. I seem to remember reading that you need to take care in unregistering and reregistering clients, so I’m not sure if trying to do that with a new activation code would work. Does the push via ssh use salt-ssh via public/private key pair? That would seem to be more secure than a user/password approach.

Thanks,

Paul-Andre Panon

For more information on how and why we collect your personal information, please visit our Privacy Policy.