Персональные инструменты
Вы здесь: Главная / Заметки на полях / mergemaster
« Март 2024 »
Март
ПнВтСрЧтПтСбВс
123
45678910
11121314151617
18192021222324
25262728293031
 

mergemaster

Mergemaster tips and tricks!

 

При переходе с версии на версию FreeBSD самым неприятным этапом является обновление конфигурационных файлов. mergemaster отнимает массу времени и сил, требует аккуратности и внимательности. Это наверное один из самых неудобных инструментов FreeBSD!
Но на самом деле это не совсем так! Если внимательно изучить, как он работает и разобраться с его ключами, то можно значительно упростить себе жизнь. Не скажу, что обновление станет приятным, но уж оно точно перестанет быть такой головной болью.

Как работает mergemaster

mergemaster – это обычный shell скрипт! Очень длинный, слегка запутанные и требующий неплохого знания программирования на sh (man sh, man test, man mtree вам в помощь!), но все же всего лишь скрипт.
Если очень упрощенно рассказывать, как он работает, то получится примерно такая схема:

  • Из свежих /usr/src собирается новый корень в отдельном каталоге. По умолчанию это /var/tmp/temproot
  • Запускается цикл сравнения всех файлов из нового корня с аналогичными по названию файлами в текущем корне
  • По результатам сравнения принимается решение, что делать с этим файлом

Результатов сравнения может быть не так много:
1) Файл есть в новом корне, но нет в текущем
2) Файлы не отличаются
3) Файлы имеют разный тип (например в текущем корне это линк, а в новом обычный файл
4) Файлы отличаются
Но вот число файлов при проверке исчисляется сотнями.
Если запускать mergemaster с минимальным набором опций и без подготовки, то вся тяжесть выбора ложится на системного администратора. Но выход есть, и есть он в самом mergemaster!
Скрипт имеет несколько механизмов автоматического выбора действия при сравнении.

Механизмы автоматического выбора

  • 1) mtree база данных

Допустим у нас есть конфигурационный файл, который никак не менялся пользователем. Значит его можно спокойно обновить до новой версии, так как никаких правок, специфичных для данного сервера в него не вносилось. Логика простая, но как узнать, что файл не изменился с момента установки системы?
Ответом может стать утилита mtree. При ее помощи можно создать текущий снимок дерева каталогов (права и размер файлов их чексуммы и т.п.). Такую базу данных можно использовать для сравнения с состоянием того же дерева каталогов, но в другой момент времени. mtree покажет, какие файлы изменились.
mergemaster активно использует mtree, и в конце своей работы создает снимок системы. При следующем запуске mergmaster, он вам задаст куда меньше вопросов, чем прошлый раз именно потому, что теперь у него есть база mtree.
Проблема в том, что при установки сервера никто такую базу специально не делает и потому первое обновление будет очень долгим.
Но можно создать такую базу самому, делается это так:

 
mtree -ci -p / -k size,time, md5digest -X /usr/src/exclude.list > /var/db/mergemaster.mtree

/usr/src/exclude.list – это текстовый файл с элементами, которые не стоит включать в базу mtree. Это значительно уменьшает время ее создания и время проверки.

 
cat /usr/src/exclude.list
./usr/src/*
./usr/obj/*
./usr/.snap/*
./jail/*
./usr/ports/*

/var/db/mergemaster.mtree – это путь, где mergemaster будет искать базу данных mtree.
Как mergemaster использует mtree? При запуске скрипт проверяет, есть ли файл mtree. Если он его находит, то сравнивает корень с ним. Получается список измененных файлов.
При сравнении всех файлов из нового корня с текущем, если файл изменился, то проверяется, есть ли этот файл в списке измененных файлов, полученный из mtree. Если в списке его нет, то mergemaster просто заменит файл (нужно указать ключ -U), если файл есть в списке, то будет выведен diff двух файлов и решение об обновлении придется принимать вам.
Но что же делать, если при первой настройке сервера mtree базу данных никто не делал? Ведь если создать ее сразу перед выполнением mergemaster все файлы будут считаться неизмененными? Т.е. с ключом -U mergemaster обновить нам все файлы, даже те, которые мы совсем не хотим обновлять (/etc/group /etc/master.passwd и еще массу полезных файлов)? В общем-то да, так и будет, из обновления систему получится катастрофа, но выход есть в разделе 3) mergemaster.rc и IGNORE_FILES

  • 2) Теги в файлах конфигов

Если выбрать какой-нибудь системный конфиг FreeBSD, то вы сразу заметете в его шапке что-то похожее на:
# $FreeBSD: src/etc/group,v 1.35.8.1 2009/04/15 03:14:26 kensmith Exp $
Это тег файла, при его помощи определяют версию конфига. Но фишка в том, что в файле от релиза к релизу может измениться только сам тег, а конфиг ничем не будет отличаться. Т.е. вполне логично, что если в файле изменился только тег, то стоит его просто заменить. Именно так и работает mergemaster c ключом -F. Всегда ставьте ключ -F при запуске mergemaster!

  • 3) mergemaster.rc и IGNORE_FILES

Было бы здорово заставить mergemaster не проверять какие-то файлы вообще. Например /etc/group или /etc/master.passwd. Видимо такая мысль пришла в голову автора mergemaster и он реализовал ее через переменную IGNORE_FILES. Для хранения таких переменных используется файл /etc/mergemaster.rc. В IGNORE_FILES нужно добавить не такой большой список файлов, но жизнь это упростит значительно:
IGNORE_FILES=’/etc/master.passwd /etc/group /etc/mail/aliases /etc/sysctl.conf /etc/syslog.conf /etc/newsyslog.conf /etc/crontab /etc/login.conf /etc/ssh/sshd_config /root/.cshrc /.cshrc’
Теперь можно смело создавать базу mtree перед запуском mergemaster, все нужные файлы мы “защитили”.
Тут правда есть одна проблема проблема! Мы можем разойтись с новой версией в опциях, которые вообще-то было бы лучше установить. Т.е. нам нужно смерджить эти файлы с новыми конфигами или хотя бы узнать, что в них изменилось. Как подсмотреть, что же изменилось я расскажу в 6) Подсматриваем в /usr/src

  • 4) А если нет такого файла?

Может так случиться, что появится какой-то новый конфигурационный файл, которого в прошлой версии не было. Логично его просто скопировать, а не спрашивать, что же с ним делать у администратора. Именно так и сделает megremaster, если указать ключ -i.

  • 5) На всякий случай все сохраняем

Вообще сохранить конфиги перед тем, как что-то делать с ними – хорошая идея. И эта идея реализована в mergemaster. Если задать ключ -P, то будет создан каталог /var/tmp/mergemaster. В нем можно будет найти копию измененных файлов.

  • 6) Подсматриваем в /usr/src

Нам нужно сравнить текущие файлы, которые мы решили не обновлять и эти же файлы в новой версии. Ничего нет проще! В каталоге /usr/src/etc лежат все конфиги. Например, мы хотим узнать не появилось ли каких-то новых системных пользователей:

 
diff -u /etc/master.passwd /usr/src/etc/master.passwd

Собираем все вместе:
1 ) Создаем /etc/mergemaster.rc со списком IGNORE_FILES
2 ) Создаем базу mtree
3 ) делаем csup
4 ) собираем ядро и мир
5 ) устанавливаем ядро
6 ) запускаем mergemaster -piUP
7 ) устанавливаем мир
8 ) mergemaster -iUFP
9 ) Удаляем старые файлы и либы

 



<make sure you have good level 0 dumps>
make buildworld
make kernel KERNCONF=YOUR_KERNEL_HERE
[1]
<reboot in single user>                         [3]
mergemaster -p                                  [5]
make installworld
make delete-old
mergemaster                                     [4]
<reboot>

<make sure you have good level 0 dumps>        make buildworld        make kernel KERNCONF=YOUR_KERNEL_HERE                                                        [1]        <reboot in single user>                         [3]        mergemaster -p                                  [5]        make installworld        make delete-old        mergemaster                                     [4]        <reboot>

 

 

p.s.

взято отсюда

 http://mysyslog.ru/posts/553

Операции с документом