Чи може 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?) та надіслати це як патч Джої Хессу?

#!/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 дозволяє вам інтегрувати його в інші системи.

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

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

Я вигадав умову, щоб помістити цей матеріал під / etc / Mirror / file-to-out-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 чи очищення, наприклад для видалення старого ядра. Незвичайно .... Але ви можете запускати sudo etckeeper commitвручну в тому випадку або після посібника update-grub.

Тепер у etckeeper є -dможливість вказати, в якому каталозі він повинен працювати.

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

Зауважте, що якщо ви вважаєте, що системні цілі, сервіс, ..., файли є файлами конфігурації (я - зрештою, файли під /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 (відновлення). Потім використовуйте ці сценарії періодично або у відповідному гачку.