1

We use SaltStack for configuration management since some weeks.

How to handle the distribution specific location of systemctl?

  • On Ubuntu: /bin/systemctl
  • On SuSE: /usr/bin/systemctl

At the moment I add two lines to the sudoers file:

etc_sudoers:
  file.blockreplace:
    - name: /etc/sudoers
    - marker_start: "# START managed etc_sudoers -DO-NOT-EDIT-"
    - marker_end: "# END managed zone etc_sudoers --"
    - content: |
        some_user ALL = NOPASSWD: /bin/systemctl restart apache2
        some_user ALL = NOPASSWD: /usr/bin/systemctl restart apache2
{% endfor %}

    - append_if_not_found: True
    - backup: '.bak'
    - show_changes: True

.... Is there no simpler solution?

guettli
  • 3,113
  • 14
  • 59
  • 110

1 Answers1

5

Unfortunately there is no simpler or automatic way. But there is a better way following the Salt Best Practices, using a map.jinja file.

It is a strong convention in Salt Formulas to place platform-specific data, such as package names and file system paths, into a file named map.jinja that is placed alongside the state files.

Using it will ensure the modularity of your states, making them able to run regardless of the minion's OS.

Below there is an example of how your map.jinja file would be in the scenario you have presented. It will filter the minion by OS family and set the variables according to it:

{% set systemctl = salt['grains.filter_by']({
    'Debian': {
        'location': '/bin/systemctl'
    },
    'Suse': {
        'location': '/usr/bin/systemctl'
    }
} %}

Now you need to import it in your state file and use the variables previously defined:

{% from "systemctl/map.jinja" import systemctl with context %}

etc_sudoers:
  file.blockreplace:
    - name: /etc/sudoers
    - marker_start: "# START managed etc_sudoers -DO-NOT-EDIT-"
    - marker_end: "# END managed zone etc_sudoers --"
    - content: some_user ALL = NOPASSWD: {{ systemctl.location }} restart apache2

    - append_if_not_found: True
    - backup: '.bak'
    - show_changes: True

For more info about it, please take a look at the modularity and the lookup table sessions of the doc.

alejdg
  • 176
  • 1
  • 6
  • 1
    It should be noted that mangling `/etc/sudoers` itself is a losing proposition when you can simply add small new files in `/etc/sudoers.d/` these days when any recent `sudoers` file already contains `#includedir /etc/sudoers.d` (and if it doesn't, then make it do that instead). – Josip Rodin Apr 09 '17 at 20:11