docs(registry): strengthen software registry package
This commit is contained in:
igor04091968
@@ -35,3 +35,7 @@ data/
|
||||
/.graphify_*.json
|
||||
/.graphify_*.txt
|
||||
/.graphify_python/
|
||||
|
||||
# Release assets kept outside git
|
||||
/install-kit-awindows-*.zip
|
||||
/install-kit-awindows-*.tar.gz
|
||||
|
||||
@@ -17,6 +17,15 @@ evidence и Hayabusa используются как прикладные мод
|
||||
- Автоматизация runbook-проверок, health-check, SLO и безопасного auto-heal.
|
||||
- Сбор evidence по инцидентам и аудит действий оператора.
|
||||
|
||||
## Rust-first runtime
|
||||
|
||||
Основной серверный runtime DetMir переведен на Rust: status/check/auto-heal,
|
||||
SLO, worktime, DLP server-side helpers, evidence и install-kit tooling.
|
||||
|
||||
Python в репозитории остается для вспомогательных направлений: Telegram bot
|
||||
runtime, OCR/content-analysis, 1C/AI/ETL integration и MCP/dev helpers. Эти
|
||||
части не являются ядром Rust-first runtime.
|
||||
|
||||
## Что видит оператор
|
||||
|
||||
- Работал ли пользователь за компьютером или в удаленной сессии.
|
||||
@@ -42,6 +51,7 @@ evidence и Hayabusa используются как прикладные мод
|
||||
- [Описание продукта](PRODUCT_DESCRIPTION_RU.md)
|
||||
- [Установка для эксперта](INSTALL_FOR_EXPERT_RU.md)
|
||||
- [Сторонние компоненты](THIRD_PARTY_COMPONENTS.md)
|
||||
- [Сторонние лицензии](THIRD_PARTY_LICENSES_RU.md)
|
||||
- [Архитектура](docs/ARCHITECTURE_RU.md)
|
||||
- [Установка](docs/INSTALL_RU.md)
|
||||
- [Руководство администратора](docs/ADMIN_GUIDE_RU.md)
|
||||
|
||||
+263
-74
@@ -1,117 +1,306 @@
|
||||
# Сведения для подачи в реестр российского ПО
|
||||
|
||||
## 1. Назначение ПО
|
||||
Статус документа: рабочий пакет для подготовки продукта `DetMir` на базе
|
||||
`AWatch-rus` к экспертной проверке и возможной подаче в реестр российского ПО.
|
||||
|
||||
`DetMir` на базе `AWatch-rus` - программный комплекс операционного контроля,
|
||||
технического аудита и мониторинга ИТ-инфраструктуры.
|
||||
Документ намеренно описывает продукт как программный комплекс операционного
|
||||
контроля, технического аудита и управления ИТ-инфраструктурой. Продукт не
|
||||
заявляется как сертифицированная DLP, SIEM, EDR/XDR или средство защиты
|
||||
информации.
|
||||
|
||||
ПО предназначено для:
|
||||
## 1. Наименование продукта
|
||||
|
||||
- контроля состояния сервисов и endpoint-сборщиков;
|
||||
- учета пользовательской активности и рабочего времени;
|
||||
- централизованного технического аудита событий;
|
||||
- отображения данных в Grafana/портале оператора;
|
||||
- автоматизации runbook-проверок, SLO-контроля и безопасного реагирования;
|
||||
- фиксации evidence по прикладным инцидентам и аудита действий оператора.
|
||||
Коммерческое/продуктовое наименование:
|
||||
|
||||
ПО не заявляется как сертифицированная DLP, SIEM, EDR/XDR или средство защиты
|
||||
информации. Модули DLP/evidence/Hayabusa рассматриваются как прикладные модули
|
||||
операционного контроля и расследования событий.
|
||||
- `DetMir`.
|
||||
|
||||
## 2. Класс ПО
|
||||
Техническая база и репозиторий:
|
||||
|
||||
Основной целевой класс:
|
||||
- `AWatch-rus`.
|
||||
|
||||
- `09.10 Средства управления ИТ-службой, ИТ-инфраструктурой и ИТ-активами`.
|
||||
Рекомендуемая формула для документов:
|
||||
|
||||
Возможный дополнительный контекст:
|
||||
```text
|
||||
DetMir, программный комплекс на базе AWatch-rus.
|
||||
```
|
||||
|
||||
Такое разделение позволяет использовать `DetMir` как продуктовую марку, а
|
||||
`AWatch-rus` как техническое имя репозитория и исходной кодовой базы.
|
||||
|
||||
## 2. Назначение ПО
|
||||
|
||||
`DetMir` предназначен для централизованного операционного контроля,
|
||||
технического аудита и мониторинга ИТ-инфраструктуры организации.
|
||||
|
||||
Основные задачи:
|
||||
|
||||
- контроль состояния серверных сервисов, endpoint-сборщиков и витрин данных;
|
||||
- учет пользовательской активности, рабочих интервалов и удаленных сессий;
|
||||
- мониторинг свежести данных ActivityWatch и связанных buckets;
|
||||
- контроль выполнения эксплуатационных регламентов и runbook-проверок;
|
||||
- SLO/health мониторинг и безопасная автоматизация восстановления;
|
||||
- отображение управленческих и технических dashboards;
|
||||
- фиксация evidence по прикладным инцидентам;
|
||||
- аудит действий оператора и техническая трассировка расследований.
|
||||
|
||||
Продукт закрывает задачу эксплуатационной видимости: администратор,
|
||||
оператор ИБ или руководитель видит, что сбор данных идет, инфраструктурные
|
||||
компоненты доступны, данные обновляются, а прикладные инциденты имеют
|
||||
прослеживаемую evidence-цепочку.
|
||||
|
||||
## 3. Класс ПО
|
||||
|
||||
Основной целевой класс для реестра:
|
||||
|
||||
```text
|
||||
09.10 Средства управления ИТ-службой, ИТ-инфраструктурой и ИТ-активами
|
||||
```
|
||||
|
||||
Обоснование:
|
||||
|
||||
- продукт контролирует состояние ИТ-сервисов и инфраструктурных компонентов;
|
||||
- содержит operational dashboards, health-check и SLO-мониторинг;
|
||||
- автоматизирует эксплуатационные проверки и безопасные recovery-действия;
|
||||
- хранит технические состояния, отчеты, evidence и audit trail;
|
||||
- применяется для контроля работоспособности и наблюдаемости корпоративного
|
||||
контура.
|
||||
|
||||
Дополнительный контекст, который можно использовать в описании:
|
||||
|
||||
- автоматизация регламентов эксплуатации;
|
||||
- технический аудит;
|
||||
- мониторинг корпоративной инфраструктуры.
|
||||
- интеллектуальный мониторинг инфраструктуры;
|
||||
- автоматизация runbook-процессов;
|
||||
- контроль регламентов эксплуатации.
|
||||
|
||||
## 3. Правообладатель
|
||||
Не рекомендуется заявлять продукт как:
|
||||
|
||||
- сертифицированную DLP;
|
||||
- SIEM;
|
||||
- EDR/XDR;
|
||||
- средство защиты информации;
|
||||
- продукт с формальной ФСТЭК-моделью угроз.
|
||||
|
||||
Модули DLP/evidence/Hayabusa описываются как прикладные модули операционного
|
||||
контроля и расследования событий, а не как самостоятельная сертифицированная
|
||||
система защиты информации.
|
||||
|
||||
## 4. Правообладатель
|
||||
|
||||
Правообладатель: владелец репозитория и программного комплекса `DetMir /
|
||||
AWatch-rus`.
|
||||
|
||||
Перед подачей в реестр рекомендуется оформить отдельный правообладательский
|
||||
пакет:
|
||||
Перед подачей в реестр рекомендуется подготовить отдельный
|
||||
правообладательский пакет:
|
||||
|
||||
- сведения о правообладателе;
|
||||
- подтверждение авторства собственных модулей;
|
||||
- перечень сторонних компонентов;
|
||||
- условия лицензирования и распространения;
|
||||
- описание прав на собственные модули;
|
||||
- подтверждение авторства или передачи прав на разработанные компоненты;
|
||||
- перечень сторонних компонентов и лицензий;
|
||||
- описание модели распространения;
|
||||
- при необходимости - свидетельство Роспатента о регистрации программы для ЭВМ.
|
||||
|
||||
## 4. Состав поставки
|
||||
Собственными компонентами считаются:
|
||||
|
||||
В состав поставки входят:
|
||||
|
||||
- Rust workspace `adk-rust/` с основными runtime helpers;
|
||||
- Ansible playbooks для установки и обновления серверных компонентов;
|
||||
- Windows PowerShell collectors и deployment scripts;
|
||||
- Grafana dashboards и monitoring assets;
|
||||
- ActivityWatch server customization и RU WebUI patching;
|
||||
- Rust helpers и runtime-модули DetMir;
|
||||
- портал оператора;
|
||||
- документация администратора, оператора, установки и архитектуры;
|
||||
- install-kit artifacts для повторяемой поставки.
|
||||
- Ansible deployment automation;
|
||||
- Windows collectors/deployment scripts;
|
||||
- ActivityWatch RU customization;
|
||||
- Grafana dashboards проекта;
|
||||
- документация, runbooks и install-kit packaging.
|
||||
|
||||
Индивидуальные production inventory, пароли, токены, домены, IP-адреса и
|
||||
локальные runtime-файлы не входят в публичную поставку.
|
||||
Сторонние компоненты перечислены отдельно в `THIRD_PARTY_LICENSES_RU.md` и
|
||||
`docs/THIRD_PARTY_LICENSES_RU.md`.
|
||||
|
||||
## 5. Установка экземпляра
|
||||
## 5. Состав поставки
|
||||
|
||||
Типовой порядок установки:
|
||||
Публичная поставка состоит из исходного кода, документации и шаблонов
|
||||
конфигурации. Индивидуальные параметры конкретного стенда не входят в
|
||||
публичную поставку.
|
||||
|
||||
1. Подготовить Linux/Proxmox или другой серверный runtime согласно
|
||||
`docs/INSTALL_RU.md`.
|
||||
2. Скопировать `private-config/deploy.env.example` в локальный
|
||||
`private-config/deploy.env` и заполнить параметры конкретного экземпляра.
|
||||
3. Подготовить Ansible inventory локально на основе
|
||||
`ansible/inventory.example.ini`.
|
||||
4. Собрать Rust release artifacts:
|
||||
В состав входят:
|
||||
|
||||
- `adk-rust/` - Rust workspace с основными runtime helpers;
|
||||
- `ansible/` - playbooks и examples для установки серверных и endpoint
|
||||
компонентов;
|
||||
- `aw-server/` - ActivityWatch server customization, service files,
|
||||
RU WebUI patches и server-side helpers;
|
||||
- `windows/` - Windows collectors, scheduled task deployment и common module;
|
||||
- `grafana/` - dashboards для технического и управленческого мониторинга;
|
||||
- `proxmox/` - операторские helpers, включая Telegram runtime, если он
|
||||
используется в конкретном экземпляре;
|
||||
- `docs/` - руководства администратора, оператора, архитектура, threat model,
|
||||
registry positioning и runbooks;
|
||||
- `private-config/*.example` - шаблоны приватной конфигурации;
|
||||
- release assets - install-kit archives для проверяемых сборок.
|
||||
|
||||
Не входят в публичный репозиторий:
|
||||
|
||||
- production inventory;
|
||||
- пароли;
|
||||
- токены;
|
||||
- реальные IP-адреса и домены экземпляра;
|
||||
- runtime базы данных и evidence;
|
||||
- customer deployment snapshots;
|
||||
- локальная история работы операторских ИИ-агентов.
|
||||
|
||||
## 6. Функциональный состав
|
||||
|
||||
### 6.1. Контроль ActivityWatch telemetry
|
||||
|
||||
- проверка доступности AW API;
|
||||
- контроль свежести buckets;
|
||||
- учет event-driven buckets без ложного dead/stale статуса;
|
||||
- health summary для оператора;
|
||||
- SLO sampling и summary.
|
||||
|
||||
### 6.2. Учет активности и рабочего времени
|
||||
|
||||
- обработка window/AFK/session данных;
|
||||
- отчеты по активному времени;
|
||||
- поддержка RDP/Windows collector flow;
|
||||
- InfluxDB/Grafana витрины;
|
||||
- heartbeat freshness для контроля работы exporter-а.
|
||||
|
||||
### 6.3. Операционный контроль и auto-heal
|
||||
|
||||
- `detmir-check`;
|
||||
- `detmir-status`;
|
||||
- `detmir-auto`;
|
||||
- безопасные recovery paths;
|
||||
- контроль systemd timers/services;
|
||||
- исключение опасных destructive actions из автоматического режима.
|
||||
|
||||
### 6.4. Evidence и расследования
|
||||
|
||||
- хранение evidence metadata;
|
||||
- screenshot/evidence viewer в портале оператора;
|
||||
- audit записи просмотра evidence;
|
||||
- Hayabusa/offline DFIR flow как прикладной модуль расследования.
|
||||
|
||||
### 6.5. Визуализация
|
||||
|
||||
- Grafana dashboards;
|
||||
- портал оператора;
|
||||
- management views для руководителя;
|
||||
- technical views для администратора и оператора ИБ.
|
||||
|
||||
## 7. Архитектура
|
||||
|
||||
Типовая архитектура экземпляра:
|
||||
|
||||
```text
|
||||
Windows/Linux endpoints
|
||||
|
|
||||
v
|
||||
ActivityWatch collectors / endpoint helpers
|
||||
|
|
||||
v
|
||||
AW server + DetMir Rust helpers
|
||||
|
|
||||
+--> SQLite state/cases/policy/evidence metadata
|
||||
+--> InfluxDB/metrics storage
|
||||
+--> Grafana dashboards
|
||||
+--> DetMir operator portal
|
||||
+--> Telegram/operator runtime, если включен
|
||||
```
|
||||
|
||||
Ядро DetMir реализовано как Rust-first runtime:
|
||||
|
||||
- health/status/check helpers;
|
||||
- worktime exporters/API/bridges;
|
||||
- DLP server-side processing helpers;
|
||||
- evidence API/portal helpers;
|
||||
- install-kit validation tools;
|
||||
- operational quality gates.
|
||||
|
||||
Python в составе проекта не является основным ядром продукта. Он остается для:
|
||||
|
||||
- Telegram bot runtime, если используется заказчиком;
|
||||
- OCR/content-analysis path, где нужны Python OCR/ML библиотеки;
|
||||
- 1C/AI/ETL интеграций;
|
||||
- отдельных MCP/dev helper сценариев.
|
||||
|
||||
Такое разделение фиксируется как архитектурное: критичные серверные проверки,
|
||||
status path, SLO, worktime, DLP server-side helpers и install-kit tooling
|
||||
переведены на Rust-first модель.
|
||||
|
||||
## 8. Зависимости
|
||||
|
||||
Основные runtime dependencies:
|
||||
|
||||
- Linux/systemd;
|
||||
- ActivityWatch;
|
||||
- Rust runtime artifacts, собранные из `adk-rust`;
|
||||
- SQLite;
|
||||
- Grafana;
|
||||
- InfluxDB или совместимое хранилище временных рядов, если включены metrics;
|
||||
- Ansible для установки;
|
||||
- PowerShell/Windows Task Scheduler для Windows collectors;
|
||||
- Hayabusa для offline DFIR workflow, если включен;
|
||||
- Python только для согласованных вспомогательных модулей.
|
||||
|
||||
Сторонние лицензии и риски AGPL/GPL/weak copyleft описаны в
|
||||
`THIRD_PARTY_LICENSES_RU.md`.
|
||||
|
||||
## 9. Установка экземпляра
|
||||
|
||||
Короткий порядок для эксперта:
|
||||
|
||||
1. Склонировать репозиторий.
|
||||
2. Подготовить приватную конфигурацию:
|
||||
|
||||
```bash
|
||||
cp private-config/deploy.env.example private-config/deploy.env
|
||||
cp ansible/inventory.example.ini ansible/inventory.ini
|
||||
```
|
||||
|
||||
3. Заполнить параметры конкретного тестового экземпляра.
|
||||
4. Собрать Rust artifacts:
|
||||
|
||||
```bash
|
||||
cd adk-rust
|
||||
cargo build --release --workspace
|
||||
```
|
||||
|
||||
5. Выполнить playbooks установки серверных компонентов и сборщиков.
|
||||
6. Проверить контур:
|
||||
5. Выполнить syntax и quality checks:
|
||||
|
||||
```bash
|
||||
scripts/quality-gate.sh
|
||||
ansible-playbook --syntax-check -i ansible/inventory.ini ansible/deploy_aw_server.yml
|
||||
```
|
||||
|
||||
6. Установить серверные компоненты и collectors по `docs/INSTALL_RU.md`.
|
||||
7. Проверить работоспособность:
|
||||
|
||||
```bash
|
||||
detmir-check
|
||||
detmir-status
|
||||
```
|
||||
|
||||
Точные адреса сервисов, домены, учетные данные и токены задаются только в
|
||||
локальных конфигурационных файлах экземпляра.
|
||||
Ожидаемый результат: статус `OK`, отсутствуют критичные service failures и
|
||||
stale/dead buckets для обязательных источников.
|
||||
|
||||
## 6. Сторонние компоненты
|
||||
## 10. Ограничения
|
||||
|
||||
Основные внешние компоненты:
|
||||
|
||||
- ActivityWatch;
|
||||
- Rust crates ecosystem;
|
||||
- Grafana;
|
||||
- Prometheus/InfluxDB exporters and clients;
|
||||
- Ansible;
|
||||
- PowerShell/Windows runtime;
|
||||
- SQLite;
|
||||
- Hayabusa and related DFIR tooling where enabled.
|
||||
|
||||
Детальный перечень ведется в `docs/THIRD_PARTY_LICENSES_RU.md`.
|
||||
|
||||
## 7. Ограничения и зависимости
|
||||
|
||||
- Для полноценной работы нужны права администратора на устанавливаемых
|
||||
серверных и endpoint-компонентах.
|
||||
- Telegram runtime, если используется, остается отдельным Python-компонентом.
|
||||
- OCR/content-analysis может использовать Python-зависимости для обработки
|
||||
изображений; основной серверный runtime переведен на Rust-first helpers.
|
||||
- Сетевые адреса, домены, токены и inventory являются параметрами конкретного
|
||||
экземпляра и не должны публиковаться в репозитории.
|
||||
- Продукт не заменяет формально сертифицированные средства защиты информации
|
||||
без отдельной сертификации и модели угроз.
|
||||
без отдельной сертификации.
|
||||
- Реальные сетевые адреса, домены, токены и inventory являются параметрами
|
||||
экземпляра и не публикуются.
|
||||
- Для endpoint deployment нужны административные права.
|
||||
- Для некоторых прикладных модулей нужны внешние сервисы: Grafana, InfluxDB,
|
||||
Hayabusa или Python OCR stack.
|
||||
- License compatibility сторонних компонентов должна проверяться перед
|
||||
коммерческой поставкой.
|
||||
|
||||
## 11. Документы пакета
|
||||
|
||||
- `PRODUCT_DESCRIPTION_RU.md` - краткое описание продукта.
|
||||
- `INSTALL_FOR_EXPERT_RU.md` - короткая инструкция установки экземпляра.
|
||||
- `THIRD_PARTY_COMPONENTS.md` - обзор сторонних компонентов.
|
||||
- `THIRD_PARTY_LICENSES_RU.md` - лицензии и license-audit checklist.
|
||||
- `docs/ARCHITECTURE_RU.md` - архитектура.
|
||||
- `docs/ADMIN_GUIDE_RU.md` - руководство администратора.
|
||||
- `docs/OPERATOR_GUIDE_RU.md` - руководство оператора.
|
||||
- `docs/DETMIR_RUSSIAN_SOFTWARE_REGISTRY_POSITIONING_RU.md` - стратегия
|
||||
позиционирования.
|
||||
|
||||
@@ -0,0 +1,185 @@
|
||||
# DetMir / AWatch-rus: сторонние компоненты и лицензии
|
||||
|
||||
Статус документа: рабочий license inventory для подготовки поставки и
|
||||
экспертной проверки. Документ не является юридическим заключением. Перед
|
||||
коммерческой поставкой или подачей в реестр нужно выполнить полный
|
||||
автоматизированный SBOM/license audit по конкретной release-сборке.
|
||||
|
||||
## 1. Собственный код проекта
|
||||
|
||||
Собственные компоненты `DetMir / AWatch-rus`:
|
||||
|
||||
- Rust workspace `adk-rust/`;
|
||||
- DetMir status/check/auto/heal helpers;
|
||||
- worktime exporters/API/bridge/autoheal;
|
||||
- DLP server-side helpers;
|
||||
- evidence API и portal helpers;
|
||||
- Ansible playbooks и deployment automation;
|
||||
- Windows PowerShell collectors/deployment scripts;
|
||||
- ActivityWatch RU WebUI patches;
|
||||
- Grafana dashboards проекта;
|
||||
- install-kit tooling;
|
||||
- документация.
|
||||
|
||||
Для собственного кода в корне репозитория указан `LICENSE`:
|
||||
|
||||
```text
|
||||
Apache License 2.0
|
||||
```
|
||||
|
||||
Это применимо только к собственным частям проекта. Сторонние компоненты
|
||||
сохраняют свои лицензии.
|
||||
|
||||
## 2. Ключевые сторонние компоненты
|
||||
|
||||
| Компонент | Роль в продукте | Типовая лицензия upstream | Статус поставки | Комментарий для аудита |
|
||||
|---|---|---|---|---|
|
||||
| ActivityWatch | Базовый сбор и API событий активности | MPL-2.0 | Устанавливается/используется как внешний компонент | Weak copyleft на измененные MPL-файлы; модификации ActivityWatch нужно учитывать отдельно. |
|
||||
| Grafana OSS | Dashboards и визуализация | AGPL-3.0 для современных версий Grafana OSS | Обычно внешний сервис/контейнер, не собственный код DetMir | AGPL требует отдельной проверки модели распространения и сетевого использования. |
|
||||
| Prometheus | Monitoring ecosystem, exporters, scrape model | Apache-2.0 | Внешний компонент при включении мониторинга | Совместим с Apache-поставкой при соблюдении notice/license требований. |
|
||||
| InfluxDB / compatible TSDB | Хранилище временных рядов `aw_metrics` | Зависит от версии/дистрибутива | Внешний компонент | Зафиксировать конкретную версию в release notes. |
|
||||
| Hayabusa | Offline/DFIR timeline и enrichment | AGPLv3; rules могут иметь Detection Rule License | Опциональный прикладной модуль расследования | Не позиционировать как ядро продукта; проверить obligations при включении в поставку. |
|
||||
| Ansible | Deployment automation | GPL-3.0-or-later для Ansible core | Инструмент установки | Обычно не линкуется с кодом продукта; входит в toolchain. |
|
||||
| PowerShell | Windows deployment/collectors runtime | MIT для PowerShell Core; Windows PowerShell как компонент ОС | Runtime/tooling | Уточнять окружение заказчика: Windows PowerShell или PowerShell 7. |
|
||||
| SQLite | Local state/warehouse DB | Public domain/blessing style | Embedded/library/runtime | Обычно низкий license risk. |
|
||||
| ClickHouse clients/tooling | 1C/file analytics integration | Зависит от клиента; ClickHouse server Apache-2.0 | Отдельный 1C/business-data слой | Не является обязательным ядром DetMir. |
|
||||
| OpenAI/Pollinations-compatible integrations | AI assistant/integration paths | API terms, не open-source license | Опционально | Не включать ключи/API credentials в поставку. |
|
||||
|
||||
## 3. Rust dependencies
|
||||
|
||||
Rust является основным runtime-слоем DetMir. Точный список зависимостей должен
|
||||
фиксироваться по `Cargo.lock` конкретного релиза.
|
||||
|
||||
Ключевые crates, используемые в workspace:
|
||||
|
||||
| Crate | Назначение | Типичные лицензии ecosystem | Действие перед релизом |
|
||||
|---|---|---|---|
|
||||
| `anyhow` | Error handling | MIT OR Apache-2.0 | Проверить через `cargo about`. |
|
||||
| `clap` | CLI parsing | MIT OR Apache-2.0 | Проверить transitive deps. |
|
||||
| `chrono` | Date/time | MIT OR Apache-2.0 | Зафиксировать версию. |
|
||||
| `serde`, `serde_json`, `serde_yaml` | Serialization | MIT OR Apache-2.0 | Проверить YAML transitive deps. |
|
||||
| `reqwest` | HTTP client | MIT OR Apache-2.0 | Проверить TLS backend и transitive deps. |
|
||||
| `rusqlite` | SQLite access | MIT | Проверить bundled/system SQLite режим. |
|
||||
| `regex` | Matching rules | MIT OR Apache-2.0 | Низкий риск. |
|
||||
| `sha2` | Hashing | MIT OR Apache-2.0 | Низкий риск. |
|
||||
| `base64` | Encoding/decoding | MIT OR Apache-2.0 | Низкий риск. |
|
||||
| `tiny_http` | Lightweight HTTP service | MIT OR Apache-2.0 | Проверить версию. |
|
||||
| `url`, `urlencoding` | URL handling | MIT OR Apache-2.0 | Проверить transitive deps. |
|
||||
| `tempfile` | Tests/temp files | MIT OR Apache-2.0 | Test/dev dependency. |
|
||||
|
||||
Обязательные команды для release audit:
|
||||
|
||||
```bash
|
||||
cargo install cargo-about cargo-deny cargo-auditable
|
||||
cd adk-rust
|
||||
cargo metadata --locked --format-version 1 > ../docs/sbom-cargo-metadata.json
|
||||
cargo deny check
|
||||
cargo about generate about.hbs > ../docs/licenses-rust.html
|
||||
```
|
||||
|
||||
Если шаблон `about.hbs` отсутствует, его нужно добавить в release tooling или
|
||||
использовать стандартный шаблон организации.
|
||||
|
||||
## 4. Python-зависимости
|
||||
|
||||
Python не является основным runtime-ядром DetMir. Он остается для
|
||||
согласованных вспомогательных направлений:
|
||||
|
||||
- Telegram bot runtime, если включен в экземпляре;
|
||||
- OCR/content-analysis path;
|
||||
- 1C/AI/ETL integration layer;
|
||||
- MCP/dev helper tools;
|
||||
- legacy-compatible scripts, не входящие в Rust-first server core.
|
||||
|
||||
Известные requirements:
|
||||
|
||||
| Файл | Назначение | Основные зависимости | License-audit действие |
|
||||
|---|---|---|---|
|
||||
| `aw-server/dlp-content-analysis/requirements.txt` | OCR/content analysis | `pytesseract`, `Pillow` | Проверить OCR stack и system Tesseract license отдельно. |
|
||||
| `aw-server/dlp-case-management/requirements.txt` | Legacy/reference case API | `fastapi`, `uvicorn`, `pydantic` | Проверить, поставляется ли как runtime или только reference. |
|
||||
| `aw-server/dlp-policy-engine/requirements.txt` | Legacy/reference policy API | `fastapi`, `uvicorn`, `pydantic` | Rust replacement должен быть primary runtime. |
|
||||
| `aw-server/dlp-compliance/requirements.txt` | Legacy/reference reports | `requests` | Проверить, не входит ли в active runtime. |
|
||||
| `aw-server/dlp-integrations/requirements.txt` | Legacy/reference integrations | `PyYAML` | Проверить статус после Rust migration. |
|
||||
| `clickhouse-1c/ai/requirements.txt` | 1C/AI APIs | `fastapi`, `uvicorn`, `clickhouse-connect` | Отдельный business-data слой. |
|
||||
| `clickhouse-1c/etl/requirements.txt` | 1C ETL | `clickhouse-connect`, `PyYAML`, `python-dateutil`, `openpyxl` | Отдельный ETL слой. |
|
||||
| `detmir-mcp` | MCP helper | Python MCP stack | Не основное runtime-ядро продукта. |
|
||||
|
||||
Команды для Python license report:
|
||||
|
||||
```bash
|
||||
python3 -m venv /tmp/detmir-license-audit
|
||||
. /tmp/detmir-license-audit/bin/activate
|
||||
python -m pip install -U pip pip-licenses
|
||||
pip-licenses --from=mixed --format=markdown > docs/licenses-python.md
|
||||
```
|
||||
|
||||
Команду нужно выполнять в окружении, где установлены зависимости конкретного
|
||||
release profile.
|
||||
|
||||
## 5. Frontend, dashboards и browser tooling
|
||||
|
||||
| Компонент | Роль | License-audit действие |
|
||||
|---|---|---|
|
||||
| Grafana dashboards JSON | Собственные dashboards DetMir | Входят в собственную поставку; проверить отсутствие embedded secrets/URLs. |
|
||||
| ActivityWatch WebUI patches | Собственный overlay/patch слой | Учитывать MPL-2.0 границы ActivityWatch, если изменяются upstream файлы. |
|
||||
| Playwright/browser smoke tooling | Проверки UI | Обычно dev/test dependency; не включать в runtime claim. |
|
||||
| JavaScript snippets | WebUI patching/helper scripts | Проверить зависимости, если добавляются npm packages. |
|
||||
|
||||
## 6. Компоненты с повышенным вниманием
|
||||
|
||||
| Компонент | Причина внимания | Рекомендация |
|
||||
|---|---|---|
|
||||
| Grafana OSS | AGPL-3.0 для современных версий | В реестровой поставке описывать как внешний компонент или проверить obligations. |
|
||||
| Hayabusa | AGPLv3 + отдельная лицензия rules | Держать как optional offline module; не смешивать с закрытым ядром без аудита. |
|
||||
| Ansible | GPL toolchain | Описывать как инструмент установки, не как linked library продукта. |
|
||||
| OCR/Tesseract stack | Несколько уровней зависимостей | Фиксировать конкретные пакеты ОС и Python packages. |
|
||||
| Python legacy paths | Могут выглядеть как ядро | В документации указывать, что Rust-first runtime является основным. |
|
||||
|
||||
## 7. Что поставляется вместе с продуктом
|
||||
|
||||
В публичной поставке могут присутствовать:
|
||||
|
||||
- исходный код собственных модулей;
|
||||
- шаблоны конфигурации;
|
||||
- Ansible playbooks;
|
||||
- Grafana dashboards;
|
||||
- Windows collectors scripts;
|
||||
- install-kit archives как GitHub Release assets;
|
||||
- документация.
|
||||
|
||||
Не должны поставляться в публичном git:
|
||||
|
||||
- production inventory;
|
||||
- реальные домены/IP конкретного экземпляра;
|
||||
- пароли и токены;
|
||||
- runtime базы данных;
|
||||
- customer evidence;
|
||||
- локальная история разработки;
|
||||
- случайные binary archives в корне репозитория.
|
||||
|
||||
## 8. Release checklist по лицензиям
|
||||
|
||||
Перед каждым публичным release:
|
||||
|
||||
1. Собрать Rust SBOM по `Cargo.lock`.
|
||||
2. Выполнить `cargo deny check`.
|
||||
3. Сформировать Rust license report.
|
||||
4. Сформировать Python license report для включенных profiles.
|
||||
5. Проверить Grafana/Hayabusa/Ansible как внешние компоненты.
|
||||
6. Проверить, что root репозитория не содержит случайных архивов сборки.
|
||||
7. Проверить отсутствие secrets, private inventory, customer paths.
|
||||
8. Зафиксировать версию ActivityWatch и способ ее установки.
|
||||
9. Зафиксировать, какие optional modules включены в релиз.
|
||||
10. Сохранить отчеты в release artifacts или `docs/licenses-*`.
|
||||
|
||||
## 9. Источники для проверки upstream лицензий
|
||||
|
||||
- ActivityWatch repository/license: `https://github.com/ActivityWatch/activitywatch`
|
||||
- Grafana licensing: `https://grafana.com/licensing/`
|
||||
- Grafana repository/license: `https://github.com/grafana/grafana`
|
||||
- Prometheus repository/license: `https://github.com/prometheus/prometheus`
|
||||
- Hayabusa repository/license: `https://github.com/Yamato-Security/hayabusa`
|
||||
- Ansible repository/license: `https://github.com/ansible/ansible`
|
||||
|
||||
Финальная версия документа должна ссылаться на конкретные версии компонентов,
|
||||
использованные в release build.
|
||||
+150
-85
@@ -1,120 +1,185 @@
|
||||
# DetMir: сторонние компоненты и лицензии
|
||||
# DetMir / AWatch-rus: сторонние компоненты и лицензии
|
||||
|
||||
Статус: первичный inventory для подготовки к реестру российского ПО.
|
||||
Статус документа: рабочий license inventory для подготовки поставки и
|
||||
экспертной проверки. Документ не является юридическим заключением. Перед
|
||||
коммерческой поставкой или подачей в реестр нужно выполнить полный
|
||||
автоматизированный SBOM/license audit по конкретной release-сборке.
|
||||
|
||||
Этот документ не заменяет юридическую license audit. Перед подачей в реестр
|
||||
нужно выполнить автоматизированную проверку зависимостей и сохранить отчет.
|
||||
## 1. Собственный код проекта
|
||||
|
||||
Продуктовое имя: `DetMir`.
|
||||
|
||||
Техническая база и репозиторий: `AWatch-rus`.
|
||||
|
||||
## 1. Собственный код
|
||||
|
||||
Собственный код проекта включает:
|
||||
Собственные компоненты `DetMir / AWatch-rus`:
|
||||
|
||||
- Rust workspace `adk-rust/`;
|
||||
- Ansible playbooks;
|
||||
- Windows PowerShell collectors и deployment scripts;
|
||||
- AW-rus WebUI patches;
|
||||
- DetMir Portal;
|
||||
- DLP/worktime/status/reporting helpers;
|
||||
- документацию проекта.
|
||||
- DetMir status/check/auto/heal helpers;
|
||||
- worktime exporters/API/bridge/autoheal;
|
||||
- DLP server-side helpers;
|
||||
- evidence API и portal helpers;
|
||||
- Ansible playbooks и deployment automation;
|
||||
- Windows PowerShell collectors/deployment scripts;
|
||||
- ActivityWatch RU WebUI patches;
|
||||
- Grafana dashboards проекта;
|
||||
- install-kit tooling;
|
||||
- документация.
|
||||
|
||||
В `adk-rust/Cargo.toml` для workspace указан license:
|
||||
Для собственного кода в корне репозитория указан `LICENSE`:
|
||||
|
||||
```text
|
||||
Apache-2.0
|
||||
Apache License 2.0
|
||||
```
|
||||
|
||||
Перед публичной поставкой нужно проверить, что license root файла и все
|
||||
исходники согласованы с выбранной моделью поставки.
|
||||
Это применимо только к собственным частям проекта. Сторонние компоненты
|
||||
сохраняют свои лицензии.
|
||||
|
||||
## 2. Основные внешние компоненты runtime
|
||||
## 2. Ключевые сторонние компоненты
|
||||
|
||||
| Компонент | Роль |
|
||||
|---|---|
|
||||
| ActivityWatch | Базовый сбор и API событий активности. |
|
||||
| Grafana | Dashboards и визуализация. |
|
||||
| InfluxDB | Метрики и временные ряды. |
|
||||
| ClickHouse | 1C/file analytics слой. |
|
||||
| SQLite | Локальные state/warehouse/cases/policy хранилища. |
|
||||
| Python | Telegram runtime и legacy-compatible tooling. |
|
||||
| Rust crates ecosystem | Основной runtime DetMir helpers. |
|
||||
| PowerShell | Windows collectors/deployment. |
|
||||
| Hayabusa | Offline/DFIR enrichment. |
|
||||
| Ansible | Deployment automation. |
|
||||
| Компонент | Роль в продукте | Типовая лицензия upstream | Статус поставки | Комментарий для аудита |
|
||||
|---|---|---|---|---|
|
||||
| ActivityWatch | Базовый сбор и API событий активности | MPL-2.0 | Устанавливается/используется как внешний компонент | Weak copyleft на измененные MPL-файлы; модификации ActivityWatch нужно учитывать отдельно. |
|
||||
| Grafana OSS | Dashboards и визуализация | AGPL-3.0 для современных версий Grafana OSS | Обычно внешний сервис/контейнер, не собственный код DetMir | AGPL требует отдельной проверки модели распространения и сетевого использования. |
|
||||
| Prometheus | Monitoring ecosystem, exporters, scrape model | Apache-2.0 | Внешний компонент при включении мониторинга | Совместим с Apache-поставкой при соблюдении notice/license требований. |
|
||||
| InfluxDB / compatible TSDB | Хранилище временных рядов `aw_metrics` | Зависит от версии/дистрибутива | Внешний компонент | Зафиксировать конкретную версию в release notes. |
|
||||
| Hayabusa | Offline/DFIR timeline и enrichment | AGPLv3; rules могут иметь Detection Rule License | Опциональный прикладной модуль расследования | Не позиционировать как ядро продукта; проверить obligations при включении в поставку. |
|
||||
| Ansible | Deployment automation | GPL-3.0-or-later для Ansible core | Инструмент установки | Обычно не линкуется с кодом продукта; входит в toolchain. |
|
||||
| PowerShell | Windows deployment/collectors runtime | MIT для PowerShell Core; Windows PowerShell как компонент ОС | Runtime/tooling | Уточнять окружение заказчика: Windows PowerShell или PowerShell 7. |
|
||||
| SQLite | Local state/warehouse DB | Public domain/blessing style | Embedded/library/runtime | Обычно низкий license risk. |
|
||||
| ClickHouse clients/tooling | 1C/file analytics integration | Зависит от клиента; ClickHouse server Apache-2.0 | Отдельный 1C/business-data слой | Не является обязательным ядром DetMir. |
|
||||
| OpenAI/Pollinations-compatible integrations | AI assistant/integration paths | API terms, не open-source license | Опционально | Не включать ключи/API credentials в поставку. |
|
||||
|
||||
## 3. Rust зависимости
|
||||
## 3. Rust dependencies
|
||||
|
||||
Найдены workspace dependencies:
|
||||
Rust является основным runtime-слоем DetMir. Точный список зависимостей должен
|
||||
фиксироваться по `Cargo.lock` конкретного релиза.
|
||||
|
||||
| Dependency | Использование |
|
||||
|---|---|
|
||||
| `adk-rust` | Agent/tooling integration. |
|
||||
| `anyhow` | Error handling. |
|
||||
| `base64` | Evidence upload body decoding. |
|
||||
| `chrono` | Time/date handling. |
|
||||
| `clap` | CLI parsing. |
|
||||
| `fs2` | File locks. |
|
||||
| `reqwest` | HTTP client. |
|
||||
| `regex` | Rules/content matching. |
|
||||
| `rusqlite` | SQLite access. |
|
||||
| `serde`, `serde_json`, `serde_yaml` | Serialization. |
|
||||
| `sha2` | SHA-256 validation. |
|
||||
| `tempfile` | Tests/temp files. |
|
||||
| `tiny_http` | Lightweight HTTP services. |
|
||||
| `url`, `urlencoding` | URL handling. |
|
||||
Ключевые crates, используемые в workspace:
|
||||
|
||||
Перед релизом выполнить:
|
||||
| Crate | Назначение | Типичные лицензии ecosystem | Действие перед релизом |
|
||||
|---|---|---|---|
|
||||
| `anyhow` | Error handling | MIT OR Apache-2.0 | Проверить через `cargo about`. |
|
||||
| `clap` | CLI parsing | MIT OR Apache-2.0 | Проверить transitive deps. |
|
||||
| `chrono` | Date/time | MIT OR Apache-2.0 | Зафиксировать версию. |
|
||||
| `serde`, `serde_json`, `serde_yaml` | Serialization | MIT OR Apache-2.0 | Проверить YAML transitive deps. |
|
||||
| `reqwest` | HTTP client | MIT OR Apache-2.0 | Проверить TLS backend и transitive deps. |
|
||||
| `rusqlite` | SQLite access | MIT | Проверить bundled/system SQLite режим. |
|
||||
| `regex` | Matching rules | MIT OR Apache-2.0 | Низкий риск. |
|
||||
| `sha2` | Hashing | MIT OR Apache-2.0 | Низкий риск. |
|
||||
| `base64` | Encoding/decoding | MIT OR Apache-2.0 | Низкий риск. |
|
||||
| `tiny_http` | Lightweight HTTP service | MIT OR Apache-2.0 | Проверить версию. |
|
||||
| `url`, `urlencoding` | URL handling | MIT OR Apache-2.0 | Проверить transitive deps. |
|
||||
| `tempfile` | Tests/temp files | MIT OR Apache-2.0 | Test/dev dependency. |
|
||||
|
||||
Обязательные команды для release audit:
|
||||
|
||||
```bash
|
||||
cargo install cargo-about cargo-deny
|
||||
cargo install cargo-about cargo-deny cargo-auditable
|
||||
cd adk-rust
|
||||
cargo about generate about.hbs > ../docs/licenses-rust.html
|
||||
cargo metadata --locked --format-version 1 > ../docs/sbom-cargo-metadata.json
|
||||
cargo deny check
|
||||
cargo about generate about.hbs > ../docs/licenses-rust.html
|
||||
```
|
||||
|
||||
Шаблон `about.hbs` нужно добавить отдельно.
|
||||
Если шаблон `about.hbs` отсутствует, его нужно добавить в release tooling или
|
||||
использовать стандартный шаблон организации.
|
||||
|
||||
## 4. Python зависимости
|
||||
## 4. Python-зависимости
|
||||
|
||||
Найдены requirements:
|
||||
Python не является основным runtime-ядром DetMir. Он остается для
|
||||
согласованных вспомогательных направлений:
|
||||
|
||||
| Файл | Зависимости |
|
||||
|---|---|
|
||||
| `aw-server/dlp-case-management/requirements.txt` | `fastapi`, `uvicorn`, `pydantic` |
|
||||
| `aw-server/dlp-compliance/requirements.txt` | `requests` |
|
||||
| `aw-server/dlp-content-analysis/requirements.txt` | `pytesseract`, `Pillow` |
|
||||
| `aw-server/dlp-integrations/requirements.txt` | `PyYAML` |
|
||||
| `aw-server/dlp-policy-engine/requirements.txt` | `fastapi`, `uvicorn`, `pydantic` |
|
||||
| `clickhouse-1c/ai/requirements.txt` | `fastapi`, `uvicorn`, `clickhouse-connect` |
|
||||
| `clickhouse-1c/etl/requirements.txt` | `clickhouse-connect`, `PyYAML`, `python-dateutil`, `openpyxl` |
|
||||
- Telegram bot runtime, если включен в экземпляре;
|
||||
- OCR/content-analysis path;
|
||||
- 1C/AI/ETL integration layer;
|
||||
- MCP/dev helper tools;
|
||||
- legacy-compatible scripts, не входящие в Rust-first server core.
|
||||
|
||||
Перед релизом выполнить license scan:
|
||||
Известные requirements:
|
||||
|
||||
| Файл | Назначение | Основные зависимости | License-audit действие |
|
||||
|---|---|---|---|
|
||||
| `aw-server/dlp-content-analysis/requirements.txt` | OCR/content analysis | `pytesseract`, `Pillow` | Проверить OCR stack и system Tesseract license отдельно. |
|
||||
| `aw-server/dlp-case-management/requirements.txt` | Legacy/reference case API | `fastapi`, `uvicorn`, `pydantic` | Проверить, поставляется ли как runtime или только reference. |
|
||||
| `aw-server/dlp-policy-engine/requirements.txt` | Legacy/reference policy API | `fastapi`, `uvicorn`, `pydantic` | Rust replacement должен быть primary runtime. |
|
||||
| `aw-server/dlp-compliance/requirements.txt` | Legacy/reference reports | `requests` | Проверить, не входит ли в active runtime. |
|
||||
| `aw-server/dlp-integrations/requirements.txt` | Legacy/reference integrations | `PyYAML` | Проверить статус после Rust migration. |
|
||||
| `clickhouse-1c/ai/requirements.txt` | 1C/AI APIs | `fastapi`, `uvicorn`, `clickhouse-connect` | Отдельный business-data слой. |
|
||||
| `clickhouse-1c/etl/requirements.txt` | 1C ETL | `clickhouse-connect`, `PyYAML`, `python-dateutil`, `openpyxl` | Отдельный ETL слой. |
|
||||
| `detmir-mcp` | MCP helper | Python MCP stack | Не основное runtime-ядро продукта. |
|
||||
|
||||
Команды для Python license report:
|
||||
|
||||
```bash
|
||||
python3 -m pip install pip-licenses
|
||||
python3 -m venv /tmp/detmir-license-audit
|
||||
. /tmp/detmir-license-audit/bin/activate
|
||||
python -m pip install -U pip pip-licenses
|
||||
pip-licenses --from=mixed --format=markdown > docs/licenses-python.md
|
||||
```
|
||||
|
||||
Команду запускать в воспроизводимом virtualenv, где установлены реальные
|
||||
runtime dependencies.
|
||||
Команду нужно выполнять в окружении, где установлены зависимости конкретного
|
||||
release profile.
|
||||
|
||||
## 5. Что нужно закрыть перед подачей
|
||||
## 5. Frontend, dashboards и browser tooling
|
||||
|
||||
1. Добавить root `LICENSE`.
|
||||
2. Добавить `NOTICE`, если это потребуется выбранными лицензиями.
|
||||
3. Сформировать полный SBOM.
|
||||
4. Проверить transitive dependencies.
|
||||
5. Зафиксировать список компонентов, которые поставляются вместе с продуктом.
|
||||
6. Отделить компоненты, которые устанавливаются пользователем самостоятельно.
|
||||
7. Проверить отсутствие GPL/AGPL-компонентов, если выбранная модель поставки с
|
||||
ними несовместима.
|
||||
8. Подготовить публичный `THIRD_PARTY_NOTICES`.
|
||||
| Компонент | Роль | License-audit действие |
|
||||
|---|---|---|
|
||||
| Grafana dashboards JSON | Собственные dashboards DetMir | Входят в собственную поставку; проверить отсутствие embedded secrets/URLs. |
|
||||
| ActivityWatch WebUI patches | Собственный overlay/patch слой | Учитывать MPL-2.0 границы ActivityWatch, если изменяются upstream файлы. |
|
||||
| Playwright/browser smoke tooling | Проверки UI | Обычно dev/test dependency; не включать в runtime claim. |
|
||||
| JavaScript snippets | WebUI patching/helper scripts | Проверить зависимости, если добавляются npm packages. |
|
||||
|
||||
## 6. Связанные документы
|
||||
## 6. Компоненты с повышенным вниманием
|
||||
|
||||
- `docs/OWNERSHIP_RU.md`
|
||||
- `docs/REGISTRY_CHECKLIST_RU.md`
|
||||
- `docs/DETMIR_RUSSIAN_SOFTWARE_REGISTRY_POSITIONING_RU.md`
|
||||
| Компонент | Причина внимания | Рекомендация |
|
||||
|---|---|---|
|
||||
| Grafana OSS | AGPL-3.0 для современных версий | В реестровой поставке описывать как внешний компонент или проверить obligations. |
|
||||
| Hayabusa | AGPLv3 + отдельная лицензия rules | Держать как optional offline module; не смешивать с закрытым ядром без аудита. |
|
||||
| Ansible | GPL toolchain | Описывать как инструмент установки, не как linked library продукта. |
|
||||
| OCR/Tesseract stack | Несколько уровней зависимостей | Фиксировать конкретные пакеты ОС и Python packages. |
|
||||
| Python legacy paths | Могут выглядеть как ядро | В документации указывать, что Rust-first runtime является основным. |
|
||||
|
||||
## 7. Что поставляется вместе с продуктом
|
||||
|
||||
В публичной поставке могут присутствовать:
|
||||
|
||||
- исходный код собственных модулей;
|
||||
- шаблоны конфигурации;
|
||||
- Ansible playbooks;
|
||||
- Grafana dashboards;
|
||||
- Windows collectors scripts;
|
||||
- install-kit archives как GitHub Release assets;
|
||||
- документация.
|
||||
|
||||
Не должны поставляться в публичном git:
|
||||
|
||||
- production inventory;
|
||||
- реальные домены/IP конкретного экземпляра;
|
||||
- пароли и токены;
|
||||
- runtime базы данных;
|
||||
- customer evidence;
|
||||
- локальная история разработки;
|
||||
- случайные binary archives в корне репозитория.
|
||||
|
||||
## 8. Release checklist по лицензиям
|
||||
|
||||
Перед каждым публичным release:
|
||||
|
||||
1. Собрать Rust SBOM по `Cargo.lock`.
|
||||
2. Выполнить `cargo deny check`.
|
||||
3. Сформировать Rust license report.
|
||||
4. Сформировать Python license report для включенных profiles.
|
||||
5. Проверить Grafana/Hayabusa/Ansible как внешние компоненты.
|
||||
6. Проверить, что root репозитория не содержит случайных архивов сборки.
|
||||
7. Проверить отсутствие secrets, private inventory, customer paths.
|
||||
8. Зафиксировать версию ActivityWatch и способ ее установки.
|
||||
9. Зафиксировать, какие optional modules включены в релиз.
|
||||
10. Сохранить отчеты в release artifacts или `docs/licenses-*`.
|
||||
|
||||
## 9. Источники для проверки upstream лицензий
|
||||
|
||||
- ActivityWatch repository/license: `https://github.com/ActivityWatch/activitywatch`
|
||||
- Grafana licensing: `https://grafana.com/licensing/`
|
||||
- Grafana repository/license: `https://github.com/grafana/grafana`
|
||||
- Prometheus repository/license: `https://github.com/prometheus/prometheus`
|
||||
- Hayabusa repository/license: `https://github.com/Yamato-Security/hayabusa`
|
||||
- Ansible repository/license: `https://github.com/ansible/ansible`
|
||||
|
||||
Финальная версия документа должна ссылаться на конкретные версии компонентов,
|
||||
использованные в release build.
|
||||
|
||||
Reference in New Issue
Block a user