14

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.

cweiske
  • 781
  • 1
  • 13
  • 36

6 Answers6

13

The git author and committer name can be influenced with the environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL.

Now the trick is to submit those variables to the remote server when connecting through SSH:

  1. Define and export the variables in your ~/.bashrc file:

    export GIT_AUTHOR_NAME="Christian Weiske"

  2. Automatically send them with a SSH connection by adjusting ~/.ssh/config:

    SendEnv LANG LC_* GIT_*

    LANG and LC_* are not neccesary, but Debian has then in their default ssh_config, so I thought I should submit them, too

  3. On the remote server, adjust the sshd configuration in /etc/ssh/sshd_config to accept GIT_* environment variables:

    AcceptEnv LANG LC_* GIT_*

Voila - a git commit as root in /etc/ leads to:

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

In case serverfault faults some time in the future: http://cweiske.de/tagebuch/carry-git-settings.htm

cweiske
  • 781
  • 1
  • 13
  • 36
5

First, and not related to your question, I would urge you to urgently stop to use root logins and su and use user logins and sudo instead. Restrict your root logins to console only, or not even that.

That said, git commit has a --author option that can help you there:

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

You can also carefully use environment variables per user to set GIT_AUTHOR_NAME and GIT_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 can sudo to root and source a file with their specific git 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.

Scott Pack
  • 14,717
  • 10
  • 51
  • 83
coredump
  • 12,573
  • 2
  • 34
  • 53
  • `--author` is possible of course but people don't use that in their normal workflow since it's too much to write. On your second idea to use sudo: I'm one of the people that consider sudo harmful and rather use ssh root access with ssh keys only. And yes, we trust our admins. – cweiske Apr 07 '11 at 11:18
  • 5
    @cweiske why do you consider sudo harmful? – coredump Apr 07 '11 at 11:28
  • 1
    @cweiske Have you considered a wrapper script that interrogates the committer for vital information (who they are, what they changed, why the change was made, ticket number if applicable)? My last place of employ had a similar system (CVS-based) for DNS changes, with wrappers to enforce policy - works surprisingly well. – voretaq7 Apr 07 '11 at 14:05
  • "why do you consider sudo harmful" - because it allows people to gain root access without thinking. writing your normal user password to gain root privileges is - in my eyes - something that makes it too easy. When getting root via ssh login or sudo, you have to write your special root ssh key passwort or the machine's root password - one that's used rarely. – cweiske Apr 07 '11 at 14:14
  • 4
    @cweiske I don't agree one bit with your assessment. You can use a ssh agent to cache the ssh key password and mindlessly log into a root machine, or just use a simple passphrase or the same password on your machine than the root passphrase, while with `sudo` you **force** the user to type a password (even if he uses a ssh key to log as his user) and you can control what the user can execute and mainly you have an audit trail of who has done what. But everyone's entitled to their own opinion. – coredump Apr 07 '11 at 14:34
  • 2
    You could also configure `sudo` to force a user to enter a password for each and every command (`timestamp_timeout = 0`). Perhaps not suitable for development and staging boxes but certainly suitable for production. IMHO, based on the SF consensus, you should rethink your views on `sudo`. One of the great things about SF is having a community of peers who really know their sh*t :-). – Belmin Fernandez Nov 28 '11 at 14:09
3

With putty you can set this under "Connection -> Data -> Environment Variables".

They are also present after 'su' to root.

Cybot
  • 134
  • 7
3

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

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

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_config

minaguib
  • 31
  • 2
1

If 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:

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

Then I use gsudo instead of git to both:

  • Run as root
  • Have access to all non-root user git configuration

Check that the config is indeed being imported:

gsudo config --list --show-origin --includes | less
Tom Hale
  • 1,005
  • 1
  • 12
  • 23
0

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 the git config command.

See man git-config for more info on the command and the cool things you can do with it.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • This works only if one admin committing in that repo on that machine, but it fails with several admins. – cweiske Apr 07 '11 at 14:01
  • True -- it's more suitable for a situation where you have a central repository and people clone & pull/push to that repo. – voretaq7 Apr 07 '11 at 14:04