Хранение серверных конфигов в SVN

at-hacker — Thu, 13 Dec 2012 13:11:00 GMT

Настраивал хранение freebsd-шных конфигов в SVN. Обнаружилось небольшое западло. Маааленькое такое. В результате которого если ты закрыл консоль, то больше к серваку не подключишься :-)

Причиной является то, что при операции svn commit после добавления всех конфигов в репозиторий, svn делает меняет права на конфигурационные файлы. В частности, добавляет права на чтение для ssh-ключей хоста сервера. Вот для этих файлов, иными словами: /etc/ssh_host_dsa_key, /etc/ssh_host_rsa_key и /etc/ssh_host_ecdsa_key. После чего система отказывается принимать новые соединения по ssh, мотивируя это тем, что:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_rsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_dsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_ecdsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key

И если своевременно не принять меры по устранению и недопущению, может получиться казус. Пока ssh-консоль открыта, есть некоторый шанс. Нужно вернуть права на ключи обратно, запретив чтение группе и другим. А в идеале — вернуть вообще все уехавшие права с файлов каталога /etc и всех подкаталогов, так как модификации прав подверглись все файлы.

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

server# freebsd-update IDS | awk '/permissions/{ print $8" "$1 }' | xargs -t -L 1 chmod

Утиля долго думает, сверяется с Большим Братом в интернетах, а затем начинает генерировать отчёт, в котором английском по чёрному написано, на каком файле какие права стоят, а какие должны быть. Аккуратно выкусываем awk'ом строчки со словом permissions, который также извлекает 8 и 1 колонки (это права и имя файла соответственно), а утиля xargs доделывает всё остальное, вызывая chmod и подставляя ему результат работы предыдущего конвейера. В итоге эта команда проходится по всем файлам в каталоге /etc, возвращая им правильные права.

Стоит также отметить, что в /usr/local/etc/, которые я тоже сложил в SVN, права тоже поедут. Но там менее критично всё это, по крайней мере, не приведёт к потере управления удалённым сервером. А в идеале, надо делать отчёт с помощью утилиты mtree по правам доступа всех файлов, а после svn add / svn commit возвращать их с помощью этой же mtree обратно. Потому как после каждого commit'a права на закоммиченные файлы будут приводиться в соответствие с umask. Наверное, в идеале стоит написать какую-то обёртку для svn commit, которая будет затем возвращать права на файлы обратно. Либо пойти по пути asvn и реализовать хранение разрешений для файла в репозитории с помощью properties, а при коммите их перечитывать и делать chmod на файлы. А то западло получается... и реализовать хранение разрешений для файла в репозитории с помощью properties, а при коммите их перечитывать и делать chmod на файлы. А то западло получается...

subversion hooks

at-hacker — Sat, 20 Dec 2008 22:43:00 GMT

Потребовалось тут неожиданно исправить сообщение после свершившегося коммита изменений в subversion. Нашёл в клиенте TortoiseSVN чудесную опцию Edit log. Но при попытке её заюзать получил большой облом в виде сообщения: «svnadmin: Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook».

Курение интернета показало, что для этого потребны некие subversion hooks, каковые могут представлять собой скрипты или даже бинарники, используемые subversion при различных событиях. Некий аналог триггеров в БД, в общем.

Как утверждает методичка, лежать они должны в каталоге path_to_svn_repository/hooks. Я полез на сервак смотреть, лежит ли там что-нибудь, в этом каталоге. Оказалось, что лежит. Некий набор файлов с расширениями *.tmpl. Курение методички на предмет как же эти скрипты заюзать, показало, что нужно дать им права на исполнение. Я дал им право на исполнение, перезапустил svnserve, однако нужного эффекта это не принесло — всё равно получал вышеуказанное сообщение. Методичка умолчала о самом главном — у файла нужно убрать расширение .tmpl.

Конкретно для правки свойства svn:log, каковое и является собственно комментарием при коммите, необходимо наличие хука pre-revprop-change. Таким образом переименовываем файл path_to_svn_repository/hooks/pre-revprop-change.tmpl в path_to_svn_repository/hooks/pre-revprop-change, даём ему права на исполнение, перезапускаем svnserve, и вуаля — можем редактировать каменты коммита либо через Edit log в TortoiseSVN, либо вот такой командой:

svnadmin setlog /usr/local/svn -r 103 /usr/local/svn/log.txt

где 103 — это номер ревизии, которая должна подвергнуться редактированию, а /usr/local/svn/log.txt — это файл с сообщением, которое должно стать новой версией комментария к 103-ей ревизии. У меня не настроен русский в серверной консоли, поэтому я решил сделать комментарий в виде файла в нужной кодировке.

Компы и автомобили (Posts about Subversion)

Хранение серверных конфигов в SVN

subversion hooks