Создание файлов пользовательской конфигурации

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

1. При необходимости добавьте код продукта в файл codename.cfg.
2. Создайте файл конфигурации, используя текстовый редактор в каталоге ips_root/OS. Для имени файла соблюдайте следующие правила именования:

   product_code_version.cfg

   Где:

   • product_code

     Это переменная для представления кода продукта в системах Windows или UNIX. Коды продуктов идентифицируют продукт и (необязательно) поддерживаемую продуктом версию операционной системы. Они хранятся в файле codename.cfg. У продукта, поддерживающего несколько платформ, может быть несколько кодов продукта, каждый из которых идентифицирует продукт, платформу и версию операционной системы, если она требуется.

   • version - это код из 8 цифр, представляющий версию, выпуск, модификацию и уровень, с 2 цифрами для каждой части кода; например, 7.3.21 означает 07032100.
3. Просмотрите базовые свойства предварительных требований, описанные в разделе Справочник по обязательным предварительным свойствам, и выясните, какие свойства предварительных требований вам нужно проверять.
4. Необязательно: Добавьте раздел, соблюдая правила именования для заголовка раздела. Смотрите раздел Разделы в файлах конфигурации.
5. Необязательно: Для каждого раздела просмотрите базовые свойства предварительных требований, описанные в разделе Справочник по обязательным предварительным свойствам, и выясните, какие свойства предварительных требований вам нужно проверять.
6. Для каждого свойства предварительного требования, которое нужно добавить, введите пару имя - значение для пользовательского свойства предварительного требования и ожидаемое значение. Для ожидаемого значения можно задавать спецификаторы и уровень защиты. Соблюдайте следующий формат, задавая по одному свойству предварительного требования на строке:

   [prefix_identifier.]property_name[.suffix_identifier]=
   [[sev:FAIL|WARN]][[qualifier_name:qualifier_value]]property_value

   где:

   • prefix_identifier - это идентификатор для предварительно определенной категории свойств предварительных требований, как описано в разделе Табл. 1. Этот префиксный идентификатор требуется для некоторых предварительно определенных категорий.
   • property_name - это имя предварительного свойства.
   • suffix_identifier - это необязательный идентификатор для подтипа свойств предварительных требований, как описано в разделе Табл. 1.
   • sev:FAIL|WARN - это необязательный уровень серьезности для свойства предварительного требования, как описано в разделе Уровни серьезности.
     Прим.: Уровень серьезности нужно заключать в квадратные скобки [].
   • qualifier_name - это дополнительный атрибут для свойства предварительного требования. IBM Prerequisite Scanner использует его как спецификатор, уточняющий свойство предварительного требования или тип проверки, который нужно выполнять для свойства предварительного требования.
     Прим.: Можно задать несколько спецификаторов через запятую. Набор спецификаторов нужно заключать в квадратные скобки [].
   • qualifier_value - это значение дополнительного атрибута. Каждый спецификатор должен отделяться от своего значения двоеточием :.
   • property_value - это значение свойства предварительного требования; может быть строковым значением или целым числом.

   Например, у пользовательской предварительно определенной категории свойств предварительных требований префиксный идентификатор user. Свойство предварительного требования для проверки, входит ли зарегистрировавшийся пользователь в группу администраторов: user.isAdmin=True
7. Если свойство предварительного требования на существует в предварительно определенных категориях, добавьте имя пользовательского свойства предварительного требования, значение и необязательные спецификаторы. Затем нужно создать следующие файлы, чтобы проверить наличие и сравнить значение пользовательского свойства предварительного требования, как нужно: пользовательский сборщик, чтобы собрать фактическое значение свойства предварительного требования, и пользовательский оценщик, если стандартные функции сравнения не могут сравнить фактическое и ожидаемое значения.