Correggere i nomi utente durante il tracciamento / etc / nel repository git e il commit come root

13

Usiamo git per tenere traccia delle modifiche /etc/sui nostri server.

Gli amministratori lavorano come root quando cambiano i file in / etc /, e quindi i loro commit hanno autore

root <root@machinename>

Questo non è molto soddisfacente poiché non puoi vedere quale amministratore ha effettivamente apportato la modifica.

Cosa possiamo fare per ottenere i veri nomi di amministratore nel registro git? Non credo che mantenere un clone locale del repository sia fattibile poiché spesso cambiamo in modo interattivo fino a quando qualcosa non funziona, e un ciclo change-commit-push-seeError-repeat non sarebbe utile qui.

— cweiske
fonte

Come root reale, o sudo'd per root?

— Decado,

Attualmente come root effettivo (ssh root @ o "su", no sudo)

— cweiske,

Usa etckeeper, si occupa degli strani gotchas come questo nel versioning / etc. Inizia anche a utilizzare account per utente e sudo.

— Caleb

12

L'autore e il nome git committer possono essere influenzati con le variabili d'ambiente GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAMEe GIT_AUTHOR_EMAIL.

Ora il trucco è di inviare quelle variabili al server remoto quando ci si connette tramite SSH:

Definisci ed esporta le variabili nel tuo ~/.bashrcfile:
```
export GIT_AUTHOR_NAME="Christian Weiske"
```
Inviarli automaticamente con una connessione SSH regolando ~/.ssh/config:
```
SendEnv LANG LC_* GIT_*
```
LANGe LC_*non sono necessari, ma Debian ha quindi nel loro predefinito ssh_config, quindi ho pensato di doverli inviare anche loro
Sul server remoto, regolare la configurazione di sshd in /etc/ssh/sshd_configper accettare GIT_*le variabili di ambiente:
```
AcceptEnv LANG LC_* GIT_*
```

Voila - a git commitcome root in /etc/porta a:

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

In caso di guasti del server in futuro: http://cweiske.de/tagebuch/carry-git-settings.htm

— cweiske
fonte

5

Innanzitutto, e non correlato alla tua domanda, ti esorto a smettere urgentemente di utilizzare gli rootaccessi sue di utilizzare gli accessi utente e sudoinvece. Limita i tuoi rootaccessi solo alla console o nemmeno a quello.

Detto questo, git commitha --authorun'opzione che può aiutarti lì:

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

È inoltre possibile utilizzare attentamente le variabili di ambiente per utente da impostare GIT_AUTHOR_NAMEe le GIT_AUTHOR_EMAILvariabili. Nel registro appariranno autori diversi e lo stesso commiter ( root@host), ma ti darà più controllo. Ovviamente ciò significa che ti fidi dei tuoi amministratori per mantenere intatte le variabili. Poiché ognuno utilizza una shell specifica, è possibile sudoeseguire il root e il source di un file con le proprie gitvariabili specifiche , identificandoli in modo diverso nei commit. Non molto pratico, ma potresti persino automatizzarlo con gli script.

EDIT: Ovviamente un approccio ancora migliore come nominato da @ScottPack sarebbe quello di utilizzare un sistema di gestione della configurazione come Puppet o Chef e usare git per tracciare le modifiche sul server centrale e non sui server reali in modo che ogni amministratore possa avere una copia funzionante della configurazione.

— coredump
fonte

--authorè ovviamente possibile ma le persone non lo usano nel loro normale flusso di lavoro poiché è troppo da scrivere. Sulla tua seconda idea di usare sudo: sono una delle persone che considerano sudo dannoso e preferisco usare l'accesso root ssh solo con le chiavi ssh. E sì, ci fidiamo dei nostri amministratori.

— cweiske,

5

@cweiske perché ritieni che il sudo sia dannoso?

— coredump,

1

@cweiske Hai preso in considerazione uno script wrapper che interroga il committer per informazioni vitali (chi sono, cosa hanno cambiato, perché la modifica è stata effettuata, numero del biglietto se applicabile)? Il mio ultimo posto di lavoro aveva un sistema simile (basato su CVS) per le modifiche DNS, con wrapper per applicare la politica - funziona sorprendentemente bene.

— voretaq7,

4

@cweiske Non sono d'accordo con la tua valutazione. Puoi usare un agente ssh per memorizzare nella cache la password della chiave ssh e accedere senza pensarci a una macchina root, o semplicemente usare una passphrase semplice o la stessa password sulla tua macchina della passphrase root, mentre con sudote costringi l'utente a digitare una password (anche se usa una chiave ssh per accedere come suo utente) e puoi controllare ciò che l'utente può eseguire e principalmente hai una pista di controllo di chi ha fatto cosa. Ma ognuno ha diritto alla propria opinione.

— coredump,

2

È inoltre possibile configurare sudoper forzare un utente a immettere una password per ciascun comando ( timestamp_timeout = 0). Forse non adatto per scatole di sviluppo e messa in scena ma sicuramente adatto per la produzione. IMHO, in base al consenso SF, dovresti ripensare le tue opinioni sudo. Una delle cose più belle di SF è avere una comunità di colleghi che conoscono davvero la loro merda :-).

— Belmin Fernandez,

3

Con putty puoi impostarlo in "Connessione -> Dati -> Variabili d'ambiente".

Sono presenti anche dopo ' su' alla radice.

— Cybot
fonte

3

Se ti capita di eseguire il provisioning degli account utente sui tuoi server utilizzando le chiavi ssh, puoi effettivamente collegare le variabili di ambiente alle chiavi autorizzate al momento dell'installazione, ad esempio 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

In questo modo quando gli utenti SSH hanno automaticamente queste impostazioni envs, non è necessario che vengano inoltrate dal client locale. Punti bonus se disponi già di queste informazioni e stai generando config authorized_keys da un sistema di gestione della configurazione.

Nota: quanto sopra richiede PermitUserEnvironment yesin sshd_config

— minaguib
fonte

1

Se stai usando sudoe il tuo utente non root ha la sua home directory montata:

git -c include.path=<file>includerà la configurazione in <file>.

Per estrarre automaticamente i file di configurazione del mio utente non root, utilizzo l' bashalias:

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

Quindi uso gsudoinvece di gitentrambi:

Esegui come root
Avere accesso a tutta la configurazione git dell'utente non root

Verifica che la configurazione sia effettivamente importata:

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

— Tom Hale
fonte

0

Oltre alla risposta di coredump puoi anche impostare queste opzioni nel .git/configfile nella tua copia di lavoro del repository (manualmente o usando il git configcomando.

Vedi man git-configper maggiori informazioni sul comando e le cose interessanti che puoi fare con esso.

— voretaq7
fonte

Funziona solo se un amministratore si impegna in quel repository su quella macchina, ma fallisce con diversi amministratori.

— cweiske,

Vero: è più adatto a una situazione in cui si dispone di un repository centrale e le persone clonano e trascinano / spingono in quel repository.

— voretaq7,