Удаленный бинарное обновление 4.11 до 6.2-RELEASE

39 views
Skip to first unread message

Eugene Grosbein

unread,
Jul 28, 2007, 3:34:56 PM7/28/07
to
Удаленный бинарное обновление 4.11 до 6.2-RELEASE,
без доступа с консоли с двумя перезагрузками и
минимальным downtime, безопасное настолько, насколько
это возможно при обновлении "по месту".

Требуется доступность первого инсталляционного CD
из дистрибутива 6.2-RELEASE, либо нужно будет
скачать с десяток мегабайт из него для пункта 3 ниже.

1. Подготовить новое содержимое для /boot

Скопировать с дистрибутивного CD 6.2-RELEASE
каталог boot в /boot6, loader.conf оставить старый
(если дистрибутив машине недоступен, сначала скачать
/boot с него по сети в каталог /cdrom/boot):

cd /
CDROM=/cdrom
cp -r $CDROM/boot boot6
cd boot6
mv loader.conf loader.conf6
cp ../boot/loader.conf . || true
mv kernel kernel6
mkdir kernel
ln ../kernel kernel

2. Меняем местами старый и новый loader:

cd ..
mv boot boot4
mv boot6 boot

Теперь у нас новый loader, который грузит старое ядро
из файла /boot/kernel/kernel (это хардлинк на /kernel),
и старые модули из /modules. Система пока работает по-старому,
при перезагрузке ничего не поломается.

3. Подготовка mfsroot.

Если дистрибутива на четверке нет, этот пункт можно полностью
выполнять на другой машине, и готовый mfsroot.gz (5.5Mb)
потом скачать в /boot/mfsroot.gz. Если выполняется на свежей
FreeBSD, заменить vnconfig на mdconfig и disklabel
на bsdlabel (убрать слово auto):

TMPDIR=/var/tmp # можно и другое место
cd $TMPDIR

# быстрый и простой способ требует mfsroot на 14Mb
# создаём файл образа на основе такого же
# из дистрибутива
dd if=/dev/zero of=mfsroot bs=1m count=14
dev=vn0c
vnconfig -c -s labels $dev mfsroot
disklabel -w -B -b $CDROM/boot/boot $dev auto
newfs -m 0 -o space -b 4096 -f 512 $dev

# Монтируем оригинальный и новый mfsroot
mkdir /mnt/omfs /mnt/mfs
gzcat $CDROM/boot/mfsroot.gz > mfsroot.orig
odev=vn1c
vnconfig -c -s labels $odev mfsroot.orig
mount -o ro /dev/$odev /mnt/omfs
mount /dev/$dev /mnt/mfs

# Для начала копируем оригинальный в новый
cd /mnt/omfs
tar -cf - * | tar -C /mnt/mfs -xf -

# Оригинальный mfsroot больше не нужен
cd /mnt/mfs
umount /mnt/omfs
vnconfig -d $odev
rm $TMPDIR/mfsroot.orig

# Затачиваем новый mfsroot под неинтерактивную загрузку
rm -r etc bin sbin var stand/etc stand/help
ln -s stand bin
ln -s stand sbin
mkdir -p tmp

# В тестовой системе /usr и /var - отдельные от рута fs,
# при промежуточной загрузке будут смонтированы так:
# /mnt - рут
# /mnt/usr - /usr
# /mnt/var - /var
# Таким образом, chroot /mnt при желании
# после загрузки даст нам оригинальный расклад
# и позволит воспользоваться новым sysinstall-ом
ln -s mnt/usr usr
ln -s mnt/var var

# Hовые бинарники используются новым ядром
# при загрузке с md0
cd $CDROM
# игнорировать ошибки касательно "File exists"
tar cf - bin etc lib libexec sbin | tar -C /mnt/mfs -xkf -

# Минимально необходимый набор файлов со старой системы для успешного
удаленного
# входа в систему; nsswitch.conf берем с новой системы
cd /etc
cp -rp fstab host.conf rc.conf ssh passwd group master.passwd pwd.db spwd.db
/mnt/mfs/etc
cat <<EON > /mnt/mfs/nsswitch.conf
group: files
hosts: files dns
networks: files
passwd: files
shells: files
EON

Теперь нужно привести /mnt/mfs/etc/fstab к примерно следующему виду:
# Device Mountpoint FStype Options Dump Pass#
/dev/md0 / ufs rw 1 1
/dev/ad0s1b none swap sw 0 0
/dev/ad0s1a /mnt ufs rw 2 2
/dev/ad0s1f /mnt/usr ufs rw 2 2
/dev/ad0s1e /mnt/var ufs rw 2 2

Первая строка обязательно такая, остальные - из оригинального fstab,
точку монтирования для рута заменяем на /mnt,
/usr и /var тоже смещаем внутрь /mnt, остальные файловые системы
(если есть) намеренно не упоминаем.

В /mnt/mfs/etc/fstab желательно отключить все сервисы, кроме
sshd и каналообразующих (учитывать, что грузиться будет GENERIC),
что-то типа этого:

ifconfig_rl0="inet x.x.x.x netmask 255.255.255.0"
hostname="host.domain.ru"
sendmail_enable="NONE"
firewall_enable="NO"
inetd_enable="NO"
sshd_enable="YES"
fsck_y_enable="YES"
background_fsck="NO"
# EOF

Закрываем и запаковываем mfsroot:

cd $TMPDIR
umount /mnt/mfs
vnconfig -d $dev
gzip -1 < mfsroot > /boot/mfsroot.gz

4. Подгрузка полученного mfsroot:

cd /boot
cat loader.conf6 >> loader.conf

Это добавляет в loader.conf следующие команды:

mfsroot_load="YES"

mfsroot_type="mfs_root"

mfsroot_name="/boot/mfsroot"

Hа работу четвертой версии не влияет никак, пока по-прежнему
используется старая корневая файловая система, только увеличивается
размер оперативной памяти, зарезервированной ядром. Hа машине с 48M памяти
изменение составило те самые 14M, avail memory вместо 44316K стала 30140K.

5. Решающий момент. Для загрузки нового ядра с новым рутом посредством
nextboot:

cat <<EOF > nextboot.conf
nextboot_enable="YES"
kernel="kernel6"
vfs.root.mountfrom="ufs:md0"
EOF

Если новое ядро, скажем, зависнет на этапе определения оборудования
до перехода в multiuser, достаточно дернуть питание и машина
загрузит старое ядро и четвертую версию и у вас есть возможность
спокойно разобраться, система тем временем работает. При следующей
попытке этот пункт нужно повторить, nextboot.conf будет удалён
при перезагрузке.

При использовании cut-n-paste команд из этого пункта проверьте,
что в конце строк nextboot.conf нет лишних пробелов - загрузчик
этого не любит и может проигнорировать конфигурацию nextboot.

Перезагружаемся!

6. При успешной загрузке запускается старый /usr/sbin/sshd,
через него заходим в систему. Авторизация через keyboard-interactive
не срабатывает, зато срабатывает через password, то есть в систему
пустит после четвертой попытки набора пароля. Эту косметическую
проблему править не стал, всё равно на это один только раз
наталкиваемся.

Переименовываем /mnt/stand в /mnt/stand4,
создаём новый /mnt/stand, копируем /stand/sysinstall в
/mnt/stand/sysinstall, делаем chroot /mnt.

7. Это - точка, после которой нет возврата, кроме восстановления
из бекапа с консоли. Сейчас пока можно ещё перегрузиться обратно
в четверку и работать по-старому. Дальше уже нет.

# если не сделать этой правки loader.conf, система не поднимется
echo 'kernel="GENERIC"' >> /boot/loader.conf
/stand/sysinstall

Выбираем Upgrade. Я делал бинарное обновление по FTP,
из дистрибьюшнов ставил только base и kernels (меню Custom).
Во время обновления в терминал выдавалось куча мусора от распаковщика,
но это косметическое неудобство. Апгрейд прошел совершенно
гладко, система перезагрузилась уже в шестерку с винта
и доступна (теперь уже через свежий) sshd.

Убираем строки mfsroot_* из /boot/loader.conf
Hе забываем разгрести /etc/upgrade или сделать
обновление из исходников, mergemaster позаботится о /etc.
В любом случае перезагружаемся опять, теперь уже
это будет не из mfsroot.

Eugene
--
Господа Действительного Положения Вещей предохраняют себя от голода своим
богатством, от общественного мнения - тайной и анонимностью,
от частной критики - законами против клеветы и тем, что средства связи
находятся в их распоряжении. (Hорберт Винер)

Eugene Grosbein

unread,
Jul 28, 2007, 3:40:34 PM7/28/07
to
29 июл 2007, воскресенье, в 00:34 KRAST, Eugene Grosbein написал(а):

EG> # Минимально необходимый набор файлов со старой системы для успешного
EG> удаленного
EG> # входа в систему; nsswitch.conf берем с новой системы
EG> cd /etc
EG> cp -rp fstab host.conf rc.conf ssh passwd group master.passwd pwd.db
EG> spwd.db /mnt/mfs/etc
EG> cat <<EON > /mnt/mfs/nsswitch.conf

Очепятка: > /mnt/mfs/etc/nsswitch.conf

EG> group: files
EG> hosts: files dns
EG> networks: files
EG> passwd: files
EG> shells: files
EG> EON

Хотя, судя по всему, генерацию nsswitch.conf можно вообще
опустить: шестерка, обнаружив его отсутствие, генерирует
его сама.

Eugene
--
Как ни отмывай задний проход, он не станет глазом. (Дхарма)

Vadim Guchenko

unread,
Aug 8, 2007, 6:54:28 AM8/8/07
to

EG> Удаленный бинарное обновление 4.11 до 6.2-RELEASE,
EG> без доступа с консоли с двумя перезагрузками и
EG> минимальным downtime, безопасное настолько, насколько
EG> это возможно при обновлении "по месту".

Теоретически возможно обновление любой версии FreeBSD на любую версию
FreeBSD с нуля с удалением всех ранее существующих данных и с
переразбиением дисков, но без доступа с консоли? Пусть даже существует
вероятность того, что новая система не заработает на старом железе. В
этом случае допустима потеря сервера и как следствие - проведение работ,
требующих физического доступа к серверу.

--
Best regards, Vadim.

Eugene Grosbein

unread,
Aug 8, 2007, 10:14:43 AM8/8/07
to
08 авг 2007, среда, в 13:54 KRAST, Vadim Guchenko написал(а):

EG>> Удаленный бинарное обновление 4.11 до 6.2-RELEASE,
EG>> без доступа с консоли с двумя перезагрузками и
EG>> минимальным downtime, безопасное настолько, насколько
EG>> это возможно при обновлении "по месту".

VG> Теоретически возможно обновление любой версии FreeBSD на любую версию
VG> FreeBSD с нуля с удалением всех ранее существующих данных и с
VG> переразбиением дисков, но без доступа с консоли? Пусть даже существует
VG> вероятность того, что новая система не заработает на старом железе. В
VG> этом случае допустима потеря сервера и как следствие - проведение работ,
VG> требующих физического доступа к серверу.

Рассматриваемый метод теоретически это позволяет, потому что рутовая
файловая система (содержащая необходимий минимум /usr в себе) монтируется
из жатого образа, загруженного полностью в память. Старые файловые системы
можно сносить в такой конфигурации. Только придется sshd либо telnetd
поднимать из нового кода, а в моей инструкции они используются со старого
носителя.

Eugene
--
Choose no family

Vadim Guchenko

unread,
Aug 8, 2007, 7:59:34 AM8/8/07
to

EG> Рассматриваемый метод теоретически это позволяет, потому что
EG> рутовая
EG> файловая система (содержащая необходимий минимум /usr в себе)
EG> монтируется
EG> из жатого образа, загруженного полностью в память. Старые
EG> файловые системы
EG> можно сносить в такой конфигурации. Только придется sshd либо
EG> telnetd
EG> поднимать из нового кода, а в моей инструкции они используются
EG> со старого
EG> носителя.

А если все будет делать скрипт? Т.е. сам переразбивать и форматировать
диски указанным заранее способом, приносить систему с какого-нибудь ftp,
где уже есть базовая конфигурация с необходимыми логинами в /etc/passwd,
затем ребутить сервер. С точки зрения пользователя это будет выглядеть
так:

1. Запустить скрипт на произвольном сервере.
2. Подождать.
3. Залогиниться на сервер, а там уже новая версия системы без всяких
следов от старой.
4. Залить полезный софт.

Такое реально?


--
Best regards, Vadim.

Eugene Grosbein

unread,
Aug 8, 2007, 11:19:16 AM8/8/07
to
08 авг 2007, среда, в 14:59 KRAST, Vadim Guchenko написал(а):

VG> А если все будет делать скрипт? Т.е. сам переразбивать и форматировать
VG> диски указанным заранее способом, приносить систему с какого-нибудь ftp,
VG> где уже есть базовая конфигурация с необходимыми логинами в /etc/passwd,
VG> затем ребутить сервер. С точки зрения пользователя это будет выглядеть
VG> так:
VG> 1. Запустить скрипт на произвольном сервере.
VG> 2. Подождать.
VG> 3. Залогиниться на сервер, а там уже новая версия системы без всяких
VG> следов от старой.
VG> 4. Залить полезный софт.
VG> Такое реально?

Вполне.

Eugene
--
А если не будут брать, отключим газ.

Spartak Radchenko

unread,
Aug 9, 2007, 7:26:49 AM8/9/07
to
Vadim Guchenko <y...@rambler-co.ru> wrote:
VG>
VG> Теоретически возможно обновление любой версии FreeBSD на любую версию
VG> FreeBSD с нуля с удалением всех ранее существующих данных и с
VG> переразбиением дисков, но без доступа с консоли? Пусть даже существует
VG> вероятность того, что новая система не заработает на старом железе. В
VG> этом случае допустима потеря сервера и как следствие - проведение работ,
VG> требующих физического доступа к серверу.

Возможно, тебе подойдёт депингвинатор.

http://www.daemonology.net/depenguinator/

Сам я его не пробовал.

--
Spartak Radchenko SVR1-RIPE

Reply all
Reply to author
Forward
0 new messages