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

Subtask mgr-update-reporting failed.
by Crefeld, Tobias LKV Bayern e.V. 28 Jul '22

28 Jul '22

Hi, recently I upgraded the Uyuni system from 2021.07 to 2022.06. Several tests were successful so I'm not sure if the current problems come from the update. There are two issues: 1. Since Uyuni's update several clients don't check in any more. All of them are using "Push via SSH tunnel" or "Push via SSH" as contact method. Salt clients with contact method "Default" (SLES15-SP3) run fine. Client OS is "openSUSE Leap 15.1 x86_64" or "SUSE Linux Enterprise Server 12 SP5 x86_64". There is no "configuration" or scripting - the only target is to monitor the patch level and provide repositories. 2. After a reboot of the Uyuni host I was sent an email with this content: "Taskomatic bunch mgr-update-reporting-bunch was scheduled to run within the update-reporting-default schedule. Subtask mgr-update-reporting failed. For more information check null." (Checking "null" wasn't successful) Any hints are welcome! Regards, Tobias Crefeld.

2 1

A question about venv-salt-minion and systemd
by Simon Avery 22 Jul '22

22 Jul '22

Hi A little flummoxed about this. I've switched to using venv-salt-minion on clients, and it installs okay. However, we require /tmp to have the noexec flag. Salt doesn't like this very much. Our previous workaround was to create a file in /etc/systemd/system/salt-minion.service.d containing [Service] Environment="TMPDIR=/usr/tmp" This told salt-minion to use a different tmpdir that did have the exec flag and it was happy again. However, venv-salt-minion doesn't read that file, because it's a different service. I assumed I could just create /etc/systemd/system/venv-salt-minion.service.d instead, but the process is not reading this. If I edit the system file directly and add that file it works, but I would prefer to use a drop-in file for this. I'm not overly familiar with venv programs, and less so when combined with systemd. Can anyone please point me the right way to do this? Thanks S

2 3

A fix for using HTTP proxies for repository synced is now released
by Julio Gonzalez 21 Jul '22

21 Jul '22

The fix requires two things: - Uyuni 2022.06 - The latest python3-urlgrabber from openSUSE Leap 15.4 The issue is being tracked at https://github.com/uyuni-project/uyuni/issues/4850 Special thanks to Dan Holstad, hbrown-uiowa, phibid and SpeedBlack for the report, and to Dominik Wombacher and Pablo Suárez for the fix. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

Re: Error trying to bootstrap / register / onboard sles15sp3 salt client/minion
by Heiner W. 15 Jul '22

15 Jul '22

Hi List, here's some additional Information regarding my problem ("Error registering minion id: dehwllhdb21") What confuses me the most: Uyuni integrated salt master is able to work with said client/minion: # salt dehwllhdb21 cmd.run date dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e What i already tried: I removed any salt rpm and config from client several times before each bootstrap retry: # zypper remove -y venv-salt-minion salt* # rm -rf /etc/venv-salt-minion* /etc/salt* Also regenerated system uid: # rm /etc/machine-id /var/lib/dbus/machine-id # dbus-uuidgen --ensure # systemd-machine-id-setup ... and rebooted the client os. I tried bootstrapping with new venv salt and also the old salt-minion packages. I even tried using another network interface on my client, with another ip, net, route to uyuni. Why can't uyuni register the client (get its data/grains) but directly using salt as root in bash from uyuni seems to work great? What else could i try? Thanks, Heiner

3 5

Where is mgr-bootstrap on a containerized proxy?
by Paul-Andre Panon 14 Jul '22

14 Jul '22

After some brow sweat figuring out that a firewalld IP range overlap between zone sources was breaking routing for a containerized proxy, I'm ready to try to follow up with setting up some bootstrap scripts on the proxy. However I can't seem to find mgr-bootstrap to do so because it doesn't appear to be in the container host path. How does one generate bootstrap scripts on a containerized proxy? Thanks Paul-Andre Panon

2 9

Spacewalk add channel has failed
by Martin Willisegger 12 Jul '22

12 Jul '22

Hello list Currently I cannot attach a specific channel for opensuse Leap 15.4 to Uyuni. I get the following error message: uyuni:~ # spacewalk-common-channels -a x86_64 opensuse_leap15_4-sle-updates SUSE Manager username: admin SUSE Manager password: Base channel 'openSUSE Leap 15.4 (x86_64)' - exists WARNING: opensuse_leap15_4-x86_64-sle-updates: redstone.xmlrpc.XmlRpcFault: The channel name 'Update repository with updates from SUSE Linux Enterprise 15 (x86_64)' is already in use, please enter a different name I think there is a conflict with the existing subchannel from Leap 15.3: opensuse_leap15_3-x86_64-sle-updates However, this repo is needed for 15.3 and 15.4. What possibility do i have to import and attach this channel for 15.4 anyway? Best regards Martin

1 0

Patch for Uyuni 2022.06
by Julio Gonzalez 06 Jul '22

06 Jul '22

Hello! Several users syncing openSUSE Leap 15.3/15.4 and/or the SUSE PackageHub reported that they are getting the following error running reposync from CLI, or at the WebUI notifications area: 2022/07/05 09:22:01 +02:00 Importing packages to DB: 2022/07/05 09:22:02 +02:00 'rpm.hdr' object has no attribute 'get' Please note that this bug does **not** prevent syncing other packages, it just means that the package `kicad-packages3D` version `5.1.8-bp154.1.18` failed to sync due to the bug. So it wont be available for Uyuniu clients, as it won't be synced at the server. Other than that the reposync will work just as usual. If automated syncing is for the affected channels is enabled, then you will also get notifications at the UI (the "bell" icon). A patch for Uyuni 2022.06 to fix both problems was just published, in case you do not want to wait for Uyuni 2022.07 (it will be part of that release as well). You can apply the patch by following the instructions at: https://www.uyuni-project.org/pages/patches.html If you are using Uyuni 2022.05 or older: make sure you update to 2022.06, and remember 2022.06 changes the base OS to openSUSE Leap 15.4, so you need to follow a special procedure (check the release notes). Thank to all users that reported the issue, and specially to Jonathan Müller (LordofAgents) for providing the information about the affected package. Happy hacking! -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

1 0

How to mirror/sync repos of type yast
by Heiner Wulfhorst 04 Jul '22

04 Jul '22

Hi List, i need to sync a HPE Foundation Repo into my CLM: https://update1.linux.hpe.com/repo/hpe-foundation/2.4.3/Suse/SLES15-SP3/ Unfortunately it seems to have yast structure: https://en.opensuse.org/openSUSE:Standards_YaST2_Repository_Metadata#Reposi… How can I mirror it into uyuni? Configuring it as yum type repo produces this error when trying to sync: *# spacewalk-repo-sync --type yum --channel hpe-foundation-workaround* 16:52:20 ====================================== 16:52:20 | Channel: hpe-foundation-workaround 16:52:20 ====================================== 16:52:20 Sync of channel started. Retrieving repository 'hpe-foundation-workaround' metadata ......................................................................................................................[done] Building repository 'hpe-foundation-workaround' cache ...........................................................................................................................[done] All repositories have been refreshed. 16:52:24 Unexpected error: <class 'FileNotFoundError'> 16:52:24 Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/reposync.py", line 610, in sync repo_checksum_type = plugin.get_md_checksum_type() File "/usr/lib/python3.6/site-packages/spacewalk/satellite_tools/repo_plugins/yum_src.py", line 750, in get_md_checksum_type infile = fileutils.decompress_open(repomd_path) File "/usr/lib/python3.6/site-packages/uyuni/common/fileutils.py", line 521, in decompress_open file_obj = codecs.open(filename, 'r', encoding="utf8") File "/usr/lib64/python3.6/codecs.py", line 897, in open file = builtins.open(filename, mode, buffering) *FileNotFoundError: [Errno 2] No such file or directory: '/var/cache/rhn/reposync/1/hpe_foundation_workaround_repo/var/cache/zypp/raw/hpe-foundation-workaround/repodata/repomd.xml'* 16:52:24 Total time: 0:00:04 Thanks, BR, Heiner

3 4