Вопросы Теги

Действительно ли возможно использовать etckeeper с единственным общим репозиторием мерзавца?

Мы приняли решение использовать HP, где я работаю на основанные на Intel системы и шасси IBM для Unix. Это - действительно весь вопрос того, в чем Вы нуждаетесь, что Ваш бюджет, и как Ваши отношения с различными поставщиками. Часто поставщики времен, с которыми Вы работаете часто, могут давать Вам очень агрессивную оценку.

Поддержка также играет огромную роль, насколько хороший это и какого количества она стоит?

Для Windows мы сделали очень тяжелый анализ различных блейд-предложений, и для VMware конкретно я скажу, что HP является Вашим лучшим выбором прямо сейчас.

9
задан 12 June 2012 в 13:56
5 ответов

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

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

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

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

Теперь на начальном хосте, продвиньте свой локальный repo к серверу через ssh:

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

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

Сделайте это любое время, которое Вы вносите изменением, которое влияет на / и т.д. (и snarfed в/etc/.git etckeeper), и у Вас будет и локальный и repos вне машины для Вашей машины.

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

8
ответ дан 2 December 2019 в 22:31
  • 1
    Это выглядит большим. Существует ли способ сохранить локальный репозиторий в подкаталоге удаленного? I' d нравится делать что-то подобное, с помощью единственного удаленного репозитория для хранения (отдельных) конфигураций для нескольких серверов. –  Andrew Ferrier 24 May 2010 в 21:00

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

1
ответ дан 2 December 2019 в 22:31
  • 1
    Не уверенный, как сделать это (второй репозиторий). Можно ли уточнить? –  Brent 20 June 2009 в 07:03
  • 2
    Вероятно, необходимо клонировать один из repos на " центральный repo"; Вам только нужен тот. Оттуда можно внести изменения, и затем каждый из серверов может избирательно подойти к выбору патчей, сохраненных в пересмотре. Как Вы настраиваете его, первоначально варьируется между DSCMs. Для мерзавца см. kernel.org/pub/software/scm/git-core/docs/gittutorial.html –  jldugger 20 June 2009 в 10:17

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

Внимание на наличие реальных резервных копий Вашей системы вместо этого. Самым простым мог быть cronjob для питания tarball для записи на ленту..., о, право. Никто больше не использует ленты. Хорошо, cronjob к rsync все Ваши файлы к специализированному NAS. Для большего количества устойчивых решений для резервного копирования смотрите на Amanda и Бакулюмы.

И для случая академиков, я смог продвинуть свой etckeeper repo до GitHub точно так же, как любой другой мерзавец repo.

-2
ответ дан 2 December 2019 в 22:31
  • 1
    Nobody' s говорящий о создании этого резервная политика. Но по моему опыту удобно иметь все в одном месте на большем количестве защищенного сервера. –  Brent 20 June 2009 в 15:57
  • 2
    Затем я неправильно понял. Если, что you' ре, действительно ища является средством централизованно сохранить и распределить Вашу системную конфигурацию, затем возможно, Марионетка ( reductivelabs.com/products/puppet ) имела бы некоторую справку там. –  Shazburg 21 June 2009 в 04:25

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

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

#!/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 на центральном_сервере 

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

Протестируйте его с незначительным редактированием в / etc, а затем выполните фиксацию etckeeper "тестовое нажатие".

1
ответ дан 2 December 2019 в 22:31

Можно добавить конфигурацию удаленной ветви, чтобы сопоставить главную ветвь репозитория 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 .

3
ответ дан 2 December 2019 в 22:31

Теги

Похожие вопросы