Comments 39
в свое время писал со скуки небольшой велосипед. Демон, который автоматически коммитит раз в определенное время. Основные настройки прилагаются + есть небольшой питонский (pyqt) гуй, суть которого — работа в гит.
Он есть в моем профиле на гитхабе, прямую ссылку давать не буду, чтобы не сочли за рекламу :) (тем более, там быдлокод =))
Он есть в моем профиле на гитхабе, прямую ссылку давать не буду, чтобы не сочли за рекламу :) (тем более, там быдлокод =))
А размещение .git в / не помешает другим проектам, хранящимся в виде гитовых репозиториев? Git не станет их рассматривать в качестве submodules?
У меня не рассматривает. В принципе практика делать репозиторий в каталоге с другим репозиторием — распространённая. Существует, например, в Minetest.
Вообще, он ищет .git снизу вверх, что логично.
Вообще, он ищет .git снизу вверх, что логично.
Есчо не мешало бы интегрироваться с системой пакетов, чтобы при установке каждого нового пакета делался автоматически коммит
Что то типа
Что то типа
DPkg::Post-Invoke {"git commit -m ''Install $pakagename";};
Для меня версионирование конфигов — отдельный инструмент. Например, можно коммитить установку сразу нескольких приложений или, наоборот, не коммитить установку того-чего-не-жалко.
А с той точки зрения, что пакеты могут чего-то попортить — в gentoo уже есть защита от изменения скриптами установки юзерских конфигов.
А с той точки зрения, что пакеты могут чего-то попортить — в gentoo уже есть защита от изменения скриптами установки юзерских конфигов.
Для этого есть github.com/joeyh/etckeeper
Он не только после обновления пакетов комитит, но и по корону тоже умеет.
Упомянутую в посте проблему публикации секретных файлов он не решает, впрочем.
Он не только после обновления пакетов комитит, но и по корону тоже умеет.
Упомянутую в посте проблему публикации секретных файлов он не решает, впрочем.
По крону, конечно же.
Вы же все знаете, как так получается. «Комитет» на «комитит» исправил, а дальше проглядел.
Вы же все знаете, как так получается. «Комитет» на «комитит» исправил, а дальше проглядел.
Судя по TODO, он не решает даже проблемы слияния (в TODO написано, что хорошо бы иметь ветку с неизменёнными конфигами; а как вы будете сливать ваш вариант и обновлённый, если таковой ветки нет?). Секретные файлы тоже есть в TODO.
Кстати, а как в Debian и Ubuntu поступают с пользовательскими изменениями? Судя по Debian Policy Manual¹, он спрашивает пользователя, если файл был изменён как пользователем, так и maintainer’ом пакета (что лучше portage, который будет спрашивать всегда, если файл изменён пользователем), и etckeeper ничего с этим не делает. Но во многих случаях достаточно автоматического слияния, производимого системой контроля версий, а в остальных вы получаете привычный 3-way merge, а не (в Gentoo!) «вот два файла, твой старый и новый, теперь вспомни, что ты там наменял, а что оставил как есть» (с etckeeper вспомнить должно быть проще).
¹
Кстати, а как в Debian и Ubuntu поступают с пользовательскими изменениями? Судя по Debian Policy Manual¹, он спрашивает пользователя, если файл был изменён как пользователем, так и maintainer’ом пакета (что лучше portage, который будет спрашивать всегда, если файл изменён пользователем), и etckeeper ничего с этим не делает. Но во многих случаях достаточно автоматического слияния, производимого системой контроля версий, а в остальных вы получаете привычный 3-way merge, а не (в Gentoo!) «вот два файла, твой старый и новый, теперь вспомни, что ты там наменял, а что оставил как есть» (с etckeeper вспомнить должно быть проще).
¹
If neither the user nor the package maintainer has changed the file, it is left alone. If one or the other has changed their version, then the changed version is preferred — i.e., if the user edits their file, but the package maintainer doesn't ship a different version, the user's changes will stay, silently, but if the maintainer ships a new version and the user hasn't edited it the new version will be installed (with an informative message). If both have changed their version the user is prompted about the problem and must resolve the differences themselves.
У меня особо важное содержимое ~ лежит в гите на гитхабе.
Когда мне дают очередной сервер, то мне достаточно в /home/dovg выполнить одну простую команду git init && git remote add origin… && git pull, и я получаю привычное окружение — .bashrc, конфиги ssh, публичные ключи и т.д.
Очень удобно.
Когда мне дают очередной сервер, то мне достаточно в /home/dovg выполнить одну простую команду git init && git remote add origin… && git pull, и я получаю привычное окружение — .bashrc, конфиги ssh, публичные ключи и т.д.
Очень удобно.
а почему просто git clone нельзя сделать?
Нет, не удобно. Вам же все равно придется сначала устанавить необходимые пакеты (тот же vim, git и т.д.)
Посмотрите, как устроены популярные dotfiles, зачастую там есть setup, который ставит нужные пакеты, вычекивает vim'овые плагины. Добавить в такой скрипт интеграцию с systemctl — и можно получить точную копию системы за три пять команд: <менеджер пакетов> install git-core && git init && git remote add… && git pull && ./bootstrap.
А можно использовать ansible, конфиг которого уже хранить в git. Тогда даже нужные пакеты можно будет ставить.
Для таких целей завсегда существовала тулза под названием "rcs"
rcs creates new RCS files or changes attributes of existing ones. An RCS file contains multiple revisions of text, an access list, a change log, descriptive text, and some control attributes.
RCS поддерживается dispatch-conf. Других преимуществ перед git не вижу, а вот невозможность сделать push оттуда в привычный bitbucket/github/… — вижу.
UFO just landed and posted this here
Чтоб держать пару конфигов в версионном виде и ради этого поднимать гит — это из пушки по воробьям ИМХО.
Для больших задач — сложные инструменты, для простых — простые.
Для больших задач — сложные инструменты, для простых — простые.
Git поднять просто, даже очень (если только вам не нужен сервер, доступный по ssh, хотя это тоже не высшая математика). Обучиться работе с ним — сложнее, но многие уже и так умеют. Поэтому он и предпочтительнее: с ним зачастую человек уже работал сам, либо имеет под рукой кого‐то, кто работал, а кто сейчас работает с RCS?
Я под такие задачи всегда выбираю mercurial, но в большинстве случаев это просто персональные предпочтения, а не следствие наличия у mercurial какой‐либо отсутствующей у git возможности.
Я под такие задачи всегда выбираю mercurial, но в большинстве случаев это просто персональные предпочтения, а не следствие наличия у mercurial какой‐либо отсутствующей у git возможности.
Кстати, а у RCS есть ветки и слияние?
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.
Как-то не очень решение, как мне кажется, захламлять корень специфичными для гита файлами. Тем более, что ничего не мешает хранить конфиги в отдельной директории, а в корень или ~ кидать симлинки.
Если у вас Gentoo, то определённо есть «обновления» для конфигурационных файлов, складывающиеся в {path}/._cfg{number}_{fname}. Как вы их обрабатываете?
У меня есть отдельная ветка с файлами только по‐умолчанию и ветка с моими изменениями к ним. Всё, что делает portage (._cfg* (правильно переименованное), новые файлы, автоматически изменённые файлы), идёт в первую ветку без каких‐либо изменений. А потом делается слияние.
Относительно корня и /var/lib/portage/world: у меня он перемещён в /etc/portage. Символические ссылки и/или mount -o bind (точнее, соответствующая запись в fstab) позволяют такое проделать со всеми нужными файлами. Не могу сказать, лучше это или хуже вашего варианта, но добавление файлов в вашем варианте определённо проще.
У меня есть отдельная ветка с файлами только по‐умолчанию и ветка с моими изменениями к ним. Всё, что делает portage (._cfg* (правильно переименованное), новые файлы, автоматически изменённые файлы), идёт в первую ветку без каких‐либо изменений. А потом делается слияние.
Относительно корня и /var/lib/portage/world: у меня он перемещён в /etc/portage. Символические ссылки и/или mount -o bind (точнее, соответствующая запись в fstab) позволяют такое проделать со всеми нужными файлами. Не могу сказать, лучше это или хуже вашего варианта, но добавление файлов в вашем варианте определённо проще.
Хм, я никак не ввязываюсь в дела portage и с помощью etc-update мерджу обновления прямо в рабочее дерево. А потом делаю коммит, или несколько, или не делаю, если мне кажется, что даже потеря смердженной версии не будет сильно критична в ближайшем будущем.
Насколько я понимаю, это отличается от отдельной полноценной гитовой ветки только тем, что ветка нетронутых конфигов хранится в виде понятных для etc-update, а не git, файлов.
Насколько я понимаю, это отличается от отдельной полноценной гитовой ветки только тем, что ветка нетронутых конфигов хранится в виде понятных для etc-update, а не git, файлов.
Я тоже не вмешиваюсь в работу portage. Portage не хранит нетронутые файлы, только их контрольные суммы. Соответственно, нет никакой понятной etc-update «ветки нетронутых конфигов» — etc-update работает только с настройками пользователя в /etc и положенными туда ._cfg* файлами. Отсюда никакого автоматического слияния (нет общего предка в виде нетронутого файла). Соответственно, etc-update предлагает слить /etc/conf.d/consolefont каждый раз, когда обновляется openrc и то же самое для других файлов. Поэтому etc-update мною никогда не используется.
Если бы я сделал что‐то с portage, то он бы писал прямо в ветку с нетронутыми файлами. А так я беру и переношу все изменения из /etc в /var/etc-default, делаю commit там, делаю pull в /etc, делаю merge. Требует отсутствия локальных изменений (можно обойти требование, создав третий клон, сделав pull+merge там и pull+update в /etc). Если что, это Mercurial. Git может требовать, а может и не требовать отсутствия локальных изменений — я не помню.
Если бы я сделал что‐то с portage, то он бы писал прямо в ветку с нетронутыми файлами. А так я беру и переношу все изменения из /etc в /var/etc-default, делаю commit там, делаю pull в /etc, делаю merge. Требует отсутствия локальных изменений (можно обойти требование, создав третий клон, сделав pull+merge там и pull+update в /etc). Если что, это Mercurial. Git может требовать, а может и не требовать отсутствия локальных изменений — я не помню.
Собственно, я даже не вижу никакого смысла в использовании git без ветки неизменённых конфигов. Основное преимущество /etc под контролем VCS для меня — это автоматическое слияние, ещё удобна возможность отката. Резервное копирование всё равно необходимо делать отдельно; тем более, что это git (он позволяет переписывать историю, что совершенно недопустимо, если ваша цель — инкрементальное резервное копирование), что вы исключаете из‐под контроля множество существенных файлов (вроде того же /etc/shadow) и что, судя по описанию, репозиторий находится пока только в / (т.е. не предохраняет от повреждения ФС /).
etckeeper?
Удивительно, а ведь это действительно удобно. Спасибо!
Осталось только разобраться с etckeeper
Осталось только разобраться с etckeeper
Что только не придумают, лишь бы бэкапы не делать.
Rsnapshot настраивается за 15 минут.
Rsnapshot настраивается за 15 минут.
Для конфигураций давно придумали инструменты управления конфигурациями
— chef
— ansible
— pupppet
— surf
Если машин мало, то ansible подойдет. Заодно между делом составляется документация и из рецепта\плэйбука будет ясно что зачем когда и почему. Сами рецепты уже хранятся в git.
— chef
— ansible
— pupppet
— surf
Если машин мало, то ansible подойдет. Заодно между делом составляется документация и из рецепта\плэйбука будет ясно что зачем когда и почему. Сами рецепты уже хранятся в git.
UFO just landed and posted this here
Отлично!
А в случае чего легко можно будет перенести на другой хост.
А в случае чего легко можно будет перенести на другой хост.
Класна идея списибо
павда я не админ а програмист потому у меня моного репозиториев на хосте
потому по мотивам
Git Alias — Multiple Commands and Parameters
и
Is there a way to get the git root directory in one command?
сделал в алиасах гита
[alias]
st = !git rev-parse --show-toplevel $1 && git status
павда я не админ а програмист потому у меня моного репозиториев на хосте
потому по мотивам
Git Alias — Multiple Commands and Parameters
и
Is there a way to get the git root directory in one command?
сделал в алиасах гита
[alias]
st = !git rev-parse --show-toplevel $1 && git status
Sign up to leave a comment.
Git в помощь админу локалхоста