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.htmlhttps://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
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
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
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
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
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!
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!
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…>.*
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