Глава 26 Администрирование зон Solaris (обзор)

В этой главе рассматриваются следующие общие темы, связанные с администрированием зон:

• Новое в этой главе

• Видимость глобальной зоны и доступ к ней

• Видимость идентификатора процесса в зонах

• Возможность наблюдения системы в зонах

• Имя узла неглобальной зоны

• Файловые системы и неглобальные зоны

• Сетевые подключения в неглобальных зонах с общим IP

• Solaris 10 8/07: Сетевые подключения в неглобальных зонах с эксклюзивным IP

• Использование устройств в неглобальных зонах

• Запуск приложений в неглобальных зонах

• Элементы управления ресурсами, используемые в неглобальных зонах

• Планировщик долевого распределения в системе Solaris с установленными зонами

• Расширенный учет в системе Solaris с установленными зонами

• Полномочия в неглобальных зонах

• Использование архитектуры безопасности IP в зонах

• Использование аудита в зонах Solaris

• Файлы дампа оперативной памяти в зонах

• Резервное копирование системы Solaris с установленными зонами

• Определение данных для резервного копирования в неглобальных зонах

• Команды, используемые в системе Solaris с установленными зонами

Информацию по типизированным зонам lx см. Часть III, Типизированные зоны lx.

Новое в этой главе

Solaris 10 1/06: Добавлен новый раздел: Размонтирование файловых систем в зонах.

Solaris 10 1/06: Добавлены новые разделы, посвященные процедурам резервного копирования и восстановления зон. См. Резервное копирование системы Solaris с установленными зонами.

Solaris 10 6/06: В раздел Монтирование файловых систем в зонах добавлен новый пункт о ZFS.

Solaris 10 8/07: В этой версии добавлена или обновлена следующая информация.

• Начиная с этой версии для неглобальных зон доступны два типа IP. Добавлена информация относительно функций, доступных для каждого типа IP. См. Сетевые подключения в неглобальных зонах с общим IP и Solaris 10 8/07: Сетевые подключения в неглобальных зонах с эксклюзивным IP.

• фильтр IP Solaris теперь можно использовать в зонах с общим IP. Для получения дополнительной информации см. Фильтр IP Solaris в зонах с общим IP.

• Пересмотрена информация относительно параметров настройки полномочий в зонах. См. Таблица 26–1.

• Обновлена информация в разделе Команды, используемые в системе Solaris с установленными зонами.

Полный список новых функций Solaris 10 и описание версий Solaris приведены в Solaris 10 What’s New.

Видимость глобальной зоны и доступ к ней

Глобальная зона одновременно является зоной по умолчанию для системы и зоной, которая используется для общесистемного административного управления. Эта двойная роль вызывает ряд административных проблем. Поскольку приложения внутри зоны имеют доступ к процессам и другим системным объектам в других зонах, действия по администрированию могут повлечь за собой неожиданно далеко идущие последствия. Например, в сценариях закрытия системы часто используется команда pkill, передающая процессам с определенным именем сигнал на завершение работы. При запуске такого сценария из глобальной зоны сигнал передается всем соответствующим процессам в системе независимо от их зоны.

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

Таким образом, процессам в глобальной зоне видны процессы и другие объекты в неглобальных зонах. В результате наблюдение за такими процессами может проводиться по всей системе. Возможность контроля процессов в других зонах или отправки им сигналов ограничивается полномочиями PRIV_PROC_ZONE. Эти полномочия аналогичны полномочиям PRIV_PROC_OWNER, поскольку они обеспечивают для процессов возможность переопределения ограничений, наложенных на непривилегированные процессы. В этом случае ограничение состоит в неспособности непривилегированных процессов глобальной зоны передавать сигналы или выполнять управление процессами в других зонах. Это верно даже в случаях, когда идентификаторы пользователей процессов совпадают или действующий процесс имеет полномочия PRIV_PROC_OWNER. Полномочия PRIV_PROC_ZONE можно отозвать для проектов, наделенных другими полномочиями, что позволяет ограничить действия глобальной зоной.

Информацию о сопоставлении процессов с помощью zoneidlist см. на справочных страницах pgrep(1) и pkill(1).

Видимость идентификатора процесса в зонах

Через интерфейсы системных вызовов, принимающие на входе идентификаторы процессов, такие как команды kill и priocntl. Для получения дополнительной информации см. справочные страницы kill(1) и priocntl(1).

Возможность наблюдения системы в зонах

Для команды ps возможны следующие модификации:

• Параметр -o используется для указания формата выходных данных. Этот параметр позволяет вывести идентификатор зоны для процесса или имени зоны, в которой выполняется процесс.

• Параметр -z список_зон используется для вывода списка процессов только в указанных зонах. Зоны указываются либо по имени зоны, либо по идентификатору зоны. Этот параметр имеет смысл, только если команда выполняется в глобальной зоне.

• Параметр -Z используется для вывода имени зоны, связанной с процессом. Имя выводится в столбце с заголовком ZONE.

Для получения дополнительной информации см. справочную страницу ps(1).

К перечисленным ниже средствам Solaris добавлен параметр -z имя_зоны. Этот параметр можно использовать для фильтрации информации только по указанной зоне или по указанным зонам.

• ipcs (см. справочную страницу ipcs(1))

• pgrep (см. справочную страницу pgrep(1))

• ptree (см. справочную страницу proc(1))

• prstat (см. справочную страницу prstat(1M))

Полный список внесенных в команды изменений приведены в Таблица 26–5.

Имя узла неглобальной зоны

Администратором зоны может быть настроено имя узла в файле /etc/nodename, возвращаемое командой uname - n. Имя узла должно быть уникальным.

Файловые системы и неглобальные зоны

В этом разделе содержится информация по вопросам, связанным с файловыми системами в системе Solaris с установленными зонами. Каждой зоне соответствует ее собственный раздел иерархии файловых систем, имеющий корень в каталоге, называемом корнем (root) зоны. Процессы в зоне имеют доступ только к файлам в части иерархии, расположенной ниже корня зоны. В зоне допускается использование утилиты chroot, но только для ограничения процесса корневым путем внутри зоны. Для получения дополнительной информации о команде chroot см. chroot(1M).

Параметр -o nosuid

Параметр -o nosuid утилиты mount предоставляет следующие функциональные возможности:

• Процессы из двоичного файла setuid, расположенного в файловой системе, которая смонтирована с параметром nosetuid, при выполнении не получают полномочий двоичного файла setuid. Процессы выполняются с полномочиями пользователя, запускающего двоичный файл.

  Например, если пользователь запускает двоичный файл setuid, владельцем которого является root, процессы выполняются с полномочиями этого пользователя.

• Открытие в файловой системе записей, специфичных для устройства, не допускается. Это поведение аналогично указанию параметра nodevices.

Этот параметр зависит от конкретной файловой системы и доступна для всех файловых систем Solaris, которые могут монтироваться средствами mount, в соответствии с описанием на справочной странице mount(1M). В этом руководстве список таких файловых систем приводится в Монтирование файловых систем в зонах. Также дается описание возможностей монтирования. Для получения дополнительной информации о параметре -o nosuid см. "Accessing Network File Systems (Reference)" в руководстве System Administration Guide: Network Services.

Монтирование файловых систем в зонах

При монтировании файловых систем изнутри зоны применяется параметр nodevices. Например, если зоне предоставляется доступ к блочному устройству (/dev/dsk/c0t0d0s7 ) и к устройству без файловой системы (/dev/rdsk/c0t0d0s7), соответствующему файловой системе UFS, при монтировании изнутри зоны эта файловая система автоматически монтируется с параметром nodevices . Это правило не относится к монтируемым системам, указанным в конфигурации zonecfg.

В следующей таблице приводится описание параметров монтирования файловых систем в неглобальных зонах. Процедуры для этих вариантов монтирования приведены в Настройка, проверка и сохранение параметров зоны и Монтирование файловых систем в работающих неглобальных зонах.

В конфигурации также можно указать любой тип файловой системы, не перечисленный в таблице, если для него существует двоичная программа монтирования в каталоге /usr/lib/fstype/mount .

Для получения дополнительной информации см. Настройка зоны, Монтирование файловых систем в работающих неглобальных зонах и справочную страницу mount(1M).

Размонтирование файловых систем в зонах

Возможность демонтирования файловой системы зависит от пользователя, выполнившего начальное монтирование. Если файловая система указана как часть конфигурации зоны командой zonecfg, то эта смонтированная файловая система принадлежит глобальной зоне, и администратор неглобальной зоны не может ее размонтировать. Если файловая система смонтирована изнутри неглобальной зоны, например путем определения точки монтирования в файле зоны /etc/vfstab, администратор неглобальной зоны может размонтировать такую файловую систему.

Ограничения по безопасности и поведение файловой системы

На монтирование некоторых файловых систем изнутри зоны налагаются ограничения по безопасности. Другие файловые системы при монтировании в зоне следуют особой модели поведения. Ниже приводится список измененных файловых систем.

AutoFS

Autofs – клиентская служба, автоматически монтирующая соответствующую файловую систему. Когда клиент предпринимает попытку доступа к файловой системе, которая в текущий момент не смонтирована, вызов перехватывается файловой системой AutoFS, и для монтирования запрашиваемого каталога вызывается automountd. Файловые системы AutoFS, смонтированные внутри зоны, являются локальными по отношению к этой зоне. Доступ к смонтированной файловой системе из других зон, включая глобальную, невозможен. При остановке или перезагрузке файловые системы демонтируются. Для получения дополнительной информации об AutoFS см. раздел How Autofs Works в System Administration Guide: Network Services.

В каждой зоне выполняется собственная копия automountd. Управление автоматическим сопоставлением и тайм-аутами осуществляется администратором зоны. Запуск монтирования в другой зоне путем перекрестного использования точки монтирования AutoFS для неглобальной зоны из глобальной зоны невозможен.

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

MNTFS

MNTFS – виртуальная файловая система, обеспечивающая доступ "только для чтения" к таблице смонтированных файловых систем для локальной системы. Набор файловых систем, выводимых при вызове mnttab изнутри неглобальной зоны, – это набор установленных в зоне файловых систем плюс запись для корня (/) . Для точек монтирования со специальным устройством, которое не доступно изнутри зоны, например /dev/rdsk/c0t0d0s0, устанавливается специальное устройство, идентичное точке монтирования. Все смонтированные файловые системы отображаются в таблице /etc/mnttab глобальной зоны. Для получения дополнительной информации о MNTFS см. раздел Глава 18, Mounting and Unmounting File Systems (Tasks), в System Administration Guide: Devices and File Systems.

NFS

Файловые системы NFS, смонтированные в зоне, являются локальными по отношению к этой зоне. Доступ к смонтированной файловой системе из других зон, включая глобальную, невозможен. При остановке или перезагрузке файловые системы демонтируются.

В соответствии с описанием на справочной странице mount_nfs(1M), сервер NFS не должен предпринимать попытку монтирования собственных файловых систем. Таким образом, в зоне не должна монтироваться файловая система NFS, экспортированная глобальной зоной. Зоны не могут быть серверами NFS. Изнутри зоны смонтированные файловые системы NFS ведут себя так, как будто они смонтированы с параметром nodevices.

Выходные данные команды nfsstat относятся только к той зоне, в которой выполняется эта команда. Например, если команда выполняется в глобальной зоне, выводится информация только о глобальной зоне. Для получения дополнительной информации о команде nfsstat см. nfsstat(1M).

Если какие-либо файлы, открываемые командой zlogin, либо какая-то часть ее адресного пространства находятся в NFS, команда завершается неуспешно. Для получения дополнительной информации см. Команда zlogin.

PROCFS

Файловая система /proc, или PROCFS, накладывает ограничения по видимости процессов и доступу к ним, а также предоставляет информацию о связи процессов с зонами. В /proc видны только процессы в той же самой зоне.

Процессы в глобальной зоне могут наблюдать за процессами и другими объектами в неглобальных зонах. В результате наблюдение за такими процессами может проводиться по всей системе.

Изнутри зоны смонтированные файловые системы procfs ведут себя так, как если бы они были смонтированы с параметром nodevices. Для получения дополнительной информации о procfs см. справочную страницу proc(4).

LOFS

Область действия монтирования через LOFS ограничен той частью файловой системы, которая видна зоне. Следовательно, ограничения по монтированию LOFS в зоне отсутствуют.

UFS, UDFS, PCFS и другие файловые системы на основе хранилища

При настройке командой zonecfg файловых систем на основе хранилища, имеющих двоичный файл fsck, например UFS, администратор зоны должен указать параметр raw. Этот параметр указывает устройство без файловой системы (символьное устройство), например /dev/rdsk/c0t0d0s7 . В ходе работы команды zoneadmd перед установкой файловой системы на устройстве для него автоматически выполняется команда fsck в неинтерактивном режиме только для проверки (fsck -m). Если команда fsck завершается неуспешно, перевод зоны в состояние готовности командой zoneadmd невозможен. Путь, указанный параметром raw, не может быть относительным.

Было бы ошибкой указать для fsck устройство файловой системы, для которой отсутствует двоичный файл fsck в /usr/lib/ тип_файловой_системы/fsck. Также было бы ошибкой не указывать устройство для команды fsck, если для этой файловой системы существует двоичный файл fsck.

Для получения дополнительной информации см. Демон zoneadmd и fsck(1M)

ZFS

Набор данных ZFS можно добавить в неглобальную зону с помощью команды zonecfg с ресурсом add dataset. Набор данных станет видимым и будет смонтирован в неглобальной зоне, но перестанет быть видимым в глобальной зоне. Администратор зоны может создавать и уничтожать файловые системы в рамках этого набора данных, а также изменять свойства набора данных.

Атрибут zoned команды zfs указывает, был ли набор данных добавлен к неглобальной зоне.

# zfs get zoned tank/sales NAME PROPERTY VALUE SOURCE tank/sales zoned on local

Если необходимо совместно использовать набор данных из глобальной зоны, файловую систему ZFS с монтированием LOFS можно добавить командой zonecfg с подкомандой add fs. За установку и управление свойствами набора данных отвечает глобальный администратор.

Для получения дополнительной информации о ZFS см. Глава 10, Расширенное администрирование ZFS, в Руководство по администрированию файловых систем ZFS Solaris.

Неглобальные зоны как клиенты NFS

Зоны могут быть клиентами NFS. Поддерживаются протоколы версии 2, версии 3 и версии 4. Для получения информации относительно этих версий NFS см. раздел Features of the NFS Service в System Administration Guide: Network Services.

Версия по умолчанию – NFS версии 4. Другие версии NFS можно активировать для клиента одним из следующих методов:

• В файле /etc/default/nfs можно задать значение NFS_CLIENT_VERSMAX=число, в результате чего указанная версия будет использоваться для зоны как версия по умолчанию. См. раздел Setting Up NFS Services в System Administration Guide: Network Services. См. также процедуру "Выбор других версий NFS для клиента путем изменения файла /etc/default/nfs " в карте задач.

• Также можно создать монтирование для версии вручную. При использовании этого метода содержимое /etc/default/nfs игнорируется. См. раздел Setting Up NFS Services в System Administration Guide: Network Services. См. также процедуру "Выбор других версий NFS для клиента с помощью командной строки" в карте задач.

Запрет использования команды mknod в зоне

Обратите внимание, что для создания специального файла в неглобальной зоне не допускается использование команды mknod, описанной на справочной странице mknod(1M).

Прохождение файловых систем

Пространство имен файловой системы зоны является подмножеством пространства имен, доступного из глобальной зоны. Прослеживание иерархии файловой системы неглобальной зоны непривилегированными процессами в глобальной зоне предотвращается следующими средствами:

• в качестве владельца родительского каталога зоны указывается root, и правами на чтение, запись и выполнение наделяется только пользователь root;

• Ограничение доступа к каталогам, экспортированным /proc.

Следует отметить, что попытка доступа узлов AutoFS, смонтированных для другой зоны, завершается неуспешно. Глобальный администратор не должен иметь автосопоставлений, передаваемых по наследству в другие зоны.

Ограничение доступа к неглобальной зоне из глобальной зоны

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

Любая команда, допускающая в качестве входного параметра альтернативный корень посредством параметра -R или - b (или аналогичной), не должна использоваться в следующих случаях:

• если команда выполняются в глобальной зоне;

• если альтернативный корень относится к какому-либо корневому пути внутри неглобальной зоны, независимо от того, является ли путь относительным по отношению к глобальной зоне системы, запущенной в настоящий момент, или к глобальной зоне в альтернативном корне.

В качестве примера можно привести параметр -R путь_к_корню утилиты pkgadd, запускаемой из глобальной зоны с корневым путем неглобальной зоны.

Ниже приведен список команд, программ и служебных программ, в которых используется параметр -R с альтернативным корневым путем.

• auditreduce

• bart

• flar

• flarcreate

• installf

• localeadm

• makeuuid

• metaroot

• patchadd

• patchrm

• pkgadd

• pkgadm

• pkgask

• pkgchk

• pkgrm

• prodreg

• removef

• routeadm

• showrev

• syseventadm

Ниже приведен список команд и программ, использующих параметр -b с альтернативным корневым путем.

• add_drv

• pprosetup

• rem_drv

• roleadd

• sysidconfig

• update_drv

• useradd

Сетевые подключения в неглобальных зонах с общим IP

В системе Solaris с установленными зонами возможно взаимодействие зон по сети. Всем зонам соответствуют отдельные привязки, или подключения, и во всех зонах могут выполняться собственные серверные демоны. Эти демоны могут выполнять прослушивание одних и тех же номеров портов без конфликтов. Конфликты разрешаются стеком IP путем рассмотрения IP-адресов для входящих подключений. Зоны идентифицируются по IP-адресам.

Распределение зон с общим IP

Разделение сетевого трафика между зонами реализуется стеком IP системы с поддержкой зон. Приложения, получающие IP-трафик, могут получать только трафик, отправленный в ту же самую зону.

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

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

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

• демон служб Интернет с полным файлом конфигурации (см. справочную страницу inetd(1M));

• sendmail (см. справочную страницу sendmail(1M));

• apache (см. справочную страницу apache(1M)).

Доступ к сети для неглобальных зон ограничен. Стандартные сокетные интерфейсы TCP и UDP доступны, однако сокетные интерфейсы SOCK_RAW ограничиваются протоколом ICMP. Протокол ICMP необходим для обнаружения ошибок сети и составления отчетов по ним, а также для использования команды ping.

Сетевые интерфейсы с общим IP

В каждой неглобальной зоне, для которой требуются сетевые подключения, имеется один или несколько уникальных IP-адресов. Эти адреса связаны с логическими сетевыми интерфейсами, которые можно поместить в зону командой ifconfig. Сетевые интерфейсы зоны, настроенные командой zonecfg, автоматически настраиваются и размещаются в зоне при загрузке. Команда ifconfig может использоваться для добавления или удаления логических интерфейсов в работающей зоне. Только глобальный администратор может изменять конфигурацию интерфейса и сетевые маршруты.

Внутри неглобальной зоны команде ifconfig видимы только интерфейсы этой зоны.

Для получения дополнительной информации см. справочные страницы ifconfig(1M) и if_tcp(7P).

IP-трафик между зонами с общим IP на одной машине

Доставка пакетов между двумя зонами одной машины разрешена только при наличии в таблице переадресации "подходящего маршрута" для адресата и зоны.

Информация для сопоставления реализуется следующим образом:

• Адрес источника пакетов выбирается на выходном интерфейсе, указанном в подходящем маршруте.

• По умолчанию трафик разрешен между двумя зонами, адреса которых находятся в одной подсети. Подходящим маршрутом в этом случае является маршрут интерфейса для подсети.

• Если для данной зоны существует маршрут по умолчанию, где шлюз находится в одной из подсетей зоны, разрешается прохождение трафика из такой зоны во все другие зоны. Подходящим маршрутом в этом случае является маршрут по умолчанию.

• Если существует совпавший маршрут с флагом RTF_REJECT, отправляется сообщение ICMP о недоступности адресата. Если существует совпавший маршрут с флагом RTF_BLACKHOLE, пакеты отклоняются. Для создания маршрутов с этими флагами глобальному администратору необходимо воспользоваться командой route с параметрами, описанными в следующей таблице.

  Модификатор	Флаг	Описание
  -reject	RTF_REJECT	При совпадении выдается сообщение о недоступности ICMP.
  -blackhole	RTF_BLACKHOLE	Отклонение пакетов во время обновлений без уведомления.

  Для получения дополнительной информации см. route(1M)

Фильтр IP Solaris в зонах с общим IP

Фильтр IP Solaris обеспечивает фильтрацию пакетов с сохранением информации о состоянии, а также трансляцию сетевых адресов (NAT). Фильтр пакетов с сохранением информации о состоянии может использоваться для наблюдения за состоянием активных подключений и определения пакетов, пропускаемых через брандмауэр, на основании полученной информации. Фильтр IP Solaris включает в себя фильтрацию пакетов без сохранения информации о состоянии, а также возможность создания адресных пулов и управления ими. Для получения дополнительной информации см. раздел Глава 25, Solaris IP Filter (Overview), в System Administration Guide: IP Services.

Фильтр IP Solaris включается в неглобальных зонах путем включения фильтрации с закольцовыванием в соответствии с описанием в разделе Глава 26, Solaris IP Filter (Tasks), в System Administration Guide: IP Services.

Фильтр IP Solaris разработан на основе программного обеспечения с открытым кодом IP Filter.

Организация резервных каналов IP-сети в зонах с общим IP

Организация резервных каналов IP-сети (IPMP) обеспечивает возможность обнаружения отказов физического интерфейса и прозрачное переключение при отказе сетевого доступа для системы с несколькими интерфейсами на одном IP-канале. IPMP также обеспечивает распределение пакетной нагрузки в системах с несколькими интерфейсами.

Вся настройка сети выполняется в глобальной зоне. IPMP можно настроить в глобальной зоне, а затем распространить функциональные возможности на неглобальные зоны. Подобное распространение достигается путем помещения адреса зоны в группу IPMP при настройке зоны. Затем, если возникает отказ одного из интерфейсов глобальной зоны, будет выполнен перевод адресов неглобальной зоны на другую сетевую плату.

В отдельной неглобальной зоне по команде ifconfig видны только интерфейсы, связанные с этой зоной.

См. Распространение функциональности резервных каналов IP-сети на неглобальные зоны с общим IP. Процедура настройки зон рассматривается в Настройка зоны. Для получения информации относительно функций, компонентов и способов использования IPMP см. раздел Глава 30, Introducing IPMP (Overview), в System Administration Guide: IP Services.

Solaris 10 8/07: Сетевые подключения в неглобальных зонах с эксклюзивным IP

Зона с эксклюзивным IP имеет собственное состояние IP и переменные для настройки. При настройке такой зоны ей присваивается собственный набор каналов передачи данных.

Для получения информации относительно функций, используемых в неглобальной зоне с эксклюзивным IP, см. Solaris 10 8/07: Неглобальные зоны с эксклюзивным IP. Для получения информации относительно настройки переменных IP ndd см. Solaris Tunable Parameters Reference Manual .

Распределение зон с эксклюзивным IP

У зон с эксклюзивными IP раздельные стеки TCP/IP, поэтому разделение затрагивает канальный уровень. Глобальный администратор назначает для зоны с эксклюзивным IP одно или несколько имен каналов передачи данных, которые могут представлять собой NIC или VLAN на NIC. Администратору зоны предоставляется такая же степень гибкости настройки IP для этих каналов передачи данных, как и в глобальной зоне.

Интерфейсы каналов передачи данных с эксклюзивным IP

Отдельное имя канала передачи данных должно быть назначено одной и только одной зоне.

Команда dladm show-link может использоваться для назначения дополнительных каналов передачи данных работающим зонам.

Для получения дополнительной информации см. dladm(1M)

IP-трафик между зонами с эксклюзивным IP на одной машине

Между зонами с эксклюзивным IP не существует внутреннего закольцовывания IP-пакетов. Все пакеты отправляются в канал передачи данных. Как правило, это означает, что пакеты передаются через сетевой интерфейс. Затем такие устройства, как Ethernet-коммутаторы или IP-маршрутизаторы, пересылают пакеты их адресату, который может являться другой зоной на машине отправителя.

Фильтр IP Solaris в зонах с эксклюзивным IP

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

Организация резервных каналов IP-сети в зонах с эксклюзивным IP

Организация резервных каналов IP-сети (IPMP) обеспечивает возможность обнаружения отказов физического интерфейса и прозрачное переключение при отказе сетевого доступа для системы с несколькими интерфейсами на одном IP-канале. IPMP также обеспечивает распределение пакетной нагрузки в системах с несколькими интерфейсами.

Настройка канала передачи данных выполняется в глобальной зоне. Сначала зоне назначается несколько интерфейсов каналов передачи данных с помощью команды zonecfg. Эти множественные интерфейсы канала передачи данных должны быть присоединены к одной IP-подсети. Затем администратором зоны внутри зоны с эксклюзивным IP конфигурируется ICMP.

Использование устройств в неглобальных зонах

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

/dev и пространство имен /devices

В Solaris для работы с /devices используется файловая система devfs, описанная на справочной странице devfs(7FS). Каждый элемент в этом пространстве имен соответствует физическому пути к аппаратному устройству, псевдоустройству или связующему устройству. Пространство имен является отражением дерева устройств. Таким образом, файловая система заполняется иерархией каталогов и специальных файлов устройств.

Иерархия файлов /dev, входящая в настоящий момент в корневую файловую систему (/), состоит из символьных ссылок или логических путей, соответствующих физическим путям в каталоге /devices. Приложения ссылаются на логический путь устройства, содержащийся в /dev. В зоне осуществляется монтирование файловой системы /dev в петлевом режиме только для чтения.

Управление иерархией файлов /dev осуществляется системой, состоящей из компонентов, которые входят в следующий список.

• devfsadm (см. справочную страницу devfsadm(1M))

• syseventd (см. справочную страницу syseventd(1M))

• Библиотека информации об устройствах libdevinfo (см. справочную страницу libdevinfo(3LIB))

• Драйвер devinfo (см. справочную страницу devinfo(7D))

• Диспетчер согласования замены оборудования (RCM) (см. Reconfiguration Coordination Manager (RCM) Script Overview в System Administration Guide: Devices and File Systems)

Подсистемы, использующие пути /devices, не могут работать в неглобальных зонах, если не заданы пути /dev.

Устройства эксклюзивного использования

Может потребоваться назначить некоторые устройства определенным зонам. Разрешение доступа к блочным устройствам непривилегированным пользователям может привести к тому, что с помощью этих устройств можно будет вызвать фатальный сбой системы, сброс шины или другие нежелательные действия. Перед выполнением таких назначений следует учесть следующие аспекты:

• Перед назначением SCSI-накопителя на магнитной ленте отдельной зоне следует ознакомиться со справочной страницей sgen(7D).

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

Администрирование драйверов устройств

Для получения списка загруженных модулей ядра из неглобальной зоны можно воспользоваться командой modinfo, описанной на справочной странице modinfo(1M).

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

• добавление и удаление драйверов;

• явная загрузка и выгрузка модулей ядра;

• инициирование динамической перенастройки (DR);

• использование средств, воздействующих на состояние физической платформы.

Утилиты, не работающие в неглобальных зонах или работающие в измененном виде

Утилиты, не работающие в неглобальных зонах

Следующие утилиты не работают в зонах, поскольку они взаимодействуют с устройствами, обычно недоступными в зонах:

• cdrecord(См. справочную страницу в каталоге/usr/share/man/man1. )

• cdrw(см. справочную страницу cdrw(1)).

• rmformat(см. справочную страницу rmformat(1)).

• add_drv(см. справочную страницуadd_drv(1M)).

• disks (см. справочную страницу disks(1M)).

• prtconf (см. справочную страницу prtconf(1M));

• prtdiag (см. справочную страницу prtdiag(1M)).

• rem_drv(см. справочную страницуrem_drv(1M)).

SPARC: средство, измененное для использования в неглобальных зонах

Средство eeprom может использоваться в зоне для просмотра параметров настройки. Изменение настроек этой утилитой не допускается. Для получения дополнительной информации см. справочные страницы eeprom(1M) и openprom(7D).

Запуск приложений в неглобальных зонах

Как правило, в неглобальных зонах могут выполняться все приложения. Однако следующие типы приложений могут не подходить для данной среды:

• Приложения, использующие привилегированные операции, которые воздействуют на систему в целом. В качестве примеров можно привести операции настройки глобальных системных часов или блокировки физической памяти.

• Немногочисленные приложения, зависящие от определенных устройств, не существующих в неглобальных зонах, например /dev/kmem.

• Приложения, для которых предполагается возможность записи в /usr либо во время работы, либо при установке, применении исправления или обновлении. Это связано с тем, что каталог /usr по умолчанию доступен неглобальным зонам только для чтения. Иногда проблемы, связанные с этим типом приложений, можно устранить без изменения самого приложения.

• В зоне с общим IP – приложения, зависящие от устройств в /dev/ip.

Элементы управления ресурсами, используемые в неглобальных зонах

Для получения дополнительной информации относительно использования функции управления ресурсами в зоне см. также главу, посвященную данной функции, в части 1 настоящего руководства.

Все элементы управления ресурсами и атрибуты, описанные в главах по управлению ресурсами, можно устанавливать в файле /etc/project глобальных и неглобальных зон, в карте NIS или в службе каталога LDAP. Параметры настройки для отдельной зоны воздействуют на только эту зону. Элементы управления для проекта, автономно выполняющегося в разных зонах, можно устанавливать в каждой зоне индивидуально. Например, для проекта A в глобальной зоне может быть задано значение project.cpu-shares=10, в то время как для проекта A в неглобальной зоне может быть задано значение project.cpu-shares=5. В системе может выполняться несколько экземпляров rcapd, если каждый экземпляр работает только в собственной зоне.

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

К неглобальным зонам применяется правило "одна зона – один пул". Ресурсы одного пула могут совместно использоваться несколькими неглобальными зонами. Процессы в глобальной зоне, однако, могут привязываться достаточно привилегированным процессом к любому пулу. Контроллер ресурсов poold функционирует только в глобальной зоне, где ему доступно для работы несколько пулов. Средство poolstat, выполняемое в неглобальной зоне, выводит информацию только о том пуле, который связан с зоной. Команда pooladm, запущенная без аргументов в неглобальной зоне, отображает информацию только о пуле, связанном с зоной.

Элементы управления ресурсами для всей зоны не имеют силы, если они заданы в файле project. Элементы управления ресурсами всей зоны задаются утилитой zonecfg.

Планировщик долевого распределения в системе Solaris с установленными зонами

В этой главе описывается использование планировщика долевого распределения (FSS) в системе с зонами.

Разделение долей FSS в неглобальной зоне

Доли ЦП FSS для зоны являются иерархическими. Доли для глобальной и неглобальных зон задаются глобальным администратором через элемент управления ресурсами всей зоны zone.cpu-shares. Затем в целях дальнейшего подразделения долей, настроенных посредством элемента управления ресурсами всей зоны, для каждого проекта данной зоны можно определить элемент управления ресурсами project.cpu-shares .

Информацию по назначению долей зон командой zonecfg приведены в Установка zone.cpu-shares в глобальной зоне. Для получения дополнительной информации о project.cpu-shares см. Доступные элементы управления ресурсами. Также см. примеры процедур, демонстрирующие способ временной настройки долей в Использование планировщика долевого распределения в системе Solaris с установленными зонами.

Долевой баланс между зонами

Элемент zone.cpu-shares можно использовать для назначения долей FSS в глобальной зоне и в неглобальных зонах. Если FSS является системным планировщиком по умолчанию, и доли не назначены, каждой зоне, в т.ч. глобальной, по умолчанию выделяется одна доля. Если в системе имеется одна неглобальная зона, и этой зоне посредством zone.cpu-shares назначаются две доли, этим значением определяется пропорция процессорных ресурсов, получаемых неглобальной зоной относительно глобальной зоны. Отношение процессорных ресурсов между двумя зонами составляет 2:1.

Расширенный учет в системе Solaris с установленными зонами

При работе в глобальной зоне подсистема расширенного учета выполняет сбор и выдачу информации для всей системы (включая неглобальные зоны). Потребление ресурсов также может задаваться для отдельных зон глобальным администратором.

Подсистема расширенного учета позволяет использовать разные настройки и файлы учета в отдельных зонах для учета на основе задач или процессов. Записи exacct могут маркироваться именем зоны EXD PROC ZONENAME для процессов и именем зоны EXD TASK ZONENAME для задач. Учетные записи записываются в учетные файлы глобальной зоны, а также в учетные файлы отдельных зон. В записях EXD TASK HOSTNAME, EXD PROC HOSTNAME и EXD HOSTNAME вместо имени узла глобальной зоны содержится значение uname -n зоны, в которой выполняется процесс или задача.

Для получения информации об учете потоков IPQoS см. раздел Глава 36, Using Flow Accounting and Statistics Gathering (Tasks), в System Administration Guide: IP Services.

Полномочия в неглобальных зонах

Процессы ограничены подмножеством полномочий. Ограничение полномочий не позволяет зоне выполнять операции, которые могут воздействовать на другие зоны. Набор полномочий ограничивает возможности привилегированных пользователей внутри зоны. Для вывода списка полномочий, доступных внутри зоны, используется средство ppriv.

В следующей таблице приведен список всех полномочий Solaris и статус всех полномочий по отношению к зонам. Дополнительные полномочия не являются частью набора полномочий по умолчанию, однако их можно задать с помощью свойства limitpriv . Требуемые полномочия должны входить в итоговый набор полномочий. Запрещенные полномочия не могут входить в итоговый набор полномочий.

Свойство limitpriv доступно, начиная с Solaris 10 11/06.

В следующей таблице приведен список всех полномочий Solaris Trusted Extensions и статус всех полномочий по отношению к зонам. Дополнительные полномочия не являются частью набора полномочий по умолчанию, однако их можно задать с помощью свойства limitpriv .

Полномочия Solaris Trusted Extensions интерпретируются только в том случае, если для системы настроены Trusted Extensions.

Сведения относительно изменения полномочий в настройке неглобальной зоны приведены в Настройка, проверка и сохранение параметров зоны

Информацию по проверке наборов полномочий приведены в Использование утилиты ppriv. Для получения дополнительной информации о полномочиях см. справочную страницу ppriv(1) и руководство Руководство по системному администрированию: службы безопасности.

Использование архитектуры безопасности IP в зонах

Описание архитектуры безопасности интернет-протокола (IPsec), обеспечивающей защиту IP-датаграмм, приведены в разделе Глава 19, IP Security Architecture (Overview), в System Administration Guide: IP Services. Для автоматического управления требуемыми данными ключей в целях проверки подлинности и шифрования используется протокол обмена ключами через Интернет (IKE).

Для получения дополнительных сведений см. справочные страницы ipsecconf(1M) и ipseckey(1M).

Архитектура безопасности IP в зонах с общим IP

IPsec может использоваться в глобальной зоне. Однако для IPsec в неглобальных зонах недоступен IKE. Поэтому для управления ключами IPsec и политикой для неглобальных зон в глобальной зоне используется протокол обмена ключами через Интернет (IKE). При этом используется адрес источника, соответствующий настраиваемой неглобальной зоне.

Solaris 10 8/07: Архитектура безопасности IP в зонах с эксклюзивным IP

В зонах с эксклюзивным IP может использоваться IPsec.

Использование аудита в зонах Solaris

Описание аудита Solaris приведены в разделе Глава 28, Solaris Auditing (Overview), в System Administration Guide: Security Services. Информацию по особенностям аудита, связанным с зонами, приведены в следующих разделах:

• Глава 29, Planning for Solaris Auditing, в System Administration Guide: Security Services

• Auditing and Solaris Zones в System Administration Guide: Security Services

Запись аудита описывает событие, такое как вход в систему или запись в файл. Запись состоит из маркеров, представляющих собой наборы данных аудита. Маркер zonename позволяет настроить для аудита Solaris идентификацию событий аудита по зонам. Маркер zonename позволяет получать следующую информацию:

• записи аудита, отмеченные именем зоны, для которой сгенерированы эти записи;

• журнал аудита для отдельной зоны, который глобальный администратор может сделать доступным для администратора зоны.

Настройка аудита в глобальной зоне

Настройка журналов аудита Solaris выполняется в глобальной зоне. Политика аудита настраивается в глобальной зоне и применяется в отношении процессов во всех зонах. Записи аудита могут маркироваться именем зоны, в которой произошло событие. Для включения имен зон в записи аудита перед установкой неглобальных зон следует отредактировать файл /etc/security/audit_startup . При выборе имен зон учитывается регистр.

Если в данные аудита глобальной зоны должны включаться записи аудита из всех зон, в файл /etc/security/audit_startup необходимо добавить следующую строку:

/usr/sbin/auditconfig -setpolicy +zonename

Запустите утилиту auditconfig в глобальной зоне от имени глобального администратора:

global# auditconfig -setpolicy +zonename

Для получения дополнительной информации см. справочные страницы audit_startup(1M) и auditconfig(1M) и "Configuring Audit Files (Task Map)" в руководстве Руководство по системному администрированию: службы безопасности.

Настройка характеристик аудита пользователей в неглобальной зоне

При установке неглобальной зоны файлы audit_control и audit_user копируются из глобальной зоны в каталог /etc/security создаваемой зоны. Может потребоваться изменение эти файлов для приведения в соответствие с требованиями зоны по аудиту.

Например, для каждой зоны можно настроить разные правила аудита для разных пользователей. Для вступления в силу различных критериев предварительной выборки для отдельных пользователей необходимо отредактировать оба файла: audit_control и audit_user. Для файла audit_user в неглобальной зоне может также потребоваться правка, отражающая пользовательскую базу зоны. Поскольку аудит пользователей в каждой зоне можно настроить по-разному, файл audit_user может быть пустым.

Для получения дополнительной информации см. справочные страницы audit_control(4) и audit_user(4).

Обеспечение записей аудита для отдельной неглобальной зоны

Классификация записей аудита Solaris по зонам достигается путем добавления маркера zonename в соответствии с описанием в разделе Настройка аудита в глобальной зоне. В таком случае становится возможным сбор записей из разных зон командой auditreduce и создание журналов для отдельных зон.

Для получения дополнительной информации см. справочные страницы audit_startup(1M) и auditreduce(1M).

Файлы дампа оперативной памяти в зонах

Команда coreadm позволяет указать имя и расположение файлов дампа оперативной памяти, генерируемых некорректно завершающимися процессами. Пути файлов дампа оперативной памяти, включающие zonename зоны, в которой выполняется процесс, создаются посредством установки переменной %z. Путь указывается относительно корневого каталога зоны.

Для получения дополнительной информации см. справочные страницы coreadm(1M) и core(4).

Запуск DTrace в неглобальной зоне

В неглобальных зонах могут выполняться программы DTrace, требующие только полномочий dtrace_proc и dtrace_user. Эти полномочия можно добавить к набору полномочий, доступных в неглобальной зоне, с помощью свойства limitpriv команды zonecfg. См. указания в разделе Использование DTrace.

При наличии полномочий dtrace_proc поддерживаются поставщики fasttrap и pid. При наличии полномочий dtrace_user поддерживаются поставщикиprofile и syscall. При этом использование поставщиков и действий DTrace будет ограничено рамками этой зоны.

Для получения дополнительной информации см. также Полномочия в неглобальных зонах.

Резервное копирование системы Solaris с установленными зонами

Резервное копирование можно выполнять как в отдельных неглобальных зонах, так и для всей системы из глобальной зоны.

Резервное копирование петлевых каталогов файловой системы

Поскольку во многих неглобальных зонах имеются файлы, используемые совместно с глобальной зоной посредством монтирования файловых систем в петлевом режиме только для чтения (обычно /usr, /lib, /sbin и /platform), для резервного копирования каталогов lofs следует использовать метод резервного копирования из глобальной зоны.

Не следует выполнять в неглобальных зонах резервное копирование файловых систем lofs, используемых совместно с глобальной зоной. Попытка восстановления файловых систем lofs из неглобальной зоны со стороны неглобального администратора может вызвать серьезные проблемы.

Резервное копирование системы из глобальной зоны

Резервное копирование из глобальной зоны может быть оправданным в следующих случаях:

• Требуется создать резервную копию конфигурации неглобальных зон, а также прикладных данных.

• Главным требованием является возможность восстановления после аварии. Если требуется восстановить всю или почти всю информацию в системе, в том числе корневые файловые системы зон и их данные настойки, а также данные в глобальной зоне, резервное копирование следует выполнять из глобальной зоны.

• Требуется создать резервные копии данных командой ufsdump. Поскольку импорт физического дискового устройства в неглобальную зону приводит к изменению профиля безопасности зоны, команду ufsdump следует выполнять только из глобальной зоны.

• Используется коммерческое программное обеспечение резервного копирования по сети.

  ---

  Примечание –

  Для программного обеспечения резервного копирования по сети следует по мере возможности настроить пропуск всех унаследованных файловых систем lofs. Резервное копирование должно выполняться в период, когда зона и ее приложения не манипулируют резервируемыми данными.

  ---

Резервное копирование отдельных неглобальных зон

Резервное копирование внутри неглобальных зон может быть оправдано в следующих случаях.

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

• Требуется использовать программы, выполняющие пофайловое резервное копирование, например tar или cpio. См. справочные страницы tar(1) и cpio(1).

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

  Если приложение может сделать снимок собственного графика резервного копирования в каждой неглобальной зоне и сохранить эти резервные копии в каталоге, доступном для записи, экспортированном из глобальной зоны, то администратор глобальной зоны сможет использовать эти отдельные резервные копии в рамках стратегии резервного копирования из глобальной зоны.

Определение данных для резервного копирования в неглобальных зонах

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

Резервное копирование только прикладных данных

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

Потребуется определить местоположение файлов приложения. Файлы могут храниться в следующих местах:

• в домашних каталогах пользователей;

• /etc в случае файлов конфигурации;

• /var

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

Общие операции по резервному копированию баз данных

Если прикладные данные базы данных не находятся в ее собственном каталоге, применяются следующие правила:

• Сначала следует убедиться в том, что базы данных находятся в целостном состоянии.

  Базы данных должны находиться в покое, поскольку их внутренние буферы должны быть сохранены на диск. Перед началом резервного копирования из глобальной зоны следует удостовериться в том, что базы данных в неглобальных зонах остановлены.

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

  Этот процесс позволяет свести к минимуму затраченное время для окна резервирования и устранить необходимость в установке клиентов/модулей резервного копирования во всех зонах.

Резервное копирование на ленту

В каждой неглобальной зоне можно создать снимок закрытых файловых систем этой зоны, когда это удобно и когда приложение кратковременно переведено в состояние покоя. Позже из глобальной зоны можно выполнить резервное копирование каждого из снимков и поместить их на ленту после возвращения приложения в рабочее состояние.

Этот метод дает следующие преимущества:

• требуется меньшее количество накопителей на магнитной ленте;

• не требуется координация между неглобальными зонами;

• не требуется назначать устройства непосредственно зонам, что позволяет повысить безопасность;

• как правило, этот метод позволяет выполнять управление системой в пределах глобальной зоны, что предпочтительно.

Восстановление неглобальных зон

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

• конфигурация восстанавливаемой зоны не изменялась со времени резервного копирования;

• глобальная зона не обновлялась, и к ней не применялись исправления со времени между моментом резервного копирования и моментом восстановления.

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

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

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

Команды, используемые в системе Solaris с установленными зонами

Команды, указанные в Таблица 26–3, обеспечивают главный административный интерфейс для зон.

Демон zoneadmd – главный процесс, ответственный за управление виртуальной платформой зоны. Справочная страница демона zoneadmd – zoneadmd(1M). Демон не связан с программным интерфейсом.

Команды в следующей таблице используются для управления демоном ограниченного выделения ресурсов.

Команды, указанные в следующей таблице, были изменены для использования в системе Solaris с установленными зонами. Эти команды снабжены параметрами, которые применяются только в отношении зон или позволяют изменить формат выходных данных. Список команд составлен на основе разделов справочных страниц.