it is the documentation from the Uyuni project site:
I configured all of them exactly as documented there, including the entry in /etc/cron.d/db-backup-mgr.
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
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.
> 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 Massaguer Pla
> Linux Engineer
> SUSE Linux
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!
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 ?
Philippe Bidault | Unix Engineer | Getronics
M. 34617301667 | E. Philippe.Bidault(a)Getronics.com | W. www.getronics.com<https://www.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/
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
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?
xmpp (no email): crefeld(a)xabber.de
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?
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?
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.
Sent from a mobile device.
---- Simon Avery schrieb ----
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.
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.
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.
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
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?
aarch64 is now enabled for the Master project .
Big thanks to Guillaume Gardet for helping us with the first steps and the
This means you can now install Uyuni Master Server on top of openSUSE Leap
15.2 aarch64 by following the instructions at
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
Julio González Gil
Release Engineer, SUSE Manager and Uyuni
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
So we decided to use Uyuni integrated cobbler to create a bootable ISO for
#cobbler buildiso --distro=k8s-nodes-test:1:itmw-oss --airgapped
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
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]
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
Or is there an easy way to create a boot iso that can activate LACP and
then do a network install?
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.