在git仓库中跟踪/ etc /并以root身份提交时，更正用户名

13

我们使用git跟踪/etc/服务器中的更改。

管理员在/ etc /中更改文件时以root用户身份工作，因此其提交具有作者

root <root@machinename>

这不是很令人满意，因为您看不到哪个管理员实际进行了更改。

我们该怎么做才能在git日志中获取真实的管理员名称？我不认为保留存储库的本地克隆是不可行的，因为我们经常进行交互性更改，直到某些事情起作用为止，并且change-commit-push-seeError-repeat循环在这里无济于事。

— wei
source

作为实际的根，还是须要根？

— Decado

当前为实际根目录（ssh root @或“ su”，无sudo）

— cweiske 2011年

使用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_*
```

Voila-以a git commit为根可以/etc/导致：

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

万一将来服务器故障发生故障，请访问：http : //cweiske.de/tagebuch/carry-git-settings.htm

— wei
source

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），但是它将为您提供更多的审计功能。当然，这意味着您相信管理员可以保持变量不变。由于每个人都使用特定的shell，因此他们可以sudo使用其特定的git变量来生成根文件并为其提供源文件，从而在提交时以不同的方式标识每个文件。不太实用，但是您甚至可以使用脚本将其自动化。

编辑：当然，由@ScottPack指定的更好的方法是使用配置管理系统（如Puppet或Chef），并使用git跟踪中央服务器而不是真实服务器上的更改，因此每个管理员都可以拥有一个工作副本配置。

— 核心转储
source

--author当然可以，但是人们不会在正常的工作流程中使用它，因为这太多了。关于使用sudo的第二个想法：我是认为sudo有害并且仅通过ssh密钥使用ssh根访问权限的人之一。是的，我们信任我们的管理员。

— cweiske 2011年

5

@cweiske为什么您认为sudo有害？

— coredump

1

@cweiske您是否考虑过一个包装器脚本，该脚本会询问提交者以获取重要信息（它们是谁，他们做了什么更改，为什么进行了更改，票号（如果适用））？我最后一个受雇的地方有一个类似的系统（基于CVS）来进行DNS更改，并使用包装程序强制执行策略-效果惊人。

— voretaq7 2011年

4

@cweiske我不同意您的评估。您可以使用SSH代理缓存SSH密钥密码，盲目地登录到根机，或只使用一个简单的密码或您的机器比根密码的同一个密码，而与sudo你强制用户键入密码（甚至（如果他使用ssh密钥作为用户登录），则您可以控制该用户可以执行的操作，并且主要是您对谁做了什么进行了审核。但是每个人都有自己的见解。

— coredump

2

您还可以配置sudo为强制用户为每个命令（timestamp_timeout = 0）输入密码。也许不适合开发和暂存盒，但肯定适合生产。恕我直言，基于SF共识，您应该重新考虑对的看法sudo。关于SF的一大优点是拥有一个真正了解其sh * t :-)的同行社区。

— Belmin Fernandez 2011

3

使用腻子可以在“连接->数据->环境变量”下进行设置。

它们也以su'到根出现。

— Cybot
source

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时，他们会自动设置这些envs-无需他们从本地客户端转发它们。如果您已经有了此信息，并且正在从配置管理系统生成authorized_keys配置，则可以得到加分。

注意：以上要求PermitUserEnvironment yes在sshd_config中

— 米纳吉布
source

1

如果您正在使用sudo并且您的非root用户已挂载其主目录：

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两者都使用：

以root身份运行
有权访问所有非root用户的git配置

检查配置是否确实已导入：

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

— 汤姆·黑尔
source

0

除了coredump的答案外，您还可以.git/config在存储库的工作副本中的文件中设置这些选项（手动或使用git config命令）。

请参阅man git-config有关该命令的更多信息以及您可以使用该命令执行的一些有趣操作。

— voretaq7
source

仅当一位管理员在该计算机上的该存储库中提交时，此方法才有效，但对于多位管理员，它将失败。

— cweiske 2011年

没错-它更适合您拥有中央存储库并且人们克隆并推送到该存储库的情况。

— voretaq7 2011年