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

В частности, я хотел бы отслеживать мои grub.conf( /boot/grub/grub.conf) и некоторые файлы оракула (т.е. /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 / path-to-outside-file , например, /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 remove или purge, например, чтобы удалить старое ядро. Странно .... Но вы можете запустить sudo etckeeper commitвручную в этом случае или после ручной update-grub.

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

Хотя хуки для запуска etckeeper обычно используют construct as 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-хуке.