Where is mgr-bootstrap on a containerized proxy?
After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy? Thanks Paul-Andre Panon
Hello Paul-André There will be no mgr-bootstrap for containerized proxy and for now the bootstrap scritps are failing with it. A fix is to mirror all of the /pub folder on the proxy for containers. There is a PR for it that I tested locally: https://github.com/uyuni-project/uyuni/pull/5596 I'll need to create some test images for Uyuni for you to test it, unless you build the images yourself ;) Kind regards -- Cédric On Wed, 2022-07-06 at 02:13 +0000, Paul-Andre Panon via Uyuni Users wrote:
After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I’m ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can’t seem to find mgr-bootstrap to do so because it doesn’t appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy?
Thanks
Paul-Andre Panon
Hmm, I'm having some problem following quite how that change to uUyuni-configure.py is effecting that cloning though I'll assume it is somehow. But then how does the client register through the proxy and know to use the proxy instead of the main server? Doesn't something need to change in the bootstrap script(s) so the client is aware of the proxy? Is that done by changing the HOSTNAME variable in the script from the Uyuni server to the Uyuni proxy? Or is it done by the settings in client-config-overrides.txt, or both? And if it's done by the latter, what should those changes look like? Because those settings seem to be good for httpProxy but do seem like they would work for http/https, but would they work for the salt minion proxy as well? -----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Tuesday, July 5, 2022 11:12 PM To: users@lists.uyuni-project.org Cc: Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy? Hello Paul-André There will be no mgr-bootstrap for containerized proxy and for now the bootstrap scritps are failing with it. A fix is to mirror all of the /pub folder on the proxy for containers. There is a PR for it that I tested locally: https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... I'll need to create some test images for Uyuni for you to test it, unless you build the images yourself ;) Kind regards -- Cédric On Wed, 2022-07-06 at 02:13 +0000, Paul-Andre Panon via Uyuni Users wrote:
After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy?
Thanks
Paul-Andre Panon
On Wed, 2022-07-06 at 08:05 +0000, Paul-Andre Panon wrote:
Hmm, I'm having some problem following quite how that change to uUyuni-configure.py is effecting that cloning though I'll assume it is somehow.
The issue when running bootstrap scripts via a container proxy is that the proxy doesn't cache the bootstrap folder. This PR tells Apache to use the proxy for everything in the /pub folder.
But then how does the client register through the proxy and know to use the proxy instead of the main server? Doesn't something need to change in the bootstrap script(s) so the client is aware of the proxy? Is that done by changing the HOSTNAME variable in the script from the Uyuni server to the Uyuni proxy?
Yes you need to set the HOSTNAME to the container proxy FQDN in the bootstrap script and that's it. -- Cédric
-----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Tuesday, July 5, 2022 11:12 PM To: users@lists.uyuni-project.org Cc: Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy?
Hello Paul-André
There will be no mgr-bootstrap for containerized proxy and for now the bootstrap scritps are failing with it. A fix is to mirror all of the /pub folder on the proxy for containers. There is a PR for it that I tested locally:
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
I'll need to create some test images for Uyuni for you to test it, unless you build the images yourself ;)
Kind regards -- Cédric
On Wed, 2022-07-06 at 02:13 +0000, Paul-Andre Panon via Uyuni Users wrote:
After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy?
Thanks
Paul-Andre Panon
If you want to test the fix you can set this in the /etc/sysconfig/uyuni-proxy-systemd-services file and restart the pod: NAMESPACE=registry.opensuse.org/home/cbosdonnat/branches/systemsmanagement/uyuni/master/containers/uyuni Kind regards -- Cédric On Wed, 2022-07-06 at 08:05 +0000, Paul-Andre Panon wrote:
Hmm, I'm having some problem following quite how that change to uUyuni-configure.py is effecting that cloning though I'll assume it is somehow. But then how does the client register through the proxy and know to use the proxy instead of the main server? Doesn't something need to change in the bootstrap script(s) so the client is aware of the proxy? Is that done by changing the HOSTNAME variable in the script from the Uyuni server to the Uyuni proxy? Or is it done by the settings in client-config-overrides.txt, or both? And if it's done by the latter, what should those changes look like? Because those settings seem to be good for httpProxy but do seem like they would work for http/https, but would they work for the salt minion proxy as well?
-----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Tuesday, July 5, 2022 11:12 PM To: users@lists.uyuni-project.org Cc: Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy?
Hello Paul-André
There will be no mgr-bootstrap for containerized proxy and for now the bootstrap scritps are failing with it. A fix is to mirror all of the /pub folder on the proxy for containers. There is a PR for it that I tested locally:
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...
I'll need to create some test images for Uyuni for you to test it, unless you build the images yourself ;)
Kind regards -- Cédric
On Wed, 2022-07-06 at 02:13 +0000, Paul-Andre Panon via Uyuni Users wrote:
After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy?
Thanks
Paul-Andre Panon
Hi Cedric, I tried this out and it doesn't seem to be quite working properly, though it's pretty close. After changing the NAMESPACE entry on the proxy, I'm now getting a 404 error trying to navigate to either the bootstrap or repositories subdirectories on the proxy's /pub path. The problem appears to be that the link for the bootstrap directory points to https://proxyname/bootstrap instead of https://proxyname/pub/bootstrap (and the same for the repositories subdir link). If I directly connect to the https://proxyname/pub/bootstrap, that works and I see the files from the main server, so I expect things would probably work properly for bootstrapping since I wouldn't be trying to navigate there through the web page. It's probably just a cosmetic glitch that needs to be fixed. I'll try to test it tomorrow as is. Thanks, Paul-Andre -----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Wednesday, July 6, 2022 5:05 AM To: users@lists.uyuni-project.org; Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy? If you want to test the fix you can set this in the /etc/sysconfig/uyuni-proxy-systemd-services file and restart the pod: NAMESPACE=registry.opensuse.org/home/cbosdonnat/branches/systemsmanagement/uyuni/master/containers/uyuni Kind regards -- Cédric On Wed, 2022-07-06 at 08:05 +0000, Paul-Andre Panon wrote:
Hmm, I'm having some problem following quite how that change to uUyuni-configure.py is effecting that cloning though I'll assume it is somehow. But then how does the client register through the proxy and know to use the proxy instead of the main server? Doesn't something need to change in the bootstrap script(s) so the client is aware of the proxy? Is that done by changing the HOSTNAME variable in the script from the Uyuni server to the Uyuni proxy? Or is it done by the settings in client-config-overrides.txt, or both? And if it's done by the latter, what should those changes look like? Because those settings seem to be good for httpProxy but do seem like they would work for http/https, but would they work for the salt minion proxy as well?
-----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Tuesday, July 5, 2022 11:12 PM To: users@lists.uyuni-project.org Cc: Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy?
Hello Paul-André
There will be no mgr-bootstrap for containerized proxy and for now the bootstrap scritps are failing with it. A fix is to mirror all of the /pub folder on the proxy for containers. There is a PR for it that I tested locally:
https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith ub.com%2Fuyuni-project%2Fuyuni%2Fpull%2F5596&data=05%7C01%7Cppanon %40sierrawireless.com%7C7fb2dbf6f7d144cf526f08da5f47d11b%7C08059a4c248 643dd89e33a747e0dcbe8%7C0%7C0%7C637927059307782815%7CUnknown%7CTWFpbGZ sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 D%7C3000%7C%7C%7C&sdata=PoLuLCPFsWTIrkPuCvq66OTAgPiOWvoC6XKBiSu4nK k%3D&reserved=0
I'll need to create some test images for Uyuni for you to test it, unless you build the images yourself ;)
Kind regards -- Cédric
On Wed, 2022-07-06 at 02:13 +0000, Paul-Andre Panon via Uyuni Users wrote:
After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy?
Thanks
Paul-Andre Panon
On Thu, 2022-07-07 at 02:36 +0000, Paul-Andre Panon wrote:
The problem appears to be that the link for the bootstrap directory points to https://proxyname/bootstrap instead of https://proxyname/pub/bootstrap
Where did you see those links? Even in the https://proxyname/pub page I have the correct links here. -- Cedric
If I open the URL https://<proxyservername>/pub in a browser, I see a list of the contents of the pub directory. That page is presumably generated by the web server. Each of the file names and directories in that listing is a link. If I hover over any of the highlighted text of the file and directory names that are links, I see the actual link value in the bottom left of the browser window. For all those files and directories, the link values are https://<proxyservername>/<fileordirectoryname> instead of https://<proxyservername>/pub/<fileordirectoryname> This is the case with both MS Edge and Mozilla Firefox. -----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Thursday, July 7, 2022 1:24 AM To: users@lists.uyuni-project.org; Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy? On Thu, 2022-07-07 at 02:36 +0000, Paul-Andre Panon wrote:
The problem appears to be that the link for the bootstrap directory points to https://proxyname/bootstrap instead of https://proxyname/pub/bootstrap
Where did you see those links? Even in the https://proxyname/pub page I have the correct links here. -- Cedric
For the containerized proxy, I managed to get to the point where I could build a test VM to use with it. I bootstrapped the VM and it appears to be properly registered in Uyuni (ran into an issue with a crashed taskomatic preventing events from working, but which was fixed after configuring extra Java heap for the process and restarting taskomatic). The system shows up in the system list and the high state seems to have succeeded and apt update shows the list of channels with URLs based on the proxy server. I was also able to change the channels to an LCM channel set properly. However trying to actually apply/push updates from the Uyuni server is failing. The event history reports ... pkg_|-pkg_installed_|-pkg_installed_|-installed: name: pkg_installed result: false changes: { } comment: |- Problem encountered installing package(s). Additional info follows: errors: - Running scope as unit: run-r61db306406824d96a102fa680f075ff1.scope E: Failed to fetch https://<proxy.fqdn>:443/rhn/manager/download/ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/getPackage/linux-firmware_1.187.31-X.all-deb.deb Connection failed [IP: 10.xx.yy.xx 443] E: Failed to fetch https://<proxy.fqdn>:443/rhn/manager/download/ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/getPackage/snapd_2.54.3+20.04.1ubuntu0.3-X.amd64-deb.deb Connection failed [IP: 10.xx.yy.zz 443] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing Now going to the https://<prxy.fqdn>/pub folder works fine, so it's not a firewalling or name resolution. If I try to go to the URL in a browser I get a 403 error (but I also get an error about a missing token if try the same path on the Uyuni server proper). Trying to get an apt-get upgrade on the minion gives: 62 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. Need to get 125 MB/221 MB of archives. After this operation, 90.9 MB of additional disk space will be used. Do you want to continue? [Y/n] Err:1 https://<proxy.fqdn>:443/rhn/manager/download ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/ linux-firmware 1.187.31 Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 10.40.11.185 443] E: Failed to fetch https://<proxy.fqdn>:443/rhn/manager/download/ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/getPackage/linux-firmware_1.187.31-X.all-deb.deb Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 10.xx.yy.zz 443] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? I didn't see anything in the troubleshooting clients which seems to apply. Thanks, Paul-Andre Panon -----Original Message----- From: Cedric Bosdonnat <cbosdonnat@suse.com> Sent: Thursday, July 7, 2022 1:24 AM To: users@lists.uyuni-project.org; Paul-Andre Panon <ppanon@sierrawireless.com> Subject: Re: Where is mgr-bootstrap on a containerized proxy? On Thu, 2022-07-07 at 02:36 +0000, Paul-Andre Panon wrote:
The problem appears to be that the link for the bootstrap directory points to https://proxyname/bootstrap instead of https://proxyname/pub/bootstrap
Where did you see those links? Even in the https://proxyname/pub page I have the correct links here. -- Cedric
On Tue, 2022-07-12 at 01:37 +0000, Paul-Andre Panon wrote:
For the containerized proxy, I managed to get to the point where I could build a test VM to use with it. I bootstrapped the VM and it appears to be properly registered in Uyuni [...]. The system shows up in the system list and the high state seems to have succeeded and apt update shows the list of channels with URLs based on the proxy server. I was also able to change the channels to an LCM channel set properly.
Good!
However trying to actually apply/push updates from the Uyuni server is failing. The event history reports ... pkg_|-pkg_installed_|-pkg_installed_|-installed: name: pkg_installed result: false changes: { } comment: |- Problem encountered installing package(s). Additional info follows:
errors: - Running scope as unit: run-r61db306406824d96a102fa680f075ff1.scope E: Failed to fetch https://<proxy.fqdn>:443/rhn/manager/download/ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/getPackage/linux-firmware_1.187.31-X.all-deb.deb Connection failed [IP: 10.xx.yy.xx 443] E: Failed to fetch https://<proxy.fqdn>:443/rhn/manager/download/ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/getPackage/snapd_2.54.3+20.04.1ubuntu0.3-X.amd64-deb.deb Connection failed [IP: 10.xx.yy.zz 443] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing
Now going to the https://<prxy.fqdn>/pub folder works fine, so it's not a firewalling or name resolution. If I try to go to the URL in a browser I get a 403 error (but I also get an error about a missing token if try the same path on the Uyuni server proper). Trying to get an apt-get upgrade on the minion gives:
62 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. Need to get 125 MB/221 MB of archives. After this operation, 90.9 MB of additional disk space will be used. Do you want to continue? [Y/n] Err:1 https://<proxy.fqdn>:443/rhn/manager/download ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/ linux-firmware 1.187.31 Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 10.40.11.185 443] E: Failed to fetch https://<proxy.fqdn>:443/rhn/manager/download/ubuntu20-devtest-ubuntu-2004-amd64-main-updates-uyuni/getPackage/linux-firmware_1.187.31-X.all-deb.deb Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 10.xx.yy.zz 443] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
I didn't see anything in the troubleshooting clients which seems to apply.
Do you have a way for me to reliably reproduce this issue? -- Cédric
participants (2)
-
Cedric Bosdonnat
-
Paul-Andre Panon