Salt States

Salt is capable of applying states by matching clients with relevant state data. This data comes from SUSE Manager in the form of package and custom states.

State data comes from SUSE Manager in the form of package and custom states and targets clients at three specific levels of hierarchy. The state hierarchy is defined by the following order or priority: individual clients have priority on packages and custom states over groups; next a group has priority over the organization.

  • Client Level

    Systems  Specific Minion  States

  • Group Level

    Systems  System Groups

  • Organization Level

    Systems  Manage System Types:  My Organization

For example:

  • Org1 requires that vim version 1 is installed

  • Group1 requires that vim version 2 is installed

  • Group2 requires any version installed

This would lead to the following order of hierarchy:

  • Client1 part of [Org1, Group1] wants vim removed, vim is removed (Client Level)

  • Client2 part of [Org1, Group1] wants vim version 2 gets version 2 (Group Level)

  • Client3 part of [Org1, Group1] wants any version, gets version 2 (Org Level)

  • Client4 part of[Org1, Group2] wants any version, gets vim version 1 (Org Level)

Salt States Storage Locations

The SUSE Manager salt-master reads its state data from three file root locations.

The directory /usr/share/susemanager/salt It is shipped and updated together with SUSE Manager and includes certificate setup and common state logic to be applied to packages and channels.

The directory /srv/susemanager/salt is generated by SUSE Manager and based on assigned channels and packages for clients, groups and organizations. This file will be overwritten and regenerated. This could be thought of as the SUSE Manager database translated into salt directives.

The third directory /srv/salt is for custom state data, modules, etc. SUSE Manager does not operate within or utilize this directory. However, the state data placed here affects the Highstate of clients and is merged with the total state result generated by SUSE Manager.

SUSE Manager States

All user created SLS files will be saved to disk on the salt-master server. These files will be placed in /srv/susemanager/salt/ and each organization will be placed within its own directory. Although these states are custom, these states are created using SUSE Manager . The following provides an overview of the directory structure:

├── manager_org_DEVEL
│   ├── files
│   │    ... files needed by states (uploaded by users)...
│   └── state.sls
         ... other sls files (created by users)...
├── manager_org_TESTING
│   ├── files
│   │   └── motd     # user created
│   │    ... other files needed by states ...
│   └── motd.sls     # user created
            ... other sls files ...

Pillar Data

SUSE Manager exposes a small amount of internal data as Pillars which can be used with custom states. Data that is exposed includes group membership, organization membership, and file roots. These are managed either automatically by SUSE Manager, or manually by the user.

To avoid hard-coding organization IDs within SUSE Linux Enterprise Server files, a pillar entry is added for each organization:

org-files-dir: relative_path_to_files

The specified file is available for all clients which belong to the organization.

This is an example of a Pillar located at /etc/motd:

    - source: salt://{{ pillar['org-files-dir']}}/motd
    - user: root
    - group: root
    - mode: 644

Group States

Pillar data can be used to perform bulk actions, like applying all assigned states to clients within the group. This section contains some example of bulk actions that you can take using group states.

In order to perform these actions, you will need to determine the ID of the group that you want to manipulate. You can determine the Group ID by using the spacecmd command:

spacecmd group_details

In these examples we will use an example Group ID of GID.

To apply all states assigned to the group:

salt -I 'group_ids:GID' state.apply custom.group_GID

To apply any state (whether or not it is assigned to the group):

salt -I 'group_ids:GID' state.apply ``state``

To apply a custom state:

salt -I 'group_ids:2130' state.apply manager_org_1.``customstate``

Apply the highstate to all clients in the group:

salt -I 'group_ids:GID' state.apply

Use Pillars to Set the Package Download Endpoint

By default, SUSE Manager assumes that the download endpoint to use is the FQDN of the SUSE Manager server, or the SUSE Manager Proxy. However, there are some cases where you might like to use a different FQDN as the download endpoint. The most common example is if you need to use load balancing, caching proxies, or in environments with complicated networking requirements.

To change the package download endpoint, you can manually adjust three Salt pillars: * pkg_download_point_protocol, defaults to https. * pkg_download_point_host, defaults to the FQDN of the SUSE Manager Server (or Proxy, if in use). * pkg_download_point_port, defaults to 443.

If you do not adjust these pillars directly, SUSE Manager will fall back to the default values.

Procedure: Changing the package download endpoint pillar
  1. Navigate to /srv/pillar/ and create a file called top.sls with these contents:

        - rpm_download_points

    This example directs Salt to look at the rpm_download_points.sls file to determine the base URL to use. You can adjust this file to target different clients or groups, depending on your environment.

  2. Remain in /srv/pillar/ and create a file called rpm_download_points.sls with the base URLs you want to use. For example:

    rpm_download_point_protocol: http
    rpm_download_point_port: 444
  3. OPTIONAL: If you want to use external pillars, for example Group IDs, open the master configuration file and set the ext_pillar_first parameter to true. You can then Group IDs to set conditional values, for example:

    {% if pillar['group_ids'] is defined and 8 in pillar['group_ids'] %}
      rpm_download_point_protocol: http
      rpm_download_point_port: 444
      rpm_download_point_protocol: ftp
      rpm_download_point_port: 445
    {%- endif %}
  4. OPTIONAL: You can also use grains to set conditional values, for example:

{% if grains['fqdn'] == '' %}
{% elif grains['fqdn'] == ''' %}
{% endif %}