Новость одним абзацем: rescue initrd (специальный комплект из ядра и initrd) теперь автоматически конфигурируется на ipv4/ipv6 адреса, назначенные облачному серверу и автоматически же запускает ssh-сервер после загрузки.
Как это устроено?
Обычно загрузка виртуальной машины выглядит так: с загрузочного диска виртуальной машины (с его загрузочного раздела) читается grub.cfg/grub.lst, из него выбирается ядро и initrd. Domain builder (специальное приложение, которое создаёт домен при старте виртуальной машины, кладёт туда ядро/initrd, фомирует start page с настройками и добавляет памяти) это ядро загружает и запускает домен.
Дальше ядро уже загружается как в обычном сервере — запускается скрипт инициализации в initrd, который подготавливает корневую файловую систему, делает туда pivot_root (переключение корневого каталога) и запускается уже настоящий init, который читает inittab, запускает систему инициализации system-v или upstart, systemd, кому уж что больше нравится.
Если же возникает проблема: не доступна корневая файловая система, подозрение на взлом, исследование какой-либо проблемы, то может возникнуть необходимость в загрузке альтернативного ядра.
В этом случае ядро, вместо того, чтобы читаться с диска гостевой виртуальной машины, берётся из каталога готовых ядер. Оттуда же берётся и initrd. Гостевая машина запускается «как есть».
Всего у нас есть несколько комплектов ядер и initrd — большая часть из них позволяет запускать обычную систему, но есть несколько специфичных initrd, которые делают что-то полезное, оставаясь «вне» операционной системы.
Это:
- Auto PTMAX — специализированный initrd, который автоматически расширяет размер PV, VG и файловой системы root-раздела после изменения размера блочного устройства (увеличения размера диска).
- Auto FSCK — автоматически выполняет проверку файловой системы root-раздела
- Ванильный Linux 3.2 — тестовая версия для проверки работы pv_ops ядер (используйте на свой страх и риск)
- Rescue Initrd — главный герой нашего рассказа
Что умеет rescue initrd?
Подробнее мы про него писали сразу после запуска: habrahabr.ru/company/selectel/blog/122667/
Вкратце:
- Почти полноценный шелл (полный busybox)
- Комплект утилит для починки файловых систем и разделов
- Набор сетевых утилит для диагностики
- ssh-сервер
- Общая среда для комфортной работы (редакторы, утилиты)
- supload (о нём ниже)
Что поменялось?
Теперь rescue initrd сам определяет сетевые настройки. Магии тут никакой — при выставлении аргументов ядра в них дописываются текущие настройки виртуальных машин, а скрипты в initrd получают эти настройки и конфигурируют сеть в соответствии с ними.
Заодно теперь автоматически запускается ssh-сервер.
Есть одна проблема, теоретического решения которой мы не знаем. Это проблема приватного ключа ssh-сервера. Если он поменяется (для того же самого ip-адреса), то ssh-клиент выдаст неприятное предупреждение про «поменявшийся ключ сервера» (а на большинстве ssh-клиентов даже не даст подключиться, пока ключ не будет поменян/удалён в known_hosts).
Вариантов тут несколько:
- Копировать ключ из файловой системы виртуальной машины. Если с файловой системой какие-то проблемы, то её автоматическое монтирование может быть чревато (например, добрый xfs может привести файловую систему в «консистентное» состояние откатив гигов этак сотню записанных данных в момент монтирования). Для rescue образа это не выход.
- Хранить приватный ключ сервера в нашей базе данных. Противоречит идее приватных ключей.
- Задавать «свой» приватный ключ при установке. Аналогично.
Другими словами, никаких красивых решений нет, так что единственным возможным решением будет удалить старый ключ из известных, подключиться, после завершения работы снова удалить запомненный ключ.
… Или просто использовать консоль.
Использование supload
В состав rescue initrd входит скрипт, позволяющий загружать данные на любое swift-хранилище. Например, на наше облачное хранилище.
Выглядит это так:
supload.sh -u пользователь -k пароль контейнер file.tar.gz
В силу того, что проекты хранилища и серверов обладают некоторой автономностью друг от друга, имя пользователя и пароль придётся дописывать вручную. Узнать их можно на странице «настройка доступа» облачного хранилища.
Ближайшие перспективы
Копирование публичного ключа пользователя пользователю root в rescue-initrd. Будет реализовано в ближайшие 1-2 обновления.
Автор: amarao
