Corrija os nomes de usuário ao rastrear / etc / no repositório git e confirmar como root

13

Usamos o git para rastrear alterações em /etc/nossos servidores.

Os administradores trabalham como raiz ao alterar arquivos no / etc / e, portanto, seus commits têm autor

root <root@machinename>

Isso não é muito satisfatório, pois você não pode ver qual administrador realmente fez a alteração.

O que podemos fazer para obter os nomes reais de administrador no log do git? Eu não acho que manter um clone local do repositório seja viável, pois geralmente mudamos interativamente até que algo funcione, e um ciclo de mudança de confirmação de envio e push de seeError-repeat não ajudaria aqui.

git root vcs etc cweiske
fonte
Como root real ou sudo'd para root?
Dec11
Atualmente como root real (ssh root @ ou "su", sem sudo)
cweiske
Use etckeeper, ele cuida de truques estranhos como este no versionamento / etc. Comece também a usar contas por usuário e sudo.
Caleb

Respostas:

12

O autor git eo nome committer pode ser influenciada com as variáveis de ambiente GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAMEe GIT_AUTHOR_EMAIL.

Agora, o truque é enviar essas variáveis ​​ao servidor remoto ao se conectar através do SSH:

  1. Defina e exporte as variáveis ​​em seu ~/.bashrcarquivo:

    export GIT_AUTHOR_NAME="Christian Weiske"

  2. Envie-os automaticamente com uma conexão SSH ajustando ~/.ssh/config:

    SendEnv LANG LC_* GIT_*

    LANGe LC_*não são necessários, mas o Debian possui o ssh_config padrão, então pensei em enviá-los também

  3. No servidor remoto, ajuste a configuração sshd/etc/ssh/sshd_config para aceitar GIT_*variáveis ​​de ambiente:

    AcceptEnv LANG LC_* GIT_*

Voila - a git commitraiz como /etc/leva a:

commit 8a4654f13241f05361283a88ce041a0fc24b8ac6
Author: Christian Weiske <[email protected]>

Caso a falha do servidor falhe em algum momento no futuro: http://cweiske.de/tagebuch/carry-git-settings.htm

cweiske
fonte
5

Primeiro, e não relacionado à sua pergunta, recomendamos que você interrompa com urgência o uso de rootlogons e suos logins de usuário sudo. Restrinja seus rootlogins apenas ao console, ou nem isso.

Dito isto, git committem uma --authoropção que pode ajudá-lo lá:

# git commit --author='Author Name <[email protected]>' -a

Você também pode usar cuidadosamente variáveis ​​de ambiente por usuário para definir GIT_AUTHOR_NAMEe GIT_AUTHOR_EMAILvariáveis. No log, aparecerão autores diferentes e o mesmo commiter ( root@host), mas fornecerão mais auditorias. Claro que isso significa que você confia em seus administradores para manter as variáveis ​​intactas. Como cada um está usando um shell específico, eles podem sudofazer root e originar um arquivo com suas gitvariáveis específicas , identificando cada um de maneira diferente nos commits. Não é muito prático, mas você pode até automatizar isso com scripts.

EDIT: É claro que uma abordagem ainda melhor, como apontada pelo @ScottPack, seria usar um sistema de gerenciamento de configuração como Puppet ou Chef e usar o git para rastrear as alterações no servidor central e não nos servidores reais, para que cada administrador pudesse ter uma cópia de trabalho. da configuração.

coredump
fonte
--authoré possível, é claro, mas as pessoas não usam isso em seu fluxo de trabalho normal, pois é muito difícil escrever. Na sua segunda idéia de usar o sudo: sou uma das pessoas que consideram o sudo prejudicial e, em vez disso, usam o acesso root ssh apenas com chaves ssh. E sim, confiamos em nossos administradores.
Ceviske
5
@cweiske Por que você considera o sudo prejudicial?
Coredump #
1
@cweiske Você considerou um script de wrapper que interroga o responsável pela informação vital (quem eles são, o que eles mudaram, por que a alteração foi feita, o número do ticket, se aplicável)? Meu último local de trabalho tinha um sistema semelhante (baseado no CVS) para alterações no DNS, com wrappers para impor políticas - funciona surpreendentemente bem.
precisa saber é o seguinte
4
@weweke Não concordo nem um pouco com sua avaliação. Você pode usar um agente ssh para armazenar em cache a senha da chave ssh e sem pensar entrar em uma máquina de raiz, ou apenas usar uma senha simples ou a mesma senha em sua máquina que a senha raiz, enquanto que com sudovocê forçar o usuário digite uma senha (mesmo se ele usa uma chave ssh para registrar como usuário) e você pode controlar o que o usuário pode executar e, principalmente, você tem uma trilha de auditoria de quem fez o que. Mas todo mundo tem direito a sua própria opinião.
Coredump #
2
Você também pode configurar sudopara forçar um usuário a inserir uma senha para cada comando ( timestamp_timeout = 0). Talvez não seja adequado para caixas de desenvolvimento e preparação, mas certamente adequado para produção. IMHO, com base no consenso do SF, você deve repensar suas opiniões sudo. Uma das grandes coisas sobre SF é ter uma comunidade de colegas que realmente conhecem seus sh * t :-).
Belmin Fernandez 28/11
3

Com o putty, você pode definir isso em "Conexão -> Dados -> Variáveis ​​de ambiente".

Eles também estão presentes após sua raiz.

Cybot
fonte
3

Se você provisionar contas de usuário em seus servidores usando chaves ssh, poderá conectar variáveis ​​de ambiente às chaves autorizadas no momento da configuração - por exemplo, em ~ bob / .ssh / allowed_keys

environment="GIT_AUTHOR_NAME=Bob Smith",environment="[email protected]" ssh-rsa AAAA.... [email protected]

Dessa forma, quando os usuários fazem o SSH, eles automaticamente configuram esses envs - não há necessidade deles de encaminhá-los a partir do cliente local. Pontos de bônus, se você já possui essas informações e está gerando configurações author_keys a partir de um sistema de gerenciamento de configurações.

Nota: O acima requer PermitUserEnvironment yesno sshd_config

minaguib
fonte
1

Se você estiver usando sudoe seu usuário não root tiver o diretório inicial montado:

git -c include.path=<file>incluirá a configuração em <file>.

Para puxar automaticamente os arquivos de configuração do meu usuário não raiz, eu uso o bashalias:

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

Então eu uso em gsudovez de gitpara ambos:

  • Executar como root
  • Ter acesso a toda a configuração git do usuário não raiz

Verifique se a configuração está realmente sendo importada:

gsudo config --list --show-origin --includes | less
Tom Hale
fonte
0

Além da resposta do coredump, você também pode definir essas opções no .git/configarquivo da sua cópia de trabalho do repositório (manualmente ou usando o git configcomando

Veja man git-configpara obter mais informações sobre o comando e as coisas legais que você pode fazer com ele.

voretaq7
fonte
Isso funciona apenas se um administrador confirmar nesse repositório nessa máquina, mas falhará com vários administradores.
Ceviske
Verdadeiro - é mais adequado para uma situação em que você tem um repositório central e as pessoas clonam e puxam / empurram para esse repositório.
precisa saber é o seguinte