Хранение, редактирование, версионность конфиг. Файлов.

Паппеты. Всё настраивается паппетами. А вот они уже отлично хранятся в git.

Я с ним не работал, там небось целый рецепт сочинять придется, чтобы просто поменять строчку типа :

allow_overlapping_ips = True

на

allow_overlapping_ips = False

Скажите, как лучше всего организовать хранение, редактирование, версионность конфигурационных файлов в системе.

Каких конкретно „конфигурационных файлов“? Если задача хранить все причем даже дефолтные конфиги без каких-либо изменений то gitlab либо что угодно и вообще всю /etc в git. Я для себя всегда сохраняю только изменения относительно стандартных конфигов.

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

Каких конкретно „конфигурационных файлов“? Если задача хранить все причем даже дефолтные конфиги без каких-либо изменений то gitlab либо что угодно и вообще всю /etc в git. Я для себя всегда сохраняю только изменения относительно стандартных конфигов.

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

Да, в том числе и дефолтовые конфиги

Зачем? Дефолтные тебе и так всегда доступны в твоем пакетном манагере. Качай и наслаждайся.

И в любом случае велосипедов для сабжа придумано превеликое множество причем эта тема обсуждалась совсем недавно и пора бы научится искать (И по форуму в том числе…) прежде чем спрашивать.

целый рецепт сочинять придется

Целый рецепт = пару строк + темплейт конфига. Потом это окупится сторицей.

система контроля версий (git, mercurial, fossil), на каждый сервер отдельный бранч, к примеру по имени сервера, набор простеньких скриптов по открытию/коммиту/копированию/обновлению изменений в бранч по имени сервера.

puppet, chef, ansible — тысячи их. Но просто не будет. Можешь ещё попробовать vcs по своему вкусу для этого, но там тоже свои грабли.

Ansible. Конфигурится просто, агентов на самих серваках не требует(работает по ssh). Формат написания сценариев - не упоротый. После изменения конфига - можешь заливать его куда хочешь - хоть в git, хоть куда

Вот интересуюсь тоже темой неспешно. Как считаете: менять public ключи на серверах через ansible это трувей? :) Ну и вообще... - ansible это от десятка-двух машин... Как? Не очень круто будет?

У меня ansible работает как раз где-то на на двух десятках машин. Сначала ИМХО лучше озадачиться централизованной авторизацией. У меня это - LDAP + SSH LPK. То есть публичный ключ хранится в LDAP-е для пользователя из под которого работает ansible. И менять его нужно в 1 месте :-)

Если серваки разнесены по разным сегментам(в моём случае некоторые - по разным точкам в городе, некоторые - в других городах) - лучше LDAP реплицировать. Во избежании ну ты понел чего.

Моя проблема в том, что у меня очень старые дистрибутивы HP-UX, FreeBSD, linux. - То есть мне весьма будет проблемно реализовать SSH LPK.

Вот по сему я думаю...