Hello list I make first tests with the configuration in Uyuni. It worked to create a configuration channel, assign it to a server and copy a file 1:1 to this server. What I can't do yet is to add dynamic values of the target system to this file. Actually I thought it works like in the manual (content configuration file): # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} Unfortunately, this is exactly what the file looked like on the target system: # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} and not as in the manual: # My test file hostname=myserver.mydomain.tld ip_address=192.168.5.31 This is probably because my openSuSE client is not "Traditional" but connected with "Salt". Even if I try it with python the python code is copied 1:1 to the target system and not interpreted. Can someone give me a working example of how I would have to create this to achieve the desired goal - after that I could certainly build on it. Btw: Now that openSuSE 15.3 reports itself as SLES15 - is there still no traditional client for OpenSuSE? :) Best regards Martin
Hi Martin, I don't think this is possible with salt managed clients. From the documentation: https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/confi... You're using the correct macro strings, but they only apply to traditional clients (those using OSAD rather than salt-minion) If you look at "Table 1" on that page, you'll see the comparison of features between the two types. One workaround might be to run a script (either one off or put in /etc/cron.daily) that expands these macros to local values once they're deployed on the machine. S -----Original Message----- From: Martin Willisegger <muy.2020@wizonet.ch> Sent: 05 February 2022 08:50 To: users@lists.uyuni-project.org Subject: [EXTERNAL EMAIL] Configuration issue Hello list I make first tests with the configuration in Uyuni. It worked to create a configuration channel, assign it to a server and copy a file 1:1 to this server. What I can't do yet is to add dynamic values of the target system to this file. Actually I thought it works like in the manual (content configuration file): # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} Unfortunately, this is exactly what the file looked like on the target system: # My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |} and not as in the manual: # My test file hostname=myserver.mydomain.tld ip_address=192.168.5.31 This is probably because my openSuSE client is not "Traditional" but connected with "Salt". Even if I try it with python the python code is copied 1:1 to the target system and not interpreted. Can someone give me a working example of how I would have to create this to achieve the desired goal - after that I could certainly build on it. Btw: Now that openSuSE 15.3 reports itself as SLES15 - is there still no traditional client for OpenSuSE? :) Best regards Martin
Hi I think you cannot use the macros defined for traditional clients. But AFAIK all configuration files deployed with salt using jinja templating. You can use grains and pillar data for dynamic replacements. Since some versions, custom info variables are also available as pillar data and can be used as well. Using a Configuration channel in mix mode for traditional and salt is not possible when you want to use templating. Am Dienstag, 8. Februar 2022, 08:57:52 CET schrieb Simon Avery:
Hi Martin,
I don't think this is possible with salt managed clients.
From the documentation: https://www.uyuni-project.org/uyuni-docs/en/uyuni/client-configuration/confi...
You're using the correct macro strings, but they only apply to traditional clients (those using OSAD rather than salt-minion)
If you look at "Table 1" on that page, you'll see the comparison of features between the two types.
One workaround might be to run a script (either one off or put in /etc/cron.daily) that expands these macros to local values once they're deployed on the machine.
S
-----Original Message----- From: Martin Willisegger <muy.2020@wizonet.ch> Sent: 05 February 2022 08:50 To: users@lists.uyuni-project.org Subject: [EXTERNAL EMAIL] Configuration issue
Hello list
I make first tests with the configuration in Uyuni. It worked to create a configuration channel, assign it to a server and copy a file 1:1 to this server.
What I can't do yet is to add dynamic values of the target system to this file. Actually I thought it works like in the manual (content configuration file):
# My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |}
Unfortunately, this is exactly what the file looked like on the target system:
# My test file hostname={| rhn.system.hostname |} ip_address={| rhn.system.net_interface.ip_address(eth0) |}
and not as in the manual:
# My test file hostname=myserver.mydomain.tld ip_address=192.168.5.31
This is probably because my openSuSE client is not "Traditional" but connected with "Salt".
Even if I try it with python the python code is copied 1:1 to the target system and not interpreted.
Can someone give me a working example of how I would have to create this to achieve the desired goal - after that I could certainly build on it.
Btw: Now that openSuSE 15.3 reports itself as SLES15 - is there still no traditional client for OpenSuSE? :)
Best regards
Martin
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Ivo Totev (HRB 36809, AG Nürnberg)
participants (3)
-
Martin Willisegger -
Michael Calmer -
Simon Avery