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

Config channels - how do they work?
by Simon Avery 18 May '21

18 May '21

Hello, I'm seeking clarity about Config channels. I've read the docs and been using them for a while, and whilst all the manual aspects work as I expect, the automation bits aren't. I've read the documentation but still have some questions. I'm not sure on whether this is a bug, or more likely, I'm misunderstanding or have misconfigured. Problem: I can see Uyuni regularly compares remote files to those in the config channels and reports versions, but even when a remote file is changed, it doesn't replace the remote file. Example: I have a file in a Uyuni "managed config channel" called "/root/myfile.txt". I push this to a remote client and it appears there. (Or a new vm is built and the file deployed when it's bootstrapped to uyuni) I then modify the file *on the remote client* In Uyuni, if I manually run "Show differences between profiled config files and deployed config files" for that server (or let Uyuni do its periodic check) it does not replace the remote file. Expectation: That Uyuni would diff the remote file and if it was different, would re-push a copy from central configuration. Because there is facility for Note: Uyuni is spotting the files have changed - on the System vm page: "Last Uyuni and System Comparison: 9 hours ago 30 of 31 files on the system were successfully compared with Uyuni-Managed files. [View Details<https://ata-oxy-uyuni01.atass.com/rhn/systems/details/history/Event.do?aid=…>] 4 of 30 files on the system differed from the Uyuni-Managed files." I don't have any State Channels configured - other than salt-minion as a remote client, I'm not doing anything Salty with Uyuni at all. Can anyone help me understand what's supposed to happen please, and how I can encourage Uyuni to force certain files? Thank you Simon

3 4

Re: SMDBA Tool does not clean up the backup archives
by Thomas Weis 17 May '21

17 May '21

Hi Jordi, it is the documentation from the Uyuni project site: https://www.uyuni-project.org/uyuni-docs/uyuni/administration/backup-restor… I configured all of them exactly as documented there, including the entry in /etc/cron.d/db-backup-mgr. @Michael Calmer the one and only entries in the daily log files are: "unexpected EOF on client connection with an open transaction" I think this is just an indication of the online status of the DB during the "hot backup"? Otherwise, log files and the WAL files in / var / spacewalk / db-backup are diligently created every day. The files are just simply not deleted @Silvio Moioli that's exactly what I assumed, it doesn't make sense to keep the WAL files until the Last Judgment. To make room temporarely, I deleted the oldest files from 2020 manually now. Regards Thomas > Am 17.05.2021 um 10:46 schrieb Jordi Massaguer Pla <jmassaguerpla(a)suse.de>: > > > On 5/14/21 6:56 PM, Thomas Weis wrote: >> Hi Jordi, >> >> Thank you for your answer. >> Yes, I expected that the smba tool would only archive a certain time frame. >> According to the documentation: "The smdba tool also manages your archives, keeping only the most recent backup, and the current archive of logs." >> Have I misinterpreted that and do I delete the superfluous archives manually or by script or does the smdba tool not do what it should do here? > > Can you do me a favor and point me to the documentation? I joined this teams some months ago and, among other things, I am taking care of this, so I don't know yet all the details, thus I am not sure if you refer to suse manager docs, uyuni wiki, smdba readme > > If you don't mind sending me a link to the docs where this is stated, you would save me some time to look everywhere ;) > > > Thanks in advance > > jordi > > > > -- > Jordi Massaguer Pla > Linux Engineer > SUSE Linux > https://www.suse.com >

1 0

SMDBA Tool does not clean up the backup archives
by Thomas Weis 17 May '21

17 May '21

Hello everybody, Since our initial installation of Uyuni, we have been making database backups with the smdba tool. We set up the backup exactly according to the information in the documentation. After the first manual backup, the automatic backups were activated via cron and work perfectly. Today we received a warning about insufficient storage space and found that the old archives in the DB backup directory / var / spacewalk / db-backup are obviously not to be deleted. All daily archives are available back to 09/20/2020. Where do I start looking for the cause? Many thanks for the support! best regards Thomas

4 4

Issue trying to share EPEL 8 repo between CentOS 8 and Alma 8
by Bidault, Philippe 14 May '21

14 May '21

Hi all, I am trying to use the EPEL 8 repository already in use by a CentOS 8 channel, on a new created channel for Alma 8. However no matter what, I have this error on a Alma 8 server while trying to install a package coming from EPEL 8 repo: # yum install screen AlmaLinux 8 AppStream (x86_64) 7.2 MB/s | 8.7 MB 00:01 EPEL 8 for AlmaLinux 8 (x86_64) 711 B/s | 251 B 00:00 Errors during downloading metadata for repository 'susemanager:epel8-alma8-x86_64': - Downloading successful, but checksum doesn't match. Calculated: b3dae961df1c6d9c7aeee6aa7e47da707b371f50(sha1) Expected: 66af4e77dffc81221d6dc1e600bb7b5f8d91c3bd(sha1) - Downloading successful, but checksum doesn't match. Calculated: cbf52120a8eea9bfbd9a049f73b3d56d855fbeff(sha1) Expected: 8507cfead7c1eff2c1a04b45d0981bef6baad476(sha1) Error: Failed to download metadata for repo 'susemanager:epel8-alma8-x86_64': Yum repo downloading error: Downloading error(s): repodata/primary.xml.gz - Cannot download, all mirrors were already tried without success; repodata/filelists.xml.gz - Cannot download, all mirrors were already tried without success I have absolutely no issue with this same repo but on a CentOS 8. Somebody with this same issue ? Am I doing something wrong or am I missing something ? Thanks ! Philippe. Philippe Bidault | Unix Engineer | Getronics ________________________________ M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<https://www.getronics.com> [cid:3-lines_7512e235-163a-4853-8e4f-b0d4fc62ce73.png]<https://getronics.com/> 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/

1 1

Uyuni as simple Repository Server?
by Tobias Crefeld 14 May '21

14 May '21

Hi, I have several systems (SLES + opensuse) that have no access to the public internet but to our Uyuni system. Unfortunately we're not allowed to install a client software on these systems, so a regular system integration by Uyuni is not possible. On the other hand it is possible to edit the client's repository configuration ( /etc/zypp/repos.d/ manually. With a standard webserver that is regularly mirrored to a public repository this is no problem, but if I look at our typical salt clients I find baseurls like baseurl=https://HOST.DOMAIN.TLD:443/rhn/manager/download/sle-module-legacy15-sp1-updates-x86_64?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2MzQ5ODE5NDAsImlhdCI6MTYwMzQ0NTk0MCwibmJmIjoxNjAzNDQ1ODIwLCJqdGkiOiIzQS1PbmpjanMtQXFETmZqVTJkTU93Iiwib3JnIjoxLCJvbmx5Q2hhbm5lbHMiOlsic2xlLW1vZHVsZS1sZWdhY3kxNS1zcDEtdXBkYXRlcy14ODZfNjQiXX0.H203CwoN5ns0YUnzZMmd Using these URL in a webbrowser returns 4xx - errors. Is there any way to provide the respective clients a standard path like http://download.opensuse.org/distribution/leap/15.2/repo/oss/ to the Uyuni server? Or is there any other way to provide Uyuni's repositories to these "clients" without installing special software at the client side? TIA! -- Gruss, Tobias Crefeld. xmpp (no email): crefeld(a)xabber.de

3 2

RE: Config channels - how do they work?
by Simon Avery 14 May '21

14 May '21

Thanks Stefan, it’s good to know that it can work! However, I’ve left the modified files in place on a target system and it hasn’t replaced them after three days, so it feels like it’s not going to. I wonder what’s not right on mine that is on yours? S From: Stefan Bluhm <stefan(a)bluhm-de.com> Sent: 13 May 2021 09:08 To: uyuni-users(a)opensuse.org; Simon Avery <Simon.Avery(a)atass-sports.co.uk> Subject: [EXTERNAL EMAIL] AW: Config channels - how do they work? Hey Simon, That is how it works for me. I see how many and what files changed including a diff per System. It does take some time to sync but you can force a refresh. Best wishes, Stefan Sent from a mobile device. ---- Simon Avery schrieb ---- Hello, I’m seeking clarity about Config channels. I’ve read the docs and been using them for a while, and whilst all the manual aspects work as I expect, the automation bits aren’t. I’ve read the documentation but still have some questions. I’m not sure on whether this is a bug, or more likely, I’m misunderstanding or have misconfigured. Problem: I can see Uyuni regularly compares remote files to those in the config channels and reports versions, but even when a remote file is changed, it doesn’t replace the remote file. Example: I have a file in a Uyuni “managed config channel” called “/root/myfile.txt”. I push this to a remote client and it appears there. (Or a new vm is built and the file deployed when it’s bootstrapped to uyuni) I then modify the file *on the remote client* In Uyuni, if I manually run “Show differences between profiled config files and deployed config files” for that server (or let Uyuni do its periodic check) it does not replace the remote file. Expectation: That Uyuni would diff the remote file and if it was different, would re-push a copy from central configuration. Because there is facility for Note: Uyuni is spotting the files have changed – on the System vm page: “Last Uyuni and System Comparison: 9 hours ago 30 of 31 files on the system were successfully compared with Uyuni-Managed files. [View Details<https://ata-oxy-uyuni01.atass.com/rhn/systems/details/history/Event.do?aid=…>] 4 of 30 files on the system differed from the Uyuni-Managed files.” I don’t have any State Channels configured – other than salt-minion as a remote client, I’m not doing anything Salty with Uyuni at all. Can anyone help me understand what’s supposed to happen please, and how I can encourage Uyuni to force certain files? Thank you Simon

1 1

aarch64 available for Server/Proxy for Uyuni Master
by Julio Gonzalez 14 May '21

14 May '21

Hi everyone, aarch64 is now enabled for the Master project [1]. Big thanks to Guillaume Gardet for helping us with the first steps and the initial testing! This means you can now install Uyuni Master Server on top of openSUSE Leap 15.2 aarch64 by following the instructions at https://www.uyuni-project.org/pages/devel-version.html The proxy can be installed by following the doc, and replacing x86_64 with aarch64 where appropriate (doc is not updated yet). Remember that Uyuni Master must not be used for production purposes!!!! Before we launch it as Stable, we want to gather some feedback from the community (as discussed during the last Community Hours). - If you give it a try and you don't find any issues, let's us know by replying to this email. - If you find issues, you can reply as well, but even a better alternative is creating an issue at https://github.com/uyuni-project/uyuni/issues Happy hacking! [1] https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

Uyuni Community Hours 28.05.2021
by Pau Garcia 09 May '21

09 May '21

Uyuni Community Hours are held every last Friday of the month, at 4pm CET. The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Uyuni is the upstream project of SUSE Manager. ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_NDZmYWUyZWItMzhhOC00…> Or call in (audio only) +34 917 94 59 77,,946463263#<tel:+34917945977,,946463263#> Spain, Madrid Phone Conference ID: 946 463 263# Find a local number<https://dialin.teams.microsoft.com/58c3986f-4c3a-4b77-b4e8-f431171ef66d?id=…> | Reset PIN<https://mysettings.lync.com/pstnconferencing> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=83d1ce03-a2c8-4530-…> ________________________________________________________________________________

1 0

Autoyast complaining about unavailable Software
by Heiner Wulfhorst 06 May '21

06 May '21

Hi List, We have bare metal systems that have no network at boot/install time (LACP without fallback is used and we could not find any way to do PXE or DHCP at boot time). So we decided to use Uyuni integrated cobbler to create a bootable ISO for installation: #cobbler buildiso --distro=k8s-nodes-test:1:itmw-oss --airgapped --iso=/data/install_test_nodes_01_bios.iso --source=/var/autoinstall/SLE-15-SP2 We were able to boot from that image after switching from UEFI to legacy BIOS boot style. Autoyast starts but throws this errors: "could not set patterns: enhanced_base" "These packages cannot be found in the software repositories: autoyast2: The package is not available autoyast2-installation: The package is not available chrony-pool-empty: The package is not available tuned: The package is not available" And finally dies with: "... nothing provides /bin/sh needed by product:SLES-15.2..." I checked content of my ISO image and think it looks good, can also find the missing rpm files there: # find ./|grep -e chrony-pool-empty -e tuned -e bash-[0-9] ./Module-Server-Applications/noarch/tuned-2.10.0-11.3.2.noarch.rpm ./Module-Basesystem/noarch/chrony-pool-empty-3.2-9.12.1.noarch.rpm ./Module-Basesystem/x86_64/bash-4.4-9.10.1.x86_64.rpm I implemented it on a test system and was also able to find the rpms autoyast is missing. Why can't autoyast find these files? Must i reference them in my xml, in add-on section? If so, how? How can i create a bootable iso to install with autoyast without having a network connection? Or is there an easy way to create a boot iso that can activate LACP and then do a network install? Thanks, Heiner

1 0

New repository: Uyuni Contrib
by Jochen Breuer 04 May '21

04 May '21

Dear Uyuni community, I'm happy to let you know that we've release the Uyuni Contrib repository [0]. Uyuni Contrib contains tools that are not part of the core Uyuni system, mainly because they address a limited audience or are too experimental to be part of the main repository. This does not preclude their usefulness. So please use them with caution! Uyuni Contrib has currently two folder: * hubtools: Tools to install and configure SUSE Manager Hub. * uyuni-tools: Collection of useful Uyuni Tools. In order to use the tools with your Uyuni installation, you can simply download and extract the ZIP file [1] from GitHub to, for example, /opt. You Uyuni installation should have all dependencies needed to run all the tools. For more information, please check the corresponding README files: * https://github.com/uyuni-project/contrib/blob/main/README.md * https://github.com/uyuni-project/contrib/blob/main/hubtools/README.md * https://github.com/uyuni-project/contrib/blob/main/uyuni-tools/README.md Happy hacking! Jochen [0] https://github.com/uyuni-project/contrib/ [1] https://github.com/uyuni-project/contrib/archive/refs/heads/main.zip -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

1 0

Suma feedback / potentital enh requests
by J-M Roth 02 May '21

02 May '21

Hello, We've been in contact with our Suse Account Team after evaluating and getting a Suma subscription to show our support. First, congrats, the product seems pretty stable, usability is high (GUI is very reactive), it is well-integrated with Saltstack while at the same time providing interfaces for customization. Concerning potential feedback and enhancement requests they told us to come here. So here is my current list: * VERY DANGEROUS: Using groups: It is not clear from the system view that a state/config channel is applied to a system via a group. If a system is managed through a group, that should be made clear on the Systems > system > Configuration > Overview screen and also Systems > system > States > Configuration Channels screen of that individual system. This is _very_ dangerous because applying a highstate might do unexpected things since the system is mostly invisibly part of a group. In the same way, Configuration > Channels > channel > Systems does not show that the currently selected channel applies to any group (or a list of systems expanded from the group, for that matter). It looks like groups were retrofitted, this really needs to be cleaned up. * System shows ok (up-to-date) if product does not exist at all. If you add a system for which the product is not mirrored to Suma at all, the "Updates" column of System List shows a green checkmark while the "base repo" column shows "(none)". The green checkmark is misleading, at most there should be a grey icon or so meaning that there is actually no info. * System shows ok if there are non-compliant packages. A green checkmark appears in System List if system contains non-compliant packages (Systems > system > Software > Packages > Non Compliant). The system list could somehow reflect the presence of non-compliant packages. These could for example pose a security risk. * Very old OS release shows as ok/up-to-date. For example, a fully patched SLES11-SP1 is shown with a green checkmark. Technically, this information therefore correct. However, in reality, the OS has been end-of-life for several years. It should show something other than the green checkmark which is creating a false belief that the system is ok while it should be replaced. Certainly it would not be impossible to look at for example the release date of the latest patch. If it's too old, there can be a warning. * In general, the system list/overview page could provide an even more holistic view by making more distinctions in the "Updates" column (or adding another "Status" perhaps) - Show a warning for very old OS (see above) - Show a warning if system contains non-compliant packages (see above) - Show a warning if product does not exist at all (instead of green, see above) - Reboot required could be shown in that same list (like after an SP migration) - State apply failures could also reflect in that list * Suma bootstrapping does not recognize enabled modules/products If the system being onboarded was previously registered to SCC, SMT or RMT, the previously enabled modules (for example SDK or Web-Scripting-Module etc.) are not automatically activated, even if Suma has correctly mirrored them. Instead, you have to compare which modules were used previously and perform manual actions to add them again. Probably this is not fixable, still it was something that caught our attention. * Software Channel Management Software > Manage > Channels page could show the sync policy for the individual channels. Currently there is no overview of the sync policies of the individual channels. You have to click on each one, open it and take a look. Best regards, J-M Roth

3 2