Назад | Перейти на главную страницу

Можно ли использовать etckeeper с одним общим репозиторием git?

Я заметил, что несколько человек рекомендовали использовать etckeeper чтобы применить контроль версий к моему каталогу / etc.

Мне кажется, что установка по умолчанию помещает репозиторий на тот же компьютер, что и / etc, которым вы пытаетесь управлять. Это отлично работает для контроля версий, но не дает дополнительных преимуществ в виде резервного копирования файлов вне сервера или позволяет мне дублировать части / etc с одной исходной машины на другую.

Это возможно общий доступ к единому репозиторию git на центральной административной машине, чтобы etckeeper на каждом сервере хранил свои данные в одном месте?

(Сейчас я делаю то же самое с svn и некоторыми пользовательскими скриптами для фиксации и возврата файлов, но я должен помнить о фиксации их при внесении изменений.)

Сначала используйте install etckeeper, настроенный для git в /etc/etckeeper/etckeeper.conf. Следуйте методу установки etckeeper для вашего дистрибутива или из исходников.

Скоро у вас будет /etc/.git

Теперь на вашем сервере убедитесь, что у вас есть (безопасное) репо для отправки ...

 # ssh faruser@farhost     
 # mkdir somedir cd somedir && git init && chmod 700 .git    
 # exit

Теперь на начальном хосте отправьте локальное репо на сервер через ssh:

# cd /etc && git push faruser@farhost:somedir

Somedir, конечно, может быть относительным в этом случае (согласно соглашению ssh)

Делайте это каждый раз, когда вы вносите изменения, затрагивающие / etc (и вставленные etckeeper в /etc/.git), и у вас будут как локальные, так и внешние репозитории для вашей машины.

Или настройте ssh без пароля и сделайте перехватчик в /etc/etckeeper/commit.d/, чтобы это происходило автоматически, если машина всегда подключена.

Можно добавить конфигурацию удаленной ветви, чтобы отобразить главную ветвь репозитория etckeeper с каждого сервера на ветку в удаленном репозитории. Для этого вы можете запустить следующие команды на каждом сервере:

cd /etc
git branch -m master $HOSTNAME
git remote add origin git@git.example.com:path/to/single/repo.git
git push -u origin master:$HOSTNAME

После этой настройки последующие git push будет отправлять изменения из каждой главной ветки сервера в выделенную ветку сервера в центральном репозитории.

Хотя у ветвей не будет общей начальной точки, это позволяет легко сравнивать один и тот же файл из двух разных веток, представляющих два разных сервера, запустив:

git diff origin/server1 origin/server2 -- file

Это можно комбинировать с автоматической настройкой, предложенной Jojoo.

Не в этом дело. Если вы хотите широко распространить конфигурацию, вы настраиваете еще один репозиторий в дополнение к локальному репозиторию каждой машины, и каждая машина вишня от него по мере необходимости. Это позволяет каждой машине отклоняться (на самом деле, ветвиться) и сохранять контроль версий.

Как это сделать автоматически, полная история:

Создайте файл /etc/etckeeper/commit.d/60-push (не забудьте выполнить команду chmod + x it) на клиентах.

#!/bin/sh
git push central_server:/var/git/client_name.git master

central_server определяется в конфигурации ssh, см. ниже. /var/git/client_name.git - это каталог на центральном сервере, содержащий репозиторий git.

~ / .Ssh / config от root (!) Должен содержать что-то вроде этого:

host central_server
Hostname 192.168.0.1
User etckeeper #a user on the central server 
IdentityFile ~/.ssh/custom_key # key is in authorized_keys in
             #etcpeeper@central_server:~/.ssh/authorized_keys

Затем вам нужно запустить репозиторий git на central_server

mkdir /var/git/client_name.git
su etckeeper
cd /var/git/client_name.git
git --bare init

Протестируйте его с помощью небольшого изменения в / etc, а затем выполните фиксацию etckeeper "test push'ing".

Вы действительно не хотите делать etckeeper своей политикой резервного копирования. Хотя было бы неплохо иметь копию ваших файлов конфигурации, ее вряд ли достаточно, чтобы квалифицироваться как план аварийного восстановления.

Вместо этого сосредоточьтесь на реальных резервных копиях вашей системы. Упрощение могло бы быть cronjob для загрузки tarball на ленту ... ах, верно. Никто больше не использует кассеты. Хорошо, cronjob для rsync все ваши файлы в выделенный NAS. Для получения более надежных решений для резервного копирования взгляните на Аманда и Bacula.

А что касается ученых, я смог От себя мое репо etckeeper до github как и любой другой репозиторий git.