Глава 3 Расширение функциональности пакета (задачи)

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

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

• Создание информационных файлов и сценариев установки (карта задач)

• Создание информационных файлов

• Создание сценариев установки

• Создание подписанных пакетов

Создание информационных файлов и сценариев установки (карта задач)

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

Создание информационных файлов

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

Определение зависимостей пакета

Необходимо определить, будет ли ваш пакет иметь зависимости от других пакетов или другие пакеты будут зависеть от вашего пакета. Зависимости и несовместимые версии можно определить с помощью двух дополнительных информационных файлов пакета, compver и depend.

Файл compver позволяет указать предыдущие версии пакета, совместимые с устанавливаемой версией.

Поставка файла depend позволяет определить три типа зависимостей, связанных с создаваемым пакетом. Эти типы зависимости перечислены ниже:

• Требуемый пакет – Создаваемый пакет зависит от существования другого пакета

• Обратная зависимость – Другой пакет зависит от существования этого пакета

  ---

  Примечание –

  Использовать обратную зависимость следует только в том случае, если от существующего пакета зависит пакет, в котором нет файла depend.

  ---

• Несовместимый пакет – Созданный пакет несовместим с указанными пакетами

Файл depend разрешает только самые основные зависимости. Если пакет имеет зависимость от конкретного файла, его содержимого или поведения, файл depend не может обеспечить необходимую точность. В этом случае для подробной проверки зависимостей необходимо использовать сценарий request или сценарий checkinstall. Сценарий checkinstall также является единственным сценарием, который может без ошибок остановить процесс установки пакета.

Убедитесь в том, что файлы depend и compver имеют записи в файле prototype. Файл должен иметь тип i (для информационного файла пакета).

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

Определение зависимостей пакета

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

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

   Перечислите версии, совместимые с создаваемым пакетом. Используйте следующий формат:

   string string . . .

   Значение строки string является идентичным значению, присвоенному параметру VERSION в файле pkginfo, для каждого совместимого пакета.

3. Сохраните изменения и выйдите из редактора.

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

   Добавьте запись для каждой зависимости. Используйте следующий формат:

   type pkg-abbrev pkg-name (arch) version (arch) version . . .

   type

   Определяет тип зависимости. Должен быть выражен одним из следующих символов: P (требуемый пакет), I (несовместимый пакет) или R (обратная зависимость).

   pkg-abbrev

   Указывает сокращенное имя (аббревиатуру) пакета, например SUNWcadap.

   pkg-name

   Указывает полное описание пакета, например: Chip designers need CAD application software to design abc chips. Runs only on xyz hardware and is installed in the usr partition.

   (arch)

   Необязательный параметр. Указывает тип оборудования, на котором выполняется пакет. Например, sparc или x86. При указании архитектуры системы в качестве разделителя необходимо использовать скобки.

   version

   Необязательный параметр. Указывает значение, назначенное параметру VERSION в файле pkginfo.

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

5. Сохраните изменения и выйдите из редактора.

6. Выполните одну из следующих задач.

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

   • Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 7.

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

7. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

Пример 3–1 Файл compver

В этом примере имеются четыре версии пакета: 1.0, 1.1, 2.0, и новая версия пакета - 3.0. Новый пакет совместим со всеми тремя версиями. Файл compver для новой версии может выглядеть следующим образом:

release 3.0
release 2.0
version 1.1
1.0

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

Пример 3–2 Файл depend

В этом примере предполагается, что пример пакета SUNWcadap требует наличия установленных в целевой системе пакетов SUNWcsr и SUNWcsu. Файл depend для пакета SUNWcadap выглядит следующим образом:

P SUNWcsr Core Solaris, (Root)
P SUNWcsu Core Solaris, (Usr)

См. также

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

Создание сообщения об авторских правах

Вам необходимо решить, будет ли при установке пакета отображаться сообщение об авторских правах. Если оно должно отображаться, создайте файл copyright.

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

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

Убедитесь, что файл copyright имеет запись в файле prototype. Файл должен иметь тип i (для информационного файла пакета).

Написание сообщения об авторских правах

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

2. Создайте файл с именем copyright с помощью любого текстового редактора.

   Введите текст сообщения об авторских правах точно в том виде, в каком оно должно отображаться при установке пакета.

3. Сохраните изменения и выйдите из редактора.

4. Выполните одну из следующих задач.

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

   • Если вы не создали файл prototype, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.

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

5. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

Пример 3–3 Файл copyright

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

Copyright (c) 2003 Company Name
All Rights Reserved
 
This product is protected by copyright and distributed under
licenses restricting copying, distribution, and decompilation.

См. также

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

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

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

Команда pkgadd позволяет проверить наличие достаточного места на диске на основе определений объектов в файле pkgmap. Однако для пакета может требоваться дополнительное место на диске помимо того, что определено для объектов в файле pkgmap. Например, пакет должен создать после установки файл, в котором может быть база данных, файлы журнала или растущий файл иного рода, расходующий свободное место на диске. Чтобы зарезервировать достаточный объем дискового пространства, добавьте файл space, в котором указываются требования к объему дискового пространства. С помощью команды pkgadd производится проверка дополнительного дискового пространства, указанного в файле space. Для получения дополнительной информации см. справочную страницу space(4).

Убедитесь, что для файла space имеется запись в файле prototype. Файл должен иметь тип i (для информационного файла пакета).

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

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

2. С помощью любого текстового редактора создайте файл с именем space.

   Укажите требования к дополнительному месту на диске, которое требуется для вашего пакета. Используйте следующий формат:

   pathname blocks inodes

   pathname

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

   blocks

   Указывает место для резервирования, выраженное количеством блоков по 512 байт.

   inodes

   Указывает количество требуемых индексных дескрипторов.

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

3. Сохраните изменения и выйдите из редактора.

4. Выполните одну из следующих задач.

   • Если необходимо создать сценарии установки, перейдите к следующей задаче: Создание сценария request .

   • Если файл prototype не создан, выполните процедуру, указанную в разделе Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.

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

5. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

Пример 3–4 Файл space

В этом примере файла space указаны 1000 блоков по 512 байт и 1 индексный дескриптор, которые будут зарезервированы в каталоге /opt целевого компьютера.

/opt   1000   1

См. также

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

Создание сценариев установки

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

• Должны выполняться в интерпретаторе команд sh

• Должны содержать команды интерпретатора sh и текст

• Могут не содержать идентификатор интерпретатора команд #!/bin/sh

• Не обязательно должны быть исполняемым файлом

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

• Сценарий request

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

• Сценарий checkinstall

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

  ---

  Примечание –

  Сценарий checkinstall доступен начиная с выпуска Solaris 2.5 и совместимых выпусков.

  ---

• Процедурные сценарии

  Процедурные сценарии определяют процедуру, которая будет вызвана перед или после удаления или установки пакета. Четыре процедурных сценария - это preinstall, postinstall, preremove и postremove.

• Сценарии действий над классами

  Сценарии действия над классами определяют действие или набор действий, которые должны применяться к классу или файлам во время установки или удаления. Можно определить свои собственные классы. Кроме того, можно также использовать один из четырех стандартных классов (sed, awk, build и preserve).

Обработка сценария во время установки пакета

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

1. Выполняется сценарий request

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

2. Выполняется сценарий checkinstall

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

3. Выполняется сценарий preinstall

4. Выполняется установка объектов пакета для каждого устанавливаемого класса.

   Установка этих файлов производится по классам. Сценарии действий над классами выполняются соответствующим образом. Список классов, над которыми выполняется действие, и порядок их установки изначально определяется с помощью параметра CLASSES в файле pkginfo. Однако сценарий request или checkinstall может изменять значение параметра CLASSES. Для получения дополнительной информации об обработки классов во время установки см. раздел Обработка классов во время установки пакета.

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

   2. Выполняется установка стандартных файлов (типы файлов e, v, f) на основе их классов

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

   3. Создаются все жесткие ссылки.

5. Выполняется сценарий postinstall.

Обработка сценариев во время удаления пакета

При удалении пакета команда pkgrm выполняет следующие действия:

1. Выполняется сценарий preremove.

2. Выполняется удаление объектов пакета для каждого класса

   Удаление также производится по классам. Обработка сценариев удаления производится в порядке, обратному порядку установки, на основе последовательности, определенной в параметре CLASSES. Для получения дополнительной информации об обработки классов во время установки см. раздел Обработка классов во время установки пакета.

   1. Выполняется удаление жестких ссылок.

   2. Выполняется удаление стандартных файлов.

   3. Выполняется удаление символических ссылок, устройств и именованных каналов.

3. Выполняется сценарий postremove.

Обработка сценария 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Проверка и запись пакета.

Коды выхода для сценария

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

Примеры кодов выхода, возвращаемых сценариями установки, приведены в Глава 5Практические примеры создания пакета.

Все включенные в пакет сценарии установки должны иметь записи в файле prototype. Файл должен иметь тип i (для сценария установки пакета).

Создание сценария request

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

Результат выполнения сценария request должен представлять собой список переменных и их значений. В этот список могут входить любые параметры, созданные в файле pkginfo, а также параметры CLASSES и BASEDIR. В этом списке могут быть указаны переменные среды, которые не назначены в других компонентах. Однако файл pkginfo должен всегда содержать умолчания значений (когда это практически необходимо). Для получения дополнительной информации о переменных среды пакета см. раздел Переменные среды пакета.

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

Поведение сценария request

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

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

• При удалении пакета сценарий 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.

Если администратор, который будет устанавливать пакет, использует решение JumpStart^TM, то установка пакета не должна осуществляться в интерактивном режиме. Необходимо или не предоставлять для своего пакета сценарий request, или сообщать администраторам, чтобы до установки пакета они использовали команду pkgask. Команда pkgask сохраняет ответы администраторов в сценарийrequest. Для получения дополнительных сведений о команде pkgask см. справочную страницу pkgask(1M).

Создание сценария request

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

2. Создайте файл request с помощью любого текстового редактора.

3. По завершении сохраните изменения и закройте редактор.

4. Выполните одну из следующих задач.

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

   • Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.

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

5. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

Пример 3–5 Создание сценария request

Когда сценарий 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

Сценарий checkinstall выполняется вскоре после необязательного сценария request. Сценарий checkinstall выполняется от имени пользователя install, если такой существует, или от имени пользователя nobody. Сценарийcheckinstall не имеет полномочий на изменение данных файловой системы. Однако в зависимости от собранной информации сценарий может создавать или изменять переменные среды для контроля за ходом итоговой установки. Сценарий также может безопасно остановить процесс установки.

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

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

Сценарий checkinstall доступен, начиная с Solaris 2.5 и совместимых выпусков.

Поведение сценария checkinstall

• Сценарий checkinstall не может изменять файлы. Этот сценарий только проводит анализ состояния системы и создание списка значений переменных среды на основе этого действия. Для принудительного выполнения этого ограничения сценарий checkinstall выполняется от имени непривилегированного пользователя install (если этот пользователь существует). В противном случае сценарий выполняется от имени непривилегированного пользователя nobody. Сценарий checkinstall не имеет полномочий суперпользователя.

• Команда pkgadd производит вызов сценария checkinstall с использованием одного аргумента, содержащего информацию файла ответов сценария. Файл с результатами выполнения сценария - это файл, где хранятся данные выбора администратора.

• Сценарий checkinstall не выполняется при удалении пакета. Однако назначенные сценарием переменные среды сохраняются и доступны при удалении пакета.

Правила разработки сценария checkinstall

• Для каждого пакета может использоваться только один сценарий checkinstall. Сценарий должен иметь имя checkinstall.

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

• Переменные системной среды и переменные стандартной установки, за исключением параметров CLASSES и BASEDIR, невозможно изменить с помощью сценария checkinstall. Можно изменить все остальные созданные переменные.

• Каждая переменная среды, которая может управляться сценарием checkinstall должна иметь значение умолчания, назначенное в файле pkginfo.

• Список результирующих параметров должен иметь следующий формат PARAM=value. Пример:

  CLASSES=none class1

• Во время выполнения сценария checkinstall взаимодействие с администратором не осуществляется. Все взаимодействие с оператором ограничивается сценарием request.

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

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

2. С помощью любого текстового редактора создайте файл с именем checkinstall.

3. По завершении сохраните изменения и закройте редактор.

4. Выполните одну из следующих задач.

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

   • Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.

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

5. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

Пример 3–6 Создание сценария checkinstall

В этом примере сценария 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Проверка и запись пакета содержатся пояснения по этим задачам и поэтапные указания по записи проверенного пакета на распространяемый носитель.

Создание процедурных сценариев

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

• Сценарий preinstall

  Выполняется перед запуском установки класса. При выполнении этого сценария установка файлов не производится.

• Сценарий postinstall

  Выполняется после установки всех томов.

• Сценарий preremove

  Выполняется перед запуском удаления класса. При выполнении этого сценария удаление файлов не производится.

• Сценарий postremove

  Выполняется после удаления всех классов.

Поведение сценариев процедур

Процедурные сценарии выполняются от имени uid=root и gid=other.

Правила разработки процедурных сценариев

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

• Каждый процедурный сценарий, который выполняет установку объектов пакета не в файл pkgmap, должен использовать команду installf, чтобы передать сведения в БД пакета об изменении или добавлении путевого имени. По завершении внесения всех изменений или добавлений следует вызвать эту команду с параметром -f. Таким способом устанавливать объекты пакета могут только сценарии postinstall и postremove. Для получения дополнительной информации см. справочную страницу installf(1M) и Глава 5Практические примеры создания пакета.

• При выполнении процедурных сценариев взаимодействие с администратором не допускается. Все взаимодействие с оператором ограничивается сценарием request.

• Каждый процедурный сценарий, который производит удаление файлов, не имеющих записи в файле pkgmap, должен использовать команду removef для передачи данных в БД пакета о том, что он не производит удаление путевого имени. По завершении удаления следует вызвать эту команду с параметром -f. Более подробная информация и примеры приведены на справочной странице removef(1M) и в Глава 5Практические примеры создания пакета.

  ---

  Примечание –

  Команды installf и removef использовать не следует, поскольку процедурные сценарии не связываются автоматически с путевыми именами, указанными в файле pkgmap.

  ---

Создание процедурных сценариев

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

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

   Процедурный сценарий должен иметь одно из ранее определенных имен: preinstall, postinstall, preremove или postremove.

3. Сохраните изменения и выйдите из редактора.

4. Выполните одну из следующих задач.

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

   • Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto. Перейдите к Шаг 5.

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

5. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

См. также

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

Создание сценариев действий над классами

Определение классов объекта

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

Параметр установки CLASSES, назначенный в файле pkginfo представляет собой список устанавливаемых классов (включая класс none).

Объекты, определенные в файле pkgmap, которые принадлежат классу, не указанному в этом параметре в файле pkginfo, установлены не будут.

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

Обработка классов во время установки пакета

Ниже приведено описание действий системы при установке класса. Эти действия повторяются для каждого тома пакета во время его установки.

1. Команда pkgadd позволяет создать список путевых имен.

   С помощью команды pkgadd производится создание списка путевых имен, над которыми производит действие сценарий. В каждой строке этого списка указывается исходный и целевой пути, разделенные пробелом. Исходный путь указывает, где в установочном томе расположен устанавливаемый объект . Целевой путь указывает местоположение в целевой системе, куда будет устанавливаться объект. Содержимое списка ограничивается следующими критериями.

   • В списке содержатся только путевые имена, принадлежащие связанному классу.

   • При сбое создания объекта пакета каталоги, именованные каналы, символьные устройства, блочные устройства и символические ссылки включаются в список с исходными путевым именем, равным /dev/null. Обычно эти элементы автоматически создаются с помощью команды pkgadd (если еще не существуют) и наделяются правильными атрибутами (режим, владелец, группа) согласно определению в файле pkgmap.

   • В список ни в коем случае не включаются связанные файлы типа l. Жесткие ссылки в данном классе создаются в элементе 4.

2. Если для установки конкретного класса не предоставлен сценарий действия над классом, путевые имена в создаваемом списке копируются из тома в соответствующее целевое местоположение.

3. Выполняется сценарий действия над классом (если существует).

   При вызове сценария действия над классом на его стандартный вход подается список, созданный в элементе 1. Если этот том является последним томом пакета или при отсутствии других объектов в этом классе сценарий выполняется с единственным аргументом ENDOFCLASS.

   ---

   Примечание –

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

   ---

4. Командаpkgadd осуществляет аудит содержимого и атрибутов, а также создание жестких ссылок.

   После успешного выполнения элемента 2 или 3 команда pkgadd производит аудит содержимого и информации атрибутов для списка путевых имен. Команда pkgadd автоматически создает ссылки, связанные с классом. Обнаруженные несовпадения атрибутов в созданном списке исправляются для всех путевых имен.

Обработка классов при удалении пакета

Объекты удаляются по классам. Сначала удаляются классы, существующие для пакетов, однако не перечисленные в параметре CLASSES (например, объект, установленный с помощью команды installf). Классы, указанные в параметре CLASSES, удаляются в обратном порядке. Класс none всегда удаляется в последнюю очередь. Ниже описаны действия, которые производятся в системе при удалении класса.

1. Создание списка путевых имен с помощью команды pkgrm.

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

   Если удаляемый пакет произвел изменение каких-либо файлов типа e во время установки, то при удалении производится удаление только добавленных строк. Не удаляйте непустой редактируемый файл. Удалите строки, которые были добавлены пакетом.

2. Если сценария действия над классом не существует, производится удаление путевых имен.

   Если в пакете отсутствуют сценарии действий над классами для этого класса, производится удаление всех путевых имен в списке, созданном с помощью команды pkgrm.

   ---

   Примечание –

   Файлам, принадлежащим к типу e (редактируемые), не назначается класс и связанный с ним сценарий действия над классом. Эти файлы удаляются в данный момент, даже если их путевые имена используются другими пакетами.

   ---

3. Если сценарий действия над классом уже существует, производится выполнение сценария.

   Командаpkgrm производит вызов сценария действия над классом, на стандартный вход которого подается список, созданный в элементе 1.

4. Командаpkgrm выполняет аудит.

   После успешного выполнения сценария действия над классом команда pkgrm производит удаление ссылок на путевые имена из БД пакета, если на них нет ссылок других пакетов.

Сценарий действия над классом

Сценарий действия над классом определяет набор действия для выполнения при установке или удалении пакета. Действия выполняются над группой путевых имен в зависимости от их определения класса. Примеры сценариев действий над классами приведены в Глава 5Практические примеры создания пакета.

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

Например, имя сценария установки для класса с именем manpage будетi.manpage. Сценарий удаления должен иметь имя r.manpage.

Этот формат имен файлов не используется для файлов, которые принадлежат к системным классам sed, awk или build. Для получения дополнительной информации по этим классам см. раздел Специальные системные классы .

Поведение сценариев действий над классами

• Сценарии действий над классами выполняются под именем uid=root и gid=other.

• Сценарий выполняется для всех файлов данного класса на текущем томе.

• Команды pkgadd и pkgrm производят создание списка всех объектов, указанных в файле pkgmap, которые принадлежат классу. В результате сценарий действия над классом может выполнять операции только над путевыми именами, определенными в файле pkgmap, которые принадлежат конкретному классу.

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

• При выполнении сценариев действий над классами взаимодействие с администратором не допускается.

Правила разработки сценариев действий над классами

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

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

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

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

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

Специальные системные классы

В системе имеются четыре специальных класса:

• Класс sed

  Обеспечивает метод для использования команд sed для изменения файлов после удаления или установки пакета.

• Класс awk

  Обеспечивает метод для использования инструкций awk для изменения файлов после удаления или установки пакета.

• Класс build

  Обеспечивает метод динамического создания или изменения файла с помощью команд интерпретатора sh

• Класс preserve

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

• Класс manifest

  Обеспечивает автоматическую установку и удаление служб SMF (подсистемы управления службами, связанных с манифестом Для всех манифестов SMF в пакете должен использоваться класс manifest.

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

Сценарий класса sed

Класс sed обеспечивает метод изменения существующего объекта в целевой системе. Сценарий действия над классом sed выполняется при установке автоматически, если имеется файл, принадлежащий классу sed. Имя сценария действия над классом sed должно быть тем же, что и имя файла, над которым выполняются команды.

Сценарий действия над классом sed обеспечивает передачу инструкций sed в следующем формате:

Время, когда должны выполняться команды, показывается следующими двумя командами. При установке пакета производится выполнение команды программы sed, которая следует за командой !install. При удалении пакета производится выполнение команды программы sed, которая следует за командой !remove. Порядок, в котором используются эти команды, не учитывается.

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

Сценарий класса awk

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

Сценарий действия над классом awk выполняется при установке автоматически, если имеется файл, принадлежащий классу awk. В этом файле содержатся команды для сценария действия над классом awk в следующем формате:

Момент, когда должны выполняться команды, указывается следующими двумя командами. При установке пакета производится выполнение команд программы awk, которые следуют за командой !install. При удалении пакета производится автоматические выполнение команд, которые следуют за командой !remove. Эти команды могут выполняться в любом порядке.

Имя сценария действия над классом awk должно быть тем же, что и имя файла, над которым выполняются команды программы awk.

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

Для получения дополнительной информации о командах программы sed см. справочную страницу awk(1).

Сценарий класса build

Класс 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 возможны два варианта действий:

• Если устанавливаемый файл в целевом каталоге отсутствует, он будет установлен в стандартном порядке.

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

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

Начиная с Solaris 7, сценарий i.preserve и его копия - i.CONFIG.prsv - находятся в каталоге /usr/sadm/install/scripts, где имеются и другие сценарии действий над классами.

Измените сценарий, добавив имена файлов, изменение которых необходимо предотвратить.

Сценарий класса manifest

Класс 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

Создание сценариев действий над классом

1. Сделайте каталог, где содержатся информационные файлы, текущим рабочим каталогом.

2. Назначьте для объектов пакета необходимые имена классов в файле prototype.

   Например, при назначении объектам классов applicationи manpage строка будет выглядеть следующим образом:

   f manpage /usr/share/man/manl/myappl.1l f application /usr/bin/myappl

3. Измените параметр CLASSES в файле pkginfo, добавив в него имена классов, которые необходимо использовать в пакете.

   Например, записи для классов applicationи manpage будут выглядеть следующим образом:

   CLASSES=manpage application none

   ---

   Примечание –

   Класс none всегда устанавливается первым и удаляется последним вне зависимости от места, где он указан в определении параметра CLASSES.

   ---

4. Если вы создаете сценарий действия над классом для файла, принадлежащего классу sed, awk или build, сделайте каталог, содержащий объект пакета, текущим рабочим каталогом.

5. Создайте сценарии действий над классами или объекты пакета (для файлов, которые принадлежат классу sed, awk или build).

   Например, сценарий установки для класса с именем application будет иметь имя i.application, а сценарий удаления будет иметь имя r.application.

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

6. Выполните одну из следующих задач.

   • Если файл prototype еще не создан, выполните процедуру Создание файла prototype с помощью команды pkgproto и перейдите к Шаг 7.

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

7. Выполните сборку пакета.

   В случае необходимости см. главу Как собрать пакет.

Что делать дальше

После сборки пакета установите его для подтверждения правильности выполнения установки и проверьте его целостность. В Глава 4Проверка и запись пакета содержатся пояснения по выполнению этой задачи и поэтапные указания по записи проверенного пакета на носитель для распространения.

Создание подписанных пакетов

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

Подписанные пакеты

Подписанный пакет - это стандартный пакет формата потока, который имеет цифровую подпись (цифровую подпись PKCS7 с кодировкой PEM, определение которой приводится ниже). При его установке производит следующая проверка:

• Пакет получен от того, кем он был подписан

• Факт подписывания пакета этим лицом

• Пакет не изменялся с того момента, когда он был подписан

• Лицо или компания, подписавшая пакет, является доверенным (-ой)

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

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

Управление сертификатом

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

Доверенный сертификат

Доверенный сертификат, содержащий один сертификат открытого ключа, принадлежащий другой организации. Доверенный сертификат называется таковым, поскольку владелец хранилища ключей считает, что открытый ключ в сертификате принадлежит организации (лицу), указанному в поле “тема” (владелец) сертификата. Издатель сертификата делает его доверенным, подписывая сертификат.

При проверке подписей и подключении к защищенному серверу (по протоколу SSL) используются доверенные сертификаты.

Пользовательский ключ

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

Пользовательские ключи используются при создании подписанного пакета.

По умолчанию хранилище ключей расположено в каталоге /var/sadm/security. Отдельные пользователи могут также иметь собственные хранилища ключей, которые по умолчанию располагаются в каталоге $HOME/.pkg/security.

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

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

Добавление доверенных сертификатов в хранилище ключей пакета

Доверенный сертификат можно добавить в хранилище пакета с помощью команды pkgadm. Сертификат может иметь формат PEM или DER. Пример:

$ pkgadm addcert -t /tmp/mytrustedcert.pem

В этом примере сертификат в формате PEM имеет имя mytrustedcert.pem и добавлен в хранилище ключей пакета.

Добавление в хранилище пакета пользовательского сертификата и секретного ключа

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

pkgadm addcert -n myname -e /tmp/myprivkey.pem /tmp/mypubcert.pem

В этом примере используются следующие параметры:

Проверка содержимого хранилища ключей пакета

Команда pkgadm также используется для просмотра содержимого хранилища ключей пакета. Пример:

$ pkgadm listcert

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

Удаление из хранилища пакета пользовательских сертификатов и секретных ключей

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

При удалении пользовательских сертификатов необходимо указывать псевдоним пары сертификат/ключ. Пример:

$ pkgadm removecert -n myname

Псевдоним сертификата - это его общее имя, которое может быть указано с помощью команды pkgadm listcert. Например, с помощью этой команды производится удаление доверенного сертификата с именем Trusted CA Cert 1:

$ pkgadm removecert -n "Trusted CA Cert 1"

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

Создание подписанных пакетов

Процесс создания подписанного пакета включает в себя три основных этапа:

1. Создание неподписанного пакета в формате каталога.

2. Импорт подписанного сертификата, сертификатов центров сертификации и секретного ключа в хранилище ключей пакета.

3. Подписывание пакета из Действия 1 с помощью сертификата из Действия 2.

Средства пакетирования не создают сертификаты. Эти сертификаты необходимо получать от центра сертификации, например Verisign или Thawte.

Все действия по созданию подписанных пакетов описаны в следующих процедурах.

Создание неподписанного пакета в формате каталога

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

1. Создание файла pkginfo.

   Базовое содержимое файла pkginfo должно быть следующим:

   PKG=SUNWfoo BASEDIR=/ NAME=My Test Package ARCH=sparc VERSION=1.0.0 CATEGORY=application

2. Создание файла prototype.

   Базовое содержимое файла prototye должно быть следующим:

   $cat prototype i pkginfo d none usr 0755 root sys d none usr/bin 0755 root bin f none usr/bin/myapp=/tmp/myroot/usr/bin/myapp 0644 root bin

3. Укажите список содержимого исходного каталога объектов.

   Пример:

   $ ls -lR /tmp/myroot

   В результате должно получиться следующее:

   /tmp/myroot: total 16 drwxr-xr-x 3 abc other 177 Jun 2 16:19 usr /tmp/myroot/usr: total 16 drwxr-xr-x 2 abc other 179 Jun 2 16:19 bin /tmp/myroot/usr/bin: total 16 -rw------- 1 abc other 1024 Jun 2 16:19 myapp

4. Создайте неподписанный пакет.

   pkgmk -d `pwd`

   В результате должно получиться следующее:

   ## Building pkgmap from package prototype file. ## Processing pkginfo file. WARNING: parameter <PSTAMP> set to "syrinx20030605115507" WARNING: parameter <CLASSES> set to "none" ## Attempting to volumize 3 entries in pkgmap. part 1 -- 84 blocks, 7 entries ## Packaging one part. /tmp/SUNWfoo/pkgmap /tmp/SUNWfoo/pkginfo /tmp/SUNWfoo/reloc/usr/bin/myapp ## Validating control scripts. ## Packaging complete.

   В текущем каталоге теперь размещен пакет.

Импорт сертификатов в хранилище ключей пакета

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

Каждый центр сертификации может издавать сертификаты в различных форматах. Чтобы извлечь сертификаты и секретные ключи из файла PKCS12 и вставить в файл X.509, зашифрованный с помощью алгоритма PEM (который можно импортировать в хранилище ключей пакета), воспользуйтесь таким бесплатным средством преобразования, как OpenSSL.

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

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

1. Выполните импорт всех сертификатов центра сертификации, которые находятся в файле сертификата X.509 с кодировкой PEM или DER.

   Например, для импорта всех сертификатов центра сертификации, которые находятся в файле ca.pem, необходимо ввести следующую команду:

   $ pkgadm addcert -k ~/mykeystore -ty ca.pem

   В результате должно получиться следующее:

   Trusting certificate <VeriSign Class 1 CA Individual \ Subscriber-Persona Not Validated> Trusting certificate </C=US/O=VeriSign, Inc./OU=Class 1 Public \ Primary Certification Authority Type a Keystore protection Password. Press ENTER for no protection password (not recommended): For Verification: Type a Keystore protection Password. Press ENTER for no protection password (not recommended): Certificate(s) from <ca.pem> are now trusted

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

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

   $ pkgadm addcert -k ~/mykeystore -n mycert sign.pem

   В результате должно получиться следующее:

   Enter PEM passphrase: Enter Keystore Password: Successfully added Certificate <sign.pem> with alias <mycert>

2. Убедитесь, что сертификат импортирован в хранилище ключей пакета.

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

   $ pkgadm listcert -k ~/mykeystore

Подписывание пакета

После того, как сертификаты импортированы в хранилище пакета, можно подписать пакет. Фактически подписание пакета производится с помощью команды pkgtrans.

1. Подпишите пакет с помощь команды pkgtrans. Укажите расположение подписанного пакета, а также псевдоним ключа для подписания.

   Например, используя примеры процедур выше, для создания подписанного пакета с именем SUNWfoo.signed необходимо ввести следующее:

   $ pkgtrans -g -k ~/mykeystore -n mycert . ./SUNWfoo.signed SUNWfoo

   В результате выполнения этой команды получится следующее:

   Retrieving signing certificates from keystore </home/user/mykeystore> Enter keystore password: Generating digital signature for signer <Test User> Transferring <SUNWfoot> package instance

   Подписанный пакет создан в файле SUNWfoo.signed. Пакет имеет формат потока пакета. Подписанный пакет можно скопировать на веб-сайт и установить с помощью команды pkgadd, указав URL-адрес.