Алексей Федорчук
24 декабря 2008 г
Как я уже неоднократно говорил в предыдущих заметках, OpenSolaris — это вовсе не очередной дистрибутив Linux’а, и даже не следующая по счету BSD-система. Не сказать, что здесь «все не так, ребята» — но и рассчитывать на понимание системы, основываясь на ранее нажитом богачестве знаний, тоже не следует. И это надо четко уяснить до того, как предпринимать какие-либо действия, вредоносные последствия которых будут, возможно, не совсем уж необратимыми, но на их ликвидацию уйдет уйма сил и времени. Особенно существенными, если четкого понимания глубинной сути действий еще нет. А суть многих, казалось бы, обыденных для любой из тех ОС, с которыми мы сталкивались ранее, действий — во многом иная. Что мы скоро увидим на примере банального обновления системы.
Многоскорбный повествователь настоящих заметок не может пока, положа руку на сердце, сказать, что он глубоко проник в суть происходящих в OpenSolaris явлений. Однако за некоторое время общения с этой системой сделал некоторые наблюдения, которыми и хотел бы поделиться с читателями, дабы предостеречь их от весьма тривиальных ошибок.
На мой взгляд, тремя основополагающими понятиями в OpenSolaris являются: образ (Image), стартовая среда (или, как она названа в русском переводе Руководства по быстрому введению в OpenSolaris, среда загрузки — Boot Environment) и роли (Role). Ни одно из них не имеет аналогов ни в одном Linux’е или BSD, а первые два, насколько я понял, ещё не инкорпорированы и в собственно Solaris.
Начнем с первого. Все, что установлено в системе, рассматривается как образы. Образ — это и сама работающая система, и отдельные программные комплексы, связанные между собой зависимостями, и единичные пакеты. Образ можно определить как комплекс взаимосвязанных файлов, каталогов, жестких и символических ссылок и зависимостей. С помощью специального инструментария они сливаются воедино в определенном формате. Образы могут быть
- полными, представляющими собой завершенную систему,
- частичными — наборами, связанными с родительским образом полной системы, и
- пользовательскими — отдельными пакетами, пригодными к автономному перемещению и установке.
Всеми образами управляет IPS (Image Packaging System — Система Упаковки Образов). С помощью специальных инструментов командной строки (команда pkg с рядом субкоманд, по своему поведению похожая на утилиты семейства apt из deb based дистрибутивов Linux’а) или графических фронт-эндов к ним (упоминавшихся ранее Диспетчера обновлений и Диспетчера пакетов) она позволяет создавать образы отдельных пакетов добавлять их к образу системы или удалять их из образа, а также выполнять тотальное обновление образа системы.
Следует подчеркнуть, что IPS является специфическим элементом именно OpenSolaris, разработанным при деятельном участии Яна Мёрдока, создавшего некогда дистрибутив Debian и придумавшего формат deb-пакетов. Поэтому родовые черты сходства между инструментами той и другой систем бросаются в глаза. Хотя внутренне IPS очень далеко отошла от традиционной концепции пакетов, существующей во всех Unix-подобных системах издревле. И тут напрашивается аналогия со столь же радикальной системой PBI из PC-BSD — хотя сходства между ними нет ни в чем, кроме радикализма.
Насколько я знаю, IPS еще не инкорпорирована в собственно ОС Solaris. Там применяются пакеты традиционного для UNIX формата SVR4, для работы с которыми служит столь же консервативное семейство утилит pkgadm — pkgadd, pkgrm и так далее, не только по названию, но и по действию сходное с утилитами группы pkg_add из Slackware или FreeBSD. Эти же утилиты существуют и в OpenSolaris. В последней, наряду с «родными пакетами могут использоваться и пакеты в формате SVR4 (в частности, именно в нем хранятся пакеты в репозиториях Blastwave и SunFreeware). Причем для их установки нет необходимости прибегать к утилитам pkgadm — с этой задачей прекрасно справляется Диспетчер пакетов IPS. Впрочем, до изучения пакетов SVR4 я ещё не добрался — и не уверен, доберусь ли: как я отмечал ранее, это совершенно особая история, требующая осторожного подхода ввиду возможного конфликта зависимостей.
Тотальное обновление образа системы может сопровождаться созданием нового образа или модификацией существующего, причем первый вариант принят по умолчанию при выполнении этой процедуры через графический интерфейс Диспетчера обновлений. Аналогично и добавление новых пакетов может происходить как к существующему образу, так и приводить к созданию образа нового; тут при использовании графического интерфейса Диспетчера пакетов, напротив, по умолчанию модифицируется существующий образ. При действии через утилиты командной строки тот или иной порядок обновления задается опциями соответствующих субкоманд команды pkg.
Таким образом, на одной и той же машине могут одновременно сосуществовать два и более образов цельной системы. Возникает вопрос — каким образом с ними разобраться. И здесь пора перейти ко второму фундаментальному понятию OpenSolaris — средам загрузки и управлению ими.
Для этого вернемся к самому началу — моменту старта системы и появлению меню загрузчика GRUB. В свежеустановленной системе мы увидим там два пункта:
- opensolaris в графическом режиме и
- opensolaris в текстовом режиме загрузки.
Чтобы более не возвращаться к этому вопросу, скажу, что в обоих случаях происходит загрузка одного и того же образа системы, завершающаяся запуском Иксов и авторизацией в графическом режиме через gdm. Разница только в том, что в первом случае мы видим графическую сплэш-картинку, бегунок которой якобы отражает прогресс загрузки системы, а во втором выводятся текстовые сообщения о ее ходе. Собственно загрузка в текстовом режиме (в том числе и однопользовательском) тоже возможна, но об этом как-нибудь в другой раз.
Загрузившись любым образом и попав в рабочее окружение GNOME, мы очень быстро видим всплывающее над значком Диспетчера обновлений (на одной из двух умолчальных гномовских панелей) сообщение, предлагающее выполнить обновление системы. Разумеется, это имеет место быть только в том случае, если при инсталляции была корректно настроена сеть. В противном случае оно появится сразу после победы над сетевым интерфейсом.
Как показала практика, отказываться от этого предложения ни в коем случае не следует. Более того, его не следует и откладывать на потом — даже если, как это было в моем случае, обновлять в сущности и нечего (я устанавливал OpenSolaris через несколько часов после того, как версия 2008.11 стала доступной для скачивания). Напротив, надо незамедлительно щелкнуть на значке Диспетчера обновлений, после чего можно наблюдать список тех образов пакетов, которые можно обновить (рис. 1).
Рис. 1. Предложение диспетчера обновлений
Как видно из рисунка, обновлять мне было нечего. Однако, едва счастливо приобщившись к Интернету, я таки последовал совету Диспетчера и нажал на кнопку Обновить все. И уже на следующем же шаге осознал глубокий смысл этого действия (рис. 2): Диспетчер сделал просто копию текущего образа системы и внес соответствующие изменения в конфигурационный файла GRUB’а. Забегая вперед, скажу, что они выразились в появлении в его меню третьей строки — opensolaris-1, причем она оказалась отмеченной для загрузки по умолчанию. Загрузка предыдущего образа также будет доступной — но при использовании нового старый образ как бы не существует. И наоборот — любые изменения, внесенные в старый образ после его обновления (например, настройки или добавление пакетов) на новом образе никак не отразятся — как будто бы их и не было.
Рис. 2. Сообщение диспетчера обновлений
Впрочем, никаких изменений после завершения процедуры обновления (рис. 3) делать и не следует.
Рис. 3. Ход процедуры создания обновленного образа
Более того, следует, закрыв предварительно Диспетчер обновлений и не производя более никаких действий типа настраивания, подкручивания или инсталлирования, выполнить его последний завет (рис. 4), а именно — немедленно перезагрузиться.
Рис. 4. Последний завет Диспетчера обновлений
Таким образом, мы сохраняем в целости и сохранности образ первозданной системы. Она будет нашей палочкой-выручалочкой на случай, если мы что-то безнадежно напортачим в новом образе (а вероятность этого для начинающего «солнцепоклонника» достаточно велика, будь он хоть трижды гуру в Linux’е или FreeBSD). Всегда есть возможность откатиться назад и начать все с чистого листа.
В дальнейшем целесообразно время от времени выполнять тотальные обновления (даже если обновлять по-прежнему нечего) и создавать слепки новых образов, уже обросших настройками и доустановленным софтом. Возможно, кому-то может пригодиться и возможность создания нескольких рабочих образов под разные задачи — с разными настройками и различными наборами прикладного софта (я такой необходимости пока не ощутил, но потенциальную пользу осознаю).
Созданными посредством Диспетчера обновлений образами загрузки в дальнейшем можно управлять весьма гибким образом: активизировать (то есть делать загружаемыми по умолчанию) одни из них и деактивизировать — иные, создавать новые образы на основе не только текущего образа, но и любого из неактивных, уничтожать те, в которых были допущены критические ошибки или просто ставшие ненужными. Всем этим целям служит утилита beadm, имеющая множество возможностей, которые мы рассмотрим в свое время. Пока же замечу, что управление образами загрузки тесно завязано на файловую систему ZFS (или, правильнее сказать, на файловую среду этого имени), в частности, на ее возможности по созданию снапшотов. И без ZFS она функционировать не может.
Вероятно, именно поэтому система управления образами загрузки — пока столь же уникальная особенность OpenSolaris, как и IPS, и в собственно ОС Solaris, где по умолчанию вроде бы используется файловая система UFS (хотя, разумеется, ZFS доступна — иначе сапожник был бы без сапог), еще не включена. Видимо, разработчики Sun’а последовали мудрому завету старушки из известного анекдота и, в отличие от коммунистов, решили сначала поэкспериментировать на кроликах (то есть на нас, пользователях).
Надо, однако, сразу сказать, что попытка воспользоваться утилитой beadm «в лоб» завершится неудачей: если тотальное обновление образа через Диспетчер оных мы спокойно выполняли от лица обычного пользователя — того самого, аккаунт которого был создан при инсталляции, то запуск утилиты beadm из командной строки терминала вызовет радостное сообщение о недостатке у нас прав для этой операции. Почему?
Чтобы ответить на этот вопрос, обратимся к третьему основополагающему понятию OpenSolaris — ролям. Мы привыкли к тому, что обычный пользователь, чтобы обрести привилегии пользователя «супер» (то есть root’а) может дать команду su с вводом административного пароля или sudo — с указанием пароля своего, пользовательского. Причем если дать эту команду с соответствующими опциями, например, в форме
$ su -
пользователь наследует все переменные окружения администратора, то есть на самом деле становится неотличимым от root’а. Одно из немногих ограничений на получение root’овых полномочий — во FreeBSD или в некоторых дистрибутивах Linux’а (если память не изменяет, Gentoo, CRUX, Arch) для этого пользователь должен быть членом группы wheel; впрочем, это положение по умолчанию нетрудно изменить. И никто ни в Linux’е, ни во FreeBSD не в силах запретить пользователю войти в систему root’ом при первичной авторизации — причем как при консольной авторизации, так и при регистрации через десктоп-менеджеры типа xdm, gdm и kdm. Частые в большинстве дистрибутивов Linux’а ограничения на сей предмет также касаются исключительно настроек последних и легко отменяются (хотя, разгрызи меня гром, как говаривал бригадир Жерар, я не в силах представить себе ситуации, когда запустить Иксы с правами администратора было бы необходимо).
В OpenSolaris на первый взгляд все обстоит точно так же: авторизовавшись в свежеинсталлированной системе обычным юзером и обычным (через gdm) образом, мы можем в командной строке эмулятора терминала дать команду
$ su
и, после ввода пароля администратора (помните, мы его определяли при инсталляции?), увидеть изменение вида приглашения командной строки с $ на # (напоминаю что в качестве регистрационного шелла у нас самый обычный bash с настройками по умолчанию). А если к команде su добавить еще и символ дефиса — то и текущие каталог изменится на /root, в чем легко убедиться командой pwd. И в любом случае мы получаем возможность работать с утилитами типа beadm, требующими административных привилегий.
Однако интересно, что если права суперпользователя получить посредством просто su, то значение переменной USER, как и следовало ожидать, не изменится и будет равно имени пользователя. А вот после команды
$ su -
в ответ на
# echo $USER
последует вовсе не root, как это обычно бывает (по крайней мере, во FreeBSD), а просто пустая строка, как будто бы эта переменная не определена. Так что возможность выполнять административные действия вовсе не значит, что «юзверь дрожащая» отныне «право root’а имеет».
Да и попытка авторизоваться root’ом при регистрации в системе закончится неудачей. И тут уже дело вовсе не в настройках gdm. Просто в OpenSolaris аккаунта суперпользователя на самом деле нет. Не так, как об этом говорят свежеобращенные адепты Ubuntu, где root-аккаунт на самом деле есть, только по умолчанию нет пароля для его авторизации. Тут все с точностью до наоборот: пароль root’а есть, а аккаунта — нет (как тут не вспомнить историю Венечки Ерофеева про вымя и херес.).
Потому что в OpenSolaris root по умолчанию — не нормальный аккаунт, во всех отношениях, кроме прав доступа, практически равноценный любому другому. Это — роль, которую может исполнять тот или иной юзер. Точнее, только тот, у которого соответствующая роль записана в репертуаре, то есть в числе атрибутов его учетной записи, определенных в специальном файле /etc/user_attr. И когда такой пользователь дает команду su и вводит административный пароль, он не меняет идентифкатор пользователя (то есть никакого set UID не происходит, а ангажируется на роль администратора (не путать с министром-администратором в исполнении незабвенного Андрея Миронова).
Роль root’а закреплена за первым любовником… пардон, за первым пользователем, аккаунт которого создан во время первичной инсталляции. Пользователи, чьи аккаунты будут созданы позднее, по умолчанию на нее претендовать не могут. Однако, поскольку первый любовник по совместительству и режиссер театра, он может разрешить играть свою роль какой-нибудь особо способной (или особо приятной инженю). Более того, он может даже снять с этой роли самого себя, подобно герою песни Василь Иваныча Чапаева, навострившего востру саблю…
Частным понятием в ролевом подходе является понятие профиля пользователя. Это — также его атрибут, которому может быть присвоено некоторое значение или набор оных. Профили позволяют пользователю выполнять действия, требующие административных привилегий, но не все, а только те, которые за данным профилем закреплены. Например, устанавливать программное обеспечение, заниматься администрирование web-сервера, и так далее — причем делать это от своего собственного имени, не прибегая ни к каким set UID. Наш первый любовник автоматически получает единственное значение профиля Primary Administrator — именно оно, а не роль root’а, дает ему возможность своими полномочиями выполнять обновление системы и установку пакетов, а также ряд настроечных мероприятий, через графические фронт-энды. Хотя те же действия через утилиты командной строки потребуют от него выхода на сцену в амплуа root’а.
Иными словами, система ролей и профилей действует примерно так же, как команда sudo. С той только разницей, что делает она это не после тщательных и кропотливых настроек, а по умолчанию. Да и использование ее особенностей не только более просто, но и гораздо прозрачнее и понятнее даже для начинающего «солнцепоклонника» — внимание, редкий случай в этой операционной системе! Для полноты картины стоит отметить, что создать нормальный аккаунт root’а в OpenSolaris’е тоже можно, причёс двумя путями: во время инсталляции и позднее, руками. Однако стоит ли? В любом случае, к этой теме мы ещё вернёмся в одной из последующих заметок.
Надеюсь, мне удалось донести до читателя те особенности ОС OpenSolaris, которые представляются наиболее существенными. В последующих заметках я рассчитываю рассказать, как же их можно использовать на практике.