Corrija los nombres de usuario al rastrear / etc / en el repositorio de git y al confirmar como root

13

Usamos git para rastrear cambios en /etc/nuestros servidores.

Los administradores trabajan como root cuando cambian archivos en / etc /, y por lo tanto sus commits tienen autor

root <root@machinename>

Esto no es muy satisfactorio ya que no puede ver qué administrador realmente hizo el cambio.

¿Qué podemos hacer para obtener los nombres de administrador reales en el registro de git? No creo que sea factible mantener un clon local del repositorio ya que a menudo cambiamos de manera interactiva hasta que algo funciona, y un ciclo change-commit-push-seeError-repeat no ayudaría aquí.

git root vcs etc Cweiske
fuente
Como raíz real, o sudo'd a la raíz?
Decado
Actualmente como root real (ssh root @ o "su", no sudo)
cweiske
Uso etckeeper, se encarga de las cosas raras como esta en el control de versiones / etc. También comience a usar cuentas por usuario y sudo.
Caleb

Respuestas:

12

El autor Git y el nombre del confirmador pueden ser influenciados con las variables de entorno GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAMEy GIT_AUTHOR_EMAIL.

Ahora el truco es enviar esas variables al servidor remoto cuando se conecta a través de SSH:

  1. Defina y exporte las variables en su ~/.bashrcarchivo:

    export GIT_AUTHOR_NAME="Christian Weiske"

  2. Envíelos automáticamente con una conexión SSH ajustando ~/.ssh/config:

    SendEnv LANG LC_* GIT_*

    LANGy LC_*no son necesarios, pero Debian tiene su ssh_config predeterminado, así que pensé que debería enviarlos también

  3. En el servidor remoto, ajuste la configuración de sshd/etc/ssh/sshd_config para aceptar GIT_*variables de entorno:

    AcceptEnv LANG LC_* GIT_*

Voila - a git commitcomo raíz en /etc/conduce a:

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

En caso de fallas del servidor por defecto en el futuro: http://cweiske.de/tagebuch/carry-git-settings.htm

Cweiske
fuente
5

Primero, y no relacionado con su pregunta, le insto a que que deje de usar los rootinicios de sesión urgenciasu y, en su sudolugar, use los inicios de sesión de los usuarios . Restrinja sus rootinicios de sesión solo a la consola, o ni siquiera eso.

Dicho esto, git committiene una --authoropción que puede ayudarte allí:

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

También puede usar cuidadosamente las variables de entorno por usuario para establecer GIT_AUTHOR_NAME y las GIT_AUTHOR_EMAILvariables. En el registro, aparecerán diferentes autores y el mismo commiter ( root@host), pero le dará más auditoría. Por supuesto, eso significa que confía en sus administradores para mantener las variables intactas. Como cada uno usa un shell específico, pueden sudorootear y obtener un archivo con sus gitvariables específicas , identificando cada uno de manera diferente en los commits. No es muy práctico, pero incluso puede automatizar eso con scripts.

EDITAR: Por supuesto, un enfoque aún mejor según lo designado por @ScottPack sería usar un sistema de administración de configuración como Puppet o Chef y usar git para rastrear los cambios en el servidor central y no en los servidores reales para que cada administrador pueda tener una copia de trabajo de la configuración.

volcado de memoria
fuente
--authores posible, por supuesto, pero la gente no usa eso en su flujo de trabajo normal ya que es demasiado para escribir. En su segunda idea de usar sudo: soy una de las personas que considera sudo dañino y prefiero usar el acceso raíz ssh solo con claves ssh. Y sí, confiamos en nuestros administradores.
cweiske
55
@cweiske, ¿por qué consideras que el sudo es dañino?
coredump
1
@cweiske ¿Ha considerado una secuencia de comandos de envoltura que interroga al encargado para obtener información vital (quiénes son, qué cambiaron, por qué se realizó el cambio, número de ticket si corresponde)? Mi último lugar de trabajo tenía un sistema similar (basado en CVS) para cambios de DNS, con envoltorios para hacer cumplir la política, funciona sorprendentemente bien.
voretaq7
44
@cweiske No estoy de acuerdo ni un poco con su evaluación. Se puede utilizar un agente de ssh para almacenar en caché la contraseña de clave ssh y sin pensar iniciar sesión en una máquina de raíz, o simplemente utilizar una frase de contraseña simple o la misma contraseña en su máquina que la frase de contraseña de la raíz, mientras que con la sudoque obliga al usuario que escriba una contraseña (incluso si usa una clave ssh para iniciar sesión como su usuario) y usted puede controlar lo que el usuario puede ejecutar y principalmente tiene una pista de auditoría de quién ha hecho qué. Pero todos tienen derecho a su propia opinión.
coredump
2
También puede configurar sudopara obligar a un usuario a ingresar una contraseña para cada comando ( timestamp_timeout = 0). Tal vez no sea adecuado para el desarrollo y los escenarios, pero ciertamente es adecuado para la producción. En mi humilde opinión, sobre la base del consenso de SF, debe repensar sus puntos de vista sudo. Una de las mejores cosas de SF es tener una comunidad de compañeros que realmente conocen su mierda :-).
Belmin Fernández el
3

Con masilla puede configurar esto en "Conexión -> Datos -> Variables de entorno".

También están presentes después de ' su' a la raíz.

Cybot
fuente
3

Si aprovisiona cuentas de usuario en sus servidores utilizando claves ssh, puede adjuntar variables de entorno a las claves autorizadas en el momento de la configuración, por ejemplo en ~ bob / .ssh / Authorizedkeys

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

De esta manera, cuando los usuarios de SSH ingresan, automáticamente configuran estos envs; no es necesario que los reenvíen desde el cliente local. Puntos de bonificación si ya tiene esta información y está generando configuraciones de claves_autorizadas desde un sistema de administración de configuración.

Nota: Lo anterior requiere PermitUserEnvironment yesen sshd_config

minaguib
fuente
1

Si estas usando sudo y su usuario no root tiene su directorio de inicio montado:

git -c include.path=<file>incluirá la configuración en <file>.

Para extraer automáticamente los archivos de configuración de mi usuario no root, utilizo el bash alias:

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

Entonces uso gsudo lugar de gitambos:

  • Ejecutar como root
  • Tener acceso a toda la configuración git de usuario no root

Verifique que la configuración se esté importando:

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

Además de la respuesta de coredump, también puede configurar estas opciones en el .git/config archivo en su copia de trabajo del repositorio (a mano o con el git configcomando.

Consulte man git-configpara obtener más información sobre el comando y las cosas interesantes que puede hacer con él.

voretaq7
fuente
Esto funciona solo si un administrador se compromete en ese repositorio en esa máquina, pero falla con varios administradores.
cweiske
Es cierto: es más adecuado para una situación en la que tiene un repositorio central y la gente clona y tira / empuja a ese repositorio.
voretaq7