gitリポジトリで/ etc /を追跡し、rootとしてコミットするときにユーザー名を修正します

13

gitを使用し/etc/て、サーバー上の変更を追跡します。

管理者は/ etc /のファイルを変更するときにrootとして動作するため、コミットには作成者がいます

root <root@machinename>

どの管理者が実際に変更を行ったかを確認できないため、これはあまり満足のいくものではありません。

gitログで実際の管理者名を取得するにはどうすればよいですか？リポジトリのローカルクローンを保持することは、何かが機能するまでしばしばインタラクティブに変更されるため、実行可能であるとは思わず、change-commit-push-seeError-repeatサイクルはここでは役に立ちません。

— クワイスケ
ソース

実際のルートとして、またはルートにsudo'd？

— デカド

現在、実際のルート（ssh root @または「su」、sudoなし）として

— cweiske

使用するとetckeeper、それはバージョン管理/ etcにあるこのような奇妙な落とし穴の世話をします。また、ユーザーごとのアカウントとの使用を開始しますsudo。

— カレブ

12

Gitの作者とコミッタ名は環境変数で影響を受けることができGIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL、GIT_AUTHOR_NAMEとGIT_AUTHOR_EMAIL。

ここでのコツは、SSHを介して接続するときに、これらの変数をリモートサーバーに送信することです。

~/.bashrcファイル内の変数を定義してエクスポートします。
```
export GIT_AUTHOR_NAME="Christian Weiske"
```
以下を調整して、SSH接続で自動的に送信します~/.ssh/config。
```
SendEnv LANG LC_* GIT_*
```
LANG必要でLC_*はありませんが、Debianはデフォルトのssh_configにあるので、私もそれらを提出すべきだと思いました
リモートサーバーで、sshd構成を調整して環境変数/etc/ssh/sshd_configを受け入れGIT_*ます。
```
AcceptEnv LANG LC_* GIT_*
```

出来上がり- git commitとしてのルートとして/etc/：

commit 8a4654f13241f05361283a88ce041a0fc24b8ac6
Author: Christian Weiske <christian.weiske@netresearch.de>

serverfaultが将来的に障害を起こした場合：http : //cweiske.de/tagebuch/carry-git-settings.htm

— クワイスケ
ソース

5

まず、あなたの質問とは関係ありませんが、緊急にrootログインを使用するのをやめsu、sudo代わりにユーザーログインを使用することをお勧めします。rootログインをコンソールのみに制限するか、それさえしません。

とはいえ、そこに役立つオプションgit commitがあり--authorます：

# git commit --author='Author Name <author@email.address.com>' -a

ユーザーごとに環境変数を慎重に使用してGIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL変数を設定および変更することもできます。ログでは、異なる作成者と同じコミッター（root@host）が表示されますが、より多くの監査が提供されます。もちろん、管理者が変数をそのまま保持することを信頼することを意味します。それぞれが特定のシェルを使用しているためsudo、特定のgit変数を使用してファイルをルート化し、ソースを作成して、コミット時にそれぞれを個別に識別することができます。あまり実用的ではありませんが、スクリプトで自動化することもできます。

編集：もちろん、@ ScottPackによって指定されたさらに優れたアプローチは、PuppetやChefなどの構成管理システムを使用し、gitを使用して、実際のサーバーではなく中央サーバーで変更を追跡し、各管理者が作業コピーを持つことです構成の。

— コアダンプ
ソース

--authorもちろん可能ですが、書くのが多すぎるため、人々は通常のワークフローでそれを使用しません。sudoを使用する2番目のアイデア：私はsudoを有害と考え、sshキーのみでsshルートアクセスを使用する人の1人です。はい、管理者を信頼しています。

— cweiske

5

@cweiskeなぜsudoは有害だと思いますか？

— コアダンプ

1

@cweiskeコミッターに重要な情報（誰が、何を変更し、何を変更したのか、該当する場合はチケット番号）を問い合わせるラッパースクリプトを検討しましたか？私が最後に雇用した場所には、DNSの変更に対して同様のシステム（CVSベース）があり、ポリシーを適用するラッパーがありました-驚くほどうまく機能します。

— voretaq7

4

@cweiskeあなたの評価に少し同意しません。sshエージェントを使用してsshキーのパスワードをキャッシュし、気付かないうちにルートマシンにログインするか、単純なパスフレーズまたはルートパスフレーズと同じマシン上の同じパスワードを使用しながら、ユーザーにパスワードの入力sudoを強制できます（偶数彼がユーザーとしてログインするためにsshキーを使用している場合）ユーザーが実行できることを制御でき、主に誰が何をしたかについての監査証跡があります。しかし、誰もが自分の意見を受ける権利があります。

— コアダンプ

2

またsudo、すべてのコマンド（timestamp_timeout = 0）に対してユーザーにパスワードの入力を強制するように構成することもできます。おそらく、開発およびステージングボックスには適していませんが、生産には確かに適しています。私見、SFのコンセンサスに基づいて、あなたの意見を再考する必要がありますsudo。SFの素晴らしい点の1つは、sh * tを本当に知っている仲間のコミュニティを持つことです:-)。

— ベルミンフェルナンデス

3

ではパテあなたは「 - >データ- >環境変数の接続」の下にこれを設定することができます。

またsu、ルートへの' 'の後に存在します。

— サイボット
ソース

3

sshキーを使用してサーバーにユーザーアカウントをプロビジョニングする場合、セットアップ時に環境変数を承認済みのキーに実際にアタッチできます（例：〜bob / .ssh / authorized_keys）

environment="GIT_AUTHOR_NAME=Bob Smith",environment="GIT_AUTHOR_EMAIL=bob.smith@megacorp.com" ssh-rsa AAAA.... bob.smith@megacorp.com

この方法では、ユーザーがSSHで自動的にこれらのenvをセットアップします-ローカルクライアントから転送する必要はありません。既にこの情報があり、config管理システムからauthorized_keys設定を生成している場合、ボーナスポイントがあります。

注：上記はPermitUserEnvironment yessshd_configで必要です

— ミナギブ
ソース

1

使用sudoしていて、非ルートユーザーのホームディレクトリがマウントされている場合：

git -c include.path=<file>の構成が含まれ<file>ます。

非rootユーザーの構成ファイルを自動的に取り込むには、bashエイリアスを使用します。

alias gsudo='sudo git -c "include.path='"${XDG_CONFIG_DIR:-$HOME/.config}/git/config\" -c \"include.path=$HOME/.gitconfig\""

次に、両方のgsudo代わりに使用しますgit：

ルートとして実行
すべての非ルートユーザーgit構成にアクセスできる

設定が実際にインポートされていることを確認します。

gsudo config --list --show-origin --includes | less

— トム・ヘイル
ソース

0

コアダンプの答えに加えて.git/config、リポジトリの作業コピーのファイルにこれらのオプションを設定することもできます（手動またはgit configコマンドを使用）。

man git-configコマンドの詳細と、それを使用して実行できるクールなことを参照してください。

— voretaq7
ソース

これは、1人の管理者がそのマシンのそのリポジトリでコミットした場合にのみ機能しますが、複数の管理者で失敗します。

— -cweiske

確かに、中央リポジトリがあり、人々がそのリポジトリにクローンを作成し、プル/プッシュする状況に適しています。

— voretaq7