We use git to track changes in /etc/
on our servers.
Administrators work as root when changing files in /etc/, and thus their commits have author
root <root@machinename>
This is not very satisfying since you cannot see which admin actually did the change.
What can we do to get the real admin names in the git log? I don't think that keeping a local clone of the repository is feasible since we often change interatively until something works, and a change-commit-push-seeError-repeat cycle would not help here.
The git author and committer name can be influenced with the environment variables
GIT_COMMITTER_NAME
,GIT_COMMITTER_EMAIL
,GIT_AUTHOR_NAME
andGIT_AUTHOR_EMAIL
.Now the trick is to submit those variables to the remote server when connecting through SSH:
Define and export the variables in your
~/.bashrc
file:Automatically send them with a SSH connection by adjusting
~/.ssh/config
:LANG
andLC_*
are not neccesary, but Debian has then in their default ssh_config, so I thought I should submit them, tooOn the remote server, adjust the sshd configuration in
/etc/ssh/sshd_config
to acceptGIT_*
environment variables:Voila - a
git commit
as root in/etc/
leads to:In case serverfault faults some time in the future: http://cweiske.de/tagebuch/carry-git-settings.htm
First, and not related to your question, I would urge you to urgently stop to use
root
logins andsu
and use user logins andsudo
instead. Restrict yourroot
logins to console only, or not even that.That said,
git commit
has a--author
option that can help you there:You can also carefully use environment variables per user to set
GIT_AUTHOR_NAME
andGIT_AUTHOR_EMAIL
variables. In the log, it will appear different authors and the same commiter (root@host
), but it will give you more auditing. Of course that means you trust your admins to keep the variables intact. As each one is using a specific shell, they cansudo
to root and source a file with their specificgit
variables, identifying each one differently on the commits. Not very practical, but you may even automatize that with scripts.EDIT: Of course an even better approach as appointed by @ScottPack would be to use a configuration management system like Puppet or Chef and use git to track the changes on the central server and not on the real servers so each admin could have a working copy of the configuration.
With putty you can set this under "Connection -> Data -> Environment Variables".
They are also present after '
su
' to root.If you happen to provision user accounts on your servers using ssh keys, you can actually attach environment variables to the authorized keys at setup time - for example in ~bob/.ssh/authorized_keys
This way when users SSH in they automatically have these envs setup - there's no need for them for forward them from the local client. Bonus points if you already have this info and are generating authorized_keys configs from a config management system.
Note: The above requires
PermitUserEnvironment yes
in sshd_configIf you're using
sudo
and your non-root user has their home directory mounted:git -c include.path=<file>
will include the configuration in<file>
.To automatically pull in my non-root user's config files, I use the
bash
alias:Then I use
gsudo
instead ofgit
to both:Check that the config is indeed being imported:
In addition to coredump's answer you can also set these options in the
.git/config
file in your working copy of the repository (by hand, or using thegit config
command.See
man git-config
for more info on the command and the cool things you can do with it.