We are managing our SLES server with SUMA and salt. However, for the RHEL/OEL servers, we just want them registered with salt so we can invoke salt from the SUMA server to perform maintenance on the RHEL/OEL servers. We don’t need anything SUMA will provide for the RHEL/OEL servers at the moment. I am downloading salt on the RHEL/OEL servers directly from saltstack. When I start up the minion, I can either accept the client’s key from the SUMA Salt tab or from the command-line on the SUMA server using “[FONT=Courier New]salt-key -a [/FONT]”. However, this then creates an entry for the server in SUMA under Systems and then removes access to any yum repos we have configured on the RHEL/OEL server (on the RHEL/OEL server, we are getting updates directly from Oracle, not SUMA).
[QUOTE=achinayoung_waubonsee;59478]We are managing our SLES server with SUMA and salt. However, for the RHEL/OEL servers, we just want them registered with salt so we can invoke salt from the SUMA server to perform maintenance on the RHEL/OEL servers. We don’t need anything SUMA will provide for the RHEL/OEL servers at the moment. I am downloading salt on the RHEL/OEL servers directly from saltstack. When I start up the minion, I can either accept the client’s key from the SUMA Salt tab or from the command-line on the SUMA server using “[FONT=Courier New]salt-key -a [/FONT]”. However, this then creates an entry for the server in SUMA under Systems and then removes access to any yum repos we have configured on the RHEL/OEL server (on the RHEL/OEL server, we are getting updates directly from Oracle, not SUMA).
(after registering the server with suma all of the “enabled” channels are removed except for the “salt” repo)
# yum repolist all
...
salt-latest/x86_64 SaltStack Latest Release Channel for RHE disabled
...
We want SUMA to leave the yum channels intact. simples can we use salt without SUMA?[/QUOTE]
Why do you want all systems to have repos from RedHat instead of having them locally ?
Anywhay, I think what you asked is not possible. I have added openBSD and even that had an entry in SUMA.
The simplest way is to have a RedHat repos in SUMA and then create a bootstrap repo and necessary channels (one registration key should be sufficient).
For two reasons: 1) We are installing ksplice on these servers and SUMA would need to register with Oracle’s ULN to fetch this repo but we’ve no idea how to do this; 2) The ksplice repo is huge so we’d rather depend on Oracle to store those packages.
One more thing: while onboarding a client in SUSE Manager disables the local repos (disablelocalrepos.sls), after onboarding you can add the ksplice repository definition on the clients in /etc/yum.repos.d/. The highstate does not disable the local repos again.
Thanks. However, adding a repository in this way doesn’t work when you need to authenticate against it. If I “[FONT=Courier New]yum repolist[/FONT]”, the list of repos returned doesn’t come from [FONT=Courier New]/etc/yum.repos.d[/FONT] but from the yum plugin configured to talk to Oracle’s ULN. Oracle manages ULN yum repos differently from RedHat so I can’t follow something like https://documentation.suse.com/external-tree/en-us/suma/4.0/suse-manager/client-configuration/clients-rh.html.
Once I reinstalled these packages and enabled [FONT=Comic Sans MS]/etc/yum/pluginconf.d/rhnplugin.conf[/FONT], “[FONT=Courier New]yum repolist[/FONT]” was back to normal. I presume a bootstrap script can be used to do the above?
