- ARCHIVED: Uyuni Users

Ubuntu patch updates not syncing?
by Paul-Andre Panon 21 Feb '23

21 Feb '23

Hi, We don't seem to have received any new Ubuntu patch information recently, with the latest being 5814-1 dated Jan 19. 5810-1 on the 17th also seems to be missing even though it's on Ubuntu's advisories web page. Is there something wrong with the upstream Uyuni patch processing for Ubuntu? Cheers, Paul-Andre

2 1

Uyuni Proxy not working properly as proxy
by Paul-Andre Panon 01 Feb '23

01 Feb '23

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 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

1 1

kickstartfile-sync failed, cobbler-sync failed
by Crefeld, Tobias LKV Bayern e.V. 30 Jan '23

30 Jan '23

Hi, since some weeks we receive (usually after a reboot of the Uyuni server) "TASCOMATIC NOTICATIONS": Subtask kickstartfile-sync failed. Subtask cobbler-sync failed. At the log file /var/log/rhn/rhn_taskomatic_daemon.log we see messages like these one: 2023-01-30 18:15:00,201 [DefaultQuartzScheduler_Worker-12] ERROR com.redhat.rhn.manager.kickstart.cobbler.CobblerLoginCommand - XmlRpcFault while logging in. most likely user doesn't have permissions. redstone.xmlrpc.XmlRpcFault: <class 'ssl.SSLError'>:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852) 2023-01-30 18:16:00,116 [DefaultQuartzScheduler_Worker-17] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Message: We had an error trying to login. 2023-01-30 18:16:00,116 [DefaultQuartzScheduler_Worker-17] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Cause: {} redstone.xmlrpc.XmlRpcFault: <class 'ssl.SSLError'>:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852) + 2023-01-30 18:37:00,057 [DefaultQuartzScheduler_Worker-9] ERROR com.redhat.rhn.taskomatic.task.CobblerSyncTask - Stack trace:com.redhat.rhn.manager.kickstart.cobbler.NoCobblerTokenException: We had an error trying to login. [..] Caused by: redstone.xmlrpc.XmlRpcFault: <class 'ssl.SSLError'>:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852) Actually we renewed our internal Root-CA certificate last month, added a new certificate chain to /etc/apache2/ssl.crt/ and included it in /etc/apache2/vhosts.d/vhost-ssl.conf . Webbrowsers show the updated certificate chain. Initially we forgot to add the new Root-CA-certificate to /etc/ssl/certs/ (+ run "update-ca-certificates") but this has been fixed meanwhile. I wonder if /etc/ssl/ca-bundle.pem is used by Apache Tomcat for validation of SSL-server certificates? Any other idea? Regards, Tobias Crefeld.

2 2

Uyuni 2023.01 is released!
by Julio Gonzalez 30 Jan '23

30 Jan '23

VERY IMPORTANT: 2023.01 will require a special procedure if you are not upgrading from 2022.12 Make sure you read the release notes for all the versions between the one you are using now, and 2023.01! We are happy to announce the availability of Uyuni 2023.01. Most openSUSE mirrors should already have 2023.01, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2023.01, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Release notes cleanup - SUSE Linux Enterprise Micro support as client - Content Lifecycle Management: Disabling modularity for AppStream repositories Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2023.01. As always, we hope you will enjoy this new Uyuni version and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

how to verify salt master config / add custom module
by Heiner Wulfhorst 24 Jan '23

24 Jan '23

Hi list, i want to add a custom salt module "pwgen" but always get this error: salt.exceptions.SaltRenderError: Jinja variable 'salt.utils.templates.AliasedLoader object' has no attribute 'pwgen.get_pw' I tried adding it using "module_dirs" in a custom config file: echo 'module_dirs: [/opt/passdb/pwgen-salt-module]' > /etc/salt/master.d/mycustom.conf I tried using "extension_modules" directly in /etc/salt/master: echo 'extension_modules: /opt/passdb/pwgen-salt-module' > /etc/salt/master I also tried with and without subdirectory "modules" within " /opt/passdb/pwgen-salt-module" After adding to config I restarted uyuni (spacewalk-service stop/start) and also salt (systemctl restart salt-master). Where is my error? In Salt config or in my module (python) code? How can i verify, that salt master accepts my additional config and reads/adds my custom module (/opt/passdb/pwgen-salt-module/pwgen.py)? BR Heiner

3 2

Uyuni salt master lost communications to most minions
by Paul-Andre Panon 19 Jan '23

19 Jan '23

Hi, We've got a weird behaviour that happened in the last day or so. The Uyuni salt master stopped being able to communicate with nearly all minions except one. salt -vvv ServerX test.ping Executing job with jid 20230118190311229937 ------------------------------------------- ServerX: Minion did not return. [Not connected] ERROR: Minions returned with non-zero exit code The venv-salt-minion service seems to be working on the minion. The service has the error salt-minion[952]: [ERROR] File /etc/venv-salt-minion/minion.d/_mgractionchains.conf not found, but that appears to be cosmetic based on the outstanding issue, and the working minion has the same error. However, I restarted one of the salt-minions and the salt master appears to be able to connect afterwards. And yet the minion system was rebooted the previous day and hasn't been patched in the interim so there should have been no version change. Is there possibly a bug in the latest salt minion version? The Ubuntu 22.04 minion version is venv-salt-minion 3004-11.3.uyuni amd64 The venvjailed client component for Salt although we're also getting this across the board on CentOS 7, openSUSE, and multiple versions of Ubuntu. Could the salt master have issued something that put all the salt minions in a wedged state due to some bug? Is there anything we can gather, information wise before restarting those venv-salt-minion services across the board? Cheers, Paul-Andre

1 1

Uyuni 2022.12 is released!
by Julio Gonzalez 17 Jan '23

17 Jan '23

VERY IMPORTANT: 2022.12 will require a special procedure if you are not upgrading from 2022.11 Make sure you read the release notes for all the versions between the one you are using now, and 2022.12! We are happy to announce the availability of Uyuni 2022.12. Most openSUSE mirrors should already have 2022.12, but if you do not see it yet, wait a few hours until your local openSUSE mirror is synced. At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2022.12, including the release notes, documentation, requirements and setup instructions. This is the list of highlights for this release: - Indications for systems requiring reboot or with a scheduled reboot - Notification messages via email - Monitoring: Grafana update to 8.5.15 - Subscription warning notifications - Limit changelogs at repositories metadata to the last 20 entries - Drop legacy way to prevent disabling local repositories at bootstrap scripts Remember that Uyuni follows a rolling release planning, so the next version will contain bugfixes for this one and any new features. There will be no maintenance of 2022.12. As always, we hope you will enjoy Uyuni 2022.12 and we invite everyone of you to send us your feedback [1] and of course your patches, if you can contribute. Happy hacking! [1] https://www.uyuni-project.org/pages/contact.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

5 5

Canceled: Uyuni Community Hours
by Julio Gonzalez 16 Dec '22

16 Dec '22

Dear Community: The December session of the Community hours will be skipped, as a lot of people is away because of the winter holidays. See you again in January, or at Gitter/Mailing lists. Happy hacking!

1 0

IMPORTANT: Security Patch for Uyuni Server 2022.11
by Julio Gonzalez 13 Dec '22

13 Dec '22

Hello! The SUSE security team detected a security problem that caused the proxy password to be present at the browser log, when using the Uyuni Server via WebUI. A patch for Uyuni 2022.11 is now available, and we recommend you apply it as soon as possible, without waiting for the next release (that obviously will include it as well. You can apply the patch at the Uyuni Server by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are still on 2022.10 or earlier, update first to 2022.11 normally (make sure you read the release notes, as special steps required if you are not on 2022.10 already), and then apply the patch as explained above. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

OES 2023 repos
by Nick Fletcher 10 Dec '22

10 Dec '22

Hi, I'm fairly new to Uyuni and I am evaluating it as a better solution than Micro Focus SMT. I've entered my Micro Focus credentials and I can see all the OES 2018 products but not OES 2023, which I can see on my Micro Focus SMT server. Will OES 2023 appear eventually or do I need to do anything in particular to add these products? I couldn't see anything about this in the documentation. Thanks, Nick

4 10