May 2021 - ARCHIVED: Uyuni Users - openSUSE Mailing Lists

[uyuni-users] Fresh Install uyuni 2020.05 Error generating bootstrap repo
by Thomas Weis 24 Aug '22

24 Aug '22

Hello everyone we are configuring a fresh installation of Uyuni 2020.05 After a successful reposync of SUSE Linux Enterprise Server 15 SP1 x86_64 we get an error message: Type: Creating Bootstrap Repository failed Summary: Error generating bootstrap repo for: SLE-15-SP1-x86_64 show details said: ERROR: package 'hwdata' not found ERROR: package 'python3-hwdata' not found ERROR: package 'python3-rhnlib' not found ERROR: package 'spacewalk-check' not found ERROR: package 'spacewalk-client-setup' not found ERROR: package 'spacewalk-client-tools' not found ERROR: package 'python3-spacewalk-check' not found ERROR: package 'python3-spacewalk-client-setup' not found ERROR: package 'python3-spacewalk-client-tools' not found ERROR: package 'python3-uyuni-common-libs' not found ERROR: none of 'mgr-daemon', 'spacewalksd' found ERROR: package 'suseRegisterInfo' not found ERROR: package 'python3-suseRegisterInfo' not found ERROR: package 'zypp-plugin-spacewalk' not found ERROR: package 'python3-zypp-plugin-spacewalk' not found The installation was error-free, we proceeded exactly according to the documentation. What is our mistake? thanks for suggestions Regards Thomas-- To unsubscribe, e-mail: uyuni-users+unsubscribe(a)opensuse.org To contact the owner, e-mail: uyuni-users+owner(a)opensuse.org

3 2

Re: [EXTERNAL] Re: Equivalent of macros functionality with salt registered system?
by Allen Beddingfield 28 May '21

28 May '21

Thanks. Sigh. That's is a lot further off into the weeds than I wanted to get, but I can probably make something work. My usage for SUSE Manager and Uyuni is about 50% patching, 40% pushing config files, and 10% remote execution. I really haven't gotten into the Salt states, because until I started finding that macros don't work, I haven't had much need to change my process from the original way I've been doing things forerver (pre-salt). Postfix was the example I gave, but I've been using salt postfix.set_main to set relayhost and the hostname. What I'm trying to do is to deploy an rpm-based agent to about 500 clients, then push the config file, having the hostname populated. With this, I can figure out enough of salt to do a salt state to put the agent out there, then do what you suggested with the file replace, or push it as I had planned, and remote execute something to use sed in a shell script to do it. Or, I can remote execute a shell script to do the whole thing. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu <https://www.ua.edu/> ________________________________ From: Julio Gonzalez Sent: Friday, May 28, 2021 4:52 PM To: uyuni-users(a)opensuse.org; users(a)lists.uyuni-project.org Cc: Allen Beddingfield Subject: [EXTERNAL] Re: Equivalent of macros functionality with salt registered system? On viernes, 28 de mayo de 2021 21:48:28 (CEST) Allen Beddingfield wrote: > Is there an equivalent of the Spacewalk macros that work with traditional > clients for systems registered with salt? > > For example, here is what I used to put in the /etc/postfix/main.cf config > file: myhostname = {| rhn.system.hostname |} > > When the client is registered with salt, it puts that string of text, > instead of putting the value of the hostname. How can I accomplish this > with a salt client? > > Here is a link to the functionality I mention. > https://access.redhat.com/documentation/en-us/red_hat_satellite/5.6/html/get > ting_started_guide/getting_started_guide-channel_management-managing_configu > ration_channels-including_macros_in_configuration_files You use grains, and can use pillar data, depend on what you need. https://www.uyuni-project.org/uyuni-docs/uyuni/salt/salt-states.html https://docs.saltproject.io/en/3002/topics/grains/ https://docs.saltproject.io/en/3002/topics/pillar/index.html And since 2021.05 you can have also any custom data as pillar data, that then you can use at the salt states: https://www.uyuni-project.org/doc/2021.05/release-notes-uyuni-server.html#_… For your example, if you only want to change a single line, you could use file.replace as part of a state https://docs.saltproject.io/en/latest/ref/states/all/salt.states.file.html#… mystate: file.replace: - name: /etc/postfix/main.cf - pattern: 'myhostname = .*' - repl: 'myhostname = '"{{salt['grains.get']('fqdn')}}"' But as I guess you want to change more things at that postfix configuration, then you should consider "file.managed" and jinja templates: https://docs.saltproject.io/en/3002/topics/jinja/index.html#jinja-in-files Hope it helps :-) > Thanks! > Allen B. > -- > Allen Beddingfield > Systems Engineer > Office of Information Technology > The University of Alabama > Office 205-348-2251 > allen(a)ua.edu -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Equivalent of macros functionality with salt registered system?
by Allen Beddingfield 28 May '21

28 May '21

Is there an equivalent of the Spacewalk macros that work with traditional clients for systems registered with salt? For example, here is what I used to put in the /etc/postfix/main.cf config file: myhostname = {| rhn.system.hostname |} When the client is registered with salt, it puts that string of text, instead of putting the value of the hostname. How can I accomplish this with a salt client? Here is a link to the functionality I mention. https://access.redhat.com/documentation/en-us/red_hat_satellite/5.6/html/ge… Thanks! Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

2 1

Fix for a problem syncing Debian/Ubuntu client tools
by Julio Gonzalez 28 May '21

28 May '21

Hi, Thanks to a report from Markus Thum, we realized that the repository syncing scripts did not support DEB packages without a Maintainer field at the control file. This was never a problem because Debian and Ubuntu DEB packages always have this field (it is mandatory according to their policies). But the new "scap-security-guide-*" DEBs don't have this field at this moment. We intend to fix this in collaboration with the SLE package maintaners (as we just build the package for Ubuntu/Debian from their sources), but that is going to take some time, and it would require republishing the client tools for Uyuni. While this problem does not break the repository syncing scripts, it shows an error on-screen, or at the logs (that produces an email each time an automated sync is launched). For this reason we decided to use the Patch procedure to fix this issue at the server (in the end packages without the Maintaner field are valid [1]), instead of waiting until Uyuni 2021.06 is released. You can apply the patch by following the instructions at: https://www.uyuni-project.org/pages/patches.html#server Of course, the fix will be part of Uyuni 2021.06 as well, so it's not required if you don't manage Debian or Ubuntu clients. Best regards. [1] https://manpages.debian.org/buster/dpkg-dev/deb-control.5.en.html -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Reposync error Debian10-Uyuni-Client-Tools
by Markus.Thum＠iese.fraunhofer.de 28 May '21

28 May '21

Hi, synchronizing the repository "External - Uyuni Client Tools for Debian 10 Buster AMD64<https://uyuni.iese.fhg.de/rhn/channels/manage/repos/RepoEdit.do?id=526>" throws an error. In the logs I find 11:47:44 | Channel: debian-10-amd64-uyuni-client 11:47:44 ====================================== 11:47:44 Sync of channel started. 11:47:45 Repo URL: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… 11:47:45 Packages in repo: 35 11:47:45 Packages already synced: 31 11:47:45 Packages to sync: 4 11:47:45 New packages to download: 4 11:47:45 Downloading packages: 11:47:45 Downloading total 4 files from 1 queues. 11:47:45 1/4 : scap-security-guide_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:46 2/4 : scap-security-guide-debian_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:46 3/4 : scap-security-guide-ubuntu_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:47 4/4 : scap-security-guide-redhat_0.1.55git20210323-1.13.2.uyuni_all.deb 11:47:47 11:47:47 Importing packages to DB: 11:47:47 Package batch #1 of 1 completed... 11:47:47 11:47:47 Patches in repo: 0. 11:47:47 Total time: 0:00:02 2021-05-27 11:47:47,372 [Thread-113] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - 11:47:47 'Maintainer' 11:47:47 'Maintainer' 11:47:47 'Maintainer' 11:47:47 'Maintainer' 2021-05-27 11:47:47,439 [DefaultQuartzScheduler_Worker-7] ERROR com.redhat.rhn.taskomatic.task.RepoSyncTask - Command '[/usr/bin/spacewalk-repo-sync, --channel, debian-10-amd64-uyuni-client, --type, deb, --non-interactive]' exited with error code 4 Uyuni 2021.05 on openSUSE Leap 15.2 Regards Markus

3 5

Centos 7 - salt-minion regresion ?
by Cristian Gherman 27 May '21

27 May '21

Hello I spoted a issue with install packges action from Uyuni which not marked as finished (but process is ok on minions) From my log I saw a newer version in instaled on my minion. From my yum log: /var/log/yum.log:Feb 08 02:53:54 Updated: salt-minion-3000-26.2.uyuni.x86_64 /var/log/yum.log:Mar 10 07:47:56 Updated: salt-minion-3000-29.1.uyuni.x86_64 /var/log/yum.log:Apr 24 01:52:50 Updated: salt-minion-3000-36.1.uyuni.x86_64 But now on server in folder http://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable:… I see version salt-minion-3000-20.2 On my server (Opensuse 15.2) after upgrade to Uyuni 2021.05 I have slat master version salt-master-3000-lp152.3.33.1.x86_64 (I think form Opensuse repos). After I downgraded on one sever to salt-minion-3000-20.2.uyuni.x86_64 install , the task Package Install/Upgrade is marked as finished. I checked also the sync log: From my sync log: 2021/04/22 03:14:17 -04:00 Command: ['/usr/bin/spacewalk-repo-sync', '--channel', 'centos7-uyuni-client', '--type', 'yum', '--non-interactive'] 2021/04/22 03:14:17 -04:00 Sync of channel started. 2021/04/22 03:14:21 -04:00 Repo URL: https://download.opensuse.org/repositories/systemsmanagement:/Uyuni:/Stable… 2021/04/22 03:14:21 -04:00 Packages in repo: 269 2021/04/22 03:14:21 -04:00 Packages already synced: 215 2021/04/22 03:14:21 -04:00 Packages to sync: 54 2021/04/22 03:14:21 -04:00 New packages to download: 54 2021/04/22 03:14:21 -04:00 Downloading packages: 2021/04/22 03:14:29 -04:00 30/54 : python2-suseRegisterInfo-4.2.3-2.1.uyuni.noarch.rpm 2021/04/22 03:14:29 -04:00 31/54 : go1.15-bin-1.15.2-10.1.uyuni.x86_64.rpm 2021/04/22 03:14:29 -04:00 32/54 : python2-uyuni-common-libs-4.2.3-3.2.uyuni.x86_64.rpm 2021/04/22 03:14:29 -04:00 33/54 : salt-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 34/54 : salt-cloud-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 35/54 : salt-api-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 36/54 : salt-master-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 37/54 : salt-minion-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 38/54 : salt-proxy-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 39/54 : python2-salt-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 40/54 : salt-ssh-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 41/54 : salt-standalone-formulas-configuration-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 42/54 : salt-doc-3000-36.1.uyuni.x86_64.rpm 2021/04/22 03:14:30 -04:00 43/54 : salt-syndic-3000-36.1.uyuni.x86_64.rpm Than you. -- Cristian Gherman Support / PHP developer cristian.gherman(a)reea.net | www.reea.net | +4 0365410942

2 2

Uyuni 2021.05 is released!
by Julio Gonzalez 24 May '21

24 May '21

Hello everyone! We are happy to announce the immediate availability of Uyuni 2021.05 At https://www.uyuni-project.org/pages/stable-version.html you will find all the resources you need to start working with Uyuni 2021.05, including the release notes, documentation, requirements and setup instructions. IMPORTANT: Read the release notes. Depending on your current Uyuni version some more manual steps can be required to update the Server (for example if your current version is < 2021.05) This is the list of highlights for this release: - SLE Micro 5.0 and openSUSE MicroOS as clients - Deprecated products (RHEL6 and clones, Ubuntu16.04) - Prometheus TLS - Updated Prometheus - Migrate clients from openSUSE Leap to SUSE Linux Enterprise Server - Easier system group and configuration channel assignment - Enhanced CLM filter list - Notify beacon for DEB-based clients - Allow setting primary FQDN for the systems - Virtualization improvements - Custom data as pillar - Retracted patches - Client systems forwarded to SUSE Customer Center - Configuration state summary - Live patching made easy with filter templates - HTML documentation for the API - New API calls - spacecmd improvements - Activation key dropped from system details - Software Crashes (ABRT) dropped Please check the release notes for full details. 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 2021.05 As always, we hope you will enjoy Uyuni 2021.05 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

Schema migration with Uyuni 2021.05 upgrade fails
by Bob Martens 24 May '21

24 May '21

I have run into an issue where the schema migration has failed with the 2021.05 upgrade. This is what I get when I try to run the migration on my own: Schema upgrade: [susemanager-schema-4.2.9-1.1.uyuni] -> [susemanager-schema-4.2.13-1.1.uyuni] Searching for upgrade path to: [susemanager-schema-4.2.13-1] Searching for upgrade path to: [susemanager-schema-4.2.13] Searching for upgrade path to: [susemanager-schema-4.2] Was not able to find upgrade path in directory [/etc/sysconfig/rhn/schema-upgrade]. There is no directory beyond susemanager-schema-4.2.11-to-susemanager-schema-4.2.12. I am wondering if something is missing on my end and what I can do to get it back and get back up and running. Thanks!

2 1

Replacing the SSL cert for the web interface
by Bob Martens 24 May '21

24 May '21

Is there a supported way to replace the web interface SSL cert? Is it the best option to keep that (Apache certificate) and the SSL certs used for management separate? If I had used a signed wildcard cert to set up the server originally, would it be best to switch to a self-signed cert for the management portion now? Thanks!

2 2

Client Package List updating problems with Ubuntu 20.04 and Uyuni
by Paul-Andre Panon 20 May '21

20 May '21

After those changes you suggested for changing the machine-id of cloned VMs and enabling the repo signing, we’ve now added a few servers as clients, gone through two package patching cycles, and have noticed that the package list for at least some clients doesn’t appear to be updating. I currently have nine Ubuntu 20.04 clients registered with Uyuni. Two show outstanding package updates (even though they’ve been updated from the client side with apt-get upgrade) and apt-get upgrade command shows no outstanding patches. Some of the others show no outstanding upgrades/patches from the Uyuni client pages, but an apt-get upgrade shows multiple outstanding packages. The clients appear to be updating some info though. None show up in the Inactive systems list, and the last reboot parameter appears to be updated. For the two where Uyuni shows updatable packages and apt reports none, the UUID in the System Info is the same for both systems. However since the Web UI reference documentation doesn’t say much about the UUID field (beyond “The universally unique identifier”) it’s hard to tell if that’s an internal Uyuni number, or something like the machine-id that hasn’t been properly updated . I tried looking at the possibly relevant Troubleshooting guides but didn’t find anything that appeared relevant. /var/log/rhn/rhn_taskomatic_daemon.log has some 401 and 403 errors that appear to be for the SLES for SAP product/channels that we haven’t started using yet. mgr-sync list credentials reports a primary credentials entry but there’s this error in the taskomatic log file 2021-02-01 00:26:08,950 [DefaultQuartzScheduler_Worker-12] WARN com.redhat.rhn.manager.content.ContentSyncManager - Error reading UUID: /etc/zypp/credentials.d/SCCcredentials (No such file or directory) While I don’t think that ‘s relevant to the Ubuntu package list, it’s something I’ll have to figure out fairly soon. Cheers, Paul-Andre *From:* Paul-Andre Panon <paul-andre.panon(a)avigilon.com> *Sent:* Tuesday, January 26, 2021 4:02 PM *To:* 'Pau Garcia' <pau.garcia(a)suse.com>; 'users(a)lists.uyuni-project.org' < users(a)lists.uyuni-project.org> *Subject:* RE: Registration problems with Ubuntu 20.04 and Uyuni Well, it’s a definite improvement. I’ve rolled that into the template customization scripts and I can now see more than 1 system registered. Thank you. I’m now seeing a different problem. W: Failed to fetch https://myuniserver.mydomain:443/rhn/manager/download/dists/ubuntu-2004-amd… Undetermined Error [IP: AA.BB.CC.DD 443] If I try to go to that URL from a browser, I get You need a token to access /manager/download/ubuntu-2004-amd64-main-security-uyuni/repodata/InRelease The only reference I’ve found in google for that appears to be in Spanish and CentOS related on a capa9.net forum. *From:* Pau Garcia <pau.garcia(a)suse.com> *Sent:* Tuesday, January 26, 2021 1:18 AM *To:* Paul-Andre Panon <paul-andre.panon(a)avigilon.com>; users(a)lists.uyuni-project.org *Subject:* Re: Registration problems with Ubuntu 20.04 and Uyuni Hello Have you checked this? https://www.uyuni-project.org/uyuni-docs/uyuni/administration/tshoot-regist… <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.uyuni-2Dproject.or…> Troubleshooting Registering Cloned Clients :: Uyuni Documentation <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.uyuni-2Dproject.or…> If you are using Uyuni to manage virtual machines, you might find it useful to create clones of your VMs. A clone is a VM that uses a primary disk that is an exact copy of an existing disk. www.uyuni-project.org Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager SUSE Software Solutions Spain ------------------------------ *From:* Paul-Andre Panon <paul-andre.panon(a)avigilon.com> *Sent:* Tuesday, January 26, 2021 8:30 AM *To:* users(a)lists.uyuni-project.org <users(a)lists.uyuni-project.org> *Subject:* Registration problems with Ubuntu 20.04 and Uyuni Hi, I’m trying to set up an Uyuni server to replace a Spacewalk server, starting with setting up support for Ubuntu 20.04. Ideally we would like to be able to use a vSphere VM template that we can use to generate/clone new VMs, and then run a script on that new VM to customize it with the specific desired hostname, AD domain registration, and Uyuni registration. For the Uyuni registration, I started with the generated bootstrap script and customized it with an Activation Key and the Ubuntu GPG keys (ubuntu-gpg-pubkey-871920D1991BC93C.key,uyuni-gpg-pubkey-0d20833e.key) . The registration script appears to work. If I look in Uyuni’s Salt->Keys page, I see the key, can approve it and the system shows up in the system list…. the first time. On subsequent VMs however, I see the key in the Salt->Keys page, can approve them, and then after some time I only see one of the two VMs in the system list, usually the last one added. While setting up the Uyuni server and VM template, it took me a while to figure out I was supposed to use the modified bootstrap script, so I had first tried to install salt packages on the template and thought that might be the problem. I took a hint from the bootstrap script and tried to run apt-get purge salt-minion apt-get purge salt-common rm -rf /etc/salt/minion.d/ on the template to clear any salt state, cleared systems and keys on the Uyuni server, and started over creating new VMs,… with the same result. Any suggestions on what could be going wrong? Thanks, Paul-Andre Panon, B.Sc. Senior Systems Administrator Video Security & Analytics *o:* +1.604.629.5182 ext 2190 *m*: +1.604.787.4547 *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?elqTrackI…>.* -- *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?elqTrackI…>.*

4 4