Служба управления конфигурациями "Осмакс"

Руководство по эксплуатации

Версия 1.3.1

Содержание

    Общие сведения

    Раздел содержит инструкции по настройке и использованию продукта «Служба управления конфигурациями» (LCM).

    Основные понятия

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

    Сервер управления

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

    Агент

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

    Методы управления агентами

    Модуль координации поддерживает следующие методы управления агентами:

    Удаленное выполнение

    Удаленное выполнение реализовано посредством модуля выполнения.

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

    Команды состоят из:

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

    • описания цели — агентов, на которых должна быть выполнена задача;

    • функции исполнения — кода на языке Python, который должен быть выполнен на агентах;

    • аргументов функции — значений, которые передаются в функцию при ее вызове.

    Цели

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

    Цель — это группа агентов на одном или нескольких серверах управления, к которым применяется Salt-команда.

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

    Ниже приведен пример простой команды:

    salt '*' test.ping

    Где:

    • звездочка (*) — цель, которая определяет всех агентов;

    • test.ping — передает агентам команду запустить функцию test.ping:

    Модуль координации позволяет указывать агентов в качестве цели по большому количеству критериев:

    Пример 1:

    salt 'larry1, larry2, curly1' test.ping

    Пример 2:

    salt 'larry*' test.ping

    Пример 3:

    salt '*1' test.ping

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

    Параметры Grains

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

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

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

    Пример команды:

    salt -G 'os:Ubuntu' test.version

    Где:

    • -G — определяет, что модуль координации будет выполнять команду на узлах, у которых есть заданный групповой тег; групповой тег определяется по значению переменной grains, которая также должна быть задана на каждом узле;

    • os:Ubuntu — операционная система Ubuntu, которая определяется по значению переменной os, которая должна быть задана на каждом узле;

    • test.version  — команда вывода версии модуля, которая должна быть выполнена на всех узлах, для которых определен тег -G и задана переменная os:Ubuntu.

    Использование параметров Grains (статистических данных-фактов, полученных от агентов) также возможно за счет использования шаблонов Jinja.

    В примере ниже файл состояния /srv/salt/webserver_setup.sls устанавливает Apache и настраивает имя для пакета в соответствии с операционной системой:

    install_apache:
      pkg.installed:
        {% if grains['os'] == 'CentOS' %}
        - name: httpd
        {% else %}
        - name: apache
        {% endif %}
    Управление конфигурацией

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

    Состояния

    Состояния определяются в файлах состояний с расширением .sls.

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

    Формулы

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

    Большинство формул состоит из нескольких состояний, которые описываются в файле формата YAML. Состояние — это конечное состояние, которого должна достичь система после применения формулы.

    Top-файл

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

    Хранилище Pillar

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

    Хранилище Pillar организовано в виде директории, которая содержит файлы состояния — YAML-файлы с конфигурационными данными. Каждый файл соответствует определенному агенту или группе агентов и содержит информацию о параметрах конфигурации для этого агента или группы. Для удобства файлы могут быть разбиты на поддиректории.

    Top-файл top.sls определяет связь между файлами состояний и агентами.

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

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

    Ниже приведен пример создания системных пользователей для агентов с помощью хранилища Pillar:

    1. Сохраните данные пользователей в хранилище Pillar в файле с разрешением .sls —  /srv/Pillar/user_info.sls:

      users:
        thatch: 1000
        shouse: 1001
        utahdave: 1002
        redbeard: 1003
    2. Создайте Top-файл, который будет передавать данные Pillar в агенты — /srv/Pillar/top.sls:

      base:
        '*':
          - user_info
    Шаблоны Jinja

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

    Ниже приведен пример файла состояния /srv/salt/user_setup.sls, в котором используются данные Pillar из предыдущей секции для создания пользователей системы:

    {% for user, uid in Pillar.get('users', {}).items() %}
    {{ user }}:
      user.present:
        - uid: {{ uid }}
    {% endfor %}

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

    thatch:
      user.present:
        - uid: 1000
    
    shouse:
      user.present:
        - uid: 1001
    
    utahdave:
      user.present:
        - uid: 1002
    
    redbeard:
      user.present:
        - uid: 1003

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

    salt '*' state.apply user_setup

    Формула

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

    Чтобы применить формулу:

    1. Формула должна быть написана согласно определенным правилам и загружена (все входящие в нее файлы и директории) в хранилище S3, на использование которого настроен сервер управления.

    2. Для формулы должна быть создана конфигурация — файл в формате JSON. Конфигурация формулы должна быть загружена в модуль LCM «Кабинет администратора».

    3. Для формулы должна быть создана версия конфигурации — файл в формате JSON. Версия конфигурации формулы должна быть загружена в модуль LCM «Кабинет администратора».

    Продукт «Служба управления конфигурациями» включает:

    • готовые формулы — формулы, загруженные в хранилище S3 и готовые к использованию с настройками по умолчанию без какой-либо дополнительной конфигурации;

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

    • формулы-шаблоны — формулы, которые используются в качестве примера для создания пользовательских формул подобного типа.

    Подробная информация содержится в разделе «Работа с формулами».

    Конфигурация

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

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

    Подробную информацию см. в разделе «Создание и импорт конфигурации».

    Версия конфигурации

    Версия конфигурации формулы — это отдельный файл в формате JSON, который загружается в модуль «Кабинет администратора» и позволяет изменять конфигурацию в соответствии с требованиями пользователя. В файле указывается идентификатор версии, мета-атрибуты версии и параметры формулы, доступные для переопределения (параметр pillarProperty).

    Разные версии конфигурации могут ссылаться на разные формулы.

    Актуальной будет считаться версия с последней датой выпуска (параметр releaseDate).

    Подробнее о версии конфигурации см. в разделе «Добавление версии конфигурации».

    Настройка модуля координации

    Для корректной работы модуля необходимо выполнить следующие настройки SaltStack:

    Настройка конфигурации серверов управления

    Сервер управления настраивается через главный файл конфигурации — /etc/salt/master.

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

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

    Чтобы логически разделить параметры конфигурации, рекомендуется использовать директорию /etc/salt/master.d/.

    Например, если вы используете хранилище S3, задайте настройки подключения к хранилищу для агентов в файле s3.conf и поместите его в директорию /etc/salt/master.d/ (см. пример ниже).

    Директория /etc/salt/master.d/ может содержать только файлы с расширением .conf.
    Дополнительные настройки при использовании хранилища S3

    При использовании хранилища S3 в качестве пространства для хранения общих файлов конфигураций и файлов состояний выполните настройки:

    1. Создайте файл /etc/salt/master/fileserver_backend.conf и укажите в нем, что в качестве бэкенда для файлов будет использоваться хранилище S3:

      fileserver_backend:
        - s3fs
    1. В файле /etc/salt/master/s3.conf пропишите настройки подключения к хранилищу S3:

      s3.service_url: <s3_hostname>:<s3_port>
      s3.keyid: <ACCESS_KEY>
      s3.key: <SECRET_KEY>
      s3.buckets:
        - salt-bucket
      s3.path_style: True
      s3.location: <REGION>

      Где в параметре s3.buckets указана корзина с именем salt-bucket для хранения файлов состояния и формул.

      Подробное описание всех параметров приведено в официальной документации.
    2. Выполните настройку подключения к S3 для хранения в отдельной корзине данных хранилища Pillar — создайте файл /etc/salt/master/ext_pillar.conf, в котором будет указана корзина pillar-bucket:

      ext_pillar:
        - s3:
            service_url: <s3_hostname>:<s3_port>
            keyid: <ACCESS_KEY>
            key: <SECRET_KEY>
            bucket: pillar-bucket
            multiple_env: False
            environment: base
            prefix: ''
            verify_ssl: False
            s3_cache_expire: 30
            s3_sync_on_update: True
            path_style: True
            https_enable: False
      Подробное описание всех полей приведено в официальной документации.

    Настройка конфигурации агентов

    Агент настраивается через файл конфигурации — /etc/salt/minion.

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

    В конфигурационном файле задайте параметр ping_interval. Параметр определяет интервал в минутах, через который агент отправляет ping-запрос на сервер управления. Рекомендуемое значение — 10 минут.

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

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

    • чем меньше значение параметра, тем больший объем данных будет передаваться в единицу времени, увеличивая нагрузку на сеть;

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

    Загрузка пользовательских формул в хранилище S3

    Готовые формулы (подробнее см. раздел «Готовые формулы» документа «Руководство по эксплуатации») импортируются автоматически при установке продукта.

    Чтобы загрузить пользовательские формулы (см. раздел «Пользовательские формулы» документа «Руководство по эксплуатации») и формулы-шаблоны (см. раздел «Формулы-шаблоны» документа «Руководство по эксплуатации»), используйте API для импорта формулы в хранилище S3 importFormulas (см. раздел «Метод importFormulas» документа «Описание API»).

    Настройка конфигурации отправки событий в Apache Kafka

    Отправка событий с сервера управления в Apache Kafka выполняется с помощью библиотеки librdkafka.

    В файле salt-master.conf (отдельно для каждого сервера управления) выполните настройку параметров:

    Наименование Описание Значение по умолчанию

    returner.kafka_custom.bootstrap

    Список хостов с указанием портов, где запущен Apache Kafka

    "kafka_host:9092"

    returner.kafka_custom.topic

    Топик Apache Kafka

    salt-topic

    returner.kafka_custom.security.protocol

    Протокол, который используется для связи с Apache Kafka

    plaintext

    returner.kafka_custom.ssl.cipher.suites

    Набор шифров (именованная комбинация аутентификации, шифрование, MAC-адреса и алгоритмы обмена ключами), используемые для согласования параметров безопасности сетевого подключения с использованием сетевого протокола SSL. Подробнее см. SSL_CTX_set_cipher_list

    returner.kafka_custom.ssl.curves.list

    Поддерживаемые кривые (supported curves), стандартные/именованные или «явные» GF(2^k) или GF(p) для использования сервером, которые передаются в сообщении TLS ClientHello. Подробнее см. SSL_CTX_set1_curves_list

    returner.kafka_custom.ssl.sigalgs.list

    Поддерживаемые алгоритмы цифровой подписи для использования сервером, которые передаются в сообщении TLS ClientHello. Подробнее см. SSL_CTX_set1_sigalgs

    returner.kafka_custom.ssl.key.location

    Путь к закрытому ключу клиента (PEM), который используется для аутентификации

    returner.kafka_custom.ssl.key.password

    Пароль для закрытого ключа (для использования с ssl.key.location и set_ssl_cert())

    returner.kafka_custom.ssl.key.pem

    Строка закрытого ключа клиента (в PEM-формате), которая используется для аутентификации

    returner.kafka_custom.ssl.certificate.location

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

    returner.kafka_custom.ssl.certificate.pem

    Строка публичного ключа клиента (в PEM-формате), которая используется для аутентификации

    returner.kafka_custom.ssl.ca.location

    Путь к файлу или каталогу сертификатов CA для проверки ключа брокера

    returner.kafka_custom.ssl.ca.pem

    Строка сертификата CA (в PEM-формате) для проверки ключа брокера

    returner.kafka_custom.ssl.ca.certificate.stores

    Список хранилищ сертификатов Windows (разделенный запятыми), из которых можно загрузить сертификаты CA. Сертификаты будут загружены в том же порядке, в котором указаны хранилища

    returner.kafka_custom.ssl.crl.location

    Путь к CRL для валидации сертификата брокера

    returner.kafka_custom.ssl.keystore.location

    Путь к хранилищу ключей клиента (PKCS#12), которые используются для аутентификации

    returner.kafka_custom.ssl.keystore.password

    Пароль хранилища ключей клиента (PKCS#12)

    returner.kafka_custom.ssl.providers

    Список провайдеров (разделенный запятыми) OpenSSL 3.0.x

    returner.kafka_custom.ssl.engine.id

    Идентификатор OpenSSL

    returner.kafka_custom.enable.ssl.certificate.verification

    Включение проверки сертификата встроенного брокера OpenSSL (сервера). Эта проверка может быть расширена приложением путем реализации certificate_verify_cb

    returner.kafka_custom.ssl.endpoint.identification.algorithm

    Алгоритм идентификации endpoint для проверки имени хоста брокера с использованием сертификата брокера

    returner.kafka_custom.debug

    Список контекстов отладки (разделенный запятыми), которые необходимо включить

    returner.kafka_custom.log_level

    Уровень логирования

    returner.kafka_custom.allow.auto.create.topics

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

    Для корректной работы данной конфигурации брокер должен быть настроен с параметром auto.create.topics.enable=true

    event_return: kafka_custom

    Выбор способа отправки событий возврата

    В качестве инструкции по генерации сертификатов рекомендуется использовать документ "Using SSL with librdkafka".

    Работа с формулами

    Работа с формулами включает этапы:

    Принципы написания формулы

    Формула — это обычная директория, которая именуется согласно шаблону: <top_level_dir>-formula.

    Директория обязательно содержит поддиректорию <top_level_dir>, имя которой совпадает с именем формулы и файлы:

    • обязательные:

      • <top_level_dir>/init.sls — главный файл с состояниями формулы, может включать в себя другие файлы с расширением .sls через директиву include;

      • <top_level_dir>/clean.sls — файл отката состояний формулы;

      • pillar.example — файл с примером указания параметров формулы;

      • FORMULA — описание формулы в формате YAML;

    • не обязательные:

      • docs/README.RST — файл с описанием способов применения формулы и входящих в нее состояний;

      • <top_level_dir>/any.sls — другие файлы с расширением .sls, содержащие состояния, которые включены в init.sls или clean.sls директивой include;

      • <top_level_dir>/<any_dir> — другие поддиректории, содержащие файлы с расширением .sls, которые включены в init.sls или clean.sls директивой include;

      • <top_level_dir>/map.jinja — необязательный файл, описывает особенности конфигурации под конкретную ОС или другие статические конфигурации.

    Файл FORMULA включает атрибуты формулы:

    • name — имя формулы;

    • os — ОС, поддреживающие формулу;

    • os_family — семейства ОС, поддреживающие формулу;

    • version — версия пакета с формулой, указанная в формате YYYYMM; если в месяце было несколько релизов, то минорный месячный релиз проставляется в атрибуте release;

    • release — выпуск версии; атрибут расширяет версионность формулы, если в месяце было несколько релизов;

    • summary — краткое описание формулы;

    • description — более подробное описание формулы;

    • top_level_dir — имя поддиректории, где расположены файлы с расширением .sls.

    SLS-файлы формулы составлены в синтаксисе YAML и содержат описания состояний, которые достигает система при применении формулы. Имена SLS-файлов не могут содержать точки, кроме точки между именем и расширением .sls.

    Каждому состоянию присвоен уникальный идентификатор в рамках LCM.

    Добавление формулы в хранилище S3, на использование которого настроен сервер управления

    Чтобы загрузить формулу на файловый сервер SALT.FILESERVER.S3FS, используйте путь s3://<bucket name>/base/<formula-name>.

    Для более подробной информации см. официальную документацию:

    Также формулу можно загрузить при помощи API-метода importFormulas. Метод описан в разделе «Метод importFormulas» документа «Описание API».

    Создание и импорт конфигурации

    Конфигурация описывается в файле формата JSON.

    Пример описания конфигурации для формулы по установке Яндекс Браузера:

    {
      "displayName": "Яндекс Браузер",
      "description": "Яндекс Браузер — безопасный и быстрый браузер с голосовым помощником.",
      "fullDescription": "Яндекс Браузер — безопасный и быстрый браузер с голосовым помощником.",
      "isApplication": true,
      "categories": [
        "network"
      ],
      "icon": {
        "resourcePath": "specifications/icons/yandex-browser-logo.svg",
        "contentType": "image/svg+xml"
      },
      "images": [
        {
          "resourcePath": "specifications/images/yandex-browser-screen1.webp",
          "contentType": "image/webp"
        }
      ]
    }

    Где:

    • displayName — имя, которое отображается в пользовательском интерфейсе (обязательное поле);

    • description — описание конфигурации или ПО;

    • fullDescription — полное описание конфигурации или ПО; для ПО данное описание отображается в качестве подробной информации о нем в магазине приложений;

    • isApplication — флаг, который устанавливается для ПО; если это конфигурация, флаг выключен (обязательное поле);

    • categories — список категорий;

    • icon — иконка ПО, которая отображается в магазине приложений;

    • images — изображения для отображения на странице с подробным описанием ПО.

    После того как вы подготовите JSON-файл с конфигурацией, импортируйте его в кабинете администратора, используя метод /v1/specifications. Метод описан в документе «Описание API» в разделе «Метод createSpecification».

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

    Добавление версии конфигурации

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

    Пример описания версии конфигурации для формулы по установке Яндекс Браузера:

    {
      "displayName": "23.9.1.1023",
      "formulaName": "yandex-browser",
      "releaseDate": "2023-11-14",
      "softwareRequirements": "example",
      "pillarProperty": {
        "lookup": {
          "pkg": {
            "version": "23.9.1.1023-1"
          }
        }
      }
    }

    Где:

    • displayName — имя, которое отображается в пользовательском интерфейсе (обязательное поле);

    • formulaName — имя формулы, используемой для установки данной версии (обязательное поле);

    • releaseDate — дата выпуска версии (обязательное поле);

    • softwareRequirements — требования к установке данной версии (обязательное поле);

    • pillarProperty — параметры для переопределения; если поле останется незаполненным, формула версии будет устанавливаться с параметрами по умолчанию.

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

      Пример файла pillar.example для формулы по установке Яндекс Браузера:

      yandex-browser:
        # Переопределите значение map.jinja
        lookup:
          # Укажите параметры пакета
          pkg:
            # Укажите имя пакета для конкретной ОС
            name: yandex-browser-stable
            # Set the specific version of a package. If value is an empty string then used latest version
            version: '23.5.4.685-1'
            # Укажите репозиторий, из которого будет производиться установка. Когда репозиторий будет добавлен (по repo.name),
            # он будет назначен заданному релизу (suite).
            #  Значение может быть пустой строкой
            fromrepo: 'stable'
          # Укажите параметры репозитория
          repo:
            # Укажите имя репозитория, которое будет импортировано в систему. Значение должно быть указано в формате
            # one-line-style (https://manpages.debian.org/unstable/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_GENERAL_FORMAT)
            # без опций. Чтобы задать опции, используйте дополнительные параметры репозитория.
            # Если значение представляет собой пустую строку, то репозиторий не будет импортирован
            name: 'deb http://repo.yandex.ru/yandex-browser/deb stable'
            # Выполните настройку репозитория, чтобы он стал недоступным для поиска и установки пакетов.
            # Значения: True или False
            disabled: False
            # Укажите тип пакетов (компонентов), которые будут установлены из репозитория (например, main, nonfree, ...).
            # Значения параметра comps должны быть заданы в виде списка через запятую
            comps: 'main,contrib,non-free'
            # Укажите имена файлов .list и .gpg. Не могут быть пустой строкой
            conf_name: 'yandex-browser'
            # Укажите key-файл (.gpg) для загрузки на агент. Этот файл может храниться как на сервере управления,
            # так и на серверах HTTP(S) или FTP.
            # Этот файл используется в опции репозитория signed-by. Значение может быть пустой строкой.
            key_file: 'https://repo.yandex.ru/yandex-browser/YANDEX-BROWSER-KEY.GPG'
            # Установите значение True, чтобы декодировать данные key-файла из формата base64 в бинарный
            key_file_dearmor: True
            # Установите полный путь к каталогу ключей на агенте
            key_keyrings_dir: '/etc/apt/keyrings/'
            # Укажите имена для установки пакетов, необходимых для импорта репозитория. Значения должны быть представлены в виде списка через запятую
            required_packages: [ 'gpg' ]

    После того как вы подготовите JSON-файл с версией конфигурации, импортируйте его, используя метод /v1/configurations/{configurationId}/versions/. Метод описан в документе «Описание API» в разделе «Метод createSpecificationVersion».

    Готовые формулы

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

    Такими формулами являются:

    Формула ark-formula

    Формула для установки пакета Ark (инструмент для сжатия/распаковки графических файлов).

    Доступные состояния

    Состояние ark

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает пакет Ark из целевого репозитория. Имеет зависимость от ark.repository, ark.package через список include.

    Состояние ark.repository

    Имеет зависимость от ark.repository.install через список include.

    Состояние ark.repository.install

    Импортирует репозиторий, если значение repo.name указано в хранилище Pillars (или не пустое по умолчанию) и имеет зависимость от:

    • ark.repository.package.install через список include;

    • ark.repository.key.install через список include и реквизит require.

    Состояние ark.repository.package.install

    Устанавливает пакеты repo.required_packages(по умолчанию — gpg).

    Состояние ark.repository.key.install

    Загружает repo.key_file на агент и декодирует данные файла из формата base64 в бинарный.

    Состояние ark.package

    Устанавливает пакет Ark.

    Состояние ark.clean

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Отменяет все действия, выполненные в мета-состоянии ark, в обратном порядке, т.е. удаляет пакет и удаляет целевой репозиторий (если он был импортирован). Имеет зависимость от ark.package.clean и ark.repository.clean через список include.

    Состояние ark.package.clean

    Удаляет пакет Ark.

    Состояние ark.repository.clean

    Удаляет файл конфигурации репозитория. Имеет зависимость от ark.repository.key.clean через список include.

    Состояние ark.repository.key.clean

    Удаляет Key-файл репозитория.

    Пример файла pillar.example
    ark:
      # Переопределите значение map.jinja
      lookup:
        # Укажите параметры пакета
        pkg:
          # Укажите имя пакета для конкретной ОС
          name: my-ark
          # Укажите конкретную версию пакета. Если значение представляет собой пустую строку, используется последняя версия
          version: '1.0.0.685-1'
          # Укажите репозиторий, из которого будет производиться установка. Когда репозиторий будет добавлен (по repo.name),
          # он будет назначен заданному релизу (suite).
          #  Значение может быть пустой строкой
          fromrepo: 'stable'
        # Укажите параметры репозитория
        repo:
          # Укажите имя репозитория, которое будет импортировано в систему. Значение должно быть указано в формате
          # one-line-style (https://manpages.debian.org/unstable/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_GENERAL_FORMAT)
          # без опций. Чтобы задать опции, используйте дополнительные параметры репозитория.
          # Если значение представляет собой пустую строку, то репозиторий не будет импортирован
          name: 'deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-main/ 1.7_x86-64'
          # Выполните настройку репозитория, чтобы он стал недоступным для поиска и установки пакетов.
          # Значения: True или False
          disabled: False
          # Укажите тип пакетов (компонентов), которые будут установлены из репозитория (например, main, nonfree, ...).
          # Значения параметра comps должны быть заданы в виде списка через запятую
          comps: 'main,contrib,non-free'
          # Укажите имена файлов .list и .gpg. Не могут быть пустой строкой
          conf_name: 'ark'
          # Укажите key-файл (.gpg) для загрузки на агент. Этот файл может храниться как на сервере управления,
          # так и на серверах HTTP(S) или FTP.
          # Этот файл используется в опции репозитория signed-by. Значение может быть пустой строкой.
          key_file: 'salt://files/keys/MY-ARK-KEY.GPG'
          # Установите значение True, чтобы декодировать данные key-файла из формата base64 в бинарный
          key_file_dearmor: True
          # Установите полный путь к каталогу ключей на агенте
          key_keyrings_dir: '/etc/apt/keyrings/'
          # Укажите имена для установки пакетов, необходимых для импорта репозитория. Значения должны быть представлены в виде списка через запятую
          required_packages: [ 'gpg' ]
    Формула google-chrome-formula

    Формула для установки веб-браузера Google Chrome.

    Доступные состояния

    Состояние google-chrome

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает пакет google-chrome из целевого репозитория. Имеет зависимость от google-chrome.repository и google-chrome.package через список include.

    Состояние google-chrome.repository

    Имеет зависимость от google-chrome.repository.install` через список include.

    Состояние google-chrome.repository.install

    Импортирует репозиторий, если значение repo.name указано в хранилище Pillars (или не пустое по умолчанию). Имеет зависимость от:

    • google-chrome.repository.package.install через список include;

    • google-chrome.repository.key.install` через список include и реквизит require.

    Состояние google-chrome.repository.package.install

    Устанавливает пакеты repo.required_packages (по умолчанию — gpg).

    Состояние google-chrome.repository.key.install

    Загружает repo.key_file на агент и декодирует данные файла из формата base64 в бинарный.

    Состояние google-chrome.package

    Устанавливает пакет google-chrome.

    Состояние google-chrome.clean

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Отменяет все действия, выполненные в мета-состоянии google-chrome, в обратном порядке, т.е. удаляет пакет и удаляет целевой репозиторий (если он был импортирован). Имеет зависимость от google-chrome.package.clean и google-chrome.repository.clean через список include.

    Состояние google-chrome.package.clean

    Удаляет пакет google-chrome.

    Состояние google-chrome.repository.clean

    Удаляет файл конфигурации репозитория. Имеет зависимость от google-chrome.repository.key.clean через список include.

    Состояние google-chrome.repository.key.clean

    Удаляет Key-файл репозитория.

    Пример файла pillar.example
    google-chrome:
      # Переопределите значение map.jinja
      lookup:
        # Укажите параметры пакета
        pkg:
          # Укажите имя пакета для конкретной ОС
          name: google-chrome-stable
          # Set the specific version of a package. If value is an empty string then used latest version
          version: ''
          # Укажите репозиторий, из которого будет производиться установка. Когда репозиторий будет добавлен (по repo.name),
          # он будет назначен заданному релизу (suite).
          #  Значение может быть пустой строкой
          fromrepo: ''
        # Укажите параметры репозитория
        repo:
          # Укажите имя репозитория, которое будет импортировано в систему. Значение должно быть указано в формате
          # one-line-style (https://manpages.debian.org/unstable/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_GENERAL_FORMAT)
          # без опций. Чтобы задать опции, используйте дополнительные параметры репозитория.
          # Если значение представляет собой пустую строку, то репозиторий не будет импортирован
          name: 'deb http://dl.google.com/linux/chrome/deb/ stable main'
          # Выполните настройку репозитория, чтобы он стал недоступным для поиска и установки пакетов.
          # Значения: True или False
          disabled: False
          # Укажите тип пакетов (компонентов), которые будут установлены из репозитория (например, main, nonfree, ...).
          # Значения параметра comps должны быть заданы в виде списка через запятую
          comps: ''
          # Укажите имена файлов .list и .gpg. Не могут быть пустой строкой
          conf_name: 'google-chrome'
          # Укажите key-файл (.gpg) для загрузки на агент. Этот файл может храниться как на сервере управления,
          # так и на серверах HTTP(S) или FTP.
          # Этот файл используется в опции репозитория signed-by. Значение может быть пустой строкой.
          key_file: 'https://dl.google.com/linux/linux_signing_key.pub'
          # Установите значение True, чтобы декодировать данные key-файла из формата base64 в бинарный
          key_file_dearmor: True
          # Установите полный путь к каталогу ключей на агенте
          key_keyrings_dir: '/etc/apt/keyrings/'
          # Укажите имена для установки пакетов, необходимых для импорта репозитория. Значения должны быть представлены в виде списка через запятую
          required_packages: [ 'gpg' ]
    Формула okular-formula

    Формула для установки ПО Okular (для просмотра документов в различных форматах).

    Доступные состояния

    Состояние okular

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает пакет okular из целевого репозитория. Имеет зависимость от okular.repository и okular.package через список include.

    Состояние okular.repository

    Имеет зависимость от okular.repository.install через список include.

    Состояние okular.repository.install

    Импортирует репозиторий, если значение repo.name указано в хранилище Pillars (или не пустое по умолчанию). Имеет зависимость от:

    • okular.repository.package.install через список include;

    • okular.repository.key.install` через список include и реквизит require.

    Состояние okular.repository.package.install

    Устанавливает пакеты repo.required_packages (по умолчанию — gpg).

    Состояние okular.repository.key.install

    Загружает repo.key_file на агент и декодирует данные файла из формата base64 в бинарный.

    Состояние okular.package

    Устанавливает пакет okular.

    Состояние okular.clean

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Отменяет все действия, выполненные в мета-состоянии okular, в обратном порядке, т.е. удаляет пакет и удаляет целевой репозиторий (если он был импортирован). Имеет зависимость от okular.package.clean и okular.repository.clean через список include.

    Состояние okular.package.clean

    Удаляет пакет okular.

    Состояние okular.repository.clean

    Удаляет файл конфигурации репозитория. Имеет зависимость от okular.repository.key.clean через список include.

    Состояние okular.repository.key.clean

    Удаляет Key-файл репозитория.

    Пример файла pillar.example
    okular:
      # Переопределите значение map.jinja
      lookup:
        # Укажите параметры пакета
        pkg:
          # Укажите имя пакета для конкретной ОС
          name: okular
          # Set the specific version of a package. If value is an empty string then used latest version
          version: ''
          # Укажите репозиторий, из которого будет производиться установка. Когда репозиторий будет добавлен (по repo.name),
          # он будет назначен заданному релизу (suite).
          #  Значение может быть пустой строкой
          fromrepo: ''
        # Укажите параметры репозитория
        repo:
          # Укажите имя репозитория, которое будет импортировано в систему. Значение должно быть указано в формате
          # one-line-style (https://manpages.debian.org/unstable/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_GENERAL_FORMAT)
          # без опций. Чтобы задать опции, используйте дополнительные параметры репозитория.
          # Если значение представляет собой пустую строку, то репозиторий не будет импортирован
          name: ''
          # Выполните настройку репозитория, чтобы он стал недоступным для поиска и установки пакетов.
          # Значения: True или False
          disabled: False
          # Укажите тип пакетов (компонентов), которые будут установлены из репозитория (например, main, nonfree, ...).
          # Значения параметра comps должны быть заданы в виде списка через запятую
          comps: ''
          # Укажите имена файлов .list и .gpg. Не могут быть пустой строкой
          conf_name: 'okular'
          # Укажите key-файл (.gpg) для загрузки на агент. Этот файл может храниться как на сервере управления,
          # так и на серверах HTTP(S) или FTP.
          # Этот файл используется в опции репозитория signed-by. Значение может быть пустой строкой.
          key_file: ''
          # Установите значение True, чтобы декодировать данные key-файла из формата base64 в бинарный
          key_file_dearmor: True
          # Установите полный путь к каталогу ключей на агенте
          key_keyrings_dir: '/etc/apt/trusted.gpg.d/'
          # Укажите имена для установки пакетов, необходимых для импорта репозитория. Значения должны быть представлены в виде списка через запятую
          required_packages: [ 'gpg' ]
    Формула yandex-browser-formula

    Формула для установки веб-браузера Yandex.

    Доступные состояния

    Состояние yandex-browser

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает пакет yandex-browser из целевого репозитория. Имеет зависимость от yandex-browser.repository и yandex-browser.package через список include.

    Состояние yandex-browser.repository

    Имеет зависимость от yandex-browser.repository.install через список include.

    Состояние yandex-browser.repository.install

    Импортирует репозиторий, если значение repo.name указано в хранилище Pillars (или не пустое по умолчанию). Имеет зависимость от:

    • yandex-browser.repository.package.install через список include;

    • yandex-browser.repository.key.install через список include и реквизит require.

    Состояние yandex-browser.repository.package.install

    Устанавливает пакеты repo.required_packages (по умолчанию — gpg).

    Состояние yandex-browser.repository.key.install

    Загружает repo.key_file на агент и декодирует данные файла из формата base64 в бинарный.

    Состояние yandex-browser.package

    Устанавливает пакет yandex-browser.

    Состояние yandex-browser.clean

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Отменяет все действия, выполненные в мета-состоянии yandex-browser, в обратном порядке, т.е. удаляет пакет и удаляет целевой репозиторий (если он был импортирован). Имеет зависимость от yandex-browser.package.clean и yandex-browser.repository.clean через список include.

    Состояние yandex-browser.package.clean

    Удаляет пакет yandex-browser.

    Состояние yandex-browser.repository.clean

    Удаляет файл конфигурации репозитория. Имеет зависимость от yandex-browser.repository.key.clean через список include.

    Состояние yandex-browser.repository.key.clean

    Удаляет Key-файл репозитория.

    Пример файла pillar.example
    yandex-browser:
      # Переопределите значение map.jinja
      lookup:
        # Укажите параметры пакета
        pkg:
          # Укажите имя пакета для конкретной ОС
          name: yandex-browser-stable
          # Set the specific version of a package. If value is an empty string then used latest version
          version: '23.5.4.685-1'
          # Укажите репозиторий, из которого будет производиться установка. Когда репозиторий будет добавлен (по repo.name),
          # он будет назначен заданному релизу (suite).
          #  Значение может быть пустой строкой
          fromrepo: 'stable'
        # Укажите параметры репозитория
        repo:
          # Укажите имя репозитория, которое будет импортировано в систему. Значение должно быть указано в формате
          # one-line-style (https://manpages.debian.org/unstable/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_GENERAL_FORMAT)
          # без опций. Чтобы задать опции, используйте дополнительные параметры репозитория.
          # Если значение представляет собой пустую строку, то репозиторий не будет импортирован
          name: 'deb http://repo.yandex.ru/yandex-browser/deb stable'
          # Выполните настройку репозитория, чтобы он стал недоступным для поиска и установки пакетов.
          # Значения: True или False
          disabled: False
          # Укажите тип пакетов (компонентов), которые будут установлены из репозитория (например, main, nonfree, ...).
          # Значения параметра comps должны быть заданы в виде списка через запятую
          comps: 'main,contrib,non-free'
          # Укажите имена файлов .list и .gpg. Не могут быть пустой строкой
          conf_name: 'yandex-browser'
          # Укажите key-файл (.gpg) для загрузки на агент. Этот файл может храниться как на сервере управления,
          # так и на серверах HTTP(S) или FTP.
          # Этот файл используется в опции репозитория signed-by. Значение может быть пустой строкой.
          key_file: 'https://repo.yandex.ru/yandex-browser/YANDEX-BROWSER-KEY.GPG'
          # Установите значение True, чтобы декодировать данные key-файла из формата base64 в бинарный
          key_file_dearmor: True
          # Установите полный путь к каталогу ключей на агенте
          key_keyrings_dir: '/etc/apt/keyrings/'
          # Укажите имена для установки пакетов, необходимых для импорта репозитория. Значения должны быть представлены в виде списка через запятую
          required_packages: [ 'gpg' ]

    Пользовательские формулы

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

    Такими формулами являются:

    Формула ca-cert-formula

    Формула для установки CA-сертификатов.

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

    Состояние ca-cert

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает сертификаты в системном хранилище и хранилища профилей пользователей (NSSDB). Имеет зависимость от ca-cert.sys, ca-cert.user через список include.

    Состояние ca-cert.sys

    Имеет зависимость от ca-cert.sys.install через список include.

    Состояние ca-cert.sys.install

    Запускает команду sys.certs_update_cmd для обновления системных сертификатов и имеет зависимость от ca-cert.sys.certs.files через список include и реквизит onchanges.

    Состояние ca-cert.sys.certs.files

    Сохраняет на диске (в директории certs.dest_dir) файлы сертификата из списка certs.files.

    Состояние ca-cert.user

    Имеет зависимость от ca-cert.user.install через список include.

    Состояние ca-cert.user.install

    Имеет зависимость от ca-cert.user.nssdb через список include.

    Состояние ca-cert.user.nssdb

    Имеет зависимость от ca-cert.user.nssdb.update через список include.

    Состояние ca-cert.user.nssdb.update

    Добавляет сертификаты в хранилища профилей пользователей (NSSDB) и имеет зависимость от:

    • ca-cert.user.nssdb.create через список include и реквизит require;

    • ca-cert.user.certs.files через список include и реквизит onchanges.

    Если в хранилище Pillar нет пользователей в user.usernames, пользователи будут настраиваться по имени каталога в /home.

    Состояние ca-cert.user.nssdb.create

    Создает хранилище сертификатов пользователя (NSSDB) в домашней директории пользователя и имеет зависимость от ca-cert.user.package.instal через список include и реквизит require. Если в хранилище Pillar в поле user.usernames не указано ни одного пользователя, пользователи будут настраиваться по имени каталога в /home.

    Состояние ca-cert.user.package.install

    Устанавливает пакет cacert.user.pkg.name (по умолчанию — libnss3-tools).

    Состояние ca-cert.user.certs.files

    Сохраняет на диске (в директории certs.dest_dir_user) файлы сертификата из списка certs.files.

    Состояние ca-cert.clean

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Удаляет сертификаты их системного хранилища и хранилища профилей пользователей (NSSDB). Имеет зависимость от ca-cert.sys.clean, ca-cert.user.clean через список include.

    Состояние ca-cert.sys.clean

    Запускает команду sys.certs_update_cmd для обновления системных сертификатов и имеет зависимость от ca-cert.sys.certs.clean через список include и реквизит onchanges.

    Состояние ca-cert.sys.certs.clean

    Удаляет с диска (директория certs.dest_dir) файлы сертификата из списка certs.files.

    Состояние ca-cert.user.clean

    Имеет зависимость от ca-cert.user.nssdb.clean, ca-cert.user.package.clean через список включения.

    Состояние ca-cert.user.nssdb.clean

    Удаляет сертификаты из хранилища профилей пользователей (NSSDB) и имеет зависимость от ca-cert.user.certs.clean через список include и реквизит require.

    Состояние ca-cert.user.certs.clean

    Удаляет с диска (директория certs.dest_dir_user) файлы сертификата из списка certs.files.

    Состояние ca-cert.user.package.clean

    Удаляет пакет cacert.user.pkg.name (по умолчанию — libnss3-tools).

    Пример файла pillar.example
    ca-cert:
      # Переопределите значение map.jinja
      lookup:
        # Укажите параметры сертификатов
        certs:
          # Укажите список имен файлов сертификатов. Значения не могут быть пустыми
          #  Значения должны быть указаны в виде списка через запятую
          files: [
            "my_ca_1.crt",
            "my_ca_2.crt",
          ]
          # Укажите полный путь к каталогу, в котором хранятся файлы сертификатов,
          #  на файловом сервере
          source_dir: "salt://files/cacerts/"
          # Укажите полный путь к каталогу для системных сертификатов на агенте
          dest_dir: "/usr/local/share/ca-certificates/"
          # Укажите полный путь к каталогу для общих сертификатов пользователей на агенте
          dest_dir_user: "/usr/local/share/ca-certificates-nssdb/"
        # Укажите некоторые параметры системы
        sys:
          # Укажите команду, которая будет выполняться для обновления системных сертификатов
          certs_update_cmd: "update-ca-certificates --fresh"
        # Укажите некоторые параметры пользователей
        user:
          # Укажите список имен пользователей для обновления сертификатов. Если пользователи
          # не заданы, пользователи будут выбраны по имени каталога в /home
          usernames: [
            "username_1",
            "username_1",
          ]
    Изменение значений параметров по умолчанию
    1. Извлеките формулу ca-cert-formula из архива.

      $ tar -xvf ~/Downloads/inno-lcm-salt-formulas-X.Y.Z.tar.gz \
          --strip-components 3 \
          -C ~/ \
          ./formulas/ca-cert-formula/ca-cert
      $ cd ~/ca-cert
    2. Создайте директорию files и скопируйте в нее необходимые сертификаты.

      В качестве примера используются сертификаты ЦС НУЦ Минцифры:

      $ ls ./files/
      russian_trusted_root_ca_pem.crt  russian_trusted_sub_ca_pem.crt
    3. Измените файл map.jinja(словарь со значениями по умолчанию):

      1. Измените значение default.certs.source_dir, указав директорию files, созданную в формуле.

      2. Измените значение default.certs.files, указав в списке имена файлов в директории files.

      3. Оставьте пустым списком значение default.user.usernames — это будет означать, что сертификаты будут установлены для всех пользователей, для которых создана папка в каталоге /home/).

      4. Удалите все значения, относящиеся к ОС Debian.

        {% set mapdata = salt['grains.filter_by']({
            'default': {
                'certs': {
                    'files': [
                        'russian_trusted_root_ca_pem.crt',
                        'russian_trusted_sub_ca_pem.crt',
                    ],
                    'source_dir': 'salt://ca-cert/files/',
                    'dest_dir': '/usr/local/share/ca-certificates/',
                    'dest_dir_user': '/usr/local/share/ca-certificates-nssdb/',
                },
                'sys': {
                    'certs_update_cmd': 'update-ca-certificates --fresh',
                },
                 'user': {
                    'usernames': [
                    ],
                    'pkg': {
                        'name': 'libnss3-tools',
                    },
                },
            },
        }, merge=salt['pillar.get']('ca-cert:lookup'), base='default') %}

    После переопределения значений по умолчанию, следуйте инструкциям по работе с формулой в разделе «Работа формулами».

    Формула deb-repo-formula

    Формула для добавления пользовательского репозитория с Deb-пакетами.

    Доступные состояния

    Состояние deb-repo

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Добавляет и настраивает Deb-репозиторий. Имеет зависимость от deb-repo.install через список include.

    Состояние deb-repo.install

    Импортирует репозиторий, если значение name указано в хранилище Pillars (или не пустое по умолчанию).

    Состояние deb-repo.key.install

    Загружает deb-repo.key_file на агент и декодирует данные файла из формата base64 в бинарный.

    Состояние deb-repo.clean

    Удаляет файл конфигурации репозитория. Имеет зависимость от deb-repo.key.clean через список include.

    Состояние deb-repo.key.clean

    Удаляет Key-файл репозитория.

    Пример файла pillar.example
    deb-repo:
      # Переопределите значение map.jinja
      lookup:
        # Укажите имя репозитория, которое будет импортировано в систему. Значение должно быть указано в формате
        # one-line-style (https://manpages.debian.org/unstable/apt/sources.list.5.en.html#THE_DEB_AND_DEB-SRC_TYPES:_GENERAL_FORMAT)
        #  с опциями в квадратных скобках ([]). Опции используются для установки дополнительных параметров репозитория,
        # например, `signed-by`, `trusted`, `allow-insecure`.
        #  Опция настройки архитектуры ('arch') будет добавлена автоматически из параметра grain на агенте
        name: 'deb [signed-by=/etc/apt/keyrings/repo-key.gpg trusted=yes] https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-main/ 1.7_x86-64'
        # Выполните настройку репозитория, чтобы он стал недоступным для поиска и установки пакетов.
        # Значения: True или False
        disabled: False
        # Укажите тип пакетов (компонентов), которые будут установлены из репозитория (например, main, nonfree, ...).
        # Значения параметра comps должны быть заданы в виде списка через запятую
        comps: 'main,contrib,non-free'
        # Укажите имена файлов .list и .gpg. Не могут быть пустой строкой
        conf_name: 'repository-main'
        # Укажите key-файл (.gpg) для загрузки на агент. Этот файл может храниться как на сервере управления,
        # так и на серверах HTTP(S) или FTP.
        # Этот файл используется в опции репозитория signed-by. Значение может быть пустой строкой.
        # Отсутствие значения означает, что key-файл не будет импортирован и не будет использоваться.
        # Если используется key-файл, необходимо добавить опцию в формате 'signed-by={{ key_keyrings_dir }}{{ conf_name }}.gpg', example 'signed-by=/etc/apt/keyrings/repository-main.gpg'
        key_file: ''
        # Установите значение True, чтобы декодировать данные key-файла из формата base64 в бинарный
        key_file_dearmor: False
        # Установите полный путь к каталогу ключей на агенте
        key_keyrings_dir: '/etc/apt/keyrings/'
        # Укажите имена для установки пакетов, необходимых для импорта репозитория. Значения должны быть представлены в виде списка через запятую
        required_packages: [ 'gpg' ]
    Формула web-mail-formula

    Формула для установки Web Mail.

    Доступные состояния

    Состояние web-mail

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает ссылку на Web Mail. Имеет зависимость от web-mail.install через список include.

    Состояние web-mail.install

    Создает ссылку (файл web-mail.desktop) на Web Mail на рабочем столе пользователя (папка ~/Desktop).

    Если в хранилище Pillar в поле user.usernames не указано ни одного пользователя, пользователи будут настраиваться по имени каталога в /home.

    Если в полях link.name и link.url значения не заданы, формула не будет выполнена, и отобразится соответствующее уведомление.

    Состояние web-mail.clean

    Удаляет ссылку (файл web-mail.desktop) c рабочего стола пользователя (папка ~/Desktop).

    Если в хранилище Pillar в поле user.usernames не указано ни одного пользователя, пользователи будут настраиваться по имени каталога в /home.

    Если в полях link.name и link.url значения не заданы, формула не будет выполнена, и отобразится соответствующее уведомление.

    Пример файла pillar.example
    web-mail:
      # Переопределите значение map.jinja
      lookup:
        # Укажите параметры ссылки
        link:
          # Укажите название ссылки на рабочем столе
          name: "Link to My Corp Mail"
          # Укажите URL доступа
          url: "https://mail.yandex.ru/"
          # Задайте имя (или путь к файловой системе агента) иконки, которая будет использоваться для отображения
          # на рабочем столе Значение по умолчанию: "mail"
          icon: "/path/to/icon"
        # Задайте параметры пользователей
        user:
          # Укажите список имен пользователей для обновления сертификатов. Если пользователи
          # не заданы, пользователи будут выбраны по имени каталога в /home
          usernames: [
            "username_1",
            "username_2",
          ]

    Формулы-шаблоны

    Формулы-шаблоны используются в качестве примера для создания собственных формул подобного типа. Такими формулами являются:

    Формула tpl-shortcut-formula

    Формула-шаблон для добавления ярлыка приложения, url-адреса и символической ссылки (symlink) на рабочий стол пользователя.

    Доступные состояния

    Состояние tpl-shortcut

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает ссылку на Web Mail. Имеет зависимость от tpl-shortcut.install через список include.

    Состояние tpl-shortcut.install

    Создает символическую ссылку или файл Desktop Entry (приложение, ссылку) на рабочем столе пользователя (папка ~/Desktop).

    Если в хранилище Pillar в поле user.usernames не указано ни одного пользователя, пользователи будут настраиваться по имени каталога в /home.

    Если в полях link.name и link.url значения не заданы, формула не будет выполнена, и отобразится соответствующее уведомление.

    Состояние tpl-shortcut.clean

    Удаляет символическую ссылку или файл Desktop Entry (приложение, ссылку) c рабочего стола пользователя (папка ~/Desktop).

    Если в хранилище Pillar в поле user.usernames не указано ни одного пользователя, пользователи будут настраиваться по имени каталога в /home.

    Если в полях link.name и link.url значения не заданы, формула не будет выполнена, и отобразится соответствующее уведомление.

    Пример файла pillar.example
    tpl-shortcut:
      # Переопределите значение map.jinja
      lookup:
        # Переопределите параметры ссылки на приложение
        application:
          # Задайте имя файла ссылки на рабочий стол
          name: "bash_application"
        # Задайте параметры ссылки
        link:
          # Задайте имя файла ссылки на рабочий стол
          name: "ya-ru_link"
        # Задайте параметры ссылки
        symlink:
          # Задайте имя файла символической ссылки на рабочий стол
          name: "distro-info_debian_symlink"
          # Задайте полный путь к целевому файлу в файловой системе агента
          target: "/usr/share/distro-info/debian.csv"
        # Задайте параметры пользователей
        user:
          # Укажите список имен пользователей для обновления сертификатов. Если пользователи
          # не заданы, пользователи будут выбраны по имени каталога в /home
          usernames: [
            "username_1",
            "username_2",
          ]
    Написание формулы типа tpl-shortcut-formula
    1. Скопируйте формулу-шаблон (tpl-shortcut) в новую директорию с новым названием (my-shortcut):

      $ tar -xvf ~/Downloads/inno-lcm-salt-formulas-0.9.0.tar.gz \
          --strip-components 3 \
          -C ~/ \
          ./formulas/tpl-shortcut-formula/tpl-shortcut
      $ cp -R ~/tpl-shortcut/ ~/my-shortcut && cd ~/my-shortcut
    2. Измените файл состояний install.sls (создание ярлыков):

      1. Измените ID состояний.

        Рекомендуется для соблюдения уникальности придерживаться именования вида: formula-name-state-name-other-state-name-module-function-some-id. Например, ID состояния для создания symlink будет выглядеть как: my-shortcut-install-file-symlink-{{ username }}-symlink.
      2. Измените значение аргумента contents для функции из состояния: my-shortcut-install-file-managed-{{ username }}-application (ярлык для приложения). Например, имя (Name), запускаемую программу (Exec) и иконку ярлыка (Icon).

      3. Измените значение аргумента contents для функции из состояния my-shortcut-install-file-managed-{{ username }}-link (ярлык для url). Например, имя (Name) и url-адрес (URL).

        # -*- coding: utf-8 -*-
        # vim: ft=sls
        
        {#- Get the `tplroot` from `tpldir` #}
        {%- set tplroot = tpldir.split('/')[0] %}
        {%- from tplroot ~ "/map.jinja" import mapdata as tplshortcut with context %}
        {%- from tplroot ~ "/_usernames_lib.sls" import usernames with context %}
        
        {#- Create application link #}
        {%- if tplshortcut.application.name %}
        {%- for username in usernames  %}
        
        my-shortcut-install-file-managed-{{ username }}-application:
          file.managed:
            - name: /home/{{ username }}/Desktop/{{ tplshortcut.application.name }}.desktop
            - user: {{ username }}
            - group: {{ username }}
            - makedirs: True
            - contents: |
                [Desktop Entry]
                Type=Application
                Name=Run bash manpage
                Exec=man bash
                Terminal=true
                Icon=dictionary
        
        {%- endfor %}
        {%- endif %}
        
        {#- Create url link #}
        {%- if tplshortcut.link.name %}
        {%- for username in usernames  %}
        
        my-shortcut-install-file-managed-{{ username }}-link:
          file.managed:
            - name: /home/{{ username }}/Desktop/{{ tplshortcut.link.name }}.desktop
            - user: {{ username }}
            - group: {{ username }}
            - makedirs: True
            - contents: |
                [Desktop Entry]
                Type=Link
                Name=Love DuckDuckGo!
                URL=https://duckduckgo.com
        
        {%- endfor %}
        {%- endif %}
        
        {#- Create symlink #}
        {%- if tplshortcut.symlink.name %}
        {%- for username in usernames  %}
        
        my-shortcut-install-file-symlink-{{ username }}-symlink:
          file.symlink:
            - name: /home/{{ username }}/Desktop/{{ tplshortcut.symlink.name }}
            - target: {{ tplshortcut.symlink.target }}
            - user: {{ username }}
            - group: {{ username }}
            - makedirs: True
        
        {%- endfor %}
        {%- endif %}
    3. В файле состояний clean.sls (удаление ярлыков) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplshortcut with context %}
      {%- from tplroot ~ "/_usernames_lib.sls" import usernames with context %}
      
      {#- Delete application link #}
      {%- if tplshortcut.application.name %}
      {%- for username in usernames  %}
      
      my-shortcut-install-file-managed-{{ username }}-application:
        file.absent:
          - name: /home/{{ username }}/Desktop/{{ tplshortcut.application.name }}.desktop
      
      {%- endfor %}
      {%- endif %}
      
      {#- Delete url link #}
      {%- if tplshortcut.link.name %}
      {%- for username in usernames  %}
      
      my-shortcut-install-file-managed-{{ username }}-link:
        file.absent:
          - name: /home/{{ username }}/Desktop/{{ tplshortcut.link.name }}.desktop
      
      {%- endfor %}
      {%- endif %}
      
      {#- Delete symlink #}
      {%- if tplshortcut.symlink.name %}
      {%- for username in usernames  %}
      
      my-shortcut-install-file-symlink-{{ username }}-symlink:
        file.absent:
          - name: /home/{{ username }}/Desktop/{{ tplshortcut.symlink.name }}
      
      {%- endfor %}
      {%- endif %}
    4. Измените файл map.jinja(словарь со значениями по умолчанию):

      1. Измените имя ключа для словаря в хранилище Pillar, используемого для динамического переопределения значений по умолчанию.

        Рекомендуется для соблюдения уникальности придерживаться именования вида: formula-name:lookup. Например, my-shortcut:lookup.
      2. Измените значение application.name.

      3. Измените значение link.name.

      4. Измените значения symlink.name и symlink.target.

        {% set mapdata = salt['grains.filter_by']({
            'default': {
                'application': {
                    'name': 'man_application',
                },
                'link': {
                    'name': 'duckduckgo_link',
                },
                'symlink': {
                    'name': 'distro-info_ubuntu_symlink',
                    'target': '/usr/share/distro-info/ubuntu.csv'
                },
                'user': {
                    'usernames': [
                    ],
                },
            },
        }, merge=salt['pillar.get']('my-shortcut:lookup'), base='default') %}
    После того как формула будет написана, следуйте инструкциям по работе с формулой в разделе «Работа с формулами».
    Формула tpl-script-formula

    Формула-шаблон для выполнения скриптов.

    Доступные состояния

    Состояние tpl-script

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Выполняет скрипт. Имеет зависимость от tpl-script.run через список include.

    Состояние tpl-script.run

    Выполняет скрипт test_script.sh, если файл /tmp/test_script-unless отсутствует в файловой системе агента. The running script creates /tmp/test_script-unless file with TEST_ENV shell variable content.

    Состояние tpl-script.clean

    Удаляет файл /tmp/test_script-unless на агенте.

    Пример файла pillar.example
    tpl-script:
      # Переопределите значение map.jinja
      lookup:
        # Задайте имя для файла скрипта, который хранится в {{ tpldir }}/files/
        file_name: "test_script.sh"
         # Задайте оболочку, которая будет использоваться для выполнения скрипта
        shell: "/bin/sh"
         # Задайте переменные env
        env:
          test_env: "HELLO WORLD!"

    Написание формулы типа tpl-script-formula

    1. Скопируйте формулу-шаблон (tpl-script) в новую директорию с новым названием (my-script).

      $ tar -xvf ~/Downloads/inno-lcm-salt-formulas-0.10.0.tar.gz \
          --strip-components 3 \
          -C ~/ \
          ./formulas/tpl-script-formula/tpl-shortcut
      $ cp -R ~/tpl-script/ ~/my-script && cd ~/my-script
    2. Переименуйте файл ./files/test_script.sh в ./files/my-new-script.sh и затем измените его содержимое. Файл будет выглядеть следующим образом:

      #!/bin/bash
      #
      echo "Working hard..."
      echo "True" > /var/local/my-script.run.id
      
      # writing the state line
      echo  # an empty line here so the next line will be the last.
      echo "changed=yes comment='Created /var/local/my-script.run.id file' whatever=123"
    3. Измените файл состояний run.sls (запуск скрипта):

      1. Измените ID состояний.

      2. Удалите аргумент env и его значения.

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

        # -*- coding: utf-8 -*-
        # vim: ft=sls
        
        {#- Get the `tplroot` from `tpldir` #}
        {%- set tplroot = tpldir.split('/')[0] %}
        {%- from tplroot ~ "/map.jinja" import mapdata as tplscript with context %}
        
        {#- Run custom script #}
        {%- if tplscript.file_name %}
        
        my-script-run-cmd-script:
          cmd.script:
            - source: salt://{{ tpldir }}/files/{{ tplscript.file_name }}
            - cwd: /
            - shell: {{ tplscript.shell }}
            - unless: "test -f /var/local/my-script.run.id"
        
        {%- endif %}
    4. Измените файл состояний clean.sls (удаление проверочного файла):

      1. Измените ID состояний.

      2. Измените значение аргумента name.

        # -*- coding: utf-8 -*-
        # vim: ft=sls
        
        {#- Get the `tplroot` from `tpldir` #}
        {%- set tplroot = tpldir.split('/')[0] %}
        {%- from tplroot ~ "/map.jinja" import mapdata as tplscript with context %}
        
        {#- Delete symlink #}
        {%- if tplscript.file_name %}
        
        my-script-clean-file-absent:
          file.absent:
            - name: /var/local/my-script.run.id
        
        {%- endif %}
    5. Измените файл map.jinja(словарь со значениями по умолчанию):

      1. Измените имя ключа для словаря в хранилище Pillar, используемого для динамического переопределения значений по умолчанию.

      2. Измените значение file_name, указав имя созданного скрипта.

      3. Удалите env.

        {% set mapdata = salt['grains.filter_by']({
            'default': {
                'file_name': 'my-new-script.sh',
                'shell': '/bin/sh',
            },
        }, merge=salt['pillar.get']('my-script:lookup'), base='default') %}
    После того как формула будет написана, следуйте инструкциям по работе с формулой в разделе «Работа с формулами».
    Формула tpl-yb-settings-formula

    Формула-шаблон для управления настройками веб-браузера Yandex.

    Доступные состояния

    Состояние tpl-yb-settings

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает политики Яндекс-браузера. Имеет зависимость от tpl-yb-settings.install через список include.

    Состояние tpl-yb-settings.install

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

    Состояние tpl-yb-settings.clean

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

    Пример файла pillar.example
    tpl-yb-settings:
      # Override map.jinja
      lookup:
        # Переопределите значение map.jinja
        policies:
          # Задайте параметры управляемых политик
          managed:
            # Задайте имя файла с управляемыми политиками (.json), который будет помещен в файловую систему агента
            name: "managed_policies"
            # Задайте имя файла с управляемыми политиками (.json) для загрузки на агент, этот файл может быть помещен как на
            # сервере управления, так и на сервере HTTP(S) или FTP server. Значение может быть пустой строкой
            source: "salt://tpl-yb-settings/files/managed_policies.json"
          # Задайте параметры рекомендуемых политик
          recommended:
            # SЗадайте имя файла с рекомендуемыми политиками (.json), который будет помещен в файловую систему агента
            name: "recommended_policies"
            # Задайте имя файла с рекомендуемыми политиками (.json) для загрузки на агент, этот файл может быть помещен как на
            # сервере управления, так и на сервере HTTP(S) или FTP server. Значение может быть пустой строкой
            source: "salt://tpl-yb-settings/files/recommended_policies.json"
    Написание формулы типа tpl-yb-settings
    1. Скопируйте формулу-шаблон (tpl-yb-settings) в новую директорию с новым названием (my-yb-settings):

      $ tar -xvf ~/Downloads/inno-lcm-salt-formulas-0.11.0.tar.gz \
          --strip-components 3 \
          -C ~/ \
          ./formulas/tpl-yb-settings-formula/tpl-yb-settings
      $ cp -R ~/tpl-yb-settings/ ~/my-yb-settings && cd ~/my-yb-settings
    2. Измените файл ./files/managed_policies.json, добавив в него политики, которые нужно принудительно применить на устройствах пользователей.

      В качестве примера рассмотрим добавление нескольких разрешающих и запрещающую по умолчанию все доступы URL политик:

      {
          "URLBlocklist": ["*"],
          "URLAllowlist": [
            "browser://policy",
            "duckduckgo.com",
            "https://yandex.ru/pogoda",
            "file://*"
          ]
      }
    3. Измените файл ./files/recommended_policies.json, добавив в него политики:

      {
          "HomepageLocation": "https://duckduckgo.com"
      }
    4. В файле состояний install.sls (установка политик) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplybsettings with context %}
      
      {%- if tplybsettings.policies.managed.source %}
      
      my-yb-settings-install-file-managed-policies-managed:
        file.managed:
          - name: "/etc/opt/yandex/browser/policies/managed/{{ tplybsettings.policies.managed.name }}.json"
          - source: {{ tplybsettings.policies.managed.source }}
          - skip_verify: True
          - makedirs: True
      
      {%- endif %}
      
      {%- if tplybsettings.policies.recommended.source %}
      
      my-yb-settings-install-file-managed-policies-recommended:
        file.managed:
          - name: "/etc/opt/yandex/browser/policies/recommended/{{ tplybsettings.policies.recommended.name }}.json"
          - source: {{ tplybsettings.policies.recommended.source }}
          - skip_verify: True
          - makedirs: True
      
      {%- endif %}
    5. В файле состояний clean.sls (удаление политик) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplybsettings with context %}
      
      {%- if tplybsettings.policies.managed.source %}
      
      my-yb-settings-clean-file-absent-policies-managed:
        file.absent:
          - name: "/etc/opt/yandex/browser/policies/managed/{{ tplybsettings.policies.managed.name }}.json"
      
      {%- endif %}
      
      {%- if tplybsettings.policies.recommended.source %}
      
      my-yb-settings-clean-file-absent-policies-recommended:
        file.absent:
          - name: "/etc/opt/yandex/browser/policies/recommended/{{ tplybsettings.policies.recommended.name }}.json"
      
      {%- endif %}
    6. Измените файл map.jinja(словарь со значениями по умолчанию):

      1. Измените имя ключа для словаря в хранилище Pillar, используемого для динамического переопределения значений по умолчанию.

      2. Измените значения policies.managed.source и policies.recommended.source и расположение файлов политик file_name.

        {% set mapdata = salt['grains.filter_by']({
            'default': {
                'policies': {
                    'managed': {
                        'name': 'managed_policies',
                        'source': 'salt://my-yb-settings/files/managed_policies.json',
                    },
                    'recommended': {
                        'name': 'recommended_policies',
                        'source': 'salt://my-yb-settings/files/recommended_policies.json',
                    },
                },
            },
        }, merge=salt['pillar.get']('my-yb-settings:lookup'), base='default') %}
    После того как формула будет написана, следуйте инструкциям по работе с формулой в разделе «Работа с формулами».
    Формула tpl-yb-settings-formula

    Формула-шаблон для управления настройками веб-браузера Yandex.

    Доступные состояния

    Состояние tpl-yb-settings

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Устанавливает политики Яндекс-браузера. Имеет зависимость от tpl-yb-settings.install через список include.

    Состояние tpl-yb-settings.install

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

    Состояние tpl-yb-settings.clean

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

    Пример файла pillar.example
    tpl-yb-settings:
      # Override map.jinja
      lookup:
        # Переопределите значение map.jinja
        policies:
          # Задайте параметры управляемых политик
          managed:
            # Задайте имя файла с управляемыми политиками (.json), который будет помещен в файловую систему агента
            name: "managed_policies"
            # Задайте имя файла с управляемыми политиками (.json) для загрузки на агент, этот файл может быть помещен как на
            # сервере управления, так и на сервере HTTP(S) или FTP server. Значение может быть пустой строкой
            source: "salt://tpl-yb-settings/files/managed_policies.json"
          # Задайте параметры рекомендуемых политик
          recommended:
            # SЗадайте имя файла с рекомендуемыми политиками (.json), который будет помещен в файловую систему агента
            name: "recommended_policies"
            # Задайте имя файла с рекомендуемыми политиками (.json) для загрузки на агент, этот файл может быть помещен как на
            # сервере управления, так и на сервере HTTP(S) или FTP server. Значение может быть пустой строкой
            source: "salt://tpl-yb-settings/files/recommended_policies.json"
    Написание формулы типа tpl-yb-settings
    1. Скопируйте формулу-шаблон (tpl-yb-settings) в новую директорию с новым названием (my-yb-settings):

      $ tar -xvf ~/Downloads/inno-lcm-salt-formulas-0.11.0.tar.gz \
          --strip-components 3 \
          -C ~/ \
          ./formulas/tpl-yb-settings-formula/tpl-yb-settings
      $ cp -R ~/tpl-yb-settings/ ~/my-yb-settings && cd ~/my-yb-settings
    2. Измените файл ./files/managed_policies.json, добавив в него политики, которые нужно принудительно применить на устройствах пользователей.

      В качестве примера рассмотрим добавление нескольких разрешающих и запрещающую по умолчанию все доступы URL политик:

      {
          "URLBlocklist": ["*"],
          "URLAllowlist": [
            "browser://policy",
            "duckduckgo.com",
            "https://yandex.ru/pogoda",
            "file://*"
          ]
      }
    3. Измените файл ./files/recommended_policies.json, добавив в него политики:

      {
          "HomepageLocation": "https://duckduckgo.com"
      }
    4. В файле состояний install.sls (установка политик) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplybsettings with context %}
      
      {%- if tplybsettings.policies.managed.source %}
      
      my-yb-settings-install-file-managed-policies-managed:
        file.managed:
          - name: "/etc/opt/yandex/browser/policies/managed/{{ tplybsettings.policies.managed.name }}.json"
          - source: {{ tplybsettings.policies.managed.source }}
          - skip_verify: True
          - makedirs: True
      
      {%- endif %}
      
      {%- if tplybsettings.policies.recommended.source %}
      
      my-yb-settings-install-file-managed-policies-recommended:
        file.managed:
          - name: "/etc/opt/yandex/browser/policies/recommended/{{ tplybsettings.policies.recommended.name }}.json"
          - source: {{ tplybsettings.policies.recommended.source }}
          - skip_verify: True
          - makedirs: True
      
      {%- endif %}
    5. В файле состояний clean.sls (удаление политик) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplybsettings with context %}
      
      {%- if tplybsettings.policies.managed.source %}
      
      my-yb-settings-clean-file-absent-policies-managed:
        file.absent:
          - name: "/etc/opt/yandex/browser/policies/managed/{{ tplybsettings.policies.managed.name }}.json"
      
      {%- endif %}
      
      {%- if tplybsettings.policies.recommended.source %}
      
      my-yb-settings-clean-file-absent-policies-recommended:
        file.absent:
          - name: "/etc/opt/yandex/browser/policies/recommended/{{ tplybsettings.policies.recommended.name }}.json"
      
      {%- endif %}
    6. Измените файл map.jinja(словарь со значениями по умолчанию):

      1. Измените имя ключа для словаря в хранилище Pillar, используемого для динамического переопределения значений по умолчанию.

      2. Измените значения policies.managed.source и policies.recommended.source и расположение файлов политик file_name.

        {% set mapdata = salt['grains.filter_by']({
            'default': {
                'policies': {
                    'managed': {
                        'name': 'managed_policies',
                        'source': 'salt://my-yb-settings/files/managed_policies.json',
                    },
                    'recommended': {
                        'name': 'recommended_policies',
                        'source': 'salt://my-yb-settings/files/recommended_policies.json',
                    },
                },
            },
        }, merge=salt['pillar.get']('my-yb-settings:lookup'), base='default') %}
    После того как формула будет написана, следуйте инструкциям по работе с формулой в разделе «Работа с формулами».
    Формула tpl-group-members-formula

    Формула-шаблон для управления членством в локальных группах.

    Доступные состояния

    Состояние tpl-group-members

    Мета-состояние (состояние, которое включает в себя другие состояния).

    Создает и управляет локальными настройками групп. Имеет зависимость от tpl-group-members.install через список include.

    Состояние tpl-group-members.install

    Создает group_name (если эта группа отсутствует на агенте) и изменяет настройки группы.

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

    • если для параметра change установлено значение del, пользователи будут исключены из состава группы;

    • если для параметра change установлено значение "", заменяет существующих членов группы списком новых участников.

    Состояние tpl-group-members.clean

    Удаляет группу group_name на агенте.

    Пример файла pillar.example
    tpl-group-members:
      # Переопределите значение map.jinja
      lookup:
        # Задайте имя группы
        group_name: "sudo"
        # Задайте id для группы;
        # Если оставить поле пустым, группе автоматически будет присвоен следующий свободный идентификатор.
        gid: ""
        # Укажите, является ли группа системной группой.
        # Это опция '-r' в команде 'groupadd`
        system: false
        # Задайте действие для списка пользователей: добавить (`add`), удалить(`del`) или заменить ("").
        change: ""
        # Задайте список пользователей
        users: [
            "user1",
            "user2",
        ]
    Написание формулы типа tpl-group-members-formula
    1. Скопируйте формулу-шаблон (tpl-group-members) в новую директорию с новым названием (my-group-members).

      $ tar -xvf ~/Downloads/inno-lcm-salt-formulas-X.Y.Z.tar.gz \
          --strip-components 3 \
          -C ~/ \
          ./formulas/tpl-yb-settings-formula/tpl-group-members
      $ cp -R ~/tpl-group-members/ ~/my-group-members && cd ~/my-group-members
    2. В файле состояний install.sls (создание и настройка группы) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplgroupmembers with context %}
      
      {%- if tplgroupmembers.group_name %}
      
      my-group-members-group-present:
        group.present:
          - name: {{ tplgroupmembers.group_name }}
          {%- if tplgroupmembers.gid %}
          - gid: {{ tplgroupmembers.gid }}
          {%- endif %}
          {%- if tplgroupmembers.system %}
          - system: {{ tplgroupmembers.system }}
          {%- endif %}
          {%- if tplgroupmembers.change == 'add' %}
          - addusers: {{ tplgroupmembers.users }}
          {%- elif tplgroupmembers.change == 'del' %}
          - delusers: {{ tplgroupmembers.users }}
          {%- else %}
          - members: {{ tplgroupmembers.users }}
          {%- endif %}
      
      {%- endif %}
    3. В файле состояний clean.sls (удаление группы) измените ID состояний:

      # -*- coding: utf-8 -*-
      # vim: ft=sls
      
      {#- Get the `tplroot` from `tpldir` #}
      {%- set tplroot = tpldir.split('/')[0] %}
      {%- from tplroot ~ "/map.jinja" import mapdata as tplgroupmembers with context %}
      
      {%- if tplgroupmembers.group_name %}
      
      my-group-members-group-absent:
        group.absent:
          - name: {{ tplgroupmembers.group_name }}
      
      {%- endif %}
    4. Измените файл map.jinja(словарь со значениями по умолчанию). Например, добавьте в группу sudo некоторых пользователей, для этого:

      1. Измените имя ключа для словаря в хранилище Pillar, используемого для динамического переопределения значений по умолчанию.

      2. Измените значение group_name на sudo.

      3. Измените значение change на add (добавить в группу).

      4. Измените значение users, указав список пользователей.

        {% set mapdata = salt['grains.filter_by']({
            'default': {
                'group_name': 'sudo',
                'gid': '',
                'system': false,
                'change': '',
                'users': [
                    'user1',
                    'user2',
                ],
            },
        }, merge=salt['pillar.get']('my-group-members:lookup'), base='default') %}
    После того как формула будет написана, следуйте инструкциям по работе с формулой в разделе «Работа с формулами».

    Интеграция бэкенда LCM с модулем координации

    В рамках интеграции c модулем координации бэкенд LCM обеспечивает:

    Использование внешней Apache Kafka

    Компонент Apache Kafka используется для передачи данных с серверов управления в бэкенд LCM с помощью подписки на топик брокера сообщений.

    Для использования Apache Kafka необходимо выполнить настройки:

    Первые три шага выполняются перед установкой продукта.
    1. Установите Apache Kafka, следуя инструкциям в официальной документации.

    2. Создайте топик salt-topic, следуя инструкции в официальной документации.

    3. В конфигурационном файле application.properties задайте параметры:

      1. Укажите URL сервиса Apache Kafka (параметр mp.messaging.incoming.salt-events-kafka.bootstrap.servers).

      2. Задайте имя созданного топика (параметр mp.messaging.incoming.salt-events-kafka.topic).

      3. Опционально. Задайте количество партиций для топика (параметр mp.messaging.incoming.salt-events-kafka.partitions).

        Подробное описание параметров см. в разделе «Настройка бэкенда продукта» документа «Руководство по установке»
    4. После установки продукта задайте имя топика для сервера управления  — в конфигурационном файле salt-master.conf для параметра returner.kafka_custom.topic укажите имя топика salt-topic.

    Определение сервера управления для агента при отправке HTTP-запроса на установку ПО

    Чтобы выполнить запрос на установку ПО на агенте, бэкенд LCM отправляет HTTP-запрос, содержащий идентификатор агента, на соответствующий сервер управления. Для того чтобы корректно определить сервер управления, бэкенд LCM анализирует сообщения о событиях SaltStack:

    • minion_ping — указывает на то, что агент только что отправил ping-запрос на сервер управления;

    • minion_start — указывает на то, что агент только что запустился;

    • /minion/refresh/<minion-id> — указывает на то, что была выполнена операция обновления данных на агенте с указанным идентификатором.

    Чтобы сообщения обрабатывались корректно, важно выполнить следующие настройки при установке продукта:

    1. В конфигурационном файле агента настраивается интервал времени между отправкой ping-запросов от агента на сервер управления — параметр ping_interval (см. раздел «Настройка интервала времени между отправкой ping-запросов от агентов на сервер управления» документа «Руководство по установке»).

    2. Для всех серверов управления задаются одинаковые порт, на котором будет запущен API-интерфейс, логин и пароль для подключения к серверу управления. Описание настроек приведено в разделе «Настройка бэкенда продукта» документа «Руководство по установке»).

    Инвентаризация

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

    Коллекция АРМ — это множество АРМ, которое формируется в результате фильтрации всех АРМ по атрибутам самих АРМ и атрибутам пользователей, ассоциированных с ними.

    Подробнее о создании и обновлении коллекций АРМ см. в разделе «Создание и обновление коллекций АРМ».

    Продукт «Служба управления конфигурациями» обеспечивает следующие способы загрузки атрибутов в коллекции АРМ:

    Импорт данных из модуля координации по аппаратной конфигурации АРМ

    В рамках инвентаризации в БД продукта «Служба управления конфигурациями» импортируются следующие технические характеристики АРМ из модуля координации:

    • актуальные данные по аппаратной конфигурации АРМ;

    • актуальные данные системного ПО АРМ;

    • список фактически развернутого прикладного и системного ПО на АРМ.

    Данные поступают от агентов с помощью механизма Grains на сервер управления согласно расписанию, заданному в конфигурации модуля координации. Сервер управления публикует их в виде события в канале REST endpoint Events, который прослушивается LCM. Каждое из таких событий содержит технические характеристики по одному из агентов, которые актуализируются в БД:

    Параметр АРМ из ответа модуля координации Параметр в LCM БД Описание

    id

    machines.minion_id

    Идентификатор агента

    nodename

    machines.node_name

    Короткое имя АРМ (NetBIOS name)

    fqdn

    machines.fqdn

    Полное доменное имя АРМ

    fqdn_ip4

    machines.domain_ip

    Набор доменных адресов IPv4

    domain

    machines.domain

    Имя домена

    num_cpus

    machines.cpu_num

    Количество ядер процессора

    cpu_model

    machines.cpu_model

    Модель процессора

    cpuarch

    machines.cpu_arc

    Архитектура процессора

    mem_total

    machines.ram

    Объем ОЗУ

    swap_total

    machines.swap

    Общий физический размер свопинга

    hwaddr_interfaces

    machine_networks.mac

    Физические адреса сетевого оборудования (MAC)

    ip4_gw

    machines.ip4_gw

    Шлюз Ipv4

    ip4_interfaces

    machine_networks.ipv4_list

    Сетевые интерфейсы IPv4

    ip6_interfaces

    machine_networks.ipv6_list

    Сетевые интерфейсы IPv6

    ssds

    machine_disks

    Диски SSD

    disks

    machines.machine_disks

    Диски HDD

    serialnumber

    machines.serial_number

    Серийный номер устройства

    kernel

    machines.kernel

    Ядро ОС

    kernelrelease

    machines.kernel_release

    Релиз ядра ОС

    lsb_distrib_codename

    machines.distrib_codename

    Код дистрибутива ОС

    lsb_distrib_description

    machines.os_description

    Описание версии ОС

    oscodename

    machines.os_codename

    Код версии ОС

    osarch

    machines.cpu_arc

    Архитектура ОС

    osfullname

    machines.os_fullname

    Полное наименование ОС

    osmajorrelease

    machines.os_major_release

    Мажорная версия релиза ОС

    osrelease

    machines.os_release

    Версия релиза ОС

    saltversion

    machines.salt_version

    Версия модуля координации на агенте

    master

    machines.salt_master

    Имя сервера управления

    pythonversion

    machines.python_version

    Версия Python для модуля координации на агенте

    _stamp

    machines.updated_at

    Дата и время актуализации характеристик

    Импорт данных по учётным записям пользователей c сервера LDAP

    Импорт учетных данных пользователей сервера LDAP выполняется согласно расписанию, которое задается в конфигурационных параметрах бэкенда продукта (см. описание параметров в документе «Руководство по установке» в разделе «Настройка бэкенда продукта»).

    После синхронизации в БД в таблицах users и user_groups появляется информация о пользователях домена и их группах:

    Параметр на LDAP-сервере Параметр в БД LCM Описание

    objectGUID

    users.id

    Уникальный идентификатор пользователя

    sAMAccountName

    users.login

    Имя пользователя для входа в систему (Логин)

    userAccountControl

    true

    Указывает, что учетная запись пользователя выключена

    userPrincipalName

    users.domain_full_name

    Полное доменное имя пользователя (например, ivanov@inno.tech или petrov@samara.vtb.ru)

    userPrincipalName (подстрока)

    users.domain

    Имя домена в короткой форме записи (например, inno.tech или samara.vtb.ru)

    mail

    users.email

    Адрес электронной почты

    cn

    users.common_name

    Общее имя пользователя

    name

    users.first_name

    Короткое имя пользователя

    givenName

    users.given_name

    Имя пользователя

    sn

    users.last_name

    Фамилия пользователя

    displayName

    users.display_name

    Отображаемое имя пользователя

    title

    users.title

    Должность пользователя

    department

    users.department

    Отдел, в котором работает пользователь

    company

    users.company

    Подразделение, в котором работает пользователь

    memberOf

    user_groups.group_name

    Группы пользователя, связь один к многим

    Расписание выполнения синхронизации пользователей

    Синхронизация происходит с помощью встроенного в продукт планировщика задач по расписанию. Управление расписанием осуществляется с помощью параметра lcm.inventory.job.sync-users.cron.expr в файле application.properties:

    lcm.inventory.job.sync-users.cron.expr=*/5 * * * * ?

    Значением данного параметра выступает выражение cron-like.

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

    Описание полей:

    Поле Обязательность заполнения Допустимые значения Допустимые специальные символы

    Секунды

    Да

    0-59

    , - * /

    Минуты

    Да

    0-59

    , - * /

    Часы

    Да

    0-23

    , - * /

    День месяца

    Да

    1-31

    , - * ? / L W

    Месяц

    Да

    1-12 или JAN-DEC, где:

    • (1) JAN — январь;

    • (2) FEB — февраль;

    • (3) MAR — март;

    • (4) APR — апрель;

    • (5) MAY — май;

    • (6) JUN — июнь;

    • (7) JUL — июль;

    • (8) AUG — август;

    • (9) SEP — сентябрь;

    • (10) OCT — октябрь;

    • (11) NOV — ноябрь;

    • (12) DEC — декабрь

    , - * /

    День недели

    Да

    1-7 или SUN-SAT, где:

    • (1) SUN — воскресенье;

    • (2) MON — понедельник;

    • (3) TUE — вторник;

    • (4) WED — среда;

    • (5) THU — четверг;

    • (6) FRI — пятница;

    • (7) SAT — суббота

    , - * ? / L #

    Год

    Нет

    1970-2099

    , - * /

    Описание специальных символов:

    Значение Расшифровка Описание

    *

    Все значения

    Используется для выбора всех значений в поле. Например, если в поле Минуты указано значение *, — это будет означать, что задание должно выполняться каждую минуту

    ?

    Нет специального значения

    Используется, когда не важно, какой это должен быть день месяца или день недели. Например, если в поле День месяца указано значение 10, а в поле День недели — ?, — это будет означать, что задание должно выполняться 10-го числа месяца, независимо от того, какой это будет день недели

    -

    Используются для указания диапазона. Например, если в поле Часы указано значение 10-12, — это будет означать, что задание будет выполняться в 10:00, 11:00 и 12:00 часов

    ,

    Используется для поочередного указания значений. Например, если в поле День недели указано значение MON,WED,FRI, — это будет означать, что задание будет выполняться в понедельник, среду и пятницу

    /

    Используется для указания приращения. Например, если в поле Секунды указано значение 0/15, — это будет означать, что задание будет выполняться в 0, 15, 30 и 45 секунд; а если указано значение 5/15 — в 5,20,35 и 50 секунд

    L

    От англ. — last (последний)

    Используется для указания значений:

    • в поле День месяца — последнего дня месяца; например, для января — это будет 31 января, а для февраля — 28 февраля в не високосный год;

    • в поле День недели — субботы; однако если значение L используется после другого значения, оно будет означать последние n-дней месяца, например, значение 6L будет означать последнюю пятницу месяца.

    Также может использоваться для указания смещения от последнего дня месяца, например, L-3 будет означать третий день до конца месяца.

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

    W

    От англ. — weekday (рабочий день)

    Используется для указания ближайшего рабочего дня недели (понедельник-пятница) к указанному дню. Например, если в поле День месяца указано значение 15W, — это будет означать, что задание будет выполняться в ближайший рабочий день к 15-му числу месяца. Если 15-е число выпадает на субботу, задание будет запущено в пятницу 14-го числа, а если 15-е число выпадает на воскресенье, то в понедельник 16-го числа. Если 15-е число выпадает на вторник, то задание будет запущено во вторник 15-го числа. Однако, если указано значение 1W для дня месяца, и 1-е число выпадает на субботу, то задание будет запущено в понедельник 3-го числа, так как оно не может пересекать границы дней месяца.

    Можно объединить символ W с символом L (LW), чтобы задать значение, которое будет означать последний будний день месяца.

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

    #

    Используется для указания n-ного дня месяца. Например, если в поле День недели указано значение 6#3, — это будет означать, что задание будет выполняться в третью пятницу месяца.

    Если указано значение #5, а в месяце нет пяти заданных дней недели, то в этом месяце задание выполнено не будет

    Примеры выражений:

    • * * * ? * * — задача должна выполняться каждую секунду;

    • 0 * * ? * * — задача должна выполняться каждую минуту;

    • 0 */2 * ? * * — задача должна выполняться каждую четную минуту;

    • 0 15,30,45 * ? * * — задача должна выполняться каждый час в 15, 30 и 45 минут;

    • 0 0 * * * — задача должна выполняться в полночь каждый день;

    • 0 0 12 ? * 5#3 — задача должна выполняться каждый месяц в третий четверг месяца с 00:00 до 12:00.

    Больше примеров вы можете найти, перейдя по ссылке.

    В качестве значения параметра по умолчанию используется 0 0 12 * * ?, что соответствует ежедневному запуску задания в 00:00:00.

    Для выключения задания синхронизации используется значение указанного параметра off:

    lcm.inventory.job.sync-users.cron.expr=off

    Синхронизация пользователей может быть осуществлена из нескольких доменов LDAP-сервера и выполняется последовательно. Для задания параметров подключения к каждому из доменов заполните следующий набор параметров группы lcm.inventory.ldap.datasource[i] в файле application.properties:

    # максимальное количество пользователей для одной итерации синхронизации
    lcm.inventory.ldap.search-page-size=500
    
    # Блок параметров подключения к домену номер #1 (нумерация с 0)
    
    # условное обозначение домена
    lcm.inventory.ldap.datasource[0].name=domain_alias1
    # IP адрес или сетевое имя контроллера домена
    lcm.inventory.ldap.datasource[0].host=192.168.0.1
    # Порт для соединения по протоколу LDAP. Опционален, по умолчанию имеет значение `389`.
    # Для LDAP over SSL обычно используют порт 636
    lcm.inventory.ldap.datasource[0].port=636
    # Имя пользователя, которое будет использовано для подключения к домену MS AD.
    # Может иметь следующие форматы
    # 1) <имя_пользователя>@<имя домена>, например ivanov@INNO
    # 2) Пользователь в формате LDAP, например CN=ivanov,CN=Users,DC=inno,DC=local
    lcm.inventory.ldap.datasource[0].username=username1@domain1_name
    # Пароль пользователя для подключения к домену MS AD.
    lcm.inventory.ldap.datasource[0].password=user_password
    # Параметр отвечающий за соединение по протоколу LDAP over SSL (LDAPS).
    # Возможные значения:
    # 1) false - соответствует выключенному протоколу LDAPS, используется обычный LDAP
    # 2) true - соответствует включенному протоколу LDAPS, требует наличие файла с сертификатом для SSL соединения (задается отдельным параметром)
    # 3) trust-all - соответствует включенному протоколу LDAPS, принимает любые сертификаты без подтверждения
    # Опционален, по умолчанию имеет значение `false`
    lcm.inventory.ldap.datasource[0].ssl=true
    # Относительный или абсолютный путь к файлу с сертификатом для подключения через LDAPS.
    # Опционален, по умолчанию имеет значение `certificate.pem`
    # Формат файла с сертификатом SSL и способ его получения описаны ниже
    lcm.inventory.ldap.datasource[0].ssl-certificate=/home/username/cert1.pem
    # Базовое имя домена для поиска пользователей в формате записи LDAP
    lcm.inventory.ldap.datasource[0].base-dn=DC=domain_name1,DC=local
    # Максимальная длительность подключения к LDAP серверу в миллисекундах. Значение `0` означает бесконечное ожидание.
    # Опционален, по умолчанию имеет значение `10000`
    lcm.inventory.ldap.datasource[0].connect-timeout-millis
    # Максимальная длительность выполнения запроса к LDAP серверу в миллисекундах. Значение `0` означает бесконечное ожидание.
    # Опционален, по умолчанию имеет значение `10000`
    lcm.inventory.ldap.datasource[0].response-timeout
    # Параметр отвечает за освобождение соединения в случае превышения максимальной длительности ожидания запроса.
    # Возможные значения `true` и `false`
    # Опционален, по умолчанию имеет значение `true`
    lcm.inventory.ldap.datasource[0].abandon-on-timeout
    # Указывает, разрешать ли использование экземпляра фабрики сокетов (который может совместно использоваться несколькими соединениями)
    # для одновременного создания нескольких сокетов. Как правило, реализации фабрики сокетов являются потокобезопасными
    # и могут создавать несколько соединений одновременно в отдельных потоках, но известно, что это не так в некоторых
    # реализациях виртуальных машин (например, фабрики сокетов SSL в IBM JVM). Этот параметр может использоваться, чтобы указать,
    # следует ли разрешить одновременные попытки создания сокета (что может обеспечить лучшую и более стабильную производительность,
    # особенно в случаях, когда попытка подключения не удалась из-за тайм-аута) или предотвратить (что может быть необходимо для
    # непотокового реализации фабрики сокетов)
    # Возможные значения `true` и `false`
    # Опционален, по умолчанию имеет значение `true`
    lcm.inventory.ldap.datasource[0].allow-concurrent-socket-factory-use
    
    # Блок параметров подключения к домену номер #2
    lcm.inventory.ldap.datasource[1].name=domain_alias2
    lcm.inventory.ldap.datasource[1].host=192.168.0.2
    lcm.inventory.ldap.datasource[1].port=389
    lcm.inventory.ldap.datasource[1].username=username2@domain2_name
    lcm.inventory.ldap.datasource[1].ssl=false
    lcm.inventory.ldap.datasource[1].base-dn=DC=domain_name2,DC=local
    
    # Блок параметров подключения к домену номер #3
    lcm.inventory.ldap.datasource[2].name=domain_alias2
    #...

    Импорт данных о связи пользователей и устройств из CSV-файла

    В рамках инвентаризации в БД продукта «Служба управления конфигурациями» импортируется информация о связи пользователей и устройств посредством загрузки данных из CSV-файла через пользовательский интерфейс администратора (см. документ «Руководство администратора»). CSV-файл должен быть определенного формата: содержать 3 столбца и в качестве разделителя использовать точку с запятой (;):

    <operation>;<user_name>@<user_domain>;<fqdn>

    Где:

    1. Параметр первого столбца operation должен содержать одну из следующих команд (перечислены в порядке приоритета выполнения):

      1. R — (от англ.: remove) удалить связь между пользователем и устройством.

      2. RA — (от англ.: remove all) удалить все связи, существующие по указанному пользователю/устройству. Требуется заполнить или логин@домен пользователя, или полное доменное имя машины.

      3. A — (от англ.: add) создать или обновить связь между пользователем и устройством.

    2. Параметр второго столбца user_name должен содержать логин пользователя в указанном домене. Например, aspushkin или fmdostoevskiy.

    3. Параметр второго столбца user_domain должен содержать домен пользователя и соответствовать полному имени домена пользователя, выгруженному с сервера LDAP. Например, inno.tech или saratov.vtb.ru.

    4. Параметр третьего столбца fqdn должен содержать полное доменное имя АРМ, выгруженного из модуля координации, например: kassa256.vtb.ru.

    • При создании CSV-файла важно учитывать регистр имен устройств. Например, Laptop1.sochi.vtb.ru и LAPTOP1.sochi.vtb.ru будут интерпретированы по-разному. Полное имя устройства должно абсолютно совпадать с реальным именем.

    • Допустимо использовать только файлы с кодировкой:

      • csv;

      • csv macintosh;

      • csv ms dos.

    Пример заполнения файла CSV:

    A;username1@domain.name;notebook1.domain.name
    A;username1@domain.name;notebook2.domain.name
    A;username2@domain.name;notebook1.domain.name
    RA;username1@domain.name;
    RA;username2@domain.name;
    RA;;notebook1.domain.name
    R;username2@domain.name;notebook2.domain.name

    Строки, не соответствующие описанному формату записи, будут проигнорированы.

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

    1. Удаление конкретного пользователя с конкретного АРМ.

    2. Удаление связок по идентификатору пользователя.

    3. Удаление связок по идентификатору АРМ.

    4. Добавление связок.

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

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

    Создание и обновление коллекций АРМ

    Коллекции АРМ могут быть статическими и динамическими.

    Имя коллекции не может быть пустым. При создании коллекции АРМ необходимо указать уникальное имя. Коллекция с невалидным именем не будет создана и сохранена.

    Статические коллекции

    Список АРМ в статических коллекциях обновляется только при создании или вручную. Для создания/обновления такой коллекции администратор выполняет SQL-запрос к базе данных через пользовательский интерфейс администратора (подробнее о создании коллекций см. «Руководство администратора» раздел «Создание/изменение коллекции устройств»).

    SQL-запрос должен иметь тип select и в списке извлекаемых колонок содержать столбец minion_id.

    При создании SQL-запроса нельзя использовать следующие операторы:

    • drop;

    • alter;

    • create;

    • update;

    • delete;

    • insert;

    • truncate.

    При использовании некорректного SQL-запроса коллекция не будет создана и сохранена.

    Шаблоны SQL-запросов

    1. Запрос с использованием базовой информации по пользователям и устройствам:

      select m.minion_id
      from users u
      join user_machine_mappings umm on umm.user_fdn = u.full_domain_name
      join machines m on m.fqdn = umm.machine_fqdn
      where <...>
    2. Запрос с использованием подробной информации по устройствам:

      select m.minion_id
      from machines m
      left join machine_disks md on md.minion_id = m.minion_id
      left join machine_networks mn on mn.minion_id = m.minion_id
      where <...>
    3. Запрос с использованием информации, доступной в модуле «Инвентаризация»:

      select m.minion_id
      from users u
      join user_machine_mappings umm on umm.user_fdn = u.full_domain_name
      join machines m on m.fqdn = umm.machine_fqdn
      left join machine_disks md on md.minion_id = m.minion_id
      left join machine_networks mn on mn.minion_id = m.minion_id
      where <...>

    Динамические коллекции

    Список АРМ в динамических коллекциях обновляется по заданному расписанию, а также при создании и редактировании. Расписание обновления представляет собой выражение cron-like для фреймворка Quartz, которое задается пользовательский интерфейс администратора (подробнее о создании коллекций см. «Руководство администратора» раздел «Создание/изменение коллекции устройств»).

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

    Настройка расписания синхронизации агентов с сервером управления

    Расписание синхронизации агентов с сервером управления с настройками по умолчанию задается в БД для всей системы при установке продукта.

    Настройки определяют:

    • операции, для которых выполняется синхронизация:

      • инвентаризации АРМ (highstate);

      • синхронизации параметров Grains (grains);

      • применения назначенных конфигураций на АРМ (grainsSync);

      • синхронизации хранилища Pillar (refreshPillar);

    • интервал в секундах, через который выполняется операция (seconds);

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

    Значения по умолчанию:

    {
      "highstate": {
        "seconds": 84400,
        "splay": 14400
      },
      "grains": {
        "seconds": 14400,
        "splay": 2400
      },
      "grainsSync": {
        "seconds": 84400,
        "splay": 14400
      },
      "refreshPillar": {
        "seconds": 14400,
        "splay": 2400
      }
    }

    Чтобы просмотреть текущие настройки или изменить их, используйте соответствующие API-методы (см. раздел «API логического модуля «Инвентаризация»» документа «Описание API»).

    Подходы работы с Java

    Дистрибутив Java включен по умолчанию в устанавливаемый Deb-пакет с модулем inno-lcm-core (бэкендом продукта «Служба управления конфигурациями»). При сборке Deb-пакета подключается дистрибутив Java, который был использован при сборке Deb-пакета непосредственно на сервере, где производилась сборка (см. раздел «Установка Deb-пакетов с модулями продукта» документа «Руководство по установке»).

    Версия Java должна быть не ниже 17.

    Запуск приложения через JRE, встроенный в Deb-пакет

    При установке и запуске модуля inno-lcm-core из Deb-пакета, автоматически происходит создание службы lcm.service и запуск бэкенда продукта «Служба управления конфигурациями» через встроенный в Deb-пакет JRE. В данном случае дополнительных действий предпринимать не требуется.

    Запуск приложения через сторонний JRE, установленный на сервере

    Для запуска модуля inno-lcm-core приложения через стороний JRE, выполните действия:

    1. Установите на сервер, на котором будет производиться запуск, JRE не ниже версии 17.

      Убедитесь, что переменная JAVA_HOME содержит путь к актуальной JRE не ниже версии 17.
    2. Загрузите и распакуйте архив *.tar.gz с пакетами inno-lcm-core любым удобным способом (см. раздел «Установка Deb-пакетов с модулями продукта» документа «Руководство по установке»).

    3. Распакуйте пакет .deb в требуемую директорию, например, выполнив команду:

      dpkg-deb -R inno-lcm.core-<version>.deb inno-lcm-core /opt/inno-lcm-core
    4. Перейдите в директорию с исполняемыми файлами *.jar приложения inno-lcm-core:

      cd /opt/inno-lcm-core/lib/app
    5. Запустите исполняемый файл lcm-app-runner.jar удобным способом, например, выполнив команду:

      java -Dquarkus.config.locations=/opt/inno-lcm-core/application.properties -jar lcm-app-runner.jar

    Рекомендации по сбору и предоставлению информации о проблеме/ошибке

    В случае возникновения проблемы/ошибки в работе продукта «Служба управления конфигурациями» (LCM):

    1. Предоставьте максимально детальное описание того, в чем заключается проблема/ошибка и в каких условиях она возникла:

      • какие действия выполнялись перед возникновением проблемы/ошибки;

      • какой результат ожидалось получить;

      • к какому фактическому результату привели выполненные действия;

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

    2. Попробуйте воспроизвести проблему/ошибку по составленному описанию.

    3. Если проблема/ошибка возникла один раз и более не воспроизводилась, предоставьте логи на момент возникновения проблемы/ошибки, а также за 30 минут до и после ее возникновения без изменения существующего уровня логирования (см. раздел «Снятие логов»).

    4. Направьте всю собранную информацию контактному лицу.

    Снятие логов

    Логи для продукта снимаются отдельно:

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

    При некорректной работе пользовательского интерфейса LCM соберите консольные и HAR-логи (логи взаимодействия браузера и сервера во время загрузки веб-страницы) в браузере.

    Пример сбора логов для Яндекс Браузера:

    • HAR-логи

    • Консольные логи

    1. Нажмите F12 на клавиатуре, чтобы открыть окно инструментов разработчика.

    2. Перейдите на вкладку Сеть.

    3. Нажмите на кнопку Запись сетевого журнала.

    4. Воспроизведите проблему.

    5. Нажмите на кнопку Остановить запись сетевого журнала.

    6. Нажмите на правую кнопку мыши в сетевой таблице и выберите Сохранить все как HAR с контентом.

    7. Выберите папку для сохранения логов и нажмите на кнопку Сохранить.

    HAR-логи будут собраны и сохранены в указанной папке.

    1. Нажмите F12 на клавиатуре, чтобы открыть окно инструментов разработчика.

    2. Перейдите на вкладку Консоль.

    3. Нажмите правой кнопкой мыши на любой строке и выберите в контекстном меню Сохранить страницу как.

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

    Консольные логи будут собраны и сохранены в указанной папке.

    Пример сбора логов для Chrome:

    • HAR-логи

    • Консольные логи

    1. Нажмите F12 на клавиатуре, чтобы открыть окно инструментов разработчика.

    2. Перейдите на вкладку Network.

    3. Нажмите на кнопку chrome clear, чтобы очистить сетевой журнал.

    4. Выберите чек-боксы Preserve log и Disable cache.

    5. Воспроизведите проблему.

    6. Нажмите chrome export har, чтобы сохранить HAR-логи.

    7. Выберите папку для сохранения логов и нажмите на кнопку Сохранить.

    HAR-логи будут собраны и сохранены в указанной папке.

    1. Нажмите F12 на клавиатуре, чтобы открыть окно инструментов разработчика.

    2. Перейдите на вкладку Console.

    3. Нажмите правой кнопкой мыши в любой области окна и выберите в контекстном меню Save as.

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

    Консольные логи будут собраны и сохранены в указанной папке.

    Пример сбора логов для Firefox:

    • HAR-логи

    • Консольные логи

    1. Нажмите F12 на клавиатуре, чтобы открыть окно инструментов разработчика.

    2. Перейдите на вкладку Сеть.

    3. Воспроизведите проблему.

    4. Нажмите на правую кнопку мыши в сетевой таблице после воспроизведения проблемы и выберите Сохранить все как HAR.

    5. Выберите папку для сохранения логов и нажмите на кнопку Сохранить.

    HAR-логи будут собраны и сохранены в указанной папке.

    1. Нажмите F12 на клавиатуре, чтобы открыть окно инструментов разработчика.

    2. Перейдите на вкладку Консоль.

    3. Нажмите правой кнопкой мыши на любой строке и выберите в контекстном меню Экспортировать видимые сообщения в и выберите Файл.

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

    Консольные логи будут собраны и сохранены в указанной папке.

    Сбор логов серверной части

    Сбор логов серверной части включает сбор логов бэкенда продукта и логов внешних подсистем (например, SaltStack, LDAP-сервер, MS Active Directory). Подробнее о сборе логов внешних подсистем см. в официальной документации.

    При некорректной работе серверной части LCM соберите логи из лог-файла, путь к которому задается в параметре quarkus.log.file.path.

    Путь к файлу: path/application.log (подробнее см. руководство по установке раздел «Параметры конфигурации бэкенда продукта»).

    Категории ПО в магазине приложений

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

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

    • Сеть — программы для работы с веб-ресурсами сети и доступа к интернет-страницам;

    • Офис — программы для работы с документами, таблицами, презентациями;

    • Архиваторы — программы для сжатия и распаковки данных;

    • Аналитика — программы для анализа данных;

    • Бизнес — программы для ведения бизнеса;

    • Ведение проектов — программы для ведения проектов;

    • Дизайн — программы для дизайнерской разработки, создания макетов;

    • Общение — программы для общения и деловой переписки;

    • Разработка — программы для разработки ПО.

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

    Операции по управлению категориями выполняются посредством соответствующих API-методов (см. раздел «Управление категориями ПО» документа «Описание API»).

    Чтобы изменить эти значения, установите необходимые значения параметров в файле application.properties: lcm.catalog.category.total-limit и lcm.catalog.category.specification-limit соответственно. (см. раздел «Настройка бэкенда продукта» документа «Руководство по установке»).

    Глоссарий

    Basic Input/Output System (BIOS)

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

    Certificate Revocation List (CRL)

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

    Deb-пакет (Debian package)

    Формат упаковки программного обеспечения для операционной системы Debian и ее производных, таких как Ubuntu. Deb-пакет содержит программу или библиотеку, а также информацию о зависимостях и конфигурации. Он может быть установлен с помощью менеджера пакетов, например, apt-get или dpkg. Deb-пакеты облегчают установку и обновление программного обеспечения в системе, а также позволяют управлять зависимостями между пакетами.

    Har-логи (HTTP Archive logs)

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

    Java Runtime Environment (JRE)

    Программное обеспечение, необходимое для запуска Java-приложений на компьютере. Оно содержит в себе виртуальную машину Java (JVM), классы Java API и другие необходимые библиотеки. JRE позволяет пользователям запускать Java-приложения без необходимости установки полного JDK (Java Development Kit).

    Network Security Services (NSS)

    Набор библиотек, предназначенных для разработки защищённых кросс-платформенных клиентских и серверных приложений. Приложения, построенные при помощи NSS, могут использовать и поддерживать SSLv3, TLS и многие другие стандарты безопасности.

    Network Security Services Database (NSSDB)

    База данных, используемая для хранения сертификатов и ключей шифрования в системах, использующих библиотеку Network Security Services (NSS).

    Privacy Enhanced Mail (PEM)

    Формат кодирования данных, который используется для хранения и передачи сертификатов, закрытых ключей, а также других конфиденциальных данных в виде текста. Формат PEM был разработан для безопасной передачи электронной почты, но сейчас широко используется в SSL/TLS-сертификатах и других системах безопасности.

    Simple Storage Service (S3)

    Cервис хранения данных в облаке, предоставляемый Amazon Web Services (AWS). Он позволяет хранить и извлекать любой объем данных из любой части мира. S3 используется для хранения статических файлов, таких как изображения, видео, аудио, документы и т.д. Этот сервис также предоставляет возможность управления доступом к данным и автоматического резервного копирования данных. S3 является одним из самых популярных сервисов AWS и широко используется в различных приложениях и сервисах.

    Unified Extensible Firmware Interface (UEFI)

    Интерфейс между операционной системой и микропрограммами, управляющими низкоуровневыми функциями оборудования, его основное предназначение: корректно инициализировать оборудование при включении системы и передать управление загрузчику или непосредственно ядру операционной системы. EFI — технология, предназначенная для замены BIOS которая обеспечивает более быструю загрузку компьютера, улучшенную безопасность и более простую настройку системы. Она также позволяет использовать жесткие диски большого объема и поддерживает новые технологии, такие как Secure Boot, которая обеспечивает защиту от вредоносных программ.

    Автоматизированное рабочее место (АРМ)

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

    Операционная система (ОС)

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

    Программное обеспечение (ПО)

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

    Сокращения