0

Introduction

Up to now we created one block in the /etc/sudoers file with N entries.

This is not a good solution, since sometimes we only want to update one system and give explicit pillar data. Then pillar.systems is a list with only one entry.

Old Code

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

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

New Code

{% for system_name in pillar.systems %}
etc_sudoers_{{system_name}}:
  file.blockreplace:
    - name: /etc/sudoers
    - marker_start: "# START managed zone etc_sudoers_{{system_name}} -DO-NOT-EDIT-"
    - marker_end: "# END managed zone etc_sudoers_{{system_name}} --"
    - content: |
        {{system_name}} ALL = NOPASSWD: /bin/systemctl restart apache2*

    - append_if_not_found: True
    - backup: '.bak'
    - show_changes: True
{% endfor %}

Question

How to delete the old block which is still on the servers?

guettli
  • 3,113
  • 14
  • 59
  • 110
  • 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 19:26
  • @JosipRodin yes, you are right. In general it is always looking for trouble if two tools work in the same config file. – guettli Apr 10 '17 at 09:26

1 Answers1

0

I would solve this by setting up a state like that:

etc_sudoers:
  file.blockreplace:
    - name: /etc/sudoers
    - marker_start: "# START managed zone etc_sudoers -DO-NOT-EDIT-"
    - marker_end: "# END managed zone etc_sudoers --"
    - content: '#'
    - append_if_not_found: False
    - backup: '.bak'
    - show_changes: True

Afterwards I would remove the three comment lines using the cmd.run module together with e.g. sed.

You may want to use the sed appraoch directly, which makes the temporary state unnecessary - but this depends on your needs - if you remove the old style at once everywhere the second approach might be easier. If you migrate boxes one after another for months the defining the state is more clear.

Community
  • 1
dahrens
  • 266
  • 1
  • 4
  • Yes, this works. Thank you. I learned this: removing configuration is harder than adding it. It's time to switch to throw away containers. – guettli Feb 02 '17 at 11:06
  • 1
    yeah - this is a little complicated. If you have a look at the widely used formulas on github - a few of them like the [users-formula](https://github.com/saltstack-formulas/users-formula/) support rolling back there states. But often this is not easy to achieve. On the other hand in the cloud fresh machines are quite cheap and easy to create. Together with proper configuration management creating a new machine instead of removing configurations is much easier. Of course you need good concepts for storing the services data in that case. On top there are a lot of modules to do things only once. – dahrens Feb 02 '17 at 17:47