среда, 13 мая 2009 г.

Патч 139556-08 - киборг-убийца

"Иногда они возвращаются".

Активно действующие SA знают, что Сан с некоторой степенью периодичности (раз в год-полтора) выпускает ядерные (kernel) патчи-дизастеры, выносящие продуктивные машины на Великий Небесный Сервер.

Обычно удается отделаться легким испугом - либо загрузкой в сэйф-моде и откатом патча с его последующей установкой в сингле, либо (в крайнем случае) стартом системы с внешнего устройства и приведением убитого бут-архива GRUB либо системы в операбельный вид.

Но 139556-08 (и его брат-близнец 139555-08) - это леденящий душу термоядерный вырвиглазный Толстый Полярный Лис.

Забегая вперед, скажу сразу - патч гарантировано убивает системы, стоящие на ZFS. Имеются в виду системы с корневым пулом ZFS.

Никакие разумные меры предосторожности, описанные в patch readme, не помогают. Писец окончательный и бесповоротный, лишь физический бэкап спасет гигантов мысли.

Лис подстерегает всякого, кто ставит на подобные системы патчи в автоматическом режиме, скажем, с использованием pca.

Вы можете сказать "Я не ставлю патчи и мне ничего не грозит", и, возможно, будете даже слегка правы. Однако данный патч относится к разряду critical и security, и, если, скажем, у меня система стоит в злом Интернете, то не патчить ее обойдется мне лично чрезвычайно дорого. Начнем с того, что Nessus отсутствие данного патча определяет практически с момента его выхода, квалифицируя это как серьезную уязвимость. Если вдумчиво почитать описание патча, станет ясно, что песец-то, в общем и без его установки подстерегает. Так что "А придется! - сказала бабка, снимая с плеча ружье".

Однако все по порядку. Намедни у меня погибла одна продуктивная и одна девелоперская система (x86 и x64 соответственно) в результате установки данного патча. Обе системы роднит одно свойство - они обе стояли на полных зеркалах ZFS, обе регулярно обновляются посредством cron и pca на автопилоте.

При этом за пару дней до этого совершенно беспроблемно прошло обновление системы x64, стоящей на ufs (продуктивный сервер, который я предпочел оставить на ufs по причинам графика работы - 24x7x365 и высокой критичности - только это и спасло его от неминуемой гибели, как оказалось в дальнейшем).

Первые признаки не предвещали ничего страшного.

pca благополучно стартовал, выругивался на якобы отсутствующие и жизненно необходимые депенденты для данного патча - SUNWauda (ну очень нужная вещь на сервере, не так ли?), SUNWdoc, SUNWnisu, и SUNWgrubS (исходники GRUB, которые не ставятся по умолчанию в Entire Distribution и по закону подлости находятся на CD 5), затем patchadd делал попытку откатить пачт и собственно патч ложился архивом в каталог, в котором находился pca на момент запуска.

Все остальные патчи накатывались, включая пререквизиты для патча 139556-08, а затем начиналось самое интересное.

Система иногда хотела реконфигурационного ребута и после него вы вылетали в черную консоль с сообщением об отсутствии platform/i86pc/unix или platform/amd64/unix(это уже клиника, принимайте покойницу) либо сыпала жуткой руганью о невозможности загрузки большинства модулей и запуска краеугольного сервиса filesystem/minimal, без которого, разумеется, не стартует ни одна служба кроме шелла.

Все. На этом смерть. Системы не реанимировалась никак. Двое суток реанимационных процедур не привели ни к какому результату.

Что показало вскрытие?

Простая логика и исследование обстоятельств гибели машин привело к следующему выводу.

Сам патч из-за неправильного ремаунта ZFS не полностью ставится и некорректно откатывается. В нем самом ошибка, приводящая к разрушению метаданных ZFS (с высокой вероятностью), а наиболее вероятным претендентом на второй баг является пререквизитный патч 140796-01 (согласно описанию, наиболее вероятная проблема в том, что кто-то физически забыл, что ZFS тоже нужен mount/umount.

Проверено на кошечках - во всех мыслимых вариантах установки, включая честнейший single user (reboot -- -s) после реконфигурационного перезапуска zfs рассыпается вдребезги. Импорты пострадавших пулов дают лишь обломки и три директории верхнего уровня. Работает лишь загрузчик. Никаким образом привести систему без бэкапа в божеский вид
нельзя.

Еще раз - системы, имеющие / на ufs - обновляются со свистом. Либо полный ufs, либо предварительное (со страху) демонтирование не-корневых пулов ZFS - и все проходит на ура. Протестировано на четырех машинах.

Вариант-альтернатива - конверсия посредством LiveUpgrade zfsBE в ufsBE, обновление, обратная конверсия в zfs root pool - как описано здесь и здесь.

Если нет другого диска - соболезнования, придется пройти через процедуру восстановления.

Если нет бэкапа - соболезнования, Песец.

Жизнь после смерти - что делать дальше?

Во втором случае обход был очевиден. Рядом с девелоперской машиной случился JumpStart-сервер. Быстрая установка системы на ufs (пришлось поменять профиль установки), обновление, конвертация Live Upgrade в zfs, зеркалирование, все. Реконструкция завершена.

В первом случае - продуктивная машина - спасло наличие flash-архивов. Создаваемых на регулярной основе посредством вот этого.

Однако все оказалось не настолько просто.

Восстановление с flash-архивов, хоть и быстрое (даже с NFS), в текущем релизе не выполняется на zfs - впрочем, это было лишь на руку.

Последовательность действий оказалась следующая.

1. Восстановление с flash-архива на ufs (на один диск из двух зеркальных).

Замечание: Учтите тот факт, что при восстановлении с flar некоторые данные из /etc не будут восстановлены. В частности, resolv.conf надо будет создавать заново. Все сервисы, минимизированные на момент записи архива, окажутся включенными и запущенными (что в моем случае привело к конфликту портов ssh и OpenSSH). Все остальное в основном восстановилось, по крайней мере, явных недостатков восстановления больше обнаружено не было.

2. Обновление системы на ufs (все еще на одном диске) с накатом киборга-убийцы. Накат выполняется в multi-user, посредством pca, и на грозные ноты в readme можно просто забить. Проблем на ufs нет.

3. Дальше самое интересное. Нам ведь хочется вернуть конфигурацию как было, на зеркалированный root-пул zfs.

Как мы это делаем? Последовательность действий не сработала, и вот почему. После восстановления у LU оказалось достаточно данных, говорящих, что "Я уже и стою на zfsBE".

Соответственно, попытка в лоб повторить действия по миграции с ZFS на UFS обломалась.

Вскрытие показало, что для воспроизведения процедуры 1 и процедуры 2 с чистого листа необходимо тупо удалить файл /etc/lutab и директорию /boot/grub/bootsign на восстановленном руте UFS.

Замечание: Сан запрещает редактирование (и, я так понимаю, любые другие действия над /etc/lutsb) lutab, однако, как и во многих других случаях подобных шаманских плясок в альтернативе лишь перестановка (шучу), а с другой стороны, команду cp никто пока не отменял. Делайте, иначе команды Live Upgrade будут обламываться. А попытки покопаться в /etc/lu не помогут.

После чего вышеописанные процедуры в точности позволили восстановить состояние системы на момент записи архива и на zfs - но уже пропатченой.

Вывод один. Хорошо, что такие устрашающие патчи выходят нечастно. Плохо - в ожидании такого дизастера нужно регулярно делать бэкапы. Хотя это кому как. Хорошая новость - flar можно записать в multi-user, он достаточно целостный для восстановления. Очень плохо - насколько можно судить по Гуглу, эту проблему на сегодня пока никто не обнаружил, включая техподдержку Сан.

Короче говоря, не расслабляйтесь. Надежность компьютерных систем и человеческого фактора, с ними связанного, посейчас не стала лучше. Только регулярные бэкапы и квалификация может спасти гигантов мысли.

PS. Я не хотел писать этой статьи, честно говоря, собирался писать статью совсем о другом предмете, однако 72 часа украденного у меня личного времени на разбор полетов и приведение машин в божеский вид, требуют адекватного воздаяния - хотя бы в виде предупреждения коллегам.