Register server with salt but not SUMA

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 "salt-key -a <server>". 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).

(before registering the server with SUMA)
# yum repolist all
...
ol7_x86_64_UEKR5               Unbreakable Enterprise Kernel Rel enabled:      0
ol7_x86_64_ksplice             Ksplice for Oracle Linux 7 (x86_6 enabled:  4,501
ol7_x86_64_latest              Oracle Linux 7 Latest (x86_64)    enabled: 16,369
ol7_x86_64_userspace_ksplice   Ksplice aware userspace packages  enabled:    438
salt-latest/x86_64             SaltStack Latest Release Channel  enabled:    103
...

(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. So, how can we use salt without SUMA?

Comments

  • strahil-nikolov-dxcstrahil-nikolov-dxc Established Member
    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 "salt-key -a <server>". 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).

    (before registering the server with SUMA)
    # yum repolist all
    ...
    ol7_x86_64_UEKR5               Unbreakable Enterprise Kernel Rel enabled:      0
    ol7_x86_64_ksplice             Ksplice for Oracle Linux 7 (x86_6 enabled:  4,501
    ol7_x86_64_latest              Oracle Linux 7 Latest (x86_64)    enabled: 16,369
    ol7_x86_64_userspace_ksplice   Ksplice aware userspace packages  enabled:    438
    salt-latest/x86_64             SaltStack Latest Release Channel  enabled:    103
    ...
    

    (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?


    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).
  • achinayoung_waubonseeachinayoung_waubonsee Established Member
    Why do you want all systems to have repos from RedHat instead of having them locally ?

    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.
  • pagarciapagarcia New or Quiet Member
    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;

    Software > Manage > Repository > Create Repository > Repository Type = uln
  • pagarciapagarcia New or Quiet Member
    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.
  • achinayoung_waubonseeachinayoung_waubonsee Established Member
    pagarcia wrote: »
    Software > Manage > Repository > Create Repository > Repository Type = uln

    Thanks. However, adding a repository in this way doesn't work when you need to authenticate against it. If I "yum repolist", the list of repos returned doesn't come from /etc/yum.repos.d 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.
  • achinayoung_waubonseeachinayoung_waubonsee Established Member
    pagarcia wrote: »
    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.

    Ok, thanks. This might be the best we are able to do.
  • achinayoung_waubonseeachinayoung_waubonsee Established Member
    pagarcia wrote: »
    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.

    In addition to disabling the existing repos, the onboarding also removed the following packages:
    rhn-check-2.0.2-24.0.7.el7.x86_64
    rhn-client-tools-2.0.2-24.0.7.el7.x86_64
    rhnlib-2.5.65-8.0.1.el7.noarch
    rhnsd-5.0.13-10.0.1.el7.x86_64
    rhn-setup-2.0.2-24.0.7.el7.x86_64
    yum-plugin-ulninfo-0.2-13.el7.noarch
    yum-rhn-plugin-2.0.1-10.0.1.el7.noarch
    

    Once I reinstalled these packages and enabled /etc/yum/pluginconf.d/rhnplugin.conf, "yum repolist" was back to normal. I presume a bootstrap script can be used to do the above?
  • achinayoung_waubonseeachinayoung_waubonsee Established Member
    In addition to disabling the existing repos, the onboarding also removed the following packages:
    rhn-check-2.0.2-24.0.7.el7.x86_64
    rhn-client-tools-2.0.2-24.0.7.el7.x86_64
    rhnlib-2.5.65-8.0.1.el7.noarch
    rhnsd-5.0.13-10.0.1.el7.x86_64
    rhn-setup-2.0.2-24.0.7.el7.x86_64
    yum-plugin-ulninfo-0.2-13.el7.noarch
    yum-rhn-plugin-2.0.1-10.0.1.el7.noarch
    

    Looks like this was done by remove_traditional_stack.sls.
  • pagarciapagarcia New or Quiet Member
    Looks like this was done by remove_traditional_stack.sls.

    Of course. You are registering OEL as a Salt minion, why do you want the traditional stack on it?
  • achinayoung_waubonseeachinayoung_waubonsee Established Member
    pagarcia wrote: »
    Of course. You are registering OEL as a Salt minion, why do you want the traditional stack on it?

    Because if we want the server to talk to Oracle's ULN, we need yum-plugin-ulninfo.
  • pagarciapagarcia New or Quiet Member
    Because if we want the server to talk to Oracle's ULN, we need yum-plugin-ulninfo.

    Ah, I see.

    Seems like a good candidate for a community-contributed formula: enable local repository X (with a form to fill in the X) ;-)

    https://github.com/SUSE/salt-formulas
Sign In or Register to comment.