As we’ve recently supported some customers on SUSE Multi Linux Manager I’d like share something which was not as easy to implement as it appeared to be in the first place. But first of all, what is SUSE Multi Linux Manager? It is basically a fork of Spacewalk which was also used as the upstream project by the Red Hat Satellite product. But as Spacewalk was dis-continued and the project on Github was archived some people decided to fork in and started a new project called Uyuni, and this is now the upstream project for SUSE Multi Linux Manager. One of the great things about Uyuni and SUSE Multi Linux Manager is, that it supports various Linux distributions such as SUSE and openSUSE distributions, Red Hat, Rocky, Oracle and Alma Linux, Debian, Ubuntu, and also ancient versions of CentOS if you still depend on them.
I am not going into the setup or basic configuration as you can already find related bogs here and more information in the documentation:
- Uyuni, an open-source configuration and infrastructure management solution for software-defined infrastructure (1) – The server (this is for version 4.x)
- Uyuni, an open-source configuration and infrastructure management solution for software-defined infrastructure (2) – Adding a client (this is for version 4.x)
- SUMA (SUSE Manager) is back and it has a new name: SUSE Multi-Linux
- SUSE Manager installation (this is for version 4)
What I want to look at in this post is automatic scheduling of OpenSCAP scans/reports. When this requirement came up, it seemed pretty easy to do, as you can easily schedule such a scan against a single system. As you can see below I have a Red Hat 9 system registered to my SUSE Multi Linux Server:

What you can easily do out of the box is to manually schedule an OpenSCAP scan:

Once the scan completed completes, it becomes visible under the “List Scan” tab and you can browse into the details:



Quite easy to do but still a manual action. As we wanted to have it automated the obvious choice was to create a “Recurring Action”:

This gives you to option to create and configure a “Recurring Action”:

The issue is, there is no pre-defined “Custom State” which is scheduling an OpenSCAP scan:

The very same is true for “System Groups”, which you normally would use because otherwise you’d need to schedule that on every single system:

The last option is to create something under “Schedule” but this only gives you a list of what you already have:

At this point we were stuck and had to talk to SUSE support, which really was a great experience by the way. It turned out there is no easy, build-in, way to do this. A feature request has been logged, but of course there is no guarantee that it will be implemented.
But, there is a workaround, not a very beautiful one, but at least it works. SUSE Multi Linux Manager (and Uyuni of course) come with an API and there is one call for triggering an OpenSCAP scan. Using this, a custom state channel can be created which in turn calls the API to trigger the scan:


The “SLS Contents” actually contains the code (Python in this case) which is taking to the API and triggers the scan:
/usr/local/bin/schedule_xccdf_scan.py:
file.managed:
- user: root
- group: root
- mode: 755
- contents: |
#!/usr/bin/python3
import xmlrpc.client
client = xmlrpc.client.ServerProxy('https://suma.dwe.local/rpc/api')
key = client.auth.login('admin', 'xxxx')
client.system.scap.scheduleXccdfScan(
key,
1000010000,
'/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml',
'--profile xccdf_org.ssgproject.content_profile_cis_server_l1'
)
client.auth.logout(key)
schedule_xccdf_scan:
cmd.run:
- name: /usr/local/bin/schedule_xccdf_scan.py
- require:
- file: /usr/local/bin/schedule_xccdf_scan.py
I am not going into the code itself, this should be easy to understand. The important part is the system ID in line 14. This defines the system you want the scan to happen on (you can also provide an array of systems, see the API documentation linked above).
As soon as you have this, you can schedule this automatically as a recurring action on either the system itself, or a group of systems in “System Groups”:



Not as easy as it could be, and the systems are still hard coded in the Python code, but at least we have something that works. Hope that helps.