February 2023 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

Unable to create new Organization
by Ken Cote 23 Mar '23

23 Mar '23

Hello, I am encountering an issue where I am unable to create a new Organization. When I try to create an organization I receive a WEB TRACEBACK. I have also tried creating a new organization with spacecmd and I receive the same traceback. The error from spacecmd is: ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: ERROR: null value in column "group_type" of relation "rhnusergroup" violates not-null constraint Detail: Failing row contains (176, Cluster Administrators, Cluster Administrators for Org OIS, null, 0, null, 24, 2023-02-24 11:57:40.317269-07, 2023-02-24 11:57:40.317269-07). Where: SQL statement "insert into rhnUserGroup ( id, name, description, max_members, group_type, org_id ) values ( group_val, 'Cluster Administrators', 'Cluster Administrators for Org ' || name_in, NULL, ug_type, new_org_id )" PL/pgSQL function create_new_org(character varying,character varying) line 146 at SQL statement The error in the emailed traceback is the same. I am currently running Uyuni 2023.01. Any ideas on how I might go about troubleshooting and resolving this issue? Thanks!

4 5

Uyuni 2023.01 on Leap 15.4: ModuleNotFoundError: No module named 'simplejson'
by Johannes Kastl 28 Feb '23

28 Feb '23

Hi all, I installed the latest Uyuni release 2023.01 on an openSUSE Leap 15.4 box. One thing I noticed: "spacewalk-repo-sync -p opensuse_leap15_4" complained that the simplejson module was missing: > root uyuni:/root # spacewalk-repo-sync -p opensuse_leap15_4 > Traceback (most recent call last): > File "/usr/bin/spacewalk-repo-sync", line 25, in <module> > import simplejson as json > ModuleNotFoundError: No module named 'simplejson' > root uyuni:/root # Does anyone else get that, too? Worth a bug report? Or did something go haywire during my installation? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

3 3

Error on applying highstate after 2023.01 update - tries to pull repomd.xml.key from external url
by Allen Beddingfield 24 Feb '23

24 Feb '23

After the 2023.01 update, I've had a couple of issues. Abid was able to help me (I think) resolve the issue with the channel listing in the web ui. Now, I noticed that an Oracle Linux 8 system that is newly added will give an error with applying the highstate. It appears to be trying to pull the repo key from the original location on the internet, instead of from the Uyuni server, from the managed system. The repositories added are the base channel, appstream, and the uyuni client tools. The error is coming from the Uyuni client tools. It seems that the managed system is trying to pull the repo key from an external URL (where Uyunio syncs this down from), and timing out. What could be going on that is causing this behavior? I would assume that it would pull that from the Uyuni server, itself. Thanks. ID: https_//download.opensuse.org/repositories/systemsmanagement_/Uyuni_/Stable_/CentOS8-Uyuni-Client-Tools/CentOS_8/repodata/repomd.xml.key Function: mgrcompat.run Name: pkg.add_repo_key Result: false Comment: Module function pkg.add_repo_key threw an exception. Exception: Error: HTTP 599: Timeout while connecting reading /repositories/systemsmanagement:/Uyuni:/Stable:/CentOS8-Uyuni-Client-Tools/CentOS_8/repodata/repomd.xml.key Started: 12:59:38.991575 Duration: 20023.057 SLS: channels.gpg-keys Changed: {} -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

1 1

"Internal Server Error" when displaying channels on 2023.01
by Allen Beddingfield 24 Feb '23

24 Feb '23

I'm getting an "Internal Server Error" message when trying to access "All" or "My Channels" under Software/Channel List. The server was recently updated to 2023.01, but that was working after the update. The only change I can think of that I have made is to do try to add the Leap 15.4 channels again, as they were display but not syncing. I did that with similar commands to this for the channels: spacewalk-common-channels -a x86_64 opensuse_leap15_4 Any help in troubleshooting this would be appreciated! Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

4 12

Community Hours today at 16.00 CET
by Julio Gonzalez 24 Feb '23

24 Feb '23

Hello, As every last Friday of each month, we'll be having a session of the Uyuni Community Hours. The agenda for today is: - Uyuni 2023.02/2023.03: What's new? (Julio) - Uyuni roadmap (Abid) - Hack Week: New Operating systems as clients for Uyuni (Raul and Julio) - Hack Week: Building the documentation on any OS and with no toolchain (Julio) - Hack Week: Improvements on the Uyuni Health Check tool (Pablo) - Hack Week: Deploying Uyuni Proxy container with fleet and elemental (Cedric) The link to join is: https://teams.microsoft.com/l/meetup-join/19%3Ameeting_ZjZlMWI0OTctNGMxZi00… See you there! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Issue importing Nodejs 15 debian repositorry in Uyuni
by Bidault, Philippe 23 Feb '23

23 Feb '23

Hi guys ! I have an issue trying to import the nodejs repo for debian 11 in Uyuni. All seems to be good, however, Uyuni don't like the package and just does not import it: 1234567891011121314152023/02/23 14:28:19 -00:00 Repo URL: https://deb.nodesource.com/node_15.x/dists/bullseye/main/binary-amd64/ 2023/02/23 14:28:19 -00:00 Packages in repo: 1 2023/02/23 14:28:19 -00:00 Packages already synced: 0 2023/02/23 14:28:19 -00:00 Packages to sync: 1 2023/02/23 14:28:19 -00:00 New packages to download: 1 2023/02/23 14:28:19 -00:00 Downloading packages: 2023/02/23 14:28:23 -00:00 1/1 : nodejs_15.14.0-deb-1nodesource1_amd64.deb 2023/02/23 14:28:23 -00:00 Importing packages started. 2023/02/23 14:28:23 -00:00 2023/02/23 14:28:23 -00:00 Importing packages to DB: 2023/02/23 14:28:23 -00:00 File not found inside package 2023/02/23 14:28:23 -00:00 Package batch #1 of 1 completed... 2023/02/23 14:28:23 -00:00 Importing packages finished. 2023/02/23 14:28:24 -00:00 2023/02/23 14:28:24 -00:00 Patches in repo: 0. Am I missing something ? Regards, 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/> <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/>

1 0

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