В этом разделе описываются дополнительные сценарии установки пакетов. С помощью команды pkgadd автоматически выполняются все действия, необходимые для установки пакета, с использованием информационных файлов в качестве входных данных. Предоставлять сценарии установки пакета нет необходимости. Однако если для пакета требуется создать специальные процедуры установки, это можно сделать с помощью сценариев установки. Сценарии установки:
Должны выполняться в интерпретаторе команд sh
Должны содержать команды интерпретатора sh и текст
Могут не содержать идентификатор интерпретатора команд #!/bin/sh
Не обязательно должны быть исполняемым файлом
Выполнять пользовательские действия можно при помощи четырех типов сценариев установки:
Сценарий request запрашивает данные у администратора, выполняющего установку пакета, с целью изменения или назначения переменных среды.
Сценарий checkinstall осуществляет проверку целевого компьютера на необходимые данные, может устанавливать или изменять переменные среды пакета и определять, можно ли продолжать процесс установки.
Сценарий checkinstall доступен начиная с выпуска Solaris 2.5 и совместимых выпусков.
Процедурные сценарии определяют процедуру, которая будет вызвана перед или после удаления или установки пакета. Четыре процедурных сценария - это preinstall, postinstall, preremove и postremove.
Сценарии действий над классами
Сценарии действия над классами определяют действие или набор действий, которые должны применяться к классу или файлам во время установки или удаления. Можно определить свои собственные классы. Кроме того, можно также использовать один из четырех стандартных классов (sed, awk, build и preserve).
Тип используемых сценариев зависит от того, в какой момент процесса установки необходимо действие над классом. После установки пакета с помощью команды pkgadd выполняются следующие действия.
Выполняется сценарий request
Пакет может запросить данные от администратора, который выполняет установку, только во время этого действия.
Выполняется сценарий checkinstall
Сценарий checkinstall производит сбор данных о файловой системе и может создавать или изменять переменные среды для управления последующей установкой. Для получения дополнительной информации о переменных среды пакета см. раздел Переменные среды пакета.
Выполняется установка объектов пакета для каждого устанавливаемого класса.
Установка этих файлов производится по классам. Сценарии действий над классами выполняются соответствующим образом. Список классов, над которыми выполняется действие, и порядок их установки изначально определяется с помощью параметра CLASSES в файле pkginfo. Однако сценарий request или checkinstall может изменять значение параметра CLASSES. Для получения дополнительной информации об обработки классов во время установки см. раздел Обработка классов во время установки пакета.
Выполняется создание символьных ссылок, устройств, именованных каналов и необходимых каталогов.
Выполняется установка стандартных файлов (типы файлов e, v, f) на основе их классов
Сценарий действия над классом разрешает установку только обычных файлов. Все другие объекты пакета создаются автоматически на основе информации в файле pkgmap.
Создаются все жесткие ссылки.
При удалении пакета команда pkgrm выполняет следующие действия:
Выполняется удаление объектов пакета для каждого класса
Удаление также производится по классам. Обработка сценариев удаления производится в порядке, обратному порядку установки, на основе последовательности, определенной в параметре CLASSES. Для получения дополнительной информации об обработки классов во время установки см. раздел Обработка классов во время установки пакета.
Выполняется удаление жестких ссылок.
Выполняется удаление стандартных файлов.
Выполняется удаление символических ссылок, устройств и именованных каналов.
Обработка сценария request во время удаления пакета не производится. Однако результат выполнения сценария сохраняется в установленном пакете и предоставляется для сценариев удаления. Результат выполнения сценария request - это список переменных среды.
Для всех сценариев установки доступны следующие группы переменных среды. Некоторые из переменных среды можно изменить с помощью сценария request или сценария checkinstall.
Сценарий request или сценарий checkinstall может установить или изменить любой из стандартных параметров в файле pkginfo, за исключением необходимых параметров. Параметры стандартной установки подробно описаныя на справочной странице pkginfo(4).
Параметр BASEDIR можно изменить только в выпусках начиная с Solaris 2.5, а также в совместимых выпусках.
Можно определить собственные переменные среды установки путем установки значений в файле pkginfo. Эти переменные среды должны быть указаны алфавитно-цифровыми символами. Первый символ должен быть заглавным. Любая из переменных среды может быть изменена с помощью сценария request или checkinstall.
Оба сценария - request и checkinstall - могут определять новые переменные среды путем установки данных и помещения в среду установки.
В следующей таблице перечислены переменные среды, которые доступны для сценариев установки в среде. Ни одна из этих переменных не может быть изменена в ходе выполнения сценария.
Переменная среды |
Описание |
---|---|
CLIENT_BASEDIR |
Основной каталог по отношению к целевому компьютеру. Переменная BASEDIR используется при ссылке на определенный объект из устанавливающей системы (обычно это сервер), а CLIENT_BASEDIR - это путь, включающий файлы, которые будут размещены на клиентской системе. Параметр CLIENT_BASEDIR существует при наличии параметра BASEDIR и полностью идентичен параметру BASEDIR при отсутствии параметра PKG_INSTALL_ROOT. |
INST_DATADIR |
Каталог находится в том расположении, где производится чтение пакета. Если чтение пакета производится с ленты, эта переменная будет иметь значение расположения временного каталога, куда пакет переносится в формате каталога. Другими словами, в предположении, что расширения имени пакета не существует (например, SUNWstuff.d), сценарий request для пакета можно найти в местоположении $INST_DATADIR/$PKG/install. |
PATH |
Для поиска команд при вызове сценария интерпретатор sh использует список поиска. Параметр PATH обычно имеет следующий формат: /sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin. |
PKGINST |
Идентификатор экземпляра устанавливаемого пакета. Если другое экземпляр пакета не установлен, это значение является сокращенным именем (аббревиатурой) пакета (например,SUNWcadap). В противном случае это значение является аббревиатурой пакета с добавлением суффикса, например SUNWcadap.4. |
PKGSAV |
Каталог, в которым могут сохраняться файлы для использования сценариями удаления, или где можно найти файлы, сохраненные ранее. Доступы только в выпуске Solaris 2.5 и совместимых выпусках. |
PKG_CLIENT_OS |
Операционная система клиента, в которую устанавливается пакет. Значение переменной - Solaris. |
PKG_CLIENT_VERSION |
Версия ОС Solaris в формате x.y. |
PKG_CLIENT_REVISION |
Версия сборки ОС Solaris. |
PKG_INSTALL_ROOT |
Корневая файловая система на целевом компьютере, куда производится установка пакета. Эта переменная существует, только если производился вызов команд pkgadd и pkgrm с параметром -R. Это условное наличие облегчает использование в процедурных сценариях в форме ${PKG_INSTALL_ROOT}/некий_путь. |
PKG_NO_UNIFIED |
Переменная среды, которая получает значение при вызове команд pkgadd и pkgrm с помощью параметров -M и -R. Эта переменная среды используется для сценариев установки или команд пакета, которые являются частью переменой пакета. |
UPDATE |
Эта переменная среды не существует в большинстве сред установки. Если эта переменная существует (со значением yes), это может означать одно из следующего: Наличие установленного пакета с тем же именем, версией и архитектурой. Пакет устанавливается с замещением установленного пакета с тем же именем по требованию администратора. В этих случаях всегда используется основной каталог. |
Для получения информации о пакете можно использовать две команды:
Команда pkginfo возвращает информацию о пакетах приложения, например, идентификатор экземпляра и имя пакета.
Команда pkgparam возвращает значения для запрошенных переменных среды.
Для получения дополнительной информации см. справочную страницу pkginfo(1), справочную страницу pkgparam(1) и Глава 4Проверка и запись пакета.
Каждый сценарий должен завершать работу с использованием кодов выхода, перечисленных в таблице ниже.
Таблица 3–2 Коды выхода сценария установки
Код |
Описание |
---|---|
0 |
Успешное выполнение сценария. |
1 |
Неустранимый сбой. При этом производится прерывание процесса установки. |
2 |
Предупреждение или состояние возможной ошибки. Процесс установки продолжается. По завершении установки показывается сообщение с предупреждением. |
3 |
Выполнение команды pkgadd останавливается. Это код возвращается только сценарием checkinstall. |
10 |
По завершении установки всех пакетов необходимо перезагрузить компьютер. (Это значение должно быть добавлено к одному из одноразрядных числовых кодов выхода.) |
20 |
По завершении установки текущего пакета следует немедленно перезагрузить компьютер. (Это значение должно быть добавлено к одному из одноразрядных числовых кодов выхода.) |
Примеры кодов выхода, возвращаемых сценариями установки, приведены в Глава 5Практические примеры создания пакета.
Все включенные в пакет сценарии установки должны иметь записи в файле prototype. Файл должен иметь тип i (для сценария установки пакета).
Сценарий request представляет собой единственный способ взаимодействия администратора с устанавливаемым пакетом. Это сценарий можно использовать, например, чтобы предоставить администратору возможность выбора установки дополнительных компонентов пакета.
Результат выполнения сценария request должен представлять собой список переменных и их значений. В этот список могут входить любые параметры, созданные в файле pkginfo, а также параметры CLASSES и BASEDIR. В этом списке могут быть указаны переменные среды, которые не назначены в других компонентах. Однако файл pkginfo должен всегда содержать умолчания значений (когда это практически необходимо). Для получения дополнительной информации о переменных среды пакета см. раздел Переменные среды пакета.
Когда сценарий request производит назначение значений для переменной, они должны быть предоставлены для использования командой pkgadd и других сценариев установки.
Сценарий request не может изменять файлы. Этот сценарий только позволяет осуществлять взаимодействие с администратором, осуществляющим установку, и создавать список значений переменных среды на основе результатов этого взаимодействия. Сценарий request выполняется от имени непривилегированного пользователя install, если такой пользователь существует. В противном случае сценарий выполняется от имени пользователя root.
С помощью команды pkgadd производится вызов сценария request с одним аргументом, который указывает имя файла ответов для сценария. В файле ответов хранятся ответы администратора.
При удалении пакета сценарий request не выполняется. Однако назначенные сценарием переменные среды сохраняются и доступны при удалении пакета.
Для каждого пакета может существовать только один сценарий request. Этот сценарий должен иметь имя request.
В среду установки также необходимо добавить значения переменных среды для использования командой pkgadd и других сценариев пакета, добавив их в файл ответов (который сценарий опознает как $1).
Переменные среды системы и стандартные переменные среды установки (за исключением параметров CLASSES и BASEDIR) невозможно изменить с помощью сценария request. Можно изменить все остальные созданные переменные среды.
Сценарий request может изменить только параметр BASEDIR, начиная с ОС Solaris 2.5 и совместимых выпусков.
Каждой переменной среды, с которая может работать сценарий request, в файле pkginfo должно быть присвоено значение по умолчанию.
Формат выходного списка должен быть следующим: PARAM=value. Пример:
CLASSES=none class1 |
В качестве стандартного вход для сценария request определен терминал администратора.
Не выполняйте какого-либо специального анализа целевого компьютера с помощью сценария request. Проверять компьютер на наличие определенных файлов или поведения, а также устанавливать переменные среды на основе такого анализа рискованно. Гарантий, что сценарий request будет выполняться в момент установки пакета, не существует. Администратор, который выполняет установку пакета, может предоставить файл ответов, который произведет вставку переменных среды даже без вызова сценария request. Если сценарий request также производит оценку целевой файловой системы, эта оценка может быть не произведена. Анализ целевого компьютера для специальной обработки лучше оставить сценарию checkinstall.
Если администратор, который будет устанавливать пакет, использует решение JumpStartTM, то установка пакета не должна осуществляться в интерактивном режиме. Необходимо или не предоставлять для своего пакета сценарий request, или сообщать администраторам, чтобы до установки пакета они использовали команду pkgask. Команда pkgask сохраняет ответы администраторов в сценарийrequest. Для получения дополнительных сведений о команде pkgask см. справочную страницу pkgask(1M).
Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.
Создайте файл request с помощью любого текстового редактора.
По завершении сохраните изменения и закройте редактор.
Выполните одну из следующих задач.
Если необходимо создать дополнительные сценарии установки, перейдите к следующей задаче, Сбор данных о файловой системе.
Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.
Если файл prototype уже создан, измените его, добавив запись для созданного сценария установки.
Выполните сборку пакета.
В случае необходимости см. главу Как собрать пакет.
Когда сценарий request присваивает значения переменным среды, они должны быть доступны для команды pkgadd. В примере ниже показан сегмент сценария request, который выполняет эту задачу для четырех переменных среды: CLASSES, NCMPBIN, EMACS и NCMPMAN. Предположим, что эти переменные были определены во время интерактивного сеанса сценария ранее.
# make environment variables available to installation # service and any other packaging script we might have cat >$1 <<! CLASSES=$CLASSES NCMPBIN=$NCMPBIN EMACS=$EMACS NCMPMAN=$NCMPMAN ! |
После сборки пакета установите его для подтверждения правильности выполнения установки и проверьте его целостность. В Глава 4Проверка и запись пакета содержатся пояснения по этим задачам и поэтапные указания по записи проверенного пакета на распространяемый носитель.
Сценарий checkinstall выполняется вскоре после необязательного сценария request. Сценарий checkinstall выполняется от имени пользователя install, если такой существует, или от имени пользователя nobody. Сценарийcheckinstall не имеет полномочий на изменение данных файловой системы. Однако в зависимости от собранной информации сценарий может создавать или изменять переменные среды для контроля за ходом итоговой установки. Сценарий также может безопасно остановить процесс установки.
Сценарий checkinstall предназначен для выполнения основной проверки файловой системы, которая будет стандартной для выполнения команды pkgadd. Например, этот сценарий может использоваться для предварительной проверки возможности перезаписи существующих файлов или управления общими зависимостями программ. Файл depend производит управление только зависимостями на уровне пакета.
В отличие от сценария request, сценарий checkinstall выполняется вне зависимости от наличия файла с результатами выполнения. Наличие сценария не позволяет считать пакет интерактивным. Сценарий checkinstall можно использовать, если сценарий request запрещен или взаимодействие с администраторам нецелесообразно.
Сценарий checkinstall доступен, начиная с Solaris 2.5 и совместимых выпусков.
Сценарий checkinstall не может изменять файлы. Этот сценарий только проводит анализ состояния системы и создание списка значений переменных среды на основе этого действия. Для принудительного выполнения этого ограничения сценарий checkinstall выполняется от имени непривилегированного пользователя install (если этот пользователь существует). В противном случае сценарий выполняется от имени непривилегированного пользователя nobody. Сценарий checkinstall не имеет полномочий суперпользователя.
Команда pkgadd производит вызов сценария checkinstall с использованием одного аргумента, содержащего информацию файла ответов сценария. Файл с результатами выполнения сценария - это файл, где хранятся данные выбора администратора.
Сценарий checkinstall не выполняется при удалении пакета. Однако назначенные сценарием переменные среды сохраняются и доступны при удалении пакета.
Для каждого пакета может использоваться только один сценарий checkinstall. Сценарий должен иметь имя checkinstall.
В среду установки также необходимо добавить значения переменных среды для использования командой pkgadd и других сценариев пакета, добавив их в файл ответов (который сценарий опознает как $1).
Переменные системной среды и переменные стандартной установки, за исключением параметров CLASSES и BASEDIR, невозможно изменить с помощью сценария checkinstall. Можно изменить все остальные созданные переменные.
Каждая переменная среды, которая может управляться сценарием checkinstall должна иметь значение умолчания, назначенное в файле pkginfo.
Список результирующих параметров должен иметь следующий формат PARAM=value. Пример:
CLASSES=none class1 |
Во время выполнения сценария checkinstall взаимодействие с администратором не осуществляется. Все взаимодействие с оператором ограничивается сценарием request.
Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.
С помощью любого текстового редактора создайте файл с именем checkinstall.
По завершении сохраните изменения и закройте редактор.
Выполните одну из следующих задач.
Если необходимо создать дополнительные сценарии установки, перейдите к следующей задаче: Создание процедурных сценариев .
Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.
Если файл prototype уже создан, измените его, добавив запись для созданного сценария установки.
Выполните сборку пакета.
В случае необходимости см. главу Как собрать пакет.
В этом примере сценария checkinstall производится проверка, установлено ли требуемое для пакета SUNWcadap ПО базы данных.
# checkinstall script for SUNWcadap # # This confirms the existence of the required specU database # First find which database package has been installed. pkginfo -q SUNWspcdA # try the older one if [ $? -ne 0 ]; then pkginfo -q SUNWspcdB # now the latest if [ $? -ne 0 ]; then # oops echo "No database package can be found. Please install the" echo "SpecU database package and try this installation again." exit 3 # Suspend else DBBASE="`pkgparam SUNWsbcdB BASEDIR`/db" # new DB software fi else DBBASE="`pkgparam SUNWspcdA BASEDIR`/db" # old DB software fi # Now look for the database file we will need for this installation if [ $DBBASE/specUlatte ]; then exit 0 # all OK else echo "No database file can be found. Please create the database" echo "using your installed specU software and try this" echo "installation again." exit 3 # Suspend fi |
После сборки пакета установите его для подтверждения правильности выполнения установки и проверьте его целостность. В Глава 4Проверка и запись пакета содержатся пояснения по этим задачам и поэтапные указания по записи проверенного пакета на распространяемый носитель.
Процедурные сценарии позволяют установить набор инструкций, которые выполняются в конкретные моменты при установке или удалении пакета. Каждый из четырех процедурных сценариев должен иметь одно из четырех заранее определенных имен в зависимости от выполняемых инструкций. Сценарии выполняются без аргументов.
Выполняется перед запуском установки класса. При выполнении этого сценария установка файлов не производится.
Выполняется после установки всех томов.
Выполняется перед запуском удаления класса. При выполнении этого сценария удаление файлов не производится.
Выполняется после удаления всех классов.
Процедурные сценарии выполняются от имени uid=root и gid=other.
Каждый сценарий должен выполняться неоднократно, поскольку он выполняется по одному разу на каждый том пакета. Это означает, что выполнение сценария неограниченное количество раз с одними вводными данными позволяет получить те же результаты, что и при однократном выполнении.
Каждый процедурный сценарий, который выполняет установку объектов пакета не в файл pkgmap, должен использовать команду installf, чтобы передать сведения в БД пакета об изменении или добавлении путевого имени. По завершении внесения всех изменений или добавлений следует вызвать эту команду с параметром -f. Таким способом устанавливать объекты пакета могут только сценарии postinstall и postremove. Для получения дополнительной информации см. справочную страницу installf(1M) и Глава 5Практические примеры создания пакета.
При выполнении процедурных сценариев взаимодействие с администратором не допускается. Все взаимодействие с оператором ограничивается сценарием request.
Каждый процедурный сценарий, который производит удаление файлов, не имеющих записи в файле pkgmap, должен использовать команду removef для передачи данных в БД пакета о том, что он не производит удаление путевого имени. По завершении удаления следует вызвать эту команду с параметром -f. Более подробная информация и примеры приведены на справочной странице removef(1M) и в Глава 5Практические примеры создания пакета.
Команды installf и removef использовать не следует, поскольку процедурные сценарии не связываются автоматически с путевыми именами, указанными в файле pkgmap.
Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.
Создайте один или более процедурный сценарий с помощью любого текстового редактора.
Процедурный сценарий должен иметь одно из ранее определенных имен: preinstall, postinstall, preremove или postremove.
Сохраните изменения и выйдите из редактора.
Выполните одну из следующих задач.
Если необходимо создать сценарии действий над классами, перейдите к следующей задаче: Создание сценариев действий над классом.
Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.
Если файл prototype уже создан, измените его, добавив запись для каждого созданного сценария установки.
Выполните сборку пакета.
В случае необходимости см. главу Как собрать пакет.
После сборки пакета установите его для подтверждения правильности выполнения установки и проверьте его целостность. В Глава 4Проверка и запись пакета содержатся пояснения по этим задачам и поэтапные указания по записи проверенного пакета на распространяемый носитель.
Классы объектов позволяют выполнять серию действий над группой объектов пакета при установке или удалении. Назначение объектов классу производится в файле prototype. Все объекты пакета должны иметь определенный класс, а для объектов, не требующих специального действия, по умолчанию используется класс none.
Параметр установки CLASSES, назначенный в файле pkginfo представляет собой список устанавливаемых классов (включая класс none).
Объекты, определенные в файле pkgmap, которые принадлежат классу, не указанному в этом параметре в файле pkginfo, установлены не будут.
Порядок установки определяется списком CLASSES. Класс none, если он имеется, всегда устанавливается первым и удаляется последним. Поскольку каталоги являются основной структурой поддержки для всех других объектов файловой системы, они должны иметь класс none. Возможны исключения, однако, как правило, класс none является самым безопасным. Эта стратегия позволяет обеспечить создание каталогов до объектов, которые в них будут содержаться. Кроме того, каталоги удаляться не будут до тех пор, пока не будут удалены содержащиеся в них объекты.
Ниже приведено описание действий системы при установке класса. Эти действия повторяются для каждого тома пакета во время его установки.
Команда pkgadd позволяет создать список путевых имен.
С помощью команды pkgadd производится создание списка путевых имен, над которыми производит действие сценарий. В каждой строке этого списка указывается исходный и целевой пути, разделенные пробелом. Исходный путь указывает, где в установочном томе расположен устанавливаемый объект . Целевой путь указывает местоположение в целевой системе, куда будет устанавливаться объект. Содержимое списка ограничивается следующими критериями.
В списке содержатся только путевые имена, принадлежащие связанному классу.
При сбое создания объекта пакета каталоги, именованные каналы, символьные устройства, блочные устройства и символические ссылки включаются в список с исходными путевым именем, равным /dev/null. Обычно эти элементы автоматически создаются с помощью команды pkgadd (если еще не существуют) и наделяются правильными атрибутами (режим, владелец, группа) согласно определению в файле pkgmap.
В список ни в коем случае не включаются связанные файлы типа l. Жесткие ссылки в данном классе создаются в элементе 4.
Если для установки конкретного класса не предоставлен сценарий действия над классом, путевые имена в создаваемом списке копируются из тома в соответствующее целевое местоположение.
Выполняется сценарий действия над классом (если существует).
При вызове сценария действия над классом на его стандартный вход подается список, созданный в элементе 1. Если этот том является последним томом пакета или при отсутствии других объектов в этом классе сценарий выполняется с единственным аргументом ENDOFCLASS.
Даже если в пакете больше нет обычных файлов этого класса, производится вызов сценария действия над классом как минимум один раз с пустым списком и аргументом ENDOFCLASS.
Командаpkgadd осуществляет аудит содержимого и атрибутов, а также создание жестких ссылок.
После успешного выполнения элемента 2 или 3 команда pkgadd производит аудит содержимого и информации атрибутов для списка путевых имен. Команда pkgadd автоматически создает ссылки, связанные с классом. Обнаруженные несовпадения атрибутов в созданном списке исправляются для всех путевых имен.
Объекты удаляются по классам. Сначала удаляются классы, существующие для пакетов, однако не перечисленные в параметре CLASSES (например, объект, установленный с помощью команды installf). Классы, указанные в параметре CLASSES, удаляются в обратном порядке. Класс none всегда удаляется в последнюю очередь. Ниже описаны действия, которые производятся в системе при удалении класса.
Создание списка путевых имен с помощью команды pkgrm.
Производится создание списка установленных путевых имен, принадлежащих указанному классу, с помощью команды pkgrm. Путевые имена, на которые ссылается другой пакет, из этого списка исключаются, если они не принадлежат к типу e. Тип файлов e означает, что по установки или удалении файл должен быть изменен.
Если удаляемый пакет произвел изменение каких-либо файлов типа e во время установки, то при удалении производится удаление только добавленных строк. Не удаляйте непустой редактируемый файл. Удалите строки, которые были добавлены пакетом.
Если сценария действия над классом не существует, производится удаление путевых имен.
Если в пакете отсутствуют сценарии действий над классами для этого класса, производится удаление всех путевых имен в списке, созданном с помощью команды pkgrm.
Файлам, принадлежащим к типу e (редактируемые), не назначается класс и связанный с ним сценарий действия над классом. Эти файлы удаляются в данный момент, даже если их путевые имена используются другими пакетами.
Если сценарий действия над классом уже существует, производится выполнение сценария.
Командаpkgrm производит вызов сценария действия над классом, на стандартный вход которого подается список, созданный в элементе 1.
Командаpkgrm выполняет аудит.
После успешного выполнения сценария действия над классом команда pkgrm производит удаление ссылок на путевые имена из БД пакета, если на них нет ссылок других пакетов.
Сценарий действия над классом определяет набор действия для выполнения при установке или удалении пакета. Действия выполняются над группой путевых имен в зависимости от их определения класса. Примеры сценариев действий над классами приведены в Глава 5Практические примеры создания пакета.
Имя сценария действия над классом основывается на классе, над которым должно производиться действие, а также на том, должны ли эти действия производиться при установке или удалении пакета. В следующей таблице показаны два формата имен:
Формат имени |
Описание |
---|---|
i.класс |
Производит действия над путевыми именами в указанном классе при установке пакета |
r.класс |
Производит действия над путевыми именами в указанном классе при удалении пакета |
Например, имя сценария установки для класса с именем manpage будетi.manpage. Сценарий удаления должен иметь имя r.manpage.
Этот формат имен файлов не используется для файлов, которые принадлежат к системным классам sed, awk или build. Для получения дополнительной информации по этим классам см. раздел Специальные системные классы .
Сценарии действий над классами выполняются под именем uid=root и gid=other.
Сценарий выполняется для всех файлов данного класса на текущем томе.
Команды pkgadd и pkgrm производят создание списка всех объектов, указанных в файле pkgmap, которые принадлежат классу. В результате сценарий действия над классом может выполнять операции только над путевыми именами, определенными в файле pkgmap, которые принадлежат конкретному классу.
При последнем выполнении сценария действия над классом (т.е. файлов, принадлежащих этому классу, больше нет) сценарий действия над классом выполняется однократно с ключевым аргументом ENDOFCLASS.
При выполнении сценариев действий над классами взаимодействие с администратором не допускается.
Если пакет распределен более чем на один том, для каждого тома, содержащего хотя бы один файл, принадлежащий этому классу, выполняется сценарий действия над классом. Соответственно, каждый сценарий должен иметь возможность неоднократного выполнения. Это означает, что выполнение сценария неограниченное количество раз с одними вводными данными должны получаться те же результаты, что и при однократном выполнении.
Если файл является частью класса, имеющего сценарий действия над классом, сценарий должен производить установку файла. Командаpkgadd не производит установку файлов, для которых существует сценарий действия над классом, однако с ее помощью производится проверка установки.
Сценарий действия над классом ни в коем случае не должен производить добавление, изменение или удаление путевого имени или системного атрибута, отсутствующего в списке, который создан с помощью команды pkgadd. Для получения дополнительной информации о списке см. пункт 1 раздела Обработка классов во время установки пакета.
Когда сценарий обнаруживает аргумент ENDOFCLASS, добавьте в сценарий действия после обработки, например очистку.
Все взаимодействие с оператором ограничивается сценарием request. Не пытайтесь получить информацию от администратора с помощью сценария действия над классом.
В системе имеются четыре специальных класса:
Обеспечивает метод для использования команд sed для изменения файлов после удаления или установки пакета.
Обеспечивает метод для использования инструкций awk для изменения файлов после удаления или установки пакета.
Обеспечивает метод динамического создания или изменения файла с помощью команд интерпретатора sh
Обеспечивает метод сохранения файлов, которые не должны перезаписываться при будущих установках пакета.
Обеспечивает автоматическую установку и удаление служб SMF (подсистемы управления службами, связанных с манифестом Для всех манифестов SMF в пакете должен использоваться класс manifest.
Если для некоторых файлов необходима специальная обработка, выполнение которой может быть невозможно с помощью команд sed, awk илиsh, установка с помощью системных классов может производиться быстрее, чем с помощью нескольких классов и соответствующих сценариев действий над классами.
Класс sed обеспечивает метод изменения существующего объекта в целевой системе. Сценарий действия над классом sed выполняется при установке автоматически, если имеется файл, принадлежащий классу sed. Имя сценария действия над классом sed должно быть тем же, что и имя файла, над которым выполняются команды.
Сценарий действия над классом sed обеспечивает передачу инструкций sed в следующем формате:
Время, когда должны выполняться команды, показывается следующими двумя командами. При установке пакета производится выполнение команды программы sed, которая следует за командой !install. При удалении пакета производится выполнение команды программы sed, которая следует за командой !remove. Порядок, в котором используются эти команды, не учитывается.
Для получения дополнительной информации об командах программы sed см. справочную страницу sed(1). Примеры сценариев действий над классами sed приведены в Глава 5Практические примеры создания пакета.
Класс awk обеспечивает метод изменения существующего объекта в целевой системе. Изменения производятся согласно командам программы awk в сценарии действия над классом awk .
Сценарий действия над классом awk выполняется при установке автоматически, если имеется файл, принадлежащий классу awk. В этом файле содержатся команды для сценария действия над классом awk в следующем формате:
Момент, когда должны выполняться команды, указывается следующими двумя командами. При установке пакета производится выполнение команд программы awk, которые следуют за командой !install. При удалении пакета производится автоматические выполнение команд, которые следуют за командой !remove. Эти команды могут выполняться в любом порядке.
Имя сценария действия над классом awk должно быть тем же, что и имя файла, над которым выполняются команды программы awk.
В качестве входных данных для команды awk используется файл, который необходимо изменить. В результате выполнения сценария производится полная замена исходного объекта. С помощью этого синтаксиса передать переменные среды для команды awk невозможно.
Для получения дополнительной информации о командах программы sed см. справочную страницу awk(1).
Класс build позволяет создавать или изменять файл объекта пакета путем выполнения инструкций интерпретатора команд sh. Эти команды предоставляются как объект пакета. Команды выполняются автоматически при установке, если объект пакета принадлежит к классу build.
Имя сценария действия над классом build должно быть тем же, что и имя файла, над которым выполняются команды. Имя должно допускать выполнение действия с помощь команды sh. Результат выполнения сценария становится новой версией измененного или созданного файла Если при выполнении сценария результат отсутствует, создание или изменение файла не производится. Таким образом, сценарий может создать или изменять сам файл.
Например, если в пакете поставляется файл /etc/randomtable по умолчанию, и если в целевой системе файл еще отсутствует, то запись файла prototype может иметь следующий вид:
e build /etc/randomtable ? ? ? |
Объект пакета /etc/randomtable может выглядеть следующим образом:
!install # randomtable builder if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then echo "/etc/randomtable is already in place."; else echo "# /etc/randomtable" > $PKG_INSTALL_ROOT/etc/randomtable echo "1121554 # first random number" >> $PKG_INSTALL_ROOT/etc/randomtable fi !remove # randomtable deconstructor if [ -f $PKG_INSTALL_ROOT/etc/randomtable ]; then # the file can be removed if it's unchanged if [ egrep "first random number" $PKG_INSTALL_ROOT/etc/randomtable ]; then rm $PKG_INSTALL_ROOT/etc/randomtable; fi fi |
Еще один пример использования класса build приведен в Глава 5Практические примеры создания пакета.
Класс preserve позволяет сохранить файл объекта пакета путем определения необходимости перезаписи существующего файла при установке пакета. При использовании сценария класса preserve возможны два варианта действий:
Если устанавливаемый файл в целевом каталоге отсутствует, он будет установлен в стандартном порядке.
Если устанавливаемый файл в целевом каталоге уже имеется, появится сообщение о том, что файл уже существует. Установка файла производиться не будет.
Для сценария preserve оба варианта являются успешными. Ошибка происходит только во втором варианте, если выполнить копирование файла в целевой каталог невозможно.
Начиная с Solaris 7, сценарий i.preserve и его копия - i.CONFIG.prsv - находятся в каталоге /usr/sadm/install/scripts, где имеются и другие сценарии действий над классами.
Измените сценарий, добавив имена файлов, изменение которых необходимо предотвратить.
Класс manifest служит для автоматической установки и удаления служб SMF (подсистемы управления службами), связанных с манифестом SMF. Для получения ознакомительной информации относительно управления службами с помощью SMF см. Глава 17, Managing Services (Overview), в System Administration Guide: Basic Administration.
Все манифесты служб в пакетах должны быть обозначены классом manifest. В подсистему пакетов включены сценарии действий классов, предназначенные для установки и удаления манифестов служб При вызове команды pkgadd(1M) выполняется импорт манифеста. При вызове команды pkgrm(1M) выполняется удаление отключенных экземпляров в манифесте служб. Все службы в манифесте, для которых не осталось экземпляров, также удаляются. Если командам pkgadd (1M) или pkgrm (1M) передается параметр -R, то соответствующие действия манифеста служб выполняются при следующей перезагрузке системы с альтернативным корневым путем.
В приведенном ниже фрагменте кода из файла информации о пакете демонстрируется использование класса manifest.
# packaging files i pkginfo i copyright i depend i preinstall i postinstall i i.manifest i r.manifest # # source locations relative to the prototype file # d none var 0755 root sys d none var/svc 0755 root sys d none var/svc/manifest 0755 root sys d none var/svc/manifest/network 0755 root sys d none var/svc/manifest/network/rpc 0755 root sys f manifest var/svc/manifest/network/rpc/smserver.xml 0444 root sys
Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.
Назначьте для объектов пакета необходимые имена классов в файле prototype.
Например, при назначении объектам классов applicationи manpage строка будет выглядеть следующим образом:
f manpage /usr/share/man/manl/myappl.1l f application /usr/bin/myappl |
Измените параметр CLASSES в файле pkginfo, добавив в него имена классов, которые необходимо использовать в пакете.
Например, записи для классов applicationи manpage будут выглядеть следующим образом:
CLASSES=manpage application none |
Класс none всегда устанавливается первым и удаляется последним вне зависимости от места, где он указан в определении параметра CLASSES.
Если вы создаете сценарий действия над классом для файла, принадлежащего классу sed, awk или build, сделайте каталог, содержащий объект пакета, текущим рабочим каталогом.
Создайте сценарии действий над классами или объекты пакета (для файлов, которые принадлежат классу sed, awk или build).
Например, сценарий установки для класса с именем application будет иметь имя i.application, а сценарий удаления будет иметь имя r.application.
Помните о том, что если файл является частью класса, который имеет сценарий действия над классом, то этот файл должен быть установлен сценарием. Командаpkgadd не производит установку файлов, для которых существует сценарий действия над классом, однако с ее помощью производится проверка установки. Кроме того, если вы определите класс, однако не создадите сценарий действия над классом, единственное действие, которое будет возможно для этого класса - копирование компонентов с установочного носителя в целевую систему (поведения по умолчанию команды pkgadd).
Выполните одну из следующих задач.
Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto и перейдите к Шаг 7.
Если файл prototype уже создан, измените его, добавив запись для каждого созданного сценария установки.
Выполните сборку пакета.
В случае необходимости см. главу Как собрать пакет.
После сборки пакета установите его для подтверждения правильности выполнения установки и проверьте его целостность. В Глава 4Проверка и запись пакета содержатся пояснения по выполнению этой задачи и поэтапные указания по записи проверенного пакета на носитель для распространения.