Ubuntu 20.04 salt client not "checking in" when going through a Squid proxy
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/conta... 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 <https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7&elqaid=2786&elqat=2#privacystatement>.*
First of all, keep in mind that the best approach is to keep your Uyuni in the DMZ, as it needs access to internet. HSZ (high-security zone) client can be authorized to access DMZ Uyuni, but the opposite is harder. 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: <!--#yiv0704732928 _filtered {} _filtered {}#yiv0704732928 #yiv0704732928 p.yiv0704732928MsoNormal, #yiv0704732928 li.yiv0704732928MsoNormal, #yiv0704732928 div.yiv0704732928MsoNormal {margin:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv0704732928 a:link, #yiv0704732928 span.yiv0704732928MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv0704732928 span.yiv0704732928EmailStyle18 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv0704732928 .yiv0704732928MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv0704732928 div.yiv0704732928WordSection1 {}--> 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/conta... 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.
participants (2)
-
Paul-Andre Panon
-
Strahil Nikolov