web-dev-qa-db-ja.com

SaltStack：/ etc / Sudo：/ bin / systemctl vs / usr / bin / systemctl

数週間から、構成管理にSaltStackを使用しています。

systemctlの配布固有の場所を処理する方法は？

  • Ubuntuの場合：/bin/systemctl
  • SuSEの場合：/usr/bin/systemctl

現時点では、sudoersファイルに2行追加しています。

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

....もっと簡単な解決策はありませんか？

sudosaltstack
1
guettli

残念ながら、これ以上簡単で自動的な方法はありません。ただし、map.jinjaファイルを使用して、 Salt Best Practices に従うより良い方法があります。

パッケージ名やファイルシステムパスなどのプラットフォーム固有のデータを、状態ファイルと一緒に配置されるmap.jinjaという名前のファイルに配置することは、SaltFormulasの強力な規則です。

これを使用すると、状態のモジュール性が保証され、ミニオンのOSに関係なく実行できるようになります。

以下に、提示したシナリオでのmap.jinjaファイルの例を示します。 OSファミリでミニオンをフィルタリングし、それに応じて変数を設定します。

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

次に、それを状態ファイルにインポートし、前に定義した変数を使用する必要があります。

{% 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

詳細については、ドキュメントの モジュール性 および ルックアップテーブル セッションを参照してください。

5
alejdg