В данной главе приводятся практические примеры случаев создания пакета, например, условная установка объектов, определение количества создаваемых файлов во время выполнения программы и изменение существующего файла данных во время установки и удаления пакета.
Рассмотрение каждого практического примера начинается с описания, затем следует перечень использованных методов создания пакета, описания подходов, использованных в этих методах, а также примеры файлов и сценариев, связанных с практическим примером.
В данной главе будут рассмотрены практические примеры.
Создание файла во время установки и сохранение его во время удаления
Изменение файла с помощью стандартных классов и сценариев действий над классами
Установка и удаление драйвера с помощью процедурных сценариев
Установка драйвера с помощью класса sed и процедурных сценариев
В данном практическом примере пакет содержатся три типа объектов. Администратор может выбрать, какой из этих трех типов следует установить и в каком месте эти объекты будут располагаться на целевом компьютере.
В практическом примере применяются следующие методы:
Использование параметрических имен путей (переменные в именах путей объекта), применяемых для создания нескольких базовых каталогов
Для получения информации о параметрических именах пути см. раздел Параметрические имена путей.
Использование сценария request для запроса ввода у администратора
Для получения информации о сценариях request см. раздел Создание сценария request .
Определение условных значений для установочного параметра.
Для настройки выборочной установки в этом практическом примере необходимо выполнить следующие задачи.
Определить класс для каждого типа объекта, который может быть установлен.
В данном практическом примере тремя типами объекта являются исполняемые файлы пакета, справочные страницы и исполняемые файлы emacs. Каждому типу присвоен собственный класс: bin, man и emacs соответственно. Обратите внимание, что в файле prototype все файлы объектов принадлежат к одному из этих трех классов.
Инициализируйте параметр CLASSES в файле pkginfo, установив для него пустое значение.
Обычно при определении класса следует внести этот класс в параметр CLASSES файла pkginfo. В противном случае ни один объект этого класса установлен не будет. В нашем практическом примере параметру первоначально присвоено пустое значение, что означает, что никаких объектов установлено не будет. Параметр CLASSES будет изменен сценарием request в соответствии с выбором, сделанным администратором. Таким образом параметр CLASSES принимает только те типы объектов, которые хочет установить администратор.
Обычно рекомендуется устанавливать для параметров значение по умолчанию. Если в пакете содержатся компоненты, общие для всех трех типов объектов, можно назначить их классу none и затем установить параметр CLASSES равным none.
Вставьте параметрические имена путей в файл prototype.
Сценарий request устанавливает для этих переменных среды значение, предоставленное администратором. После этого в ходе установки команда pkgadd вычисляет эти переменные среды и определяет, куда установить пакет.
Три переменные среды, используемые в данном примере, установлены на соответствующие значения по умолчанию в файле pkginfo и служат следующим целям:
$NCMPBIN определяет местоположение исполняемых файлов объекта
$NCMPMAN определяет местоположение справочных страниц
$EMACS определяет местоположение исполняемых файлов emacs
В примере файла prototype показано, как определить имена пути объекта при помощи переменных.
Создайте сценарий request, который будет запрашивать администратора, какие части пакета следует установить и где они должны быть размещены.
Сценарий request в данном пакете задает администратору два вопроса:
Следует ли установить эту часть пакета?
Если администратор отвечает "да", то к параметру CLASSES добавляется соответствующее имя класса. Например, если администратор решает установить справочные страницы этого пакета, то класс man добавляется к параметру CLASSES.
Если да, где следует разместить эту часть пакета?
Ответ на этот вопрос присваивается соответствующей переменной среды. В примере со справочной страницей ответ на запрос присваивается переменной $NCMPMAN.
Эти два вопроса повторяются для каждого из трех типов объекта.
В конце сценария request эти параметры становятся доступны установочной среде для выполнения команды pkgadd и других сценариев пакета. Сценарий request записывает эти определения в файл, предоставленный вызывающей служебной программой. В нашем практическом примере другие сценарии отсутствуют.
При рассмотрении сценария request для данного практического примера обратите внимание, что вопросы создаются средствами проверки данных ckyorn и ckpath. Для получения дополнительной информации об этих средствах см. ckyorn(1) и ckpath(1).
PKG=ncmp NAME=NCMP Utilities CATEGORY=application, tools BASEDIR=/ ARCH=SPARC VERSION=RELEASE 1.0, Issue 1.0 CLASSES="" NCMPBIN=/bin NCMPMAN=/usr/man EMACS=/usr/emacs |
i pkginfo i request x bin $NCMPBIN 0755 root other f bin $NCMPBIN/dired=/usr/ncmp/bin/dired 0755 root other f bin $NCMPBIN/less=/usr/ncmp/bin/less 0755 root other f bin $NCMPBIN/ttype=/usr/ncmp/bin/ttype 0755 root other f emacs $NCMPBIN/emacs=/usr/ncmp/bin/emacs 0755 root other x emacs $EMACS 0755 root other f emacs $EMACS/ansii=/usr/ncmp/lib/emacs/macros/ansii 0644 root other f emacs $EMACS/box=/usr/ncmp/lib/emacs/macros/box 0644 root other f emacs $EMACS/crypt=/usr/ncmp/lib/emacs/macros/crypt 0644 root other f emacs $EMACS/draw=/usr/ncmp/lib/emacs/macros/draw 0644 root other f emacs $EMACS/mail=/usr/ncmp/lib/emacs/macros/mail 0644 root other f emacs $NCMPMAN/man1/emacs.1=/usr/ncmp/man/man1/emacs.1 0644 root other d man $NCMPMAN 0755 root other d man $NCMPMAN/man1 0755 root other f man $NCMPMAN/man1/dired.1=/usr/ncmp/man/man1/dired.1 0644 root other f man $NCMPMAN/man1/ttype.1=/usr/ncmp/man/man1/ttype.1 0644 root other f man $NCMPMAN/man1/less.1=/usr/ncmp/man/man1/less.1 0644 inixmr other |
trap 'exit 3' 15 # determine if and where general executables should be placed ans=`ckyorn -d y \ -p "Should executables included in this package be installed" ` || exit $? if [ "$ans" = y ] then CLASSES="$CLASSES bin" NCMPBIN=`ckpath -d /usr/ncmp/bin -aoy \ -p "Where should executables be installed" ` || exit $? fi # determine if emacs editor should be installed, and if it should # where should the associated macros be placed ans=`ckyorn -d y \ -p "Should emacs editor included in this package be installed" ` || exit $? if [ "$ans" = y ] then CLASSES="$CLASSES emacs" EMACS=`ckpath -d /usr/ncmp/lib/emacs -aoy \ -p "Where should emacs macros be installed" ` || exit $? fi |
Обратите внимание, что выполнение сценария request может завершиться таким образом, что ни один из файлов не останется в файловой системе. Для установки в системе Solaris версий ниже 2.5 и совместимых версий (где нельзя использовать сценарий checkinstall), сценарий request подходит наилучшим образом для тестирования файловой системы с тем, чтобы обеспечить успешную установку. Если выполнение сценария request завершается с кодом 1, произойдет чистый выход из процесса установки.
В данных файлах примеров показано, как использовать параметрические пути для создания нескольких базовых каталогов. Однако предпочтительнее использовать параметр BASEDIR, который управляется и проверяется командой pkgadd. При использовании нескольких базовых каталогов необходимо особо тщательно следить за установкой нескольких версий и архитектур на одну и ту же платформу.
В данном практическом примере в ходе установки будет создан файл базы данных и его копия сохранена после удаления пакета.
В практическом примере применяются следующие ниже методы.
Использование классов и сценариев действий над классами для выполнения особых действий на различных наборах объектов
Для получения дополнительной информации см. раздел Создание сценариев действий над классами.
Использование файла space для сообщения команде pkgadd о необходимости дополнительного дискового пространства для корректной установки данного пакета
Для получения дополнительной информации о файле space см. раздел Резервирование дополнительного места на диске на целевой системе.
Использование команды installf для установки файла, не определенного в файлах prototype и pkgmap.
Чтобы создать файл базы данных в ходе установки и сохранить его копию при удалении, необходимо выполнить следующие ниже задачи.
Определите три класса.
Для данного практического примера пакета требуется определение следующих трех классов в параметре CLASSES:
Стандартный класс none, содержащий набор процессов, принадлежащий подкаталогу bin.
Класс admin, содержащий исполняемый файл config, а также каталог с файлами данных.
Класс cfgdata, содержащий каталог.
Сделайте пакет коллективно перемещаемым.
Обратите внимание, что в файле prototype ни одно из имен путей не начинается с косой черты или с переменной среды. Это означает, что они являются коллективно перемещаемыми.
Вычислите объем дискового пространства, требуемого для файла базы данных, и создайте файл space, который будет поставляться в составе пакета. Данный файл уведомляет команду pkgadd, что для пакета требуется дополнительное пространство и указывает его объем.
Создайте сценарий действия над классом для класса admin (i.admin).
Пример сценария инициализирует базу данных, используя файлы данных, принадлежащие классу admin. Для выполнения этой задачи сценарий выполняет следующие действия.
Копирует исходный файл данных в предназначенное место
Создает пустой файл с именем config.data и назначает его классу cfgdata
Выполняет команду bin/config (поставляемую с пакетом и уже установленную) для наполнения данными файла базы данных config.data с помощью файлов данных, принадлежащих классу admin
Выполняет команду installf -f для завершения установки файла config.data
Никакие особые действия для класса admin во время удаления пакета не требуются, поэтому сценарий действия над классом во время удаления не создается. Это означает, что все файлы и каталоги в классе admin удаляются из системы.
Создайте сценарий действия над классом для класса cfgdata (r.cfgdata).
Сценарий удаления создает копию файла базы данных перед его удалением. Никакие особые действия для этого класса во время установки не требуется, поэтому сценарий действия над классом во время установки не нужен.
Помните, что в качестве входных данных для сценария удаления выступает список имен путей, которые необходимо удалить. Имена путей всегда идут в обратном алфавитном порядке. Сценарий удаления копирует файлы в каталог с именем $PKGSAV. После обработки всех имен путей сценарий возвращается назад и удаляет все каталоги и файлы, связанные с классом cfgdata.
Результатом выполнения этого сценария удаления является копирование файла config.data в каталог $PKGSAV и последующее удаление файла config.data и каталога с данными.
PKG=krazy NAME=KrAzY Applications CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1 CLASSES=none cfgdata admin |
i pkginfo i request i i.admin i r.cfgdata d none bin 555 root sys f none bin/process1 555 root other f none bin/process2 555 root other f none bin/process3 555 root other f admin bin/config 500 root sys d admin cfg 555 root sys f admin cfg/datafile1 444 root sys f admin cfg/datafile2 444 root sys f admin cfg/datafile3 444 root sys f admin cfg/datafile4 444 root sys d cfgdata data 555 root sys |
# extra space required by config data which is # dynamically loaded onto the system data 500 1 |
# PKGINST parameter provided by installation service # BASEDIR parameter provided by installation service while read src dest do cp $src $dest || exit 2 done # if this is the last time this script will be executed # during the installation, do additional processing here. if [ "$1" = ENDOFCLASS ] then # our config process will create a data file based on any changes # made by installing files in this class; make sure the data file # is in class `cfgdata' so special rules can apply to it during # package removal. installf -c cfgdata $PKGINST $BASEDIR/data/config.data f 444 root sys || exit 2 $BASEDIR/bin/config > $BASEDIR/data/config.data || exit 2 installf -f -c cfgdata $PKGINST || exit 2 fi exit 0 |
Здесь продемонстрирован редкий случай, когда команда installf может быть необходима для сценария действия над классом. Поскольку файл space использовался для резервирования пространства в конкретной файловой системе, этот новый файл может быть добавлен в пакет несмотря на то, что он не включен в файл pkgmap.
# the product manager for this package has suggested that # the configuration data is so valuable that it should be # backed up to $PKGSAV before it is removed! while read path do # path names appear in reverse lexical order. mv $path $PKGSAV || exit 2 rm -f $path || exit 2 done exit 0 |
Пакет в данном практическом примере использует необязательные информационные файлы для определения совместимости и зависимостей пакета, а также для вывода сообщения об авторских правах во время установки.
В практическом примере применяются следующие ниже методы.
Использование файла copyright
Использование файла compver
Использование файла depend
Для получения дополнительной информации об этих файлах см. раздел Создание информационных файлов.
Для обеспечения соответствия требованиям, указанным в описании, необходимо выполнить следующие действия.
Создать файл copyright.
Файл copyrightсодержит сообщение об авторских правах в текстовом формате с кодировкой ASCII. Сообщение, приведенное в файле примера, отображается на дисплее компьютера в ходе установки пакета.
Создать файл compver.
Файл pkginfo, приведенный ниже, определяет версию пакета как версию 3.0. Файл compver определяет версию 3.0 как совместимую с версиями 2.3, 2.2, 2.1, 2.1.1, 2.1.3 и 1.7.
Создать файл depend.
Файлы, перечисленные в файле depend, должны уже быть установлены в системе во время установки пакета. Файл примера содержит 11 пакетов, которые уже должны быть установлены в системе во время установки.
PKG=case3 NAME=Case Study #3 CATEGORY=application BASEDIR=/opt ARCH=SPARC VERSION=Version 3.0 CLASSES=none |
Copyright (c) 1999 company_name All Rights Reserved. THIS PACKAGE CONTAINS UNPUBLISHED PROPRIETARY SOURCE CODE OF company_name. The copyright notice above does not evidence any actual or intended publication of such source code |
Version 3.0 Version 2.3 Version 2.2 Version 2.1 Version 2.1.1 Version 2.1.3 Version 1.7 |
P acu Advanced C Utilities Issue 4 Version 1 P cc C Programming Language Issue 4 Version 1 P dfm Directory and File Management Utilities P ed Editing Utilities P esg Extended Software Generation Utilities Issue 4 Version 1 P graph Graphics Utilities P rfs Remote File Sharing Utilities Issue 1 Version 1 P rx Remote Execution Utilities P sgs Software Generation Utilities Issue 4 Version 1 P shell Shell Programming Utilities P sys System Header Files Release 3.1 |
В данном практическом примере происходит изменение существующего файла в ходе установки пакета с помощью стандартных классов и сценариев действий над классами. Здесь используется один из трех способов изменения файла. Два других способа описаны в разделах Изменение файла с помощью класса sed и сценария postinstall и Изменение файла с помощью класса build. Изменяемый файл называется /etc/inittab.
В данном практическом примере показано, как использовать сценарии действий над классами в ходе установки и удаления пакета. Для получения дополнительной информации см. раздел Создание сценариев действий над классами.
Для изменения файла /etc/inittab в ходе установки с помощью классов и сценариев действий над классами необходимо выполнить следующие ниже задачи.
Создать класс.
Создайте класс с именем inittab. Для этого класса необходимо создать сценарий действия над классом в ходе установки и удаления. Определите inittab в параметре CLASSES файла pkginfo.
Создать файл inittab.
В данном файле содержится информация для записи, которая будет добавлена в файл /etc/inittab. Обратите внимание в примере файла prototype, что файл inittab является членом класса inittab и принадлежит к файлу типа e (редактируемый).
Создать сценарий действия над классом во время установки (i.inittab).
Помните, что сценарии действий над классами должны выдавать одинаковые результаты при каждом выполнении. Сценарий действия над классом выполняет следующие действия.
Проверяет, не была ли данная запись добавлена ранее
Если это так, удаляет все предыдущие версии записи
Редактирует файл inittab и добавляет строки с комментариями о происхождении этой записи
Перемещает временный файл обратно в файл /etc/inittab
Выполняет команду init q после получения признака ENDOFCLASS
Обратите внимание, что в данном сценарии установки можно выполнять команду init q. При таком подходе состоящий из одной строки сценарий postinstall не понадобится.
Создать сценарий действия над классом во время удаления (r.inittab).
Сценарий удаления очень похож на сценарий установки. Информация, добавленная сценарием установки, удаляется и выполняется команда init q.
Данный практический пример более сложный, чем следующий; см. Изменение файла с помощью класса sed и сценария postinstall. Требуются три файла вместо двух, и поставляемый файл /etc/inittab в действительности является лишь местозаполнителем, содержащим фрагмент записи, которая будет вставлена. Эту запись можно было бы разместить в файле i.inittab, однако для этого команде pkgadd нужен файл, который будет передан в файл i.inittab. Кроме того, процедура удаления в этом случае должна быть размещена в отдельном файле (r.inittab). Хотя данный способ работает хорошо, лучше использовать его для случаев, когда требуется очень сложная установка большого количества файлов. См. раздел Изменение файлов crontab в ходе установки.
Программа sed, используемая в разделеИзменение файла с помощью класса sed и сценария postinstall, поддерживает большое количество экземпляров пакета, поскольку комментарий в конце записи inittab основан на экземпляре пакета. В практическом примере в разделе Изменение файла с помощью класса build используется более простой подход для редактирования файла /etc/inittab в ходе установки.
PKG=case5 NAME=Case Study #5 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=inittab |
i pkginfo i i.inittab i r.inittab e inittab /etc/inittab ? ? ? |
# PKGINST parameter provided by installation service while read src dest do # remove all entries from the table that # associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest > /tmp/$$itab || exit 2 sed -e "s/$/#$PKGINST" $src >> /tmp/$$itab || exit 2 mv /tmp/$$itab $dest || exit 2 done if [ "$1" = ENDOFCLASS ] then /sbin/init q || exit 2 fi exit 0 |
# PKGINST parameter provided by installation service while read src dest do # remove all entries from the table that # are associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest > /tmp/$$itab || exit 2 mv /tmp/$$itab $dest || exit 2 done /sbin/init q || exit 2 exit 0 |
rb:023456:wait:/usr/robot/bin/setup |
В данном практическом примере происходит изменение файла, существующего на целевом компьютере в ходе установки пакета. Здесь используется один из трех способов изменения файла. Два других способа описаны в разделахИзменение файла с помощью стандартных классов и сценариев действий над классами и Изменение файла с помощью класса build. Изменяемый файл называется /etc/inittab.
В практическом примере применяются следующие ниже методы.
Использование класса sed
Для получения дополнительной информации о классе sed см. раздел Сценарий класса sed .
Использование сценария postinstall
Для получения дополнительной информации об этом сценарии см. раздел Создание процедурных сценариев .
Для изменения файла /etc/inittab в ходе установки с помощью класса sed, необходимо выполнить следующие задачи:
Добавьте сценарий класса sed в файл prototype.
Название сценария должно совпадать с именем файла, который предстоит редактировать. В нашем случае редактируемый файл называется /etc/inittab, и сценарий sed также будет называться /etc/inittab. В сценарии sed отсутствуют требования по режиму, владельцу и группе (они представлены в образце файла prototype вопросительными знаками). Файл сценария sed должен относиться к типу e (редактируемый).
Включите в параметр CLASSES класс sed.
Как показано в примере ниже, sed является единственным устанавливаемым классом. Однако количество классов может быть любым.
Создать сценарий действия над классом sed.
В пакет не может быть включена копия файла /etc/inittabв необходимом виде, поскольку /etc/inittab является динамическим файлом и неизвестно, как он будет выглядеть в период установки пакета. Однако сценарий sed позволяет изменять файл /etc/inittab в ходе установки пакета.
Создайте сценарий postinstall.
Необходимо выполнить команду init q для извещения системы о том, что файл /etc/inittab был изменен. Единственное место, где можно выполнить это действие в нашем примере, это сценарий postinstall. При рассмотрении примера сценария postinstall видно, что его единственное предназначение - выполнение команды init q.
Данный подход к изменению файла /etc/inittab в ходе установки имеет один недостаток - приходится поставлять полный сценарий (сценарий postinstall) лишь для того, чтобы выполнить команду init q.
PKG=case4 NAME=Case Study #4 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=sed |
i pkginfo i postinstall e sed /etc/inittab ? ? ? |
!remove # remove all entries from the table that are associated # with this package, though not necessarily just # with this package instance /^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d !install # remove any previous entry added to the table # for this particular change /^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d # add the needed entry at the end of the table; # sed(1) does not properly interpret the '$a' # construct if you previously deleted the last # line, so the command # $a\ # rb:023456:wait:/usr/robot/bin/setup #ROBOT # will not work here if the file already contained # the modification. Instead, you will settle for # inserting the entry before the last line! $i\ rb:023456:wait:/usr/robot/bin/setup #ROBOT |
# make init re-read inittab /sbin/init q || exit 2 exit 0 |
В данном практическом примере происходит изменение файла, существующего на целевом компьютере в ходе установки пакета. Здесь используется один из трех способов изменения файла. Два других способа описаны в разделах Изменение файла с помощью стандартных классов и сценариев действий над классами и Изменение файла с помощью класса sed и сценария postinstall. Изменяемый файл называется /etc/inittab.
В данном практическом примере показано, как использовать класс build. Для получения дополнительной информации о классе build см. раздел Сценарий класса build .
Данный подход к изменению /etc/inittab использует класс build. Сценарий класса build выполняется как сценарий интерпретатора команд, и результатом его выполнения становится новая версия исполняемого файла. Другими словами, файл данных /etc/inittab, поставляемый с этим пакетом, будет выполнен, и результатом этого выполнения станет файл /etc/inittab.
Сценарий класса build выполняется в ходе установки и удаления пакета. Параметр install передается файлу, если сценарий выполняется в ходе установки. В сценарии класса build обратите внимание на то, что действия по установке определяются посредством проверки этого параметра.
Для изменения файла /etc/inittab с помощью класса build необходимо выполнить следующие задачи.
Определить файл build в файле prototype.
Запись для файла build в файле prototype должна поместить последний в класс build и определить его тип как e (редактируемый). Убедитесь, что параметр CLASSES в файле pkginfo определен как build.
Создать сценарий класса build.
Приведенный в примере сценарий класса build делает следующее:
Изменяет файл /etc/inittab таким образом, чтобы позволить ему удалить любые существующие изменения этого пакета. Обратите внимание, что имя файла /etc/inittab жестко прописано в команде sed.
Если пакет устанавливается, добавляет новую строку к концу файла /etc/inittab. В этой строке дается комментарий с описанием происхождения данной записи.
Выполняет команду init q.
Данное решение устраняет недостатки, описанные в практических примерах Изменение файла с помощью стандартных классов и сценариев действий над классами и Изменение файла с помощью класса sed и сценария postinstall. Требуется лишь один короткий файл (помимо файлов pkginfo и prototype). Этот файл работает с несколькими экземплярами пакета, поскольку используется параметр PKGINST, а сценарий postinstall не требуется, так как команду init q можно выполнить из сценария класса build.
PKG=case6 NAME=Case Study #6 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=build |
i pkginfo e build /etc/inittab ? ? ? |
# PKGINST parameter provided by installation service # remove all entries from the existing table that # are associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" /etc/inittab || exit 2 if [ "$1" = install ] then # add the following entry to the table echo "rb:023456:wait:/usr/robot/bin/setup #$PKGINST" || exit 2 fi /sbin/init q || exit 2 exit 0 |
В данном практическом примере происходит изменение файлов crontab в ходе установки пакета.
В практическом примере применяются следующие методы:
Использование классов и сценариев действий над классами
Для получения дополнительной информации см. раздел Создание сценариев действий над классами.
Использование команды crontab в сценарии действия над классом.
Наиболее эффективным способом изменить несколько файлов в ходе установки является определение класса и создание сценария действия над классом. При использовании подхода с классом build необходимо поставлять один сценарий класса build для каждого изменяемого файла crontab. Более общим подходом будет создание класса cron. Для изменения файлов crontab при этом подходе необходимо:
Определить файлы crontab, которые будут изменяться, в файле prototype.
Создайте запись в файле prototype для каждого файла crontab, который будет изменен. Для каждого файла определите класс как cron и тип файла как e. Используйте действительное имя изменяемого файла.
Создать для пакета файлы crontab.
В этих файлах содержится информация, которую необходимо добавить к одноименным существующим файлам crontab.
Создать установочный сценарий действия над классом для класса cron.
Приведенный в примере сценарий класса i.cron делает следующее:
Определяет идентификатор пользователя (UID).
Сценарий i.cron устанавливает значение переменной user равной базовому имени выполняемого сценария класса cron. Это имя и является идентификатором пользователя (UID). Например, базовым именем /var/spool/cron/crontabs/root является root, который одновременно представляет собой UID.
Выполняет команду crontab с использованием UID и параметра -l.
Использование параметра -l означает для команды crontab, что следует направить содержимое файла crontab для определенного пользователя на стандартный вывод.
Передает результаты выполнения команды crontab в сценарий sed, который удаляет все предыдущие записи, добавленные с помощью данного метода установки.
Помещает измененное содержимое во временный файл.
Добавляет файл данных для корневого UID (поставленного с пакетом) во временный файл и добавляет метку о происходжении записей.
Выполняет команду crontabс тем же UID и передает результаты во временный файл в качестве входных данных.
Создать удаляющий сценарий действия над классом для класса cron.
Сценарий r.cron похож на установочный сценарий, за исключением отсутствия процедуры добавления данных в файл crontab.
Эти процедуры выполняются для каждого файла в классе cron.
Сценарии i.cron и r.cron, приведенные ниже, выполняются суперпользователем. Изменение суперпользователем файла crontab другого пользователя может привести к непредсказуемым результатам. При необходимости измените следующую запись в каждом сценарии:
crontab $user < /tmp/$$crontab ||
на
su $user -c "crontab /tmp/$$crontab" ||
PKG=case7 NAME=Case Study #7 CATEGORY=application BASEDIR=/opt ARCH=SPARC VERSION=Version 1.0 CLASSES=cron |
i pkginfo i i.cron i r.cron e cron /var/spool/cron/crontabs/root ? ? ? e cron /var/spool/cron/crontabs/sys ? ? ? |
# PKGINST parameter provided by installation service while read src dest do user=`basename $dest` || exit 2 (crontab -l $user | sed -e "/#$PKGINST$/d" > /tmp/$$crontab) || exit 2 sed -e "s/$/#$PKGINST/" $src >> /tmp/$$crontab || exit 2 crontab $user < /tmp/$$crontab || exit 2 rm -f /tmp/$$crontab done exit 0 |
# PKGINST parameter provided by installation service while read path do user=`basename $path` || exit 2 (crontab -l $user | sed -e "/#$PKGINST$/d" > /tmp/$$crontab) || exit 2 crontab $user < /tmp/$$crontab || exit 2 rm -f /tmp/$$crontab done exit |
41,1,21 * * * * /usr/lib/uucp/uudemon.hour > /dev/null 45 23 * * * ulimit 5000; /usr/bin/su uucp -c "/usr/lib/uucp/uudemon.cleanup" > /dev/null 2>&1 11,31,51 * * * * /usr/lib/uucp/uudemon.poll > /dev/null |
0 * * * 0-6 /usr/lib/sa/sa1 20,40 8-17 * * 1-5 /usr/lib/sa/sa1 5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A |
Если при изменении группы файлов общий размер файлов увеличится более чем на 10 КБ, создайте файл space для того, чтобы команда pkgadd приняла во внимание это увеличение. Для получения дополнительной информации о файле space см. раздел Резервирование дополнительного места на диске на целевой системе.
Данный пакет производит установку драйвера.
В практическом примере применяются следующие методы:
Установка и загрузка драйвера с помощью сценария postinstall
Выгрузка драйвера с помощью сценария preremove
Для получения дополнительной информации об этих сценариях см. раздел Создание процедурных сценариев .
Создайте сценарий request.
Сценарий request определяет место, куда администратор хочет установить объекты драйвера, задавая администратору вопросы и назначая ответы параметру $KERNDIR.
Сценарий заканчивается подпрограммой, делающей два параметра - CLASSES и KERNDIR - доступными для среды установки и для сценарияpostinstall.
Создайте сценарий postinstall.
Сценарий postinstall производит непосредственную установку драйвера. Сценарий выполняется после того, как будут установлены два файла: buffer и buffer.conf. Файл postinstall, представленный в данном примере, выполняет следующие действия:
Использует команду add_drv для загрузки драйвера в систему.
Создает ссылку для устройства с помощью команды installf.
Завершает установку с помощью команды installf -f.
Создает сценарий preremove.
Сценарий preremove использует команду rem_drv для выгрузки драйвера из системы, а затем удаляет ссылку /dev/buffer0.
PKG=bufdev NAME=Buffer Device CATEGORY=system BASEDIR=/ ARCH=INTEL VERSION=Software Issue #19 CLASSES=none |
Для установки драйвера в ходе установки пакета необходимо включить объект и файлы настройки драйвера в файл prototype.
В данном примере исполняемый модуль драйвера называется buffer. Команда add_drv работает с этим файлом. Ядро системы использует файл настройки buffer.conf для помощи в настройке драйвера.
i pkginfo i request i postinstall i preremove f none $KERNDIR/buffer 444 root root f none $KERNDIR/buffer.conf 444 root root |
При рассмотрении файла prototype в этом примере обратите внимание на следующее:
Поскольку особой обработки объектов пакета не требуется, их можно поместить в стандартный класс none. Параметру CLASSES присваивается значение none в файле pkginfo.
Имена пути файлов buffer и buffer.conf начинаются с переменной $KERNDIR. Эта переменная устанавливается в сценарии request и позволяет администратору решить, куда устанавливать файлы драйвера. Каталог по умолчанию - /kernel/drv.
Существует запись для сценария postinstall (сценария, который будет производить установку драйвера).
trap 'exit 3' 15 # determine where driver object should be placed; location # must be an absolute path name that is an existing directory KERNDIR=`ckpath -aoy -d /kernel/drv -p \ “Where do you want the driver object installed”` || exit $? # make parameters available to installation service, and # so to any other packaging scripts cat >$1 <<! CLASSES='$CLASSES' KERNDIR='$KERNDIR' ! exit 0 |
# KERNDIR parameter provided by `request' script err_code=1 # an error is considered fatal # Load the module into the system cd $KERNDIR add_drv -m '* 0666 root sys' buffer || exit $err_code # Create a /dev entry for the character node installf $PKGINST /dev/buffer0=/devices/eisa/buffer*:0 s installf -f $PKGINST |
err_code=1 # an error is considered fatal # Unload the driver rem_drv buffer || exit $err_code # remove /dev file removef $PKGINST /dev/buffer0 ; rm /dev/buffer0 removef -f $PKGINST |
В данном практическом примере описывается, как установить драйвер с помощью класса sed и процедурных сценариев. Он отличается от предыдущего практического примера (см. раздел Установка и удаление драйвера с помощью процедурных сценариев), поскольку данный пакет состоит как из абсолютных, так и перемещаемых объектов.
В практическом примере применяются следующие методы:
Создание файла prototype с абсолютными и перемещаемыми объектами.
Для получения дополнительной информации о создании файла prototype см. раздел Создание файла prototype.
Использование сценария postinstall
Для получения дополнительной информации об этом сценарии см. раздел Создание процедурных сценариев .
Использование сценария preremove
Для получения дополнительной информации об этом сценарии см. раздел Создание процедурных сценариев .
Использование файла copyright
Для получения информации об этом файле см. раздел Создание сообщения об авторских правах.
Создайте файл prototype, содержащий абсолютные и перемещаемые объекты пакета.
Подробности создания такого файла приведены в разделе Файл prototype.
Добавьте сценарий класса sed в файл prototype.
Название сценария должно совпадать с именем файла, который предстоит редактировать. В данном случае изменяемый файл называется /etc/devlink.tab, поэтому сценарий sed также будет называться /etc/devlink.tab. В сценарии sed отсутствуют требования по режиму, владельцу и группе (они представлены в образце файла prototype вопросительными знаками). Файл сценария sed должен относиться к типу e (редактируемый).
Включите в параметр CLASSES класс sed.
Создайте сценарий действия над классом sed (/etc/devlink.tab ).
Создайте сценарий postinstall.
Для добавления драйвера устройства в систему, сценарию postinstall необходимо выполнить команду add_drv.
Создайте сценарий preremove.
Для удаления драйвера устройства из системы, сценарию preremove необходимо выполнить команду rem_drv до удаления пакета.
Создайте файл copyright.
Файл copyrightсодержит сообщение об авторских правах в текстовом формате с кодировкой ASCII. Сообщение, приведенное в файле примера, отображается на дисплее компьютера в ходе установки пакета.
PKG=SUNWsst NAME=Simple SCSI Target Driver VERSION=1 CATEGORY=system ARCH=sparc VENDOR=Sun Microsystems BASEDIR=/opt CLASSES=sed |
В нашем практическом примере используется иерархическое распределение объектов пакета, как показано на рисунке ниже.
Объекты пакета устанавливаются в то же место, в котором они расположены в каталоге pkgвыше. Модули драйвера ( sst и sst.conf) устанавливаются в каталог /usr/kernel/drv, а вложенный файл в каталог /usr/include/sys/scsi/targets. Файлы sst, sst.conf и sst_def.h являются абсолютными объектами. Тестовая программа sstest.c и ее каталог SUNWsst являются перемещаемыми; место их установки определяется параметром BASEDIR.
Оставшиеся компоненты пакета (все контрольные файлы) помещаются в каталог верхнего уровня пакета на компьютере разработчика, за исключением сценария класса sed. Сценарий называется devlink.tab в соответствии с изменяемым им файлом и помещается в каталог etc, содержащий действительный файл devlink.tab.
Из каталога pkg выполните команду pkgproto следующим образом:
find usr SUNWsst -print | pkgproto > prototype |
Результат выполнения этой команды выглядит так:
d none usr 0775 pms mts d none usr/include 0775 pms mts d none usr/include/sys 0775 pms mts d none usr/include/sys/scsi 0775 pms mts d none usr/include/sys/scsi/targets 0775 pms mts f none usr/include/sys/scsi/targets/sst_def.h 0444 pms mts d none usr/kernel 0775 pms mts d none usr/kernel/drv 0775 pms mts f none usr/kernel/drv/sst 0664 pms mts f none usr/kernel/drv/sst.conf 0444 pms mts d none SUNWsst 0775 pms mts f none SUNWsst/sstest.c 0664 pms mts |
Создание данного файла prototype еще не завершено. Чтобы закончить создание этого файла, произведите следующие изменения:
Вставьте записи для контрольных файлов (тип файла i), поскольку в них содержится информация, отличная от других объектов пакета.
Удалите записи для каталогов, уже существующих в целевой системе.
Измените права доступа и принадлежность каждой записи.
Добавьте косую черту к началу абсолютных объектов пакета.
Окончательный файл prototype выглядит так:
i pkginfo i postinstall i preremove i copyright e sed /etc/devlink.tab ? ? ? f none /usr/include/sys/scsi/targets/sst_def.h 0644 bin bin f none /usr/kernel/drv/sst 0755 root sys f none /usr/kernel/drv/sst.conf 0644 root sys d none SUNWsst 0775 root sys f none SUNWsst/sstest.c 0664 root sys |
Знаки вопроса в строке для сценария sed указывают, что права доступа и принадлежность существующего файла на целевом компьютере не должны изменяться.
В примере с драйвером сценарий класса sed используется для добавления записи для драйвера в файл /etc/devlink.tab. Этот файл используется командой devlinks для создания символической ссылки из /dev в /devices. Сценарий sed выглядит так:
# sed class script to modify /etc/devlink.tab !install /name=sst;/d $i\ type=ddi_pseudo;name=sst;minor=character rsst\\A1 !remove /name=sst;/d |
Команда pkgrm не выполняет часть сценария, ответственную за удаление. Может понадобится добавление строки в сценарий preremove для того, чтобы класс sed удалил записи из файла /etc/devlink.tab напрямую.
В данном практическом примере сценарию необходимо лишь выполнить команду add_drv.
# Postinstallation script for SUNWsst # This does not apply to a client. if [$PKG_INSTALL_ROOT = "/" -o -z $PKG_INSTALL_ROOT]; then SAVEBASE=$BASEDIR BASEDIR=””; export BASEDIR /usr/sbin/add_drv sst STATUS=$? BASEDIR=$SAVEBASE; export BASEDIR if [ $STATUS -eq 0 ] then exit 20 else exit 2 fi else echo "This cannot be installed onto a client." exit 2 fi |
Команда add_drv использует параметр BASEDIR, поэтому сценарию необходимо отменить установку параметра BASEDIR перед выполнением команды и восстановить его после выполнения.
Одним из действий, выполняемых командой add_drv, является выполнение команды devlinks, которая использует запись, размещенную в каталоге /etc/devlink.tab сценарием класса sed для создания записей /dev для драйвера.
Очень важен код выхода из сценария postinstall. Код выхода 20 указывает команде pkgadd известить пользователя о необходимости перезагрузки системы после установки драйвера, а код выхода 2 указывает команде pkgadd известить пользователя о том, что установка частично не удалась.
В практическом примере с данным драйвером этот сценарий удаляет ссылки в каталоге /dev и выполняет команду rem_drv на драйвере.
# Pre removal script for the sst driver echo “Removing /dev entries” /usr/bin/rm -f /dev/rsst* echo “Deinstalling driver from the kernel” SAVEBASE=$BASEDIR BASEDIR=””; export BASEDIR /usr/sbin/rem_drv sst BASEDIR=$SAVEBASE; export BASEDIR exit |
Сценарий самостоятельно удаляет записи /dev; записи /devices удаляются командой rem_drv.
Это простой файл ASCII, содержащий текст уведомления об авторских правах. Уведомление отображается в начале установки пакета точно в таком же виде, как оно представлено в файле.
Copyright (c) 1999 Drivers-R-Us, Inc. 10 Device Drive, Thebus, IO 80586 All rights reserved. This product and related documentation is protected by copyright and distributed under licenses restricting its use, copying, distribution and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of Drivers-R-Us and its licensors, if any. |