Назад | Перейти на главную страницу

Можно ли использовать etckeeper для отслеживания файлов конфигурации вне / etc?

В частности, я хотел бы отслеживать свои grub.conf (/boot/grub/grub.conf) и некоторые файлы Oracle (т.е. /db/app/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora).

Я пытался использовать ссылки; однако etckeeper / git отслеживает только то, на что указывает ссылка, а не фактическое содержимое. И я не могу создавать жесткие ссылки, так как файлы находятся на другом томе.

Я знаю, что могу настроить другой репозиторий GIT, но я бы предпочел, чтобы все это было в etckeeper.

Обновить

Основываясь на ответе nealmcb, я придумал следующий сценарий:

#!/bin/sh
set -e

# Based on nealmcb's idea/script from http://serverfault.com/questions/211425/

# If you want other configuration data or files on the system also
# opportunistically tracked via etckeeper, use this script to copy them in.

# If there is a hook of some sort available related to the files
# you're mirroring, you can call etckeeper directly and track them
# proactively, rather than just opportunistically here.

MIRROR_ROOT=/etc/etckeeper.mirror.d
echo "etckeeper: mirroring outside files to $MIRROR_ROOT/:"

mirror_dir() {
   LOCAL_PATH=$1
   echo "  $LOCAL_PATH"
   mkdir -p $MIRROR_ROOT/$LOCAL_PATH
   rsync -a $LOCAL_PATH/ $MIRROR_ROOT/$LOCAL_PATH
}


mirror_dir "/boot/grub"
mirror_dir "/root"  

Чтобы добавить или удалить путь, просто добавьте или удалите mirror_dir звоните внизу.

Я отредактировал приведенный выше сценарий, чтобы он также включал простые файлы.

может быть, кто-то должен добавить возможность настроить это вне сценария (в конфигурации etckeeper?) и отправить это как патч Joey Hess?

#!/bin/sh
set -e

# Based on nealmcb's + ErebusBat's script from http://serverfault.com/questions/211425/

# If you want other configuration data or files on the system also
# opportunistically tracked via etckeeper, use this script to copy them in.

# If there is a hook of some sort available related to the files
# you're mirroring, you can call etckeeper directly and track them
# proactively, rather than just opportunistically here.

MIRROR_ROOT=/etc/etckeeper.mirror.d
echo "etckeeper: mirroring outside files to $MIRROR_ROOT/:"

mirror_dir() {
   LOCAL_PATH=$1
   echo "  $LOCAL_PATH"
   mkdir -p $MIRROR_ROOT/$LOCAL_PATH
   rsync -a --del $LOCAL_PATH/ $MIRROR_ROOT/$LOCAL_PATH
}

mirror_file() {
   LOCAL_PATH=$1
   DIRPATH=`dirname $LOCAL_PATH | head -n 1`
   echo "  $LOCAL_PATH"
   mkdir -p $MIRROR_ROOT/$DIRPATH
   rsync -a --del $LOCAL_PATH $MIRROR_ROOT/$DIRPATH
}
mirror_file "/var/srv/foo_bar/blog/config.py"
mirror_file "/var/srv/foo_bar_another_host/trac/conf/trac.ini"
mirror_file "/tmp/wildcards/*.jpg"

etckeeper позволяет интегрировать его с другими системами.

Я также хотел отслеживать изменения, внесенные update-grub в / boot, поэтому я поместил код ниже в /etc/etckeeper/commit.d/20mirror-outside-files

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

Я придумал соглашение помещать все это в / etc / Mirror /путь к внешнему файлу, например /etc/Mirror/boot/grub/grub.cfg но если у кого-то есть прецедент для другого такого съезда, я хотел бы услышать об этом.

#!/bin/sh
set -e

# If you want other configuration data or files on the system also
# opportunistically tracked via etckeeper, use this script to copy them in.

# If there is a hook of some sort available related to the files
# you're mirroring, you can call etckeeper directly and track them
# proactively, rather than just opportunistically here.

echo etckeeper: mirroring outside files

mkdir -p /etc/Mirror/boot/grub
cp -p /boot/grub/grub.cfg /etc/Mirror/boot/grub

Обновить:

Обратите внимание, что по какой-то причине etckeeper не запускает это, когда вы выполняете удаление или очистку apt-get, например удалить старое ядро. Странно .... Но ты можешь бежать sudo etckeeper commit вручную в этом случае, или после ручного update-grub.

etckeeper теперь имеет -d возможность указать, в каком каталоге он должен работать.

В то время как хуки для запуска etckeeper обычно используют конструкцию как etckeeper pre-install, ..., вам нужно будет добавить хуки, которые используют etckeeper pre-install -d /boot/grub вместо. Это позволит избежать дублирования файлов в вашем подходе.

Обратите внимание, что если вы считаете, что systemd target, service, ..., файлы являются файлами конфигурации (я считаю - в конце концов, файлы в /lib/systemd не сильно отличаются от файлов в /etc/init.d) тогда это -d опция поможет вам отслеживать, что происходит в /lib/systemd.

Из синопсиса: etckeeper init -d /directory

Но будьте осторожны! в следующий раз, когда вы запустите его, или на следующей неделе, если вы забудете -d path, он может создать новое автономное локальное репо с расположением по умолчанию в /etc.

Поэтому я бы рекомендовал внести эту важную деталь в конфигурацию, в etckeeper.conf. Быстрый, grep /etc \``which etckeeper\``, показывает: ETCKEEPER_DIR=/etc, поэтому просто используйте эту переменную в etckeeper.conf.

sed -i '1 i\ETCKEEPER_DIR=/' /etc/etckeeper/etckeeper.conf

Из желания «сохранить» другие вещи, включая атрибуты файлов, etckeeper init -d / у меня сработало, но потом досадно забыть о деталях. Так что лучше сохранить эту деталь. Также, uninit не отменяет использование VCS, он просто удаляет все локальное репо.

Не думаю, что etckeeper это сделает, но есть несколько решений:

  1. обратные ссылки: поместите ссылку в файловой системе на файл в / etc /

  2. скрипт для копирования этих файлов в / etc (резервное копирование) и из / etc (восстановление). Затем используйте эти сценарии периодически или в соответствующем хуке git.