Удаленный бинарное обновление 4.11 до 6.2-RELEASE
Eugene Grosbein
без доступа с консоли с двумя перезагрузками и
минимальным 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
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
EG> Удаленный бинарное обновление 4.11 до 6.2-RELEASE,
EG> без доступа с консоли с двумя перезагрузками и
EG> минимальным downtime, безопасное настолько, насколько
EG> это возможно при обновлении "по месту".
Теоретически возможно обновление любой версии FreeBSD на любую версию
FreeBSD с нуля с удалением всех ранее существующих данных и с
переразбиением дисков, но без доступа с консоли? Пусть даже существует
вероятность того, что новая система не заработает на старом железе. В
этом случае допустима потеря сервера и как следствие - проведение работ,
требующих физического доступа к серверу.
--
Best regards, Vadim.
Eugene Grosbein
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
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
VG> А если все будет делать скрипт? Т.е. сам переразбивать и форматировать
VG> диски указанным заранее способом, приносить систему с какого-нибудь ftp,
VG> где уже есть базовая конфигурация с необходимыми логинами в /etc/passwd,
VG> затем ребутить сервер. С точки зрения пользователя это будет выглядеть
VG> так:
VG> 1. Запустить скрипт на произвольном сервере.
VG> 2. Подождать.
VG> 3. Залогиниться на сервер, а там уже новая версия системы без всяких
VG> следов от старой.
VG> 4. Залить полезный софт.
VG> Такое реально?
Вполне.
Eugene
--
А если не будут брать, отключим газ.
Spartak Radchenko
VG>
VG> Теоретически возможно обновление любой версии FreeBSD на любую версию
VG> FreeBSD с нуля с удалением всех ранее существующих данных и с
VG> переразбиением дисков, но без доступа с консоли? Пусть даже существует
VG> вероятность того, что новая система не заработает на старом железе. В
VG> этом случае допустима потеря сервера и как следствие - проведение работ,
VG> требующих физического доступа к серверу.
Возможно, тебе подойдёт депингвинатор.
http://www.daemonology.net/depenguinator/
Сам я его не пробовал.
--
Spartak Radchenko SVR1-RIPE