четверг, 22 сентября 2011 г.

Solaris 10 update 10: Second Encounter

После памятного попадалова с версией корневого пула ZFS пришлось ждать обновления update 10 для Solaris 10. 

На удивление, оно вышло весьма скоро. Здесь.

Что ж, обновимся. Наш потерпевший сервер стоит на ZFS, регулярно обновляется, поэтому Live Upgrade должен пройти без проблем. 

Должен? Как бы не так!

Поступаем согласно best practices - обновляем перед началом пакеты Live Upgrade на версию из новой системы. Вот эти:

SUNWlucfg
SUNWlur
SUNWluu
SUNWluzone

Создаем новый BE:

root @ ktulhu / # lucreate -n s10x_u10wos_17b


Как бы не так. Не создается BE. Причем не создается в высшей степени странно. Снапшоты создаются, lustatus показывает, что BE создан, но при его создании вылетает ошибка. Удаление данного ущербного BE не проходит. ludelete не может размонтировать датасеты BE.

Что ж, не на тех напал. Размонтируем датасеты нового BE силовым методом, через zfs umount -f, и удаляем командами zfs destroy -r/-R. Удаляем недоношенный BE.

Много думаем.

Поиск по ошибке ни к чему не приводит, кроме одного маловразумительного сообщения о баге LU. С рекомендацией откатиться на предыдущий номер патча пакетов LU.

Окей. Откатываемся до патченых пакетов update 9.

То же самое.

Окей. Нарушаем все best practices и откатываем пакеты LU на начальный релиз 9/10. Теоретически в 9 случаях из десяти LU с пакетами старого релиза невозможен. Но разве у нас есть выбор?

ВНЕЗАПНО - BE создается:

root @ ktulhu / # lucreate -n s10x_u10wos_17b


Все корректно. Отлично, готовимся к апгрейду нового BE - и не забываем про файл авторегистрации:

root @ ktulhu / # echo "auto_reg=disable" (здесь символ редиректа) /tmp/sysidcfg


Что ж, вперед:

root @ ktulhu / # luupgrade -u -n s10x_u10wos_17b -s /data/stage -k /tmp/sysidcfg

System has findroot enabled GRUB
No entry for BE in GRUB menu
Copying failsafe kernel from media.
62128 blocks
miniroot filesystem is
Mounting miniroot at
INFORMATION: Auto Registration already done for this BE .
Validating the contents of the media .
The media is a standard Solaris media.
The media contains an operating system upgrade image.
The media contains version <10>.
Constructing upgrade profile to use.
Locating the operating system upgrade program.
Checking for existence of previously scheduled Live Upgrade requests.
Creating upgrade profile for BE .
Checking for GRUB menu on ABE .
Saving GRUB menu on ABE .
Checking for x86 boot partition on ABE.
Determining packages to install or upgrade for BE .
Performing the operating system upgrade of the BE .
CAUTION: Interrupting this process may leave the boot environment unstable
or unbootable.
Upgrading Solaris: 100% completed
Installation of the packages from this media is complete.
Restoring GRUB menu on ABE .
Updating package information on boot environment .
Package information successfully updated on boot environment .
Adding operating system patches to the BE .
The operating system patch installation is complete.
ABE boot partition backing deleted.
PBE GRUB has no capability information.
PBE GRUB has no versioning information.
ABE GRUB is newer than PBE GRUB. Updating GRUB.
GRUB update was successfull.
INFORMATION: The file on boot
environment contains a log of the upgrade operation.
INFORMATION: The file on boot
environment contains a log of cleanup operations
required.
WARNING: <22> packages failed to install properly on boot environment .
INFORMATION: The file on
boot environment contains a list of packages that failed
to upgrade or install properly.
INFORMATION: Review the files listed above. Remember that all of the files
are located on boot environment . Before you activate
boot environment , determine if any additional system
maintenance is required or if additional media of the software
distribution must be installed.
The Solaris upgrade of the boot environment is partially complete.
Creating miniroot device
Configuring failsafe for system.
Failsafe configuration is complete.
Installing failsafe
Failsafe install is complete.

root @ ktulhu / # lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
s10x_u9wos_14a yes yes yes no -
s10x_u10wos_17b yes no no yes -

root @ ktulhu / # luactivate s10x_u10wos_17b
System has findroot enabled GRUB
Generating boot-sign, partition and slice information for PBE
A Live Upgrade Sync operation will be performed on startup of boot environment .
WARNING: <22> packages failed to install properly on boot environment .
INFORMATION: on boot
environment contains a list of packages that failed to
upgrade or install properly. Review the file before you reboot the system
to determine if any additional system maintenance is required.

Generating boot-sign for ABE
Saving existing file in top level dataset for BE as //etc/bootsign.prev.
Generating partition and slice information for ABE
Copied boot menu from top level dataset.
Generating multiboot menu entries for PBE.
Generating multiboot menu entries for ABE.
Disabling splashimage
Re-enabling splashimage
No more bootadm entries. Deletion of bootadm entries is complete.
GRUB menu default setting is unaffected
Done eliding bootadm entries.

**********************************************************************

The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.

**********************************************************************

In case of a failure while booting to the target BE, the following process
needs to be followed to fallback to the currently working boot environment:

1. Boot from the Solaris failsafe or boot in Single User mode from Solaris
Install CD or Network.

2. Mount the Parent boot environment root slice to some directory (like
/mnt). You can use the following commands in sequence to mount the BE:

zpool import rpool
zfs inherit -r mountpoint rpool/ROOT/s10x_u9wos_14a
zfs set mountpoint= rpool/ROOT/s10x_u9wos_14a
zfs mount rpool/ROOT/s10x_u9wos_14a

3. Run utility with out any arguments from the Parent boot
environment root slice, as shown below:

/sbin/luactivate

4. luactivate, activates the previous working boot environment and
indicates the result.

5. Exit Single User mode and reboot the machine.

**********************************************************************

Modifying boot archive service
Propagating findroot GRUB for menu conversion.
File propagation successful
File propagation successful
File propagation successful
File propagation successful
Deleting stale GRUB loader from all BEs.
File deletion successful
File deletion successful
File deletion successful
Activation of boot environment successful.
root @ ktulhu / # lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
s10x_u9wos_14a yes yes no no -
s10x_u10wos_17b yes no yes no -

root @ ktulhu / # init 6
propagating updated GRUB menu
Saving existing file in top level dataset for BE as //boot/grub/menu.lst.prev.
File propagation successful
File propagation successful
File propagation successful
File propagation successful


Готово. Готово?

Нет. После перезапуска и активации мы обнаруживаем одну проблему.

Все наши гранты RBAC оказались утеряны. Часть сервисов (не системных) не стартует.

Разбираемся. Все просто -

/etc/security/prof_attr
/etc/security/exec_attr
/etc/user_attr

БЕЗ ПРЕДУПРЕЖДЕНИЯ И СОЗДАНИЯ БЭКАПА заменены дефолтными.

К нашему счастью, весь старый /etc у нас сохранен. Возвращаем в указанные файлы наши изменения (благо, их немного. Я сочувствую тем, у кого много кастомных ролей, профилей и авторизаций и не был сделан бэкап системы перед апгрейдом). Вуаля. Рестарт - и все сервисы взлетают, как им и положено.

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

Просто запомните.

  1. Live Upgrade на update 10 должен выполняться с использованием пакетов начального релиза 9/10.
  2. ПЕРЕД обновлением сохраните ваши конфигурации RBAC.

пятница, 16 сентября 2011 г.

Как удалить 1,5 миллиона файлов?

Вопрос, вынесенный в заголовок, недавно встал во весь рост довольно-таки приличной проблемой. 

Преамбула.

Есть почтовый сервер, который плодит в большом количестве мелкие логи сообщений и событий. Этот сервер установлен на раздел UFS, на котором внезапно кончаются inodes. Задолго до исчерпания, собственно, объема раздела. Как следствие, почтовик перестал нормально функционировать.

Задача - нужно удалить эти полтора миллиона мелких файлов (не более 1-4 Кб) с раздела, дабы сервер мог продолжать свою работу.

Проблема в следующем. Файлы лежат в одной директории. Если вы попытаетесь просто сделать ls - два часа ожидания. Пытаетесь сделать rm -f * из bash - segmentation fault. Пытаетесь сделать то же самое из Борна - too many arguments. Пытаетесь удалить директорию - rm -R - несколько часов ожидания и результат не гарантирован.

Сюрприз - никсы не рассчитаны на такое количество файлов в одной директории. Чтение метаданных занимает циклопическое время. А команды юзерлэнда даже представить не могут, что может столько файлов вообще быть принято к обработке.

Как решить проблему?

На UFS есть трюковый ход. 

unlink имя_директории

Три секунды и все. Директория со всем содержимым удалена, файлов нет, создаем директорию заново и даем на нее прежние права.

ВНИМАНИЕ! Не пытайтесь повторить это дома! В случае ошибки любая директория, включая системную, будет удалена со всем содержимым мгновенно и безвозвратно!

Имейте в виду. Данный прием работает ТОЛЬКО на ufs.

На zfs вы получите сообщение not owner:

root @ ktulhu /data # mkdir test
root @ ktulhu /data # unlink test
unlink: Not owner


Кстати, удаление директории с очень большим количеством файлов будет длительным на zfs тоже, несмотря на кэширование и все остальное. Более того, на zfs, с ее CoW, удаление может замедлиться в еще большей степени при сильном заполнении пула/датасета.

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

вторник, 6 сентября 2011 г.

Если бы строители строили свои дома, как программисты пишут свои программы...

... первый залетевший дятел разрушил бы цивилизацию.

Вот оно и свершилось, мальчики и девочки. Вот тебе раз. Вот тебе два. А вот тебе и три. Как неоднократно было сказано многими людьми, система доверия SSL CA порочна по сути. Стоит скомпрометировать один CA - и вся система в коллапсе. Последняя новость особенно леденящая душу.

Ну, где же CPS* DigiNotar? В котором написано английским по-белому - "Мамой клянусь, базовая инфраструктура PKI отделена от Интернета воздушным промежутком!"? Где эти писульки всех остальных CA, затронутых инцидентом?
_________________________________
* CPS - Certificate Policy and Certification Practice Statement

Насколько я помню, невозможно было стать CA/RA без выполнения ряда жесточайших условий, проверяемых рядом независимых аудитов, что никакое действие с приватным ключом CA невозможно выполнить менее, чем двумя людьми (separation of duty) и без полного журналирования действий, включая видеоконтроль, записи которого должны храниться три года, что ведутся логи всего и вся, что эти логи хранятся три и более года. Что проводятся периодические аудиты на соответствие высокому званию CA, что, в случае обнаружения несоответствий, удостоверяющий центр лишается права выдачи сертификатов. И многое-многое другое, масса красивых слов, декларируемых на бумажке, именуемой CPS, которые выложены на главных страницах CA и, самое главное, свято принимаемыми на веру всеми потребителями ЭЦП, увероваших в непогрешимость CA почти как в бога.

Где все эти меры? Хакнули CA - и все тут. Теперь вперед, отзови-ка все дерево сертификатов. Посредством CRL объемом этак гигабайт в сто. И, главное - сделайте это оперативно, ок? OCSP так и не заработал, и повсеместной практикой не стал.

Гром-то не гремел ни разу серьезно. До недавнего времени. Когда SSL стал мэйнстримом (слово-то какое отвратительное, суется где надо и где не надо). Кстати, в непогрешимом Линуксе тоже десятками посыпались критичные баги, едва он вылез в мэйнстрим, но это уже отдельная голубая печаль.

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

А к тому, что нам предлагают как панацею от Каминского и Ко DNSSEC. Который - ВНЕЗАПНО! - базируется не на чем ином, как на SSL. 

Ага. Снова CA, RA, деревья доверия. Доверия кому? CA? CPS? "Мамой клянемся, что свято выполняем заветы Брюса Шнайера и у нас мышь не проползет"?

Причем - что самое характерное - никто не понял, что Пушистый Пушной Зверек, собственно, уже подкрался. Что скомпрометированы все смежные технологии, прямо или косвенно использующие SSL - например, SSH. Что под фактическим ударом оказались все интернет-банкинги, гнущие пальцы, что "ваши транзакции надежно защищены".  Что коллапс деревьев доверия начался и лавину не остановить. Что надо запасаться попкорном и ждать следующей серии инцидентов с причинением ущерба в крупном и особо крупном размере.

Я не буду повторяться, цитировать Брюса или Ричарда. Незачем. Понимающему и так достаточно.

Я лишь хочу сказать снова и снова - понятия "безопасность" и "доверие" ортогональны. Хотите вы этого, или нет.