Исправьте имена пользователей при отслеживании / etc / в репозитории git и фиксации от имени пользователя root

13

Мы используем git для отслеживания изменений /etc/на наших серверах.

Администраторы работают как root при изменении файлов в / etc /, и поэтому их коммиты имеют автора

root <root@machinename>

Это не очень удовлетворительно, так как вы не можете видеть, какой администратор действительно внес изменения.

Что мы можем сделать, чтобы получить настоящие имена администраторов в журнале git? Я не думаю, что сохранение локального клона репозитория возможно, так как мы часто меняемся интерактивно, пока что-то не работает, и цикл change-commit-push-seeError-repeat здесь не поможет.

— cweiske
источник

Как настоящий root или sudo'd для root?

— Декадо

В настоящее время в качестве фактического пользователя root (ssh root @ или "su", без sudo)

— cweiske

Используйте etckeeper, это заботится о странных ошибках, подобных этому в версии / etc. Также начните использовать учетные записи пользователей и sudo.

— Калеб

12

Автор мерзавец и имя коммиттер могут влиять на переменные окружения GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_AUTHOR_NAMEи GIT_AUTHOR_EMAIL.

Теперь хитрость заключается в отправке этих переменных на удаленный сервер при подключении через SSH:

Определите и экспортируйте переменные в вашем ~/.bashrcфайле:
```
export GIT_AUTHOR_NAME="Christian Weiske"
```
Автоматически отправляйте их по SSH-соединению, настраивая ~/.ssh/config:
```
SendEnv LANG LC_* GIT_*
```
LANGи LC_*не являются необходимыми, но тогда Debian имеет по умолчанию ssh_config, так что я подумал, что я тоже должен их отправить
На удаленном сервере настройте конфигурацию sshd так,/etc/ssh/sshd_config чтобы она принимала GIT_*переменные среды:
```
AcceptEnv LANG LC_* GIT_*
```

Вуаля - git commitкак корень в /etc/приводит к:

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

В случае сбоя сервера в будущем: http://cweiske.de/tagebuch/carry-git-settings.htm

— cweiske
источник

5

Во-первых, и не имеет отношения к вашему вопросу, я настоятельно призываю вас срочно прекратить использовать rootлогины suи использовать логины пользователей и sudoвместо них. Ограничьте ваши rootлогины только консолью или даже не этим.

Тем не менее, git commitесть --authorвариант, который может помочь вам там:

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

Вы также можете осторожно использовать переменные окружения для каждого пользователя GIT_AUTHOR_NAMEи GIT_AUTHOR_EMAILпеременные. В журнале появятся разные авторы и один и тот же commiter ( root@host), но это даст вам больше аудита. Конечно, это означает, что вы доверяете своим администраторам сохранять переменные нетронутыми. Поскольку каждый из них использует определенную оболочку, он может sudoполучить root-права и исходный файл со своими конкретными gitпеременными, по-разному идентифицируя каждый в коммитах. Не очень практично, но вы можете даже автоматизировать это с помощью сценариев.

РЕДАКТИРОВАТЬ: Конечно, еще лучший подход, назначенный @ScottPack, состоит в том, чтобы использовать систему управления конфигурацией, такую как Puppet или Chef, и использовать git для отслеживания изменений на центральном сервере, а не на реальных серверах, чтобы у каждого администратора была рабочая копия. конфигурации.

— CoreDump
источник

--authorКонечно, это возможно, но люди не используют это в своем обычном рабочем процессе, потому что это слишком много для написания. Ваша вторая идея использовать sudo: Я один из тех, кто считает sudo вредным и предпочитает использовать ssh root-доступ только с ssh-ключами. И да, мы доверяем нашим администраторам.

— cweiske

5

@cweiske почему ты считаешь sudo вредным?

— coredump

1

@cweiske Рассматривали ли вы сценарий-оболочку, который запрашивает у коммиттера жизненно важную информацию (кто они, что они изменили, почему было сделано изменение, номер билета, если применимо)? В моем последнем месте работы была аналогичная система (на основе CVS) для изменений DNS с оболочками для обеспечения соблюдения политики - работает на удивление хорошо.

— voretaq7

4

@cweiske Я не совсем согласен с вашей оценкой. Вы можете использовать агент ssh для кеширования пароля ключа ssh и бездумного входа в систему на корневом компьютере, или просто использовать на своем компьютере простую фразу-пароль или тот же пароль, что и пароль-пароль root, в то время как sudoвы заставляете пользователя вводить пароль (даже если он использует ключ ssh для входа в систему как пользователь), и вы можете контролировать, что пользователь может выполнять, и, в основном, у вас есть контрольный журнал того, кто что сделал. Но каждый имеет право на собственное мнение.

— coredump

2

Вы также можете настроить, sudoчтобы заставить пользователя вводить пароль для каждой команды ( timestamp_timeout = 0). Возможно, не подходит для разработки и постановки ящиков, но, безусловно, подходит для производства. ИМХО, основываясь на консенсусе SF, вы должны пересмотреть свои взгляды sudo. Одной из замечательных особенностей SF является наличие сообщества сверстников, которые действительно знают свое дерьмо :-).

— Бельмин Фернандес

3

С помощью putty вы можете установить это в «Соединение -> Данные -> Переменные среды».

Они также присутствуют после « su» для root.

— Cybot
источник

3

Если вам случится подготовить учетные записи пользователей на ваших серверах с помощью ключей ssh, вы можете фактически прикрепить переменные среды к авторизованным ключам во время установки - например, в ~ bob / .ssh / авторизованные_коды

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

Таким образом, когда пользователи SSH автоматически устанавливают эти envs, им не нужно пересылать их с локального клиента. Бонусные баллы, если у вас уже есть эта информация и вы генерируете конфиг авторизованного_ключа из системы управления конфигами.

Примечание: вышеперечисленное требует PermitUserEnvironment yesв sshd_config

— minaguib
источник

1

Если вы используете, sudoи ваш не-root пользователь смонтировал свой домашний каталог:

git -c include.path=<file>будет включать конфигурацию в <file>.

Чтобы автоматически извлекать файлы конфигурации моего пользователя без полномочий root, я использую bashпсевдоним:

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

Тогда я использую gsudoвместо gitобоих:

Запуск от имени пользователя root
Иметь доступ ко всем настройкам git без полномочий root

Убедитесь, что конфиг действительно импортируется:

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

— Том Хейл
источник

0

В дополнение к ответу coredump вы также можете установить эти параметры в .git/configфайле в вашей рабочей копии хранилища (вручную или с помощью git configкоманды).

Смотрите man git-configдля получения дополнительной информации о команде и классные вещи, которые вы можете сделать с ней.

— voretaq7
источник

Это работает, только если один администратор фиксирует в этом репо на этой машине, но это не удается с несколькими администраторами.

— cweiske

Правда - это больше подходит для ситуации, когда у вас есть центральное хранилище, и люди клонируют и тянут / толкают к этому репо.

— voretaq7