私たちのマシンでは、cassandra、datadog など、さまざまなサービスが実行されています。
場合によっては、構成を変更する必要があり、構成ファイルの伝播と再起動を自動化したいと考えています。
当社では、アプリケーション ソフトウェアのワークフローを自動化するために Jenkins を使用しており、これをサービスにも使用することを検討していました。Jenkins が実行されるサーバーがホスト サーバーにリモート ルート (または sudo) アクセスを持つことは望ましくありません。
/etc/cassandraの所有者をcassandraに、/etc/datadogをdd-agentなどに変更しても安全かどうか疑問に思っていました。自動化に役立つからです。（実際、そのようなフォルダ/ファイルをすべき適切なユーザーが所有する必要があり、所有者が root であるのは間違っているのでしょうか?
答え1
このディレクトリの目的は、/etcディレクトリにすべてが含まれるようにすることですシステム全体構成 - ほとんどの場合、どこか下にある各ユーザーの構成とは対照的です$HOME/.config。システム全体の構成はすべてのユーザーに影響するため、それらのファイルは root が所有するのが正しいです。
さて、私はあなたのシステムを知りませんが、おそらくシステムごとに cassandra などを 1 回ずつ実行しているので、個々のユーザー構成ファイルは必要ないと思われます。それらのファイルやサブディレクトリの所有権を変更することには、設計方法と矛盾する点を除けば、何の落とし穴もないと思います。(メイン ディレクトリの所有権を変更しない限り/etc)
個人的には、インスタンス ディレクトリ (おそらくホーム フォルダー内) を設定し、そこに保存されている構成を使用しますが、それはあなた次第です。
答え2
ルートは、アプリケーションに関連する etc 構成ファイルの所有者であってはなりません。エレガントな解決策は次のようになります。datadog アプリケーションはユーザー datadog によって実行され、構成ファイルは datadog とグループ datadog によって所有されます。しかし、ここで jenkins が登場し、/etc/datadog 内の一部のファイル (おそらくすべてではない) を確認/編集する必要があります。
そこで、「datadogjenkins」という新しいグループを作成し、datadog と jenkins の両方をそのグループのメンバーにします。次に、jenkins が読み取り/書き込み/実行する必要があるファイル/フォルダーの ownerGROUP を新しいグループに変更します。
これで、Datadog と Jenkins の両方がこれらの資産にアクセスできるようになりました。どちらも権限をルートに昇格する必要はありません。また、Jenkins が侵害された場合に備えて、Jenkins が見る必要のないものを Jenkins から遮断することができます。
これで十分に説明できたと思います。