Solaris

Как вы знаете, традиционно в Solaris следовало оставлять для root'а оболочку /sbin/sh. Делается это в Solaris 8 и Solaris 9 потому, что все библиотеки, которые могут понадобиться для динамической линковки, находятся в /usr/lib, а /usr очень часто может быть отдельной файловой системой, недоступной при аварийной загрузке.

Для того, чтобы избежать невозможности входа в систему суперпользователя, ему назначается оболочка /sbin/sh, которая слинкована статически, т.е. не требует никаких внешних библиотек:



Но знали ли вы, что в Solaris 10 появилось сразу два улучшения ситуации по поводу оболочки для root? Вот они:

1) Теперь библиотеки находятся в /lib, и следовательно всегда оказываются на доступной при аварийной загрузке файловой системе.
Из-за этого, /sbin/sh теперь является обычным динамически исполняемым файлом:



2) Solaris 10 имеет встроенную защиту от неисполняемых оболочек для root. Так что, если при аварийной загрузке ваша нестандартная оболочка не может быть запущена, вам автоматически будет предоставлена стандартная /sbin/sh. Такая же защита существует для команды sudo.

Таким образом, больше нет совершенно никаких препятствий, запрещающих вам поменять стандартную оболочку root на bash или любую другую.

Последние несколько дней устанавливал патчи на нескольких системах, и пришлось раздобыть вот эту старую и проверенную временем таблицу. Она содержит коды ошибок при установке патчей, которые вы обычно видите в виде:
Installation of 'patch_number' failed. Return code N.

Самые распространённые ошибки - 2 и 8, но и остальные тоже попадаются иногда:

Несколько дней отлаживаю установку Solaris 10 на старые sparc-десктопы (Ultra 10, Ultra 60).

И вот, помимо всех прочих ошибок, наткнулся на такую аномалию: вся Jumpstart установка проходит нормально, а в конце установки получаются такие вот ошибки:



После небольшого исследования, выяснилось, что это из-за испорченного miniroot в моём имидже сетевой установки Solaris 10. А ещё спустя некоторое время я выяснил, как именно этот имидж оказался испорченным: он находился в папке /export/vol1/jumpstart/images, которую я предварительно расшарил с помощью share -o rw,anon=0 /export/vol1/jumpstart/images, когда собственно копировал сетевой имидж с той системы, где у меня был доступ к CD-ROM'у, на новый установочный сервер Jumpstart.

После копирования я отвлёкся на что-то, и забыл размонтировать этот ресурс. В результате, когда впоследствии add_install_client попыталась расшарить miniroot, она этого не стала делать, увидев уже существующий ресурс с доступом read/write.

Дальше происходит следующее: первый клиент, который вы устанавливаете с Solaris 10 по сети с такого сервера, пытается обновить файлы вроде /etc/vfstab и /etc/hosts в miniroot. И учитывая ошибку выше, эти файлы и были изменены. Обычный же сценарий таков, что клиент, не сумев обновить файлы на miniroot'е, ищет следующее место, где они могут быть, и в конце концов обновляет файлы /a/etc/vfstab и /a/etc/hosts и .тд.

В результате этой ошибки получается, что в некоторых каталогах miniroot'а оказываются обычные файлы, вместо символических линков. Вот один из примеров:

оригинальный, рабочий каталог /export/vol1/sol10/Solaris_10/Tools/Boot/etc/inet:



... и вот он же, но уже в испорченном после первой же сетевой установки виде:



ОТСЮДА ВЫВОД: будьте бдительны, и всегда проверяйте, что miniroot вашего установочного образа доступен клиентам только для чтения!