Создание пакетов программного обеспечения для установки

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

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

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

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

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

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

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

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

Требования к управляющей информации

Управляющая информация пакета должна включать следующие сведения:

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

Формат установочного пакета

Установочный пакет должен представлять собой файл в формате backup, который команда installp сможет восстановить во время установки. Этот файл может поставляться на ленте, дискетах или на компакт-дисках.

Требования к компоновке пакетов

Для поддержки бездисковых клиентов и клиентов без данных в установочном пакете должны быть разделены файлы, которые устанавливаются на каждом компьютере (компонент root), и файлы, которые могут использоваться несколькими компьютерами одновременно (компонент usr). Все файлы компонента usr должны устанавливаться в файловой системе /usr или /opt.

При установке компонента root содержимое файловой системы /usr изменяться не должно. Во время установки компонента root на бездисковых клиентах или клиентах без данных запись в файловую систему /usr будет запрещена. Машинно–зависимый (корневой) компонент должен включать в себя все файлы, не находящиеся в файловых системах /usr или /opt.

Пакеты в разделах рабочей схемы

Обратите внимание на следующие особенности отдельных программных продуктов, связанные с поддержкой разделов рабочей схемы (WPAR). Для успешного развертывания программного продукта в разделе WPAR пакет не должен пытаться записывать данные в файловые системы /usr или /opt в ходе обработки корневого компонента, поскольку WPAR монтирует эти файловые системы в режиме только для чтения. Кроме того, все операции настройки продукта в системе должны выполняться из корневого компонента пакета.

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

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

Если в случае установки в WPAR требуется другая конфигурация набора файлов, то может потребоваться дополнительная настройка при создании WPAR из системной копии, поскольку изначально набор файлов не был установлен в WPAR. Владельцы наборов файлов могут создать программы в каталогах /usr/lib/wpars/wparconvert.d/usr и /usr/lib/wpars/wparconvert.d/root, позволяющие преобразовать компоненты usr и root для поддержки системной копии WPAR. Все исполняемые файлы в этих каталогах выполняются в алфавитном порядке (локаль C) при первом запуске системной копии WPAR.

Данные реестра программного обеспечения

Информация о программном продукте и его компонентах хранится в базе данных Реестра программного обеспечения (SWVPD). SWVPD содержит набор команд и классы объектов Администратора объектных данных (ODM), предназначенные для обслуживания информации о программном продукте. Команды SWVPD позволяют пользователю запросить (lslpp) и проверить (lppchk) информацию об установленных программных продуктах. Объектные классы ODM задают диапазон и формат этой информации.

С помощью Администратора объектных данных команда installp добавляет в базу данных SWVPD следующую информацию:

• Имя программного продукта (например, bos.adt)
• Версия программного продукта
• Выпуск программного продукта, который определяет, какие изменения были внесены во внешний программный интерфейс продукта
• Уровень модификации программного продукта, который определяет, какие изменения, не связанные с внешним программным интерфейсом, были внесены в продукт
• Уровень исправления программного продукта, который определяет небольшие обновления, которые будут добавлены в продукт следующего уровня модификации
• Имена, контрольные суммы и размеры файлов, входящих в программный продукт или его компонент
• Состояние программного продукта: доступен, устанавливается, установлен, фиксируется, зафиксирован, аннулируется или содержит ошибку
• Уровень обслуживания и информацию APAR
• Имя целевого каталога и программы установки для пакетов программного обеспечения, устанавливаемых без применения команды installp (если применимо).

Компоненты установочного пакета

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

Ниже приведено краткое описание ряда файловых систем и каталогов. Оно поможет вам при разделении пакета на компоненты root, usr и share.

Некоторые каталоги, относящиеся к компоненту root:

/dev

Файлы устройств локальной системы

/etc

Файлы конфигурации (например, hosts и passwd)

/sbin

Системные утилиты, необходимые для загрузки системы

/var

Файлы данных и протоколы, относящиеся к локальной системе

Некоторые каталоги, относящиеся к компоненту usr:

/usr/bin

Команды и сценарии (обычные исполняемые файлы)

/usr/sbin

Команды администрирования системы

/usr/include

Файлы include

/usr/lib

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

/opt

Библиотеки, прочие команды и сценарии, связанные с продуктами, отличными от операционной системы

Соглашения о присвоении имен пакетам и наборам файлов

Особые соглашения о присвоении имен пакетам с драйверами

устройства.ид-типа-шины.ид-карты.расширение

Например, карте Ethernet для шины PCI в администраторе настройки соответствует идентификатор 1410bb02. Соответствующему пакету драйверов должно быть присвоено имя devices.pci.1410bb02. Набор файлов среды выполнения, входящий в состав этого пакета, должен называться devices.pci.1410bb02.rte.

Особые соглашения о присвоении имен каталогам сообщений

продукт.msg.язык.группа

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

Например, продукт Super_Widget может состоять из групп наборов файлов plastic и metal. Все каталоги сообщений продукта Super_Widget на русском языке могут поставляться в одном наборе файлов Super_Widget.msg.ru_RU. Если для групп наборов файлов plastic и metal требуются разные каталоги сообщений, то они могут поставляться в двух наборах файлов - Super_Widget.msg.en_US.plastic и Super_Widget.msg.en_US.metal.

Имена файлов

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

Идентификатор уровня набора файлов

версия.выпуск.модификация.уровень-исправления

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

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

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

Самой старшей считается первая цифра уровня, самой младшей - последняя (то есть, уровень 5.2.0.0 выше уровня 4.3.0.0).

Состав пакета программного обеспечения

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

Примеры пакетов программного обеспечения

/usr/bin/raisehog (из компонента usr)
/usr/sbin/sellhog
 (из компонента usr)

/etc/hog
 (из компонента root)

./lpp_name
./usr/lpp/farm.apps/liblpp.a
./usr/lpp/farm.apps/inst_root/liblpp.a
./usr/bin/raisehog
./usr/sbin/sellhog
./usr/lpp/farm.apps/inst_root/etc/hog

/usr/sbin/sellhog
/etc/hog

./lpp_name
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/liblpp.a
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/liblpp.a
./usr/sbin/sellhog
./usr/lpp/farm.apps/farm.apps.hog/4.1.0.3/inst_root/etc/hog

Информационный файл lpp_name

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

1 23    4
| ||    |                6         7 8 9  10       11
4 RSfarm.apps {  |       |         | | |   |        |
 5--> farm.apps.hog04.01.0000.0003 1 N U en_US Hog Utilities 
12--># ...      
[
13--> *ifreq bos.farming.rte (4.2.0.0) 4.2.0.15
%
14--> /usr/sbin 48
14--> /usr/lpp/farm.apps/farm.apps.hog/4.1.0.3 280
14--> /usr/lpp/farm.apps/farm.apps.hog/inst_root/4.1.0.3.96
14--> /usr/lpp/SAVESPACE 48
14--> /lpp/SAVESPACE 32
14--> /usr/lpp/bos.hos/farm.apps.hog/inst_root/4.1.0.3/ etc 32
%
%
15--> ranch.hog 4.1.0.0
%
16--> IX51366 Свиньи несут яйца.
16--> IX81360 У поросят слишком много ушей.
]
}

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

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

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

В приведенном ниже описании различных типов необходимого программного обеспечения требуемый-уровень обозначает минимальный уровень набора файлов, который должен быть установлен в системе. Кроме случаев, когда это явно запрещено (см. раздел Информация о заменяемом программном обеспечении), вместо указанного уровня в системе может быть установлен набор файлов более высокого уровня. Например, если в условии указано, что требуется набор файлов plum.tree 2.2.0.0, то при наличии в системе набора файлов plum.tree 3.1.0.0 это условие будет считаться выполненным.

Необходимое программное обеспечение

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

*prereqнабор-файлов требуемый-уровень

набор-файловтребуемый-уровень

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

Сопутствующее программное обеспечение

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

*coreq набор-файловтребуемый-уровень

Условная зависимость

*ifreq plum.tree (1.1.0.0) 1.1.2.3

*ifreqнабор-файлов
[(установленный-уровень)]
требуемый-уровень

Если набор файлов plum.tree вообще не установлен в системе, то он не будет установлен. Если установлен любой из следующих уровней набора файлов plum.tree, то он не будет заменен на уровень 1.1.2.3:

1.1.2.3

Этот уровень совпадает с требуемым-уровнем.

1.2.0.0

Данный базовый уровень не соответствует базовому уровню обновления 1.1.2.3.

1.1.3.0

Этот уровень выше, чем требуемый-уровень.

Если установлен любой из следующих уровней набора файлов plum.tree, то он будет заменен на уровень 1.1.2.3:

1.1.0.0

Данный уровень в точностью соответствует значению установленный-уровень.

1.1.2.0

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

Параметр (установленный-уровень) не обязателен. Если он не указан, то предполагается, что у значений установленный-уровень и требуемый-уровень совпадают версия и выпуск. Если уровень-исправления в значении требуемый-уровень равен 0, то модификация и уровень-исправления установленного-уровня тоже равны 0. В противном случае модификация в значении установленный-уровень равна модификации в значении требуемый-уровень, а значение уровень-исправления равно 0. Пример: если требуемый-уровень равен 4.1.1.1 и не указан параметр установленный-уровень, то установленный-уровень считается равным 4.1.1.0. Если требуемый-уровень равен 4.1.1.0 и не задан установленный-уровень, то предполагается, что установленный-уровень равен 4.1.0.0.

Дополнительное программное обеспечение

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

*instreq набор-файловтребуемый-уровень

Групповое условие

Групповое условие считается выполненным, если выполнено более, чем минимум из входящих в него условий. Групповое условие может содержать условия необходимого, сопутствующего и обновляемого программного обеспечения, а также вложенные групповые условия. Значение минимум перед значением {список-условий} указывает, сколько условий из списка-условий должны быть выполнены для того, чтобы групповое условие считалось выполненным. Например, если задано >2, то для выполнения группового условия требуется, чтобы были выполнены хотя бы три условия из RequisiteExpressionList.

>Число { RequisiteExpressionList }

Примеры информации о зависимостях

1. Следующий пример иллюстрирует применение сопутствующего программного обеспечения. Предположим, что набор файлов book.create 12.30.0.0 не может применяться без наборов файлов layout.text 1.1.0.0 и index.generate 2.3.0.0, поэтому для набора файлов book.create 12.30.0.0 задано следующее условие:

   *coreq layout.text 1.1.0.0
   *coreq index.generate 2.3.0.0

   Набор файлов index.generate 3.1.0.0 удовлетворяет условию index.generate, поскольку уровень 3.1.0.0 выше требуемого уровня 2.3.0.0.
2. В следующем примере применяются несколько условий различных типов. Для набора файлов new.fileset.rte 1.1.0.0 заданы следующие условия:

   *prereq database.rte 1.2.0.0
   *coreq spreadsheet.rte 1.3.1.0
   *ifreq wordprocessorA.rte (4.1.0.0) 4.1.1.1
   *ifreq wordprocessorB.rte 4.1.1.1

   На момент установки набора файлов new.fileset.rte в системе должен быть установлен набор файлов database.rte уровня 1.2.0.0 или выше. Если наборы файлов database.rte и new.fileset.rte устанавливаются за один вызов команды installp, то набор файлов database.rte будет установлен раньше набора файлов new.fileset.rte.

   Для работы набора файлов new.fileset.rte необходим набор файлов spreadsheet.rte уровня 1.3.1.0 или выше. Набор файлов spreadsheet.rte не обязательно устанавливать до набора файлов new.fileset.rte при условии, что оба набора файлов будут установлены за один вызов команды installp. Если набор файлов spreadsheet.rte нужного уровня не будет установлен на момент окончания работы команды installp, то будет выдано предупреждение о том, что отсутствует сопутствующее программное обеспечение.

   Если в системе установлен набор файлов wordprocessorA.rte уровня 4.1.0.0 (или он устанавливается вместе с набором файлов new.fileset.rte), то будет установлено обновление wordprocessorA.rte уровня 4.1.1.1 и выше.

   Если в системе установлен набор файлов wordprocessorB.rte уровня 4.1.0.0 (или он устанавливается вместе с набором файлов new.fileset.rte), то будет установлено обновление wordprocessorB.rte уровня 4.1.1.1 и выше.

3. В следующем примере проиллюстрировано применение условия на дополнительное программное обеспечение. Набор файлов Super.msg.in_IN.Widget уровня 2.1.0.0 дополняет следующий набор файлов:

   *instreq Super.Widget 2.1.0.0

   Набор файлов Super.msg.fr_FR.Widget не будет установлен автоматически, если не установлен набор файлов Super.Widget. Набор файлов Super.msg.fr_FR.Widget можно установить, если набор файловSuper.Widget не установлен, но явно указан в списке устанавливаемых наборов файлов.

4. Следующий пример иллюстрирует групповые условия. Для установки набора файлов требуется, чтобы был установлен хотя бы один из необходимых наборов файлов (могут быть установлены и оба набора). Если установлен набор файлов spreadsheet_1.rte, то он должен соответствовать уровню 1.2.0.0 или более высокому, либо должен быть установлен набор файлов spreadsheet_2.rte уровня 1.3.0.0 или выше.

   >0 {
   *prereq spreadsheet_1.rte 1.2.0.0
   *prereq spreadsheet_2.rte 1.3.0.0
   }

Размер и сведения о лицензионном соглашении

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

Информация о размере

Каталог объем-постоянной-памяти [объем-временной-памяти]

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

Каталог

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

объем-постоянной-памяти

Объем дисковой памяти, требуемый для установки или обновления набора файлов (в блоках по 512 байт). Фактически это суммарный размер новых и обновленных файлов. Кроме того, в следующих случаях это поле играет особое значение:

Если в поле Каталог указано PAGESPACE, то значение объем-постоянной-памяти задает объем пространства подкачки (в блоках по 512 байт), требуемый для установки.

Если в поле Каталог указано значение INSTWORK, то значение объем-постоянной-памяти задает объем памяти (в блоках по 512 байт), необходимый для распаковки управляющих файлов, применяемых во время установки. Эти управляющие файлы должны содержаться в архиве liblpp.a.

объем-временной-памяти

Объем дополнительной памяти, которая потребуется в указанном каталоге на время установки или обновления набора файлов (в блоках по 512 байт). После завершения установки эта память будет освобождена. Значение объем-временной-памяти указывать не обязательно. Временная память может потребоваться, например, в таких случаях, когда при установке требуется скомпоновать выполняемый файл из объектного. Другим примером может служить операция помещения объектного файла в библиотеку. Для помещения файла в библиотеку команда installp создает копию библиотеки, затем помещает файл в копию библиотеки, а после этого заменяет исходную библиотеку на копию. Память, необходимая для копии библиотеки, потребуется только на время архивации файла, и ее следует учесть в объеме временной памяти.

Если в поле Каталог указано INSTWORK, то значение объем-временной-памяти задает размер сжатого файла liblpp.a в блоках по 512 байт.

/usr/bin        30
/lib            40 20
PAGESPACE       10
INSTWORK        10  6

Поскольку структуру монтирования файловых систем в дереве каталогов предугадать достаточно сложно, рекомендуется указывать в этом разделе как можно более подробную информацию. Например, будет гораздо надежнее указать отдельные записи для каталогов /usr/bin и /usr/lib, чем одну запись для каталога /usr, потому что каталоги /usr/bin и /usr/lib могут находиться в различных файловых системах и при этом быть смонтированными в каталоге /usr. Лучше всего указывать подробную информацию о каждом каталоге, в который нужно поместить файлы.

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

/usr/lpp/SAVESPACE

Каталог save для файлов компонента usr. По умолчанию все файлы компонента usr сохраняются в каталоге /usr/lpp/пакет/набор-файлов/уровень.save.

/lpp/SAVESPACE

Каталог save для файлов компонента root. По умолчанию все файлы компонента root сохраняются в каталоге /lpp/пакет/набор-файлов/уровень.save.

Сведения о лицензионном соглашении

Новое дополнение к процессу установки AIX позволяет владельцу продукта потребовать от пользователя принять лицензионное соглашение до начала установки продукта. Обычно команда installp считывает файл lpp_name с любого образа. Если в поле размера файла lpp_name есть записи LAF или LAR, то installp вызывает команду inulag, которая показывает в окне текст лицензионного соглашения и фиксирует принятие пользователем этого соглашения. Если пользователь отказывается принять лицензионное соглашение, установка продукта прерывается.

Где должен находится файл лицензии

Владелец продукта может размещать файл лицензии по своему усмотрению. Однако настоятельно рекомендуется поместить его в каталог /usr/swlag/LANG. Рекомендуемое имя файла Лицензионного соглашения имеет вид: ИмяПродукта_ВерсияВыпуск.la . Однако использовать именно такое имя и расположение необязательно. Команда installp и такое размещение просто предлагают способ доставки информации потребителям. Все утилиты и необходимое наполнение должны предоставляться вместе с продуктом.

Требования к переводу файла лицензии

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

Способ поставки файла лицензии

Файл лицензии может поставляться в составе основного продукта или в виде отдельного набора файлов. Во многих продуктах создается отдельный набор файлов, предназначенный только для файлов лицензий. Такой подход позволяет создать для сложного продукта с большим числом компонентов один файл и один набор файлов лицензии и поставлять этот набор файлов на всех носителях, необходимых для установки различных компонентов, а не включать файлы в состав каждого компонента. В настоящее время рекомендуется присваивать такому набору файлов имя lpp.license или lpp.loc.license. Большинство продуктов в настоящее время используют первое имя. Если вы хотите, чтобы набор файлов лицензии был невидим для пользователя при обычной установке, то присвойте ему имя lpp.loc.license, поскольку выбирать для установки набор файлов лицензии не требуется.

Способ упаковки файла лицензии

Пример набора файлов LAF

iced.tea.loc.license 03.01.0000.0000 1 N U en_US IcedTea Лицензионная информация о рецепте чая
[
%
INSTWORK 16 160
LAF/usr/swlag/de_DE/iced.tea.la 24
LAF/usr/swlag/DE_DE/iced.tea.la 24
LAF/usr/swlag/en_US/iced.tea.la 24
LAF/usr/swlag/EN_US/iced.tea.la 24
LAF/usr/swlag/es_ES/iced.tea.la 24
LAF/usr/swlag/ES_ES/iced.tea.la 24
LAF/usr/swlag/fr_FR/iced.tea.la 24
LAF/usr/swlag/FR_FR/iced.tea.la 24
LAF/usr/swlag/it_IT/iced.tea.la 24
LAF/usr/swlag/IT_IT/iced.tea.la 24
LAF/usr/swlag/ja_JP/iced.tea.la 24
LAF/usr/swlag/JA_JP/iced.tea.la 32
LAF/usr/swlag/Ja_JP/iced.tea.la 24
LAF/usr/swlag/ko_KR/iced.tea.la 24
LAF/usr/swlag/KO_KR/iced.tea.la 24
LAF/usr/swlag/pt_BR/iced.tea.la 24
LAF/usr/swlag/PT_BR/iced.tea.la 24
LAF/usr/swlag/ru_RU/iced.tea.la 24
LAF/usr/swlag/RU_RU/iced.tea.la 48
LAF/usr/swlag/zh_CN/iced.tea.la 16
LAF/usr/swlag/zh_TW/iced.tea.la 16
LAF/usr/swlag/Zh_TW/iced.tea.la 16
LAF/usr/swlag/ZH_TW/iced.tea.la 24
%
%
%
]

Пример набора файлов LAR

iced.tea.server 03.01.0000.0010 1 N B en_US Набор рецептов чая
[
*prereq bos.net.tcp.client 5.1.0.10
*coreq iced.tea.tools 5.1.0.10
*coreq Java14.sdk 1.4.0.1
%
/usr/bin 624
/usr/lib/objrepos 24
/usr/include 16
/usr/include/sys 56
/usr/lpp/iced.tea 22
/usr/samples/iced.tea 8
/usr/samples/iced.tea/server 504
/usr/lpp/iced.tea/inst_root/etc/tea 8
/usr/iced.tea 8
/usr/lpp/iced.tea/inst_root/etc/tea/Top 8
INSTWORK 208 96
/lpp/iced.tea 104
/etc/tea 8
/etc/objrepos 8
/etc/tea/Top 8
/tmp 0 6
LAR/usr/swlag/%L/iced.tea.la 0
%
%
%
]

Информация о заменяемом программном обеспечении

В этом разделе указываются сведения о том, какие уровни набора файлов могут (или не могут) быть заменены набором файлов с данным уровнем. Это необязательная информация, которая может указываться только в базовых пакетах установки наборов файлов в формате AIX 4.1 и в пакетах обновления наборов файлов в формате AIX 3.2.

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

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

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

Предположим, что обновление farm.apps.hog 4.1.0.1 заменяет файл /usr/sbin/sellhog. В то же время, обновление farm.apps.hog 4.1.0.3 заменяет файлы /usr/sbin/sellhog и /etc/hog. В свою очередь обновление farm.apps.hog 4.1.1.2 заменяет файл /usr/bin/raisehog.

Обновление farm.apps.hog 4.1.0.3 заменяет обновление farm.apps.hog 4.1.0.1, так как оно заменяет те же файлы и относится к той же модификации базового набора файлов (farm.apps.hog 4.1.0.0).

Обновление farm.apps.hog 4.1.1.2 не заменяет ни обновление farm.apps.hog 4.1.0.3, ни обновление farm.apps.hog 4.1.0.1, так как оно содержит не все файлы, заменяемые этими обновлениями, и относится к другой модификации базового набора файлов (farm.apps.hog 4.1.1.0). Обновление farm.apps.hog 4.1.1.0 заменяет обновления farm.apps.hog 4.1.0.1 и farm.apps.hog 4.1.0.3.

Информация о заменяемом программном обеспечении для базового уровня набора файлов

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

Оператор границы

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

Оператор совместимости

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

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

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

Например, если набор файлов Bad.Idea был существенно переработан в версии 6.5.6.0, то в установочных пакетах всех последующих уровней набора файлов Bad.Idea должен содержаться оператор границы для уровня 6.5.6.0. Благодаря этому набор файлов Bad.Idea 6.5.4.0 не будет заменяться никакими уровнями набора файлов Bad.Idea выше, чем 6.5.6.0, потому что он будет считаться несовместимым с ними.

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

В качестве примера предположим, что набор файлов Year.Full 19.91.0.0 был разделен на несколько отдельных наборов файлов и больше не поставляется. Только для одного из этих наборов файлов, например, для Winter 19.94.0.0, должен быть указан оператор совместимости с Year.Full 19.94.0.0. Этот оператор позволяет установить набор файлов Winter 19.94.0.0 вместо набора файлов Year.Full уровня 19.94.0.0 и ниже в тех случаях, когда набор файлов Year.Full требуется для работы каких-либо других наборов файлов.

Обработка информации о заменяемом программном обеспечении

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

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

  Предположим, что пользователь вызвал команду installp с флагом -g (автоматическая установка необходимого программного обеспечения) для набора файлов farm.apps.hog 4.1.0.2. Если на установочном носителе записан только набор файлов farm.apps.hog 4.1.0.4, команда installp установит farm.apps.hog 4.1.0.4 как заменяющий набор файлов.

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

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

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

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

Информация об исправлениях

Информацию об исправлениях указывать не обязательно. В этом разделе содержится код исправления и описание исправленной ошибки длиной до 60 символов. Код исправления представляет собой уникальный идентификатор данного исправления длиной до 16 символов. Коды исправлений, начинающиеся с символов ix, iy, IY и IX зарезервированы для разработчиков операционной системы.

Обновлением уровня обслуживания называется обновление, существенно изменяющее функциональные возможности продукта. Примерами обновлений уровня обслуживания могут служить пакеты профилактического обслуживания (PMP). Идентификатор уровня обслуживания начинается с имени программного продукта (не пакета), за которым идет одна точка (.) и идентифицирующий уровень, например farm.4.1.1.0.

Библиотечный файл управления установкой - liblpp.a

Файл liblpp.a - это архивный файл, содержащий файлы для управления установкой пакета. В системах более поздних версий, чем AIX 4.3, файл liblpp.a можно создать с помощью команды ar с флагом -g, чтобы гарантировать создание 32-разрядного архива. В этом разделе описано большинство стандартных файлов, входящих в архив liblpp.a.

В именах управляющих файлов, упоминаемых в этом разделе, присутствует компонент набор-файлов. Набор-файлов задает имя отдельного набора файлов, устанавливаемого в составе пакета программного обеспечения. Например, файл со списком установки обозначается как набор-файлов.al. Это означает, что список установки для компонента bos.net.tcp.client продукта bos.net хранится в файле bos.net.tcp.client.al.

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

Файлы данных, содержащиеся в файле liblpp.a

Необязательные исполняемые файлы, содержащиеся в файле liblpp.a

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

Набор-файлов.config или Набор-файлов.config_u

Изменяет конфигурацию при завершении стандартной процедуры установки или обновления продукта. Файл набор-файлов.config вызывается только при установке продукта.

Набор-файлов.odmdel или Набор-файлов.*.odmdel

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

набор-файлов.pre_d

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

Набор-файлов.pre_i или Набор-файлов.pre_u

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

набор-файлов.pre_rej

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

набор-файлов.pre_rm

Вызывается во время установки перед удалением файлов предыдущей версии набора файлов.

Набор-файлов.post_i или Набор-файлов.post_u

Вызываются после восстановления файлов из списка установки набора файлов или обновления.

набор-файлов.unconfigнабор-файлов.unconfig_u

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

набор-файлов.unodmadd

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

Набор-файлов.unpost_i или Набор-файлов.unpost_u

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

Набор-файлов.unpre_i или Набор-файлов.unpre_u

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

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

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

instal

Применяется вместо стандартного сценария установки /usr/lib/instl/instal. Команда installp вызывает этот файл при установке базового набора файлов из пакета.

lpp.cleanup

Применяется вместо стандартного сценария очистки /usr/lib/instl/cleanup. Команда installp вызывает этот файл при установке базового набора файлов или обновления, которое было частично установлено и должно быть удалено для перевода набора файлов в согласованное состояние.

lpp.deinstal

Применяется вместо стандартного сценария удаления набора файлов /usr/lib/instl/deinstal. Этот выполняемый файл должен находиться в каталоге /usr/lpp/имя-пакета. Программа installp вызывает этот файл при удалении базового набора файлов.

lpp.reject

Применяется вместо стандартного сценария аннулирования /usr/lib/instl/reject. Команда installp вызывает этот файл при аннулировании обновления набора файлов. (Стандартный сценарий /usr/lib/instl/reject представляет собой ссылку на сценарий /usr/lib/instl/cleanup.)

update

Применяется вместо стандартного сценария обновления /usr/lib/instl/update. Команда installp вызывает этот файл при установке обновления набора файлов. (Стандартный сценарий /usr/lib/instl/update представляет собой ссылку на сценарий /usr/lib/instl/instal.)

Необязательный исполняемый файл, содержащийся в файле набор-файлов.al

Подробное описание файлов управления установкойeФайл набор-файлов.cfgfiles

В файле набор-файлов.cfgfiles перечислены файлы конфигурации, которые должны быть сохранены для перехода к новой версии набора файлов без потери пользовательских данных. Файл набор-файлов.cfgfiles должен находиться в файле liblpp.a, относящемся к тому же компоненту (usr или root), что и файлы с пользовательскими данными.

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

preserve

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

auto_merge

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

hold_new

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

user_merge

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

other

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

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

Файлы конфигурации, перечисленные в файле набор-файлов.cfgfiles, сохраняются в том же каталоге сохранения конфигурации, что и сам файл набор-файлов.cfgfiles. Имя каталога сохранения хранится в переменной среды MIGSAVE. Для разных компонентов (usr, share и root) применяются различные каталоги сохранения. Они перечислены ниже:

/usr/lpp/save.config

Компонент usr

/lpp/save.config

Компонент root

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

Предположим, что в набор файлов change.rte входит один файл конфигурации. Этот файл относится к компоненту root, и поэтому он указан в файле change.rte.cfgfiles для компонента root:

/etc/change_user   user_merge

При переходе от старого набора файлов (change.obj) к набору файлов change.rte этот файл сохранить не удастся, потому что его формат был изменен. В то же время, этот файл может сохраняться при установке новых уровней change.rte. Для этого нужно написать сценарий change.rte.post_i, алгоритм работы которого зависит от того, какой набор файлов был установлен в системе ранее. В этом случае изменения, внесенные пользователем в файл /etc/change_user, не будут потеряны при обновлении.

#! /bin/ksh
rc=0
grep -q change.rte $INSTALLED_LIST
if [$? = 0]
то
mv $MIGSAVE/etc/change_user/ /etc/change_user
rc=1
fi
exit $rc

Команда installp определяет и экспортирует переменную среды $INSTALLED_LIST. Описание файла конфигурации набор-файлов.installed_list приведен в разделе Файлы управления установкой для продуктов с измененной структурой. В переменной $MIGSAVE хранится имя каталога, в котором сохраняются файлы конфигурации компонента root.

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

./etc/cfg_leafpreserve
./etc/cfg_pudding hold_new
./etc/cfg_newtonpreserve

Файл набор-файлов.fixdata

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

Для каждого исправления должен быть отведен отдельный раздел файла набор-файлов.fixdata. Разделы файла набор-файловfixdata задаются в следующем формате:

fix:
name = ключевое-слово
abstract = описание
type = {f | p}
filesets = имя-набора-файлов уровень-набора-файлов
[имя-набора-файлов уровень-набора-файлов ...]
[symptom = [симптом]]

Ниже приведен пример раздела файла набор-файлов.fixdata для ошибки MS21235. Эта ошибка исправлена в двух наборах файлов.

fix:
name = MS21235
abstract = 82-гигабайтовый дисковод не работает на Марсе
type = f
filesets = devices.mca.8d77.rte 12.3.6.13
devices.mca.8efc.rte 12.1.0.2
symptom = 82-гигабайтовые субатомные дискеты не работают в марсианской атмосфере.

Файл набор-файлов.inventory

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

Примечание: В файле набор-файлов.inventory можно указывать информацию только о тех файлах, размер которых не превышает 2 ГБ. Если в вашем установочном пакете есть файлы размером более 2 ГБ, укажите их файле набор-файлов.al, но не задавайте их в файле набор-файлов.inventory. Команда sysck в настоящее время не поддерживает файлы размером более 2 ГБ; кроме того, во многих системах файловая система /usr по умолчанию не поддерживает файлы размером более 2 ГБ.

Файл inventory - это текстовый файл в стандартном формате файла настройки. Имена разделов этого файла представляют собой полные пути к устанавливаемым файлам. Имя раздела должно заканчиваться двоеточием (:), за которым следует символ новой строки. После имени раздела могут быть указаны атрибуты в формате атрибут=значение. Каждый атрибут должен быть указан в отдельной строке.

inventory:
type     = type
class    = inventory,apply,C2_exclude,fileset
owner    = имя_владельца
group    = group_name
mode     = TCB | SUID | SGID,permissions
target   = полный_путь_имяфайла
link     = полный-путь-жесткой-связи [additional_hardlinks]
size     =<blank> | VOLATILE |size
checksum =<blank> | VOLATILE |"checksum"

Пример fileset.inventory

Следующий пример набора файлов fileset.inventory демонстрирует применение обозначения типа type.

/usr/bin:
        owner = bin
        group = bin
        mode = 755
        type = directory
        class = apply,inventory,bos.rte


/usr/bin/tcbck:
        owner = root
        group = security
        mode = TCB,SUID,550
        type = file
        class = apply,inventory,bos.rte.security
        size = 99770
        checksum = "17077     98 "


/usr/sbin/tsm:
        owner = root
        group = security
        mode = TCB,SUID,555
        links = /usr/sbin/getty,/usr/sbin/login
        class = apply,inventory,bos.rte,security
        size = 55086
        checksum = "57960     54 "

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

набор-файлов.installed_list

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

Для того чтобы узнать, установлен ли набор файлов набор-файлов или какие-либо из наборов файлов, перечисленных в файле набор-файлов.namelist (если он есть), команда installp просматривает базу данных программного обеспечения. Если какие-либо компоненты уже установлены, то в файл набор-файлов.installed_list заносятся имена и уровни установленных наборов файлов.

В файле набор-файлов.installed_list перечислены все установленные наборы файлов. Каждая запись содержит имя и обозначение уровня набора файлов.

storm.rain 1.1.0.0

Pelly.com
GooseCreek.rte
CedarBayou.stream 

Pelly.obj 1.2.3.0
CedarBayou.stream 4.1.3.2

Файл набор-файлов.namelist должен находиться в файле liblpp.a, относящемся к компоненту usr или root. Файл набор-файлов.namelist может поставляться только с установочными пакетами базового уровня; его нельзя поставлять с обновлениями.

В начале установки команда installp просматривает реестр программного обеспечения (SWVPD) и пытается определить, установлены ли в системе какие-либо из наборов файлов, перечисленных в файле набор-файлов.namelist. При обнаружении хотя бы одного набора файлов команда installp создает файл набор-файлов.installed_list и записывает в него имена и уровни найденных наборов файлов.

family.business

lawoffice.mgr

lawoffice.mgr
BusinessOffice.mgr

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

В предыдущих примерах набор файлов small.business полностью заменяет набор файлов family.business, поэтому для него не требуется создавать файл small.business.rm_inv. Однако набор файлов LawPractice.client не полностью заменяет набор файлов lawoffice.mgr, поэтому для него обязательно должен быть создан файл LawPractice.client.rm_inv, даже если он будет пустым.

Пример 3:

bread.shop.rte
bagel.shop.rte

Кроме того, в набор необходимо добавить пустой файл bread.shop.rte.rm_inv, указывающий, что все файлы из набора bagel.shop.rte следует удалить из системы.

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

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

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

В качестве примера предположим, что набор файлов U.S.S.R 19.91.0.0 содержал следующие файлы в каталоге /usr/lib: moscow, leningrad, kiev, odessa и petrograd (символьная связь с файлом leningrad). Разработчики решили разделить набор файлов U.S.S.R19.91.0.0 на два набора файлов: Ukraine.lib 19.94.0.0 и Russia.lib 19.94.0.0. Набор файлов Ukraine.lib состоит из файлов kiev и odessa. Набор файлов Russia.lib содержит файл moscow. Файл leningrad устарел и заменен файлом st.petersburg в наборе файлов Russia.lib.

В этом случае необходимо создать файл Ukraine.lib.rm_inv, поскольку набор файлов Ukraine.lib не полностью заменяет набор файлов U.S.S.R. Файл Ukraine.lib.rm_inv должен быть пустым, так как при установке набора файлов Ukraine.lib не нужно удалять файлы, относящиеся к устаревшему набору файлов U.S.S.R.

/usr/lib/leningrad:
 symlinks = /usr/lib/petrograd
/usr/lib/petrograd:

Установочные файлы для дополнительных дисковых подсистем

Если для поставляемого устройства, подключаемого к SCSI или системной шине, требуются собственные драйвер и процедуры настройки, то изготовитель этого устройства должен поставлять специальные установочные файлы. Эти файлы должны быть записаны в формате backup на дискете, входящей в комплект поставки устройства, и им должны быть присвоены имена ./signature и ./startup. В файле signature должна содержаться строка target. Файл startup должен представлять собой сценарий, который разархивирует нужные файлы с дискеты с помощью команды restore, а затем выполняет все действия по настройке и подготовке устройства к работе.

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

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

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

Магнитная лента

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

• Файл 1 должен быть пустым. (Он может быть непустым только у загрузочных магнитных лент.)
• Файл 2 должен быть пустым. (Он может быть непустым только у загрузочных магнитных лент.)
• Файл 3 должен представлять собой таблицу содержимого с информацией о том, какие установочные образы записаны на данном наборе магнитных лент. Соответственно, на каждой магнитной ленте набора должна быть записана одна и та же полная таблица содержимого, отличающаяся только порядковыми номерами лент в наборе.
• Файлы с 4 по (N+3) содержат установочные образы продуктов 1 - N в формате backup.
• Каждый установочный образ должен целиком располагаться на одной ленте.
• После каждого файла на ленте должна быть записана метка конца файла.

компакт-диск

Компакт-диски с установочными образами нескольких продуктов должны соответствовать протоколу RRGP (Rock Ridge Group Protocol). Установочные пакеты должны находиться в каталоге, содержащем следующие данные:

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

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

AIX 5.2Пример:

Набор файлов A записан в файле A.bff на томе 1. Набор файлов B записан в файле B.bff на томе 2. В таблице содержимого в каталоге /installp/mvCD расположение наборов файлов A и B указано как vol%1/A.bff и vol%2/B.bff, соответственно. В таблице содержимого в каталоге /installp/ppc тома 1 расположение А указано как A.bff. В таблице содержимого в каталоге /installp/ppc тома 2 расположение B указано как B.bff.

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

Дискеты

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

• Таблица содержимого с описанием образов, записанных на многотомном носителе.
• Установочные образы всех продуктов.

При записи файлов на дискеты должны быть выполнены следующие правила:

• Данные должны записываться в виде потока; в блоке 0 каждой дискеты должен быть записан ИД тома. Данные, записанные в блоке 1 очередного тома, рассматриваются как логическое продолжение данных, записанных в последнем блоке предыдущего тома.
• Начало каждого файла должно приходиться на начало 512-байтового блока.
• Первым файлом набора дискет должна быть таблица содержимого. Дополните этот файл таким образом, чтобы его последний сектор был заполнен нулевыми байтами (x'00'). В конце таблицы содержимого должен быть хотя бы один нулевой байт - признак границы. Если таблица содержимого занимает целое число секторов, следующий сектор должен быть целиком заполнен нулевыми байтами.
• После таблицы содержимого должны быть последовательно записаны установочные образы всех продуктов. Последний сектор каждого образа должен дополняться нулевыми байтами. Если установочный образ занимает целое число секторов, то дополнительный нулевой сектор не требуется.
• В блоке 0 каждой дискеты должен быть записан ИД тома. ИД тома записывается в отдельном секторе в следующем формате:

  Позиция	Описание
  Байты 0:3	Сигнатура. Установочным носителям выделена сигнатура 3609823513=x'D7298918'.
  Байты 4:15	Дата и время. Это значение должно быть указано в формате месяц-день-час-минута-секунда-год. В поле час должно быть указано значение от 00 до 23. Все поля даты и времени состоят из 2 цифр. Поэтому для обозначения марта в поле месяц должно быть указано 03, а не 3, а для обозначения 1994 года в поле год должно быть указано 94, а не 1994.
  Байты 16:19	Двоичный номер дискеты в данном наборе. Первой дискете присваивается номер x'00000001'.
  Байты 20:511	Двоичные нули.

Формат даты и времени

Дата и время указываются в следующем формате:

месяц-день-час-минута-секунда-год

В поле час должно быть указано значение от 00 до 23. Все поля даты и времени состоят из 2 цифр. Поэтому для обозначения марта в поле месяц должно быть указано 03, а не 3, а для обозначения 1994 года в поле год должно быть указано 94, а не 1994.

Формат поля расположения

Расположение установочного образа указывается в формате ттт:ббббб:ррррррр:

Магнитная лента

ттт

- номер тома магнитной ленты.

ббббб

- номер файла на магнитной ленте.

рррррррр

- размер файла в байтах.

Дискета

ттт

номер тома дискеты.

ббббб

номер блока дискеты, с которого начинается файл.

рррррррр

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

Перемещаемая установка AIX

Хотя перемещаемая установка AIX поддерживается стандартными утилитами установки AIX (такими как installp, instfix , lslpp и lppchk), использование перемещения необходимо приложениям, устанавливаемым в рабочем разделе. Причина этого состоит в том, что стандартная конфигурация System WPAR не включает перезаписываемые файловые системы/usr или /opt. Поэтому, возможно, потребуется перенастроить установку приложения для установки в местах, отличных от обычного расположения /usr или /opt.

Терминология

путь к корневому каталогу установки

Базовый каталог установки приложения. Стандартный путь установки installp - "/".

путь к корневому каталогу по умолчанию

Путь к корневому каталогу установки по умолчанию ("/").

перемещенный путь установки

Любой путь к корневому каталогу установки, не являющийся стандартным. Путь может быть любым, за исключением "/". Имя пути не должно превышать 512 символов.

перемещаемые приложения

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

USIL (Пользовательский путь установки)

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

USIL

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

Команды управления USIL

/usr/sbin/mkusil

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

mkusil -R RelocatePath -c Comments [X Fa]

-a

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

-c

Комментарии, включаемые в определение пользовательского пути установки (можно видеть с помощью команды lsusil)

-R

Путь к созданному каталогу пользовательского пути установки. Каталог должен существовать.

-X

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

/usr/sbin/lsusil

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

lsusil [-R RelocatePath | "ALL"]

-R

Путь к существующему каталогу пользовательского пути установки.

/usr/sbin/rmusil

Удаляет все существующие экземпляры.

rmusil -R RelocatePath

-R

Путь к существующему каталогу пользовательского пути установки.

/usr/sbin/chusil

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

chusil -R RelocatePath -c NewComments [ X]

-c

Включить новые комментарии в определение пользовательского пути установки (можно видеть с помощью команды lsusil)

-R

Путь к существующему каталогу пользовательского пути установки.

-X

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

Утилиты перемещаемой установки

Требования к пакетам перемещаемых установок

Требования к выполнению перемещаемых приложений

Объект класса ODM USIL connector

Объектный класса администратора объектных данных коннектора пользовательского пути установки находится в файле /etc/objrepos/usilc и содержит данные, соединяющие стандартный реестр программного обеспечения с экземплярами пользовательского пути установки.

/*  Коннектор расположения пользовательской установки  */
/*  Connects the default install path to all relocated install paths.  */
class   usilc {
        vchar   path[1024];       /* Пользовательский путь установки */
        vchar   comments[2048];   /* Комментарии пользовательского пути установки  */
        long    flags;            /* Флаги пользовательского пути установки  */
        };     

Перечисляет все пути установки с опцией -R "ALL" или -R "all"

Команды lslpp и lppchk могут выполнять операции перечисления в местах установки, если используется синтаксис -R "ALL".

Операции подключения и отключения

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

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

лицензирование installp

Новый экземпляр пользовательского пути установки имеет пустое лицензионное соглашение (лицензионное соглашение объектного класса администратора объектных данных installp ). Для любых наборов файлов или лицензионных программа необходима лицензия в соответствии с соглашениями installp. Лицензии не распространяются на экземпляры пользовательских установок.

|Защищенная компьютерная база (TCB)

Установка экземпляров USIL не поддерживается системами с активированным TCB.

Переносимые реквизиты

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

Данные определенные типы реквизитов являются стандартными: prereq, ifreq, coreq и instreq). Данные реквизиты находятся в стандартном каталоге.

Изменения TOC для переносимых пакетов

sscp.rte.1.0.0.5.U.PRIVATE.bff 4 R S sscp {
sscp.rte 01.00.0000.0005 1 N B En_US Sscp
[
*coreq bos.games 1.1.1.1  <-- стандартный реквизит в стандартном разделе
*prereq bos.rte 1.1.1.1   <-- стандартный реквизит в стандартном разделе
%
/usr/bin 20
/etc 20
INSTWORK 72 40
%
%
%
IY99999  1 APAR text here.
%
RELOCATABLE <-- тег атрибута, указывающий перемещаемый пакет
%
*prereq bos.rte 1.1.1.1   <-- стандартный реквизит в пользовательском разделе
*coreq_r bos.games 1.1.1.1 <-- стандартный реквизит в пользовательском разделе
]
}

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

Повторная установка набора файлов поверх того же уровня не равносильна удалению этого набора файлов с последующей установкой. Сценарий повторной установки (см. /usr/lib/instl/rminstal) удаляет из системы файлы текущей установленной версии, но не выполняет сценарии unconfig и unpre*. В связи с этим, создаваемые вами сценарии не должны исходить из предположения о том, что был выполнен сценарий unconfig. При принятии решений относительно того, была ли удалена информация о конфигурации, сценарий .config должен предварительно проверять среду.

Предположим, что сценарий настройки набора файлов ras.berry.rte добавляет строку в файл crontab пользователя root. Если вы заново установите набор файлов ras.berry.rte, то в файле crontab окажется две записи, поскольку при повторной установке не выполняется сценарий unconfig (который должен удалять строку из файла crontab). Сценарий настройки в подобной ситуации должен сначала удалять существующую запись, а затем добавлять собственную.

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

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

1. Восстановить информационный файл lpp_name для указанного пакета с заданного устройства.
2. Убедиться, что все запрошенные наборы файлов записаны на установочном носителе.
3. Убедиться, что уровень запрошенных наборов файлов допускает установку этих наборов в системе.
4. Восстановить управляющие файлы из библиотеки liblpp.a в каталог пакета (/usr/lpp/имя-пакета для пакетов usr и usr/root. Управляющие файлы для компонента root пакета usr/root находятся в файле /usr/lpp/имя-пакета /inst_root/liblpp.a).
5. Проверить требования к объему свободной дисковой памяти.
6. Проверить, что все необходимое программное обеспечение (наборы файлов, определенный уровень которых должен быть установлен в системе перед началом установки данных наборов файлов) уже установлено или выбрано для установки.
7. Определить, нужно ли принять какие-либо лицензионные соглашения для продолжения установки.
8. Если устанавливается базовый уровень набора файлов, то просмотреть реестр программного обеспечения (SWVPD) и проверить, установлен ли в системе какой-нибудь уровень этого набора файлов или какие-либо из наборов файлов, перечисленных в файле набор-файлов.namelist. Если набор-файлов уже установлен, то записать имя и уровень установленного набора файла в файл рабочий-каталог/набор-файлов.installed_list.

   Если набор-файлов не установлен, но установлены какие-либо наборы файлов, перечисленные в файле набор-файлов.namelist, то сохранить их имена и уровни в файле рабочий-каталог/набор-файлов.installed_list. Рабочий-каталог обычно совпадает с каталогом, в котором устанавливается весь пакет за исключением компонентов root, которые устанавливаются в каталог /lpp/имя-пакета.

9. Если устанавливается базовый уровень набора файлов, то вызвать сценарий /usr/lib/instl/rminstal для каждого из устанавливаемых наборов файлов.
   Прим.: (Если не указано иное, то к этому моменту существующие файлы должны быть уже восстановлены из библиотеки управляющих файлов liblpp.a).
   1. Если файл набор-файлов.pre_rm существует, то вызвать набор-файлов.pre_rm для подготовки к удалению текущего уровня набора файлов.
   2. Если существует файл рабочий-каталогнабор-файлов.installed_list, то переместить существующие файлы, перечисленные в файле набор-файлов.cfgfiles, в каталог сохранения (путь к каталогу указан в переменной среды MIGSAVE)."
   3. Если в системе уже установлен какой-либо уровень набора-файлов, то удалить его файлы из системы и сведения об этом наборе-файлов из SWPD (за исключением хронологии).
   4. Если существует файл рабочий-каталог/набор-файлов.installed_list и при этом существует файл набор-файлов.rm_inv или файл набор-файлов.namelist содержит более одного набора файлов, либо в файле набор-файлов.namelist указан только bos.obj, то необходимо выполнить следующие действия:
      1. Удалить из системы файлы, перечисленные в файле набор-файлов.rm_inv, и удалить из SWVPD информацию об этих файлах.
      2. Удалить из системы файлы, перечисленные в файле набор-файлов.inventory, и удалить из SWVPD информацию об этих файлах.
      3. Удалите из SWVPD информацию обо всех наборах файлов, перечисленных в файле набор-файлов.namelist.
   5. Если существует файл рабочий-каталог/набор-файлов.installed_list, содержащий только один набор файлов, и список набор-файлов.namelist содержит только один набор файлов, то необходимо удалить файлы этого набора файлов, а также удалить из SWVPD информацию об этих файлах (за исключением хронологических сведений).
   6. Для каждого компонента пакета (либо только для usr, либо для usr, а затем для root)
      1. Присвоить нужные значения переменным среды INUTREE (U для usr и M для root) и INUTEMPDIR (имя ранее созданного временного рабочего каталога).
      2. Если в каталоге пакета существует управляющая программа instal (создавать ее не рекомендуется), то запустить ./instal, в противном случае запустить сценарий по умолчанию /usr/lib/instl/instal . Если управляющая программа instal не существует в каталоге пакета, то задать значение в переменной среды INUSAVEDIR.
      3. Если в каталоге пакета существует управляющая программа update (ее создавать не рекомендуется), то запустить ./update. Если управляющая программа update не существует в каталоге пакета, то запустить сценарий по умолчанию /usr/lib/instl/update.
      4. Если файл status был успешно создан сценарием instal или update, то с помощью файла status определить результат установки каждого набора файлов. Если файл status не был создан, то сделать вывод, что все запрошенные наборы файлов из пакета не были установлены.
      5. Если набор файлов был успешно установлен, то обновить реестр программного обеспечения (SWPD) и зарегистрировать требования соответствующего лицензионного соглашения. Если набор файлов не был установлен, то запустить команду /usr/lib/instl/cleanup или находящийся в каталоге пакета сценарий lpp.cleanup для очистки данных после неудачной установки.

Алгоритм работы стандартного сценария установки или обновления

Команда installp передает в качестве первого параметра сценария установки instal или update имя установочного устройства. Во втором параметре указывается полный путь к файлу со списком устанавливаемых или обновляемых наборов файлов. Ниже этот параметр обозначается $FILESETLIST. Стандартные сценарии instal и update отличаются друг от друга. текущий каталог - это каталог пакета. В каталоге /tmp создается временный каталог INUTEMPDIR для хранения рабочих файлов.

Стандартные сценарии instal и update выполняют следующие действия:

1. Выполнить следующие действия для каждого набора файлов из $FILESETLIST:
   1. Если набор файлов представляет собой обновление, то выполнить программу набор-файлов.pre_u (pre_update) при условии, что она существует. Если набор файлов не является обновлением, то выполнить программу набор-файлов.pre_i (pre_installation) при условии, что она существует.
   2. Создать список файлов для восстановления из пакета, добавив содержимое файла набор-файлов.al в новый файл INUTEMPDIR/master.al.
   3. Если выполняется обновление и необходимо сохранить какие-либо файлы, и при этом существует архивный управляющий файл lpp.acf, то

      Сохранить обновляемые элементы архива библиотек.

   4. Если операция была выполнена успешно, то добавить текущий набор файлов в список устанавливаемых наборов файлов в файле $FILESETLIST.new.
2. Если устанавливается обновление, и необходимо сохранить какие-либо файлы, то запустить сценарий inusave для сохранения текущих версий файлов.
3. При обработке компонента root запустить сценарий inucp для копирования файлов из списка установки компонента root. Если обрабатывается другой компонент, то запустить сценарий inurest для восстановления файлов из списка установки компонента usr.
4. Выполнить следующие действия для каждого набора файлов, указанного в файле $FILESETLIST.new:
   Прим.: В случае возникновения ошибки при выполнении любого из перечисленных шагов информация об этой ошибке записывается в файл status, а обработка набора файлов прекращается.
   1. Проверить, установлена ли в системе текущая или более старая версия набора файлов, а также установлены ли наборы файлов, перечисленные в файле набор-файлов.namelist. Если да, то экспортировать переменные среды INSTALLED_LIST и MIGSAVE. Такая операция называется обновлением версии.
   2. При установке обновления запустить сценарий набор-файлов.post_u (если он существует). Если сценарий набор-файлов.post_u не существует, то запустить набор-файлов.post_i (если он существует).
   3. Если существует файл набор-файлов.cfgfiles, то запустить сценарий /usr/lib/instl/migrate_cfg для обработки файлов конфигурации.
   4. Запустить sysck для добавления информации из файла набор-файлов.inventory в реестр программного обеспечения (SWVPD).
   5. Если существует файл набор-файлов.tcb, и в базе данных ODM /usr/lib/objrepos/PdAt установлен атрибут tcb_enabled, то запустить команду tcbck для добавления в систему информации о защищенной компьютерной базе.
   6. Если существует файл набор-файлов.err, то запустить сценарий errupdate для добавления шаблонов ошибок.
   7. Если существует файл набор-файлов.trc, то добавить шаблоны форматирования отчетов трассировки с помощью команды trcupdate.
   8. Если устанавливается обновление или существует файл рабочий-каталог/набор-файлов.installed_list то вызвать все сценарии вида набор-файлов.odmdel и набор-файлов.*.odmdel для удаления ненужной информации из базы данных ODM.
   9. Вызвать команду odmadd для всех файлов набор-файлов.odmadd и набор-файлов.*.odmadd для добавления информации в базу данных ODM.
   10. Если устанавливается обновление, то запустить сценарий набор-файлов.config_u (обновление конфигурации набора файлов), если он существует. В противном случае запустить сценарий набор-файлов.config (настройка набора файлов), если он существует.
   11. Указать в файле status, что текущий набор файлов успешно обработан.
5. Создать связи с управляющими файлами, необходимыми для удаления набора файлов, в каталоге deinstl пакета. Это могут быть следующие файлы:
   • lpp.deinstal
   • набор-файлов. al
   • набор-файлов. inventory
   • набор-файлов. pre_d
   • набор-файлов. unpre_i
   • набор-файлов. unpre_u
   • набор-файлов. unpost_i
   • набор-файлов. unpost_u
   • набор-файлов. unodmadd
   • набор-файлов. unconfig
   • набор-файлов. unconfig_u
   • $SAVEDIR/набор-файлов. *.rodmadd
   • SAVEDIR/набор-файлов. *.unodmadd

Алгоритмы работы стандартных сценариев аннулирования и очистки

В этом разделе описаны шаги, выполняемые командой installp при аннулировании обновлений и при очистке после неудачной установки наборов файлов. Стандартные сценарии cleanup и reject расположены в каталоге /usr/lib/instl и фактически представляют собой одну и ту же программу. Алгоритм работы этой программы незначительно отличается в случаях, когда она вызывается как reject и как cleanup. Если набор файлов состоит из компонентов usr и root, то компоненты root обрабатываются раньше компонентов usr.

1. Если выполняется операция аннулирования, то убедиться, что одновременно аннулируются все зависимые обновления.
2. Для каждого компонента пакета (например, usr или root) выполнить следующие действия:
   1. Присвоить значения переменным среды INUTREE ( U для usr и M для root.) и INUTEMPDIR.
   2. Если в текущем каталоге (INULIBDIR) существует управляющий файл reject, то запустить сценарий ./lpp.reject. В противном случае запустить сценарий по умолчанию /usr/lib/instl/reject.
3. Обновить реестр программного обеспечения (SWVPD).

Команда installp передает сценарию reject в первом параметре неопределенное значение, а во втором - полное имя файла со списком аннулируемых наборов файлов (ниже этот файл обозначается как $FILESETLIST).

В сценариях cleanup и reject задействован ряд дополнительных файлов.

Стандартные сценарии cleanup и reject выполняют следующие действия:

1. Выполнить следующие действия для каждого набора файлов из $FILESETLIST:
   1. Если вызван сценарий cleanup, определить по содержимому файла имя-пакета.s, на каком шаге была прервана установка, и перейти к соответствующему шагу. Сценарий cleanup начнет работу только с того шага, на котором произошла ошибка при установке. Например, если ошибка произошла при выполнении сценария Набор-файлов.post_i, то очистка для этого набора файлов начнется с шага i, поскольку отмена более поздних операций установки не требуется.
   2. Аннулировать результаты настройки, выполненной во время установки:

      Если требуется аннулировать обновление, то вызвать сценарий набор-файлов.unconfig_u, если он существует. Иначе вызвать сценарий набор-файлов.unconfig, если он существует.

   3. Выполнить сценарии вида набор-файлов.*.unodmadd и набор-файлов.unodmadd для удаления записей ODM, добавленных во время установки.
   4. Выполнить сценарии вида набор-файлов .*.rodmadd и набор-файлов.rodmadd, если они существуют, для восстановления записей ODM, удаленных во время установки.
   5. Если существует файл набор-файлов.undo.trc, то выполнить сценарий trcupdate, который удаляет все изменения, внесенные в шаблоны отчетов трассировки при установке набора файлов.
   6. Если существует файл набор-файлов.undo.err, то вызвать сценарий errupdate, который удаляет все изменения, внесенные в шаблоны ошибок во время установки.
   7. Если существует файл набор-файлов.tcb, и в базе данных ODM /usr/lib/objrepos/PdAt задан атрибут tcb_enabled, то удалить из системы информацию из защищенной компьютерной базы с помощью команды tcbck.
   8. Если существует файл набор-файлов.inventory, то выполнить сценарий sysck, который удаляет изменения, внесенные в базу данных программного обеспечения.
   9. Аннулировать результаты операций настройки, выполненных после установки набора файлов:

      Если требуется аннулировать обновление, то вызвать сценарий набор-файлов.unpost_u, если он существует. Иначе вызвать сценарий набор-файлов.unpost_i, если он существует.

   10. Создать список установки (файл master.al) на основе файлов набор-файла.al.
   11. Добавить набор-файлов в файл $FILESETLIST.new.
2. Если существует файл $INUTEMPDIR/master.al, то выполнить следующие действия:
   1. Перейти в каталог / (root).
   2. Удалить все файлы, указанные в файле master.al.
3. Прочитать файл $FILESETLIST.new и выполнить следующие действия:
   1. С помощью программы inurecv восстановить все сохраненные файлы.
   2. Если требуется аннулировать обновление, то вызвать сценарий набор-файлов.unpre_u, если он существует. Иначе вызвать сценарий набор-файлов.unpre_i, если он существует.
   3. Удалить файлы управления установкой.
4. Удалить файл состояния имя-пакета.s.

Алгоритм удаления программного обеспечения

В этом разделе описаны действия, выполняемые командой installp при удалении набора файлов. Если набор файлов состоит из компонентов usr и root, то компоненты root обрабатываются раньше компонентов usr.

1. Просмотреть список необходимого программного обеспечения и убедиться, что одновременно удаляются все зависимые наборы файлов.
2. Для каждого компонента пакета (например, usr или root) выполнить следующие действия:
   1. Присвоить нужные значения переменным среды INUTREE (U для usr, M для root и S для share) и INUTEMPDIR (рабочий каталог installp в файловой системе /tmp).
   2. Перейти в каталог INULIBDIR.
   3. Если в текущем каталоге существует файл deinstal, то запустить сценарий ./lpp.deinstal. Если управляющий файл deinstal отсутствует в текущем каталоге, то запустить сценарий по умолчанию /usr/lib/instl/deinstal.
3. Удалить файлы, относящиеся к данному набору файлов.
4. Удалить всю информацию о наборе файлов, кроме информации хронологии, из реестра программного обеспечения (SWVPD).
5. Отменить регистрацию лицензионного соглашения на применение набора файлов.

Команда installp передает сценарию deinstal в качестве первого параметра полное имя файла со списком удаляемых наборов файлов. Этот файл в дальнейшем будет обозначаться как $FILESETLIST.

Сценарий deinstal выполняет следующие действия:

1. Выполнить следующие действия для каждого набора файлов, указанного в файле $FILESETLIST:
2. Если существует файл набор-файлов.unconfig_d:

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

3. Если файл набор-файлов.unconfig_d не существует:
   1. Для каждого обновления набора файлов выполнить следующие действия:
      • Выполнить все сценарии набор-файлов.unconfig_u для аннулирования всех изменений, внесенных в конфигурацию при обновлении.
      • Выполнить все сценарии набор-файлов.*.unodmadd и набор-файлов.unodmadd для удаления записей ODM, добавленных во время обновления.
      • Выполнить все сценарии набор-файлов.*.rodmadd и набор-файлов.rodmadd для добавления записей ODM, удаленных во время обновления.
      • Если существует файл набор-файлов.undo.err, то выполнить сценарий errupdate, который аннулирует все изменения в шаблонах ошибок.
      • Если существует файл набор-файлов.undo.trc, то выполнить сценарий trcupdate, который аннулирует изменения в шаблонах отчетов трассировки.
      • Выполнить сценарий набор-файлов.unpost_u, который аннулирует результаты настройки, выполненной после установки обновления.
   2. Для базового уровня набора файлов выполнить следующие действия:
      • Выполнить сценарии вида набор-файлов.*.unodmadd и набор-файлов .unodmadd для удаления записей ODM, добавленных во время установки.
      • Выполнить сценарии вида набор-файлов.*.rodmadd и набор-файлов.rodmadd для добавления в базу данных ODM записей, удаленных во время установки.
      • Если существует файл набор-файлов.undo.err, то выполнить сценарий errupdate, который аннулирует все изменения в шаблонах ошибок.
      • Если существует файл набор-файлов.undo.trc, то выполнить сценарий trcupdate, который аннулирует изменения в шаблонах отчетов трассировки.
      • Выполнить сценарий набор-файлов.unconfig_i, чтобы аннулировать результаты настройки, выполненной во время установки.
      • Выполнить сценарий набор-файлов.unpost_i, чтобы аннулировать результаты настройки, выполненной после установки.
4. Удалить из системы файлы данного набора и информацию о них.
5. Если файл набор-файлов.unconfig_d не существует:
   1. Для каждого обновления набора файлов выполнить все сценарии набор-файлов.unpre_u, чтобы аннулировать результаты настройки, выполненной до установки.
   2. Для базового уровня набора файлов выполнить все сценарии набор-файлов.unpre_i для отмены настройки, выполненной до установки.
6. Удалить все пустые каталоги, оставшиеся после удаления набора файлов.
   Прим.: Если во время выполнения сценария deinstal возникнет ошибка, информация о ней будет занесена в протокол, но выполнение сценария будет продолжено. В этом состоит отличие сценария deinstal от всех остальных сценариев команды installp, которые прекращают обработку набора файлов при возникновении ошибки. Поскольку отменить действие операции удаления нельзя, при возникновении ошибки наиболее разумное решение заключается в продолжении удаления.

Файл результатов установки

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

Ниже приведен пример файла status, в котором указано, что наборы файлов tcp.client и tcp.server из пакета bos.net были установлены успешно, а набор файлов nfs.client установить не удалось.

s bos.net.tcp.client
s bos.net.tcp.server
f bos.net.nfs.client

Примеры применения этих команд можно найти в стандартном сценарии установки - /usr/lib/instl/instal.