- ARCHIVED: Uyuni Users

Ubuntu repos not working after upgrade to 2022.02
by Bidault, Philippe 15 Mar '22

15 Mar '22

Hi all ! After upgrading from 2021.12 to 2022.02, the registered Ubuntu 18.04/20.04 are not able to get the repos anymore. Result of an 'apt update': E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-main-uyuni/… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-18.04-pool-amd64-uyuni… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-uyuni-clien… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-universe-uy… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-multiverse-… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-main-update… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-main-securi… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-universe-up… 404 Not Found [IP: 10.0.0.1 443] E: Failed to fetch https://uyu01v:443/rhn/manager/download/dists/ubuntu-1804-amd64-multiverse-… 404 Not Found [IP: 10.0.0.1 443] E: Some index files failed to download. They have been ignored, or old ones used instead. I have tried to remove the apt cache on the registered servers, but no luck. I have tried to force the repo sync to regenerate the repos metadata on the Uyuni server , but it did not help neither. Somebody with this same issue ? Do I just need to be patient to let internal Uyuni mechanism to regenerate caches or whatever ? Thanks ! Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<http://www.getronics.com> Follow us on: [cid:SocialLink_Linkedin_32x32_e7c75ee5-f8bf-4d58-979b-3050856d34e9.png]<https://www.linkedin.com/company/getronics/> [cid:SocialLink_Twitter_32x32_cb75fe15-abe1-46a3-9ac3-fc99d077e43b.png] <https://twitter.com/getronics> [cid:SocialLink_Youtube_32x32_1946f212-29cc-40bc-9061-3536027a9813.png] <https://www.youtube.com/channel/UCfEFIFxLdxxhMN-Eaa6pXVA> <https://twitter.com/getronics> Getronics CMC Service Desk Iberia S.L - VAT No:S.L.: B66686262. Registered Office - Getronics CMC Service Desk Iberia S.L, C/Rosselloi, Porcel, 21 planta 11, 08016 Barcelona, Spain. The information transmitted is intended only for use by the addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. Thank you. Legal disclaimer: http://www.getronics.com/legal/ and further details of how we treat your personal data can be found in our privacy policy<https://www.getronics.com/policy-pages/corporate-policy-legal-disclaimer/>

2 4

Containerized Uyuni
by Strahil Nikolov 14 Mar '22

14 Mar '22

Hi Julio, Are there any plans for moving Uyuni into the container world ? Best Regards,Strahil Nikolov

2 1

Set up Uyuni with YaST ERROR
by M C 11 Mar '22

11 Mar '22

Can someone help I am getting the following Error output. Setup script output lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk xPerforming forced re-installation! x xShutting down spacewalk services... x xDone. x xDelete existing database... x xDelete existing salt minion keys x xCREATE ROLE w x* Loading answer file: /root/spacewalk-answers. x x** Database: Setting up database connection for PostgreSQL backend. x x** Database: Populating database. x x** Database: --clear-db option used. Clearing database. x x** Database: Shutting down spacewalk services that may be using DB. x x** Database: Services stopped. Clearing DB. x x*** Progress: # x x* Configuring tomcat. x x* Setting up users and groups. x x* Performing initial configuration. x x* Configuring apache SSL virtual host. x x* Configuring jabberd. x x* Creating SSL certificates. x x** SSL: Generating CA certificate. x x** SSL: Generating server certificate. x xCould not deploy the certificates. Exit value: 1. x xPlease examine /var/log/rhn/rhn_installation.log for more information. v mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj Error output xWarning: ALREADY_ENABLED: suse-manager-server x xERROR: spacewalk-setup failed x x

2 1

How to configure Uyuni to bootstrap systems to use public available repo URL
by jd＠eurisco.dk 06 Mar '22

06 Mar '22

I would like to configure an Uyuni installation to bootstrap systems to use a public available repo URL instead of a local one. I believe this is achieved by changing the "Uyuni server hostname" under "Uyuni Configuration - Bootstrap", but when bootstrapping a system, the repo URL is using the "Uyuni Hostname" (e.g. uyuni.my-local-domain) and not the Uyuni server hostname (e.g. update.my-public-domain). I have checked all the Uyuni documentation, and googled this topic, but I have only found hints that it should be possible, but not an explanation how to actually achieve this, so I wonder if my understanding is wrong, or if something is missing in our installation. Running Uyuni 2022.01 on openSUSE Leap 15.3 I would highly appreciate if someone could help with getting this up and running. Thanks, Jacob Dall

1 0

Re: Containerized Uyuni
by Strahil Nikolov 04 Mar '22

04 Mar '22

Sending it to the list, as it somehow ended in the Bcc. It will be useful if we have Uyuni (and later SUMA) on a Kubernetes/Openshift cluster. Best Regards,Strahil Nikolov On Thu, Mar 3, 2022 at 16:03, Julio Gonzalez<jgonzalez(a)suse.com> wrote: On jueves, 3 de marzo de 2022 14:48:28 (CET) Strahil Nikolov wrote: > Hi Julio, > Are there any plans for moving Uyuni into the container world ? > Best Regards,Strahil Nikolov Hi! Please send the question to the users list. It seems you did it, but the list was not present at the TO field :-) -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Filters and module streams
by Karjanlahti Janne 09 Feb '22

09 Feb '22

Hello! Thank you for the CLM build java stack overflow fix, that was very fast response. I can confirm that CLM build succeed every time after installing the patch. I had another minor problem regarding to Content Lifecyle filters. I have created several module stream filters to our test environment, but somehow I cannot add more filters to existing project. GUI allows me to pick additional filters (via Add/Detach filters) and there is no error message when I click save button. However nothing happens, it doesn't get saved, there was only 9 filters total in use. I was forced to detach every single filter from project, then do CLM build without any module filtered and after that I was able to add every 12 filters at once. Only then all the filters came into use. What indeed is correct way to deal with modules? My intended purpose is that nothing changes from servers perspective when it gets bootstrapped to Uyuni. I want to use all the default packages that vanilla CentOS/Rocky/Alma is using after initial installation. I understand that Uyuni does not directly support RedHat-specific module-enabled repositories and whole (stupid) module stream concept, but you can deal with modules using module filters and building Content Lifecyle environment where module enabled repositories get "flattened" to ordinary repos, and you can alter the flattening process using module filters. After initial Rocky/Alma/CentOS installation there is several module streams enabled, you can view it using "dnf module list" command. Then you bootstrap server to Uyuni and all the original repost get replaced in favor of custom channels from Uyuni's lifecycle environment. But... still "dnf module list" show that there is enabled module streams. How should I deal with it? Should I inactivate all the streams using "dnf module reset" command? And what after that? Create module filter for all the different modules, or should I create filter only for those I want to use? What happens if I don't create any module filter at all? I know that SUSE is not using whole module streams etc... so this is not directly related to Uyuni, but I hope anyway that some of you can guide me to right direction. Br, Janne Janne Karjanlahti (Mr.) Vastaava järjestelmäasiantuntija | Senior Systems Specialist ICT- ja digitaaliset palvelut | ICT and Digital Services Satakunnan ammattikorkeakoulu | Satakunta University of Applied Sciences Satakunnankatu 23 | 28130 | PORI | Finland +358 44 710 3339 janne.karjanlahti(a)samk.fi<mailto:janne.karjanlahti@samk.fi> www.samk.fi<http://www.samk.fi>

1 0

Occasional 'minion is down' warning
by Tim Shaw 08 Feb '22

08 Feb '22

Occasionally I get a failure to apply updates or a failed to reboot and the reason given in the event summary is : Minion is down or could not be contacted. Retrying the command immediately afterwards almost invariably results in success - which leads me to believe that the minion is not down and this is a time-out issue and that the minion maybe takes a while to "wake up " if it has been inactive for a time It's annoying. Do others have this issue - and is there a setting which will allow the Uyuni server to grant more time to the minion to respond? Many thanks T ___________________________________________________________ TIM SHAW - MSD IT Systems & Network Services Medical Sciences Division - University of Oxford email : tim.shaw(a)medsci.ox.ac.uk tel : +44 (0)1865 289480

1 0

Content Lifecycle Project build failed / resulting messed up repository
by Karjanlahti Janne 08 Feb '22

08 Feb '22

Hello! Yesterday Content Lifecycle Project build failed without any additional information. It was our test environment and it was never happened before. I (re)synced all source repos by hand (just in case) and after that build succeeded and all seemed to be ok. I was a bit hurry and I didn't find any errors in log files at first glance so I leave it... This morning I encountered same "failed" notice in our production Uyuni server. This time I clicked "Build" again without additional repo resync and the second build succeeded. However repository content seems to be somewhat messed up, in both Uyuni servers. Client servers found a lot of updates, mainly different Perl packages but couldn't update because of many conflicting dependencies. There is a lot of Perl 5.30 -version updates available even if I have not enabled this module stream. Default Perl version branch in Redhat EL8 derived distributions is 5.26 and additional versions is provided with module streams. Currently installed Perl version in my servers is 5.26. In fact there isn't any filters concerning Perl at all in this Content Lifecyle Project. I found errors in /var/log/rhn/ rhn_web_ui.log -file corresponding the failed environment build: 2022-02-08 07:03:03,580 [RHN Message Dispatcher] ERROR com.redhat.rhn.frontend.events.TransactionHelper - com.redhat.rhn.frontend.events.AlignSoftwareTargetAction$AlignSoftwareTargetException: java.lang.StackOverflowError 2022-02-08 07:03:03,656 [RHN Message Dispatcher] ERROR com.redhat.rhn.frontend.events.AlignSoftwareTargetAction - Error aligning target 3 com.redhat.rhn.frontend.events.AlignSoftwareTargetAction$AlignSoftwareTargetException: java.lang.StackOverflowError at com.redhat.rhn.frontend.events.AlignSoftwareTargetAction.execute(AlignSoftwareTargetAction.java:71) at com.redhat.rhn.common.messaging.ActionExecutor.lambda$run$0(ActionExecutor.java:67) at com.redhat.rhn.frontend.events.TransactionHelper.run(TransactionHelper.java:63) at com.redhat.rhn.frontend.events.TransactionHelper.handlingTransaction(TransactionHelper.java:47) at com.redhat.rhn.common.messaging.ActionExecutor.run(ActionExecutor.java:67) at com.redhat.rhn.common.messaging.MessageDispatcher.run(MessageDispatcher.java:91) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.StackOverflowError at java.base/java.util.function.Predicate.lambda$or$2(Predicate.java:101) at java.base/java.util.function.Predicate.lambda$or$2(Predicate.java:101) at java.base/java.util.function.Predicate.lambda$or$2(Predicate.java:101) Last message continues about thousand lines. Is there any other log files I should check? We are using openSUSE Leap 15.3 and Uyuni 2022.01 version. All the client servers and repositories/channels are Rocky Linux 8. I think we must ditch current Lifecycle Environment and build totally new for our Rocky Linux servers. I wonder however is this a bug or is there something we should do differently this time to avoid this kind of errors? Br, Janne Janne Karjanlahti (Mr.) Vastaava järjestelmäasiantuntija | Senior Systems Specialist ICT- ja digitaaliset palvelut | ICT and Digital Services Satakunnan ammattikorkeakoulu | Satakunta University of Applied Sciences Satakunnankatu 23 | 28130 | PORI | Finland +358 44 710 3339 janne.karjanlahti(a)samk.fi<mailto:janne.karjanlahti@samk.fi> www.samk.fi<http://www.samk.fi>

3 2

Bugfix for Content Lifecycle Managent build failures
by Julio Gonzalez 08 Feb '22

08 Feb '22

Dear Uyuni Community. In order to support the growing number of distributions that use modular repositories, the Content Lifecycle Management feature had some updates that cause stack overflow exceptions that could fail the builds, and showed the stack overflow errors at `rhn_web_ui.log`. A bugfix to offload the work from the Java stack to prevent such overflows is now released. See how to apply the patch at https://uyuni-project.org/pages/patches.html. The fix will be part of Uyuni 2022.02 as well, but we recommend you don't wait and apply the patch as soon as possible, in particular if you are already using Content Lifecycle Management. Best regards. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Configuration issue
by Martin Willisegger 08 Feb '22

08 Feb '22

Hello list I make first tests with the configuration in Uyuni. It worked to create a configuration channel, assign it to a server and copy a file 1:1 to this server. What I can't do yet is to add dynamic values of the target system to this file. Actually I thought it works like in the manual (content configuration file): # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} Unfortunately, this is exactly what the file looked like on the target system: # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} and not as in the manual: # My test file hostname=myserver.mydomain.tld ip_address=192.168.5.31 This is probably because my openSuSE client is not "Traditional" but connected with "Salt". Even if I try it with python the python code is copied 1:1 to the target system and not interpreted. Can someone give me a working example of how I would have to create this to achieve the desired goal - after that I could certainly build on it. Btw: Now that openSuSE 15.3 reports itself as SLES15 - is there still no traditional client for OpenSuSE? :) Best regards Martin

3 2