Настройки на разных системах сильно отличаются. Поэтому я не могу хранить их в едином репозитории git.

ветки тебе на что?

и зачем это нужно?

Имею свой git на vps.

Под каждую фирму есть реп вида:

firm.service

например firm.asterisk, firm.mail, firm.iptables.

Если серверов много, то уже использую firm.servername.service.

Каждый раз делая изменения банально пушу в гит.

Настройки - чаще всего из готовых, приготовленных мной.

5. думал так сделать с LFS, но потом понял, что это не есть гут для такого жирного объёма данных. лучше btrfs заюзай, или что-нибудь другое, на вкус, что умеет в снапшоты.

Ок, есть новый сервер и на этом сервере нужно настроить, допустим, только что-то одно. Например, iptables. Какие действия делаются для этого? Создается репозиторий на этом новом сервере? В какой директории? И потом в него из vps с git копируются уже заранее настроенные конфиги?

ветки тебе на что?

Ветки да, согласен.

и зачем это нужно?

Чтобы вести детальный учет всех изменений, чтобы ничего не ускользнуло. Чтобы потом можно было быстрее найти ошибку или причину каких-то проблем. Чтобы совершенствовать настройку системы, в общем.

1. Как лично Вы ведете журнал установки и настройки различных систем?

Никак. Документирую, только для того, кто унаследует все это «добро». Для себя доки не веду.

2. Вы все помните наизусть, или опираетесь на проверенные лично Вами мануалы? Или настраиваете, а потом забываете?

Нет, есть механическая память, когда надо поднять быстро, руки делают, пока мозг еще не сообразил. Лаг секунды полторы, но всегда все правильно, а не «ой, что это я в консоли напечатала». Хотя это рефлексы выработанные рабством работой у хостера.

3. Что вы делаете, если нужно отступить от привычного порядка? Как вы это фиксируете?

Оставляешь ### WARNING! ACHTUNG! ВНИМАНИЕ! ATENCION! УВАГА! ### в конфиге. Когда «припекло, доки никто не читает». Хотя, когда подсказывает практика, доки читают, только когда ничего не работает, так что бестолку записывать «индивидуальные» конфиги. Надо что бы бросалось в глаза если делаешь для других. Учти, что ни в одной конторе не будешь сидеть вечно. Всегда расчитывай на то что, за тобой, сервак унаследует умственно отсталый даун, 5ти лет от роду.

4. Самое главное: есть ли какие-то способы автоматически фиксировать изменения в системе, чтобы потом легко поднять их в читаемой форме (как журнал)?

ХЗ. У меня центральный rsyslog + puppet. ГИТа, который хранил бы все изменения, нет. Лучше потратить час на вкуривание мана, чем тупо все записывать.

Запилить оптимизацию под мускуль, апач и nginx в случае утери конфигов занимает максимум пол часа.

Документирую, как просчитывать конфиги, сами конфиги хранить как-то бестолку. Просчитать и найти в доках, по времени одинаково.

А так, для баранкиных которые унаследуют mein preciouss, если вдруг опять мне приспичит «сорваться и свалить на край света», все снапшотиться раз в сутки + rsnapshot тянет конфиги и дату со всех верваков 4 pаза в день (increment) и хранит 2 месяца. Все это мониторит nagios и если что-то отвалилось или опаздывает, шлет сообщения на мобильник мне и насяльникам. (На всякий пожарный, а вдруг, я уеду/уволюсь/забеременнею)

Мой зоопарк, примерно 500+ сервачков.

Захватывающая жизнь линуксовых эникеев.

Спасибо! По поводу пункта 4:

У меня центральный rsyslog + puppet.
+ rsnapshot тянет конфиги и дату
Мой зоопарк, примерно 500+ сервачков.

С учетом такого зоопарка (но без учета даты, которую тянет rsnapshot), какие ресурсы требуются серверу с центральным rsyslog + puppet?

Puppet:

cores = (nodes) * (check-ins per hour) * (seconds per catalog) / (seconds per hour)

Как-то так. A лучше, сам загугли. Лезть смотреть, что там в субботу вечером, плохая примета.

rsnapshot, на 40 машин, примерно 1 ядро и гиг рама если бакапишь раз в день. Если чаще, суди по тому, что говорит мониторинг. Если машинка не тянет, посмотри, на какое время все запланированно. Делать бакапы всех машин одновременно - плохая идея (сpu/network bottleneck) Если оно совсем не тянет, даже если запланированно по 1му бакапу каждые пол часа, делаешь снапшот, а из снапшота, что-то помощнее. Кстати, по моему, это не идеальный бакап софт, но до этого я ещё не добралась. Работает и ладно.

но без учета даты, которую тянет rsnapshot

Для даты, у меня просто прикрученные виртуальные диски. Снапшоты новы, это 1 диск, apache/mysql/caches config + webdata+mysqldumps 2й диск, и так далее.

Естественно, puppet и бакапы в один сервер запихивать не стоит. Как говориться, разделяй и властвуй :)

rsyslog у меня покачто живет с паппетом.

Puppet и бакапы и меня на амазоне, так что, проблем с увеличением ресурсов нет. (Там максимум 32ядрa и 244гига рамы)

Всё остальное, тоже виртуалки. Все физические серваки, я стараюсь ликвидировать. В случае поломки или большого траффика - слишком много гемороя.

Кстати, паппет и бакап каждый имеют свой elastic IP. Когда создаешь новую машинку из снапшота, получить тот же айпишник нельзя, а вот перебросить elastic IP, с одной на другую, запросто)

Мой зоопарк, примерно 500+ сервачков.

Гррр... что-то у меня срач в known_hosts. uniq говорит, что 243 :S

Самое пожалуй полезное - держать на рабочем столе текстовик со списком пакетов установленных после установки самостоятельно, с коментами что это за хрень и зачем, как ставил. Посмотришь и знаешь, чего в новой системе не хватает. Ну и дерево каталогов с дополнительными скриптами, конфигами, бинарями.

Вы все помните наизусть, или опираетесь на проверенные лично Вами мануалы?

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

Как то так:

Создаем реп на сервере. company.servername.scripts

mkdir /var/scripts/; git init git remote add origin http://... vim iptables.sh git add iptables.sh git commit git push origin

Nix + Git

Попробуйте Nix совместно с Git.

У меня две системы, все настройки храню в мозгах.

SALT! Ну или конкуренты. Почему-то в треде почти все несут пургу. Фигачишь декларативные требования к системе сразу на нужном системе языке, а потом они еще и сами выполняются. Все твои варианты — фигня.

SALT! Ну или конкуренты.

Ок, спасибо! А кто же конкуренты?

Вышеупомянутый puppet, ansible и chef. Может еще кто появился.