docs(public): sanitize release materials
This commit is contained in:
igor04091968
@@ -192,14 +192,14 @@ Grafana уже должна содержать:
|
||||
|
||||
Проверенная рабочая учётка:
|
||||
|
||||
- `SHARKON2025\Администратор`
|
||||
- `HOST-EXAMPLE\Администратор`
|
||||
|
||||
### 6.2 Команда переключения principal
|
||||
|
||||
На `<WINDOWS_HOST>`:
|
||||
|
||||
```cmd
|
||||
schtasks /Change /TN "\ActivityWatch File1C Upload" /RU "SHARKON2025\Администратор" /RP "<LOCAL_ADMIN_PASSWORD>"
|
||||
schtasks /Change /TN "\ActivityWatch File1C Upload" /RU "HOST-EXAMPLE\Администратор" /RP "<LOCAL_ADMIN_PASSWORD>"
|
||||
```
|
||||
|
||||
### 6.3 Проверка
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
### 1. Восстановление ActivityWatch-Russian
|
||||
|
||||
Симптом:
|
||||
- на `<AW_SERVER_HOST>:5600` UI не обновлялся для `SHARKON2025`;
|
||||
- на `<AW_SERVER_HOST>:5600` UI не обновлялся для `HOST-EXAMPLE`;
|
||||
- `aw-server` был жив, но stale были `aw-watcher-afk`, `aw-watcher-window`, `aw-worktime-sessions`.
|
||||
|
||||
Действия:
|
||||
@@ -33,7 +33,7 @@
|
||||
- через WinRM на `<WINDOWS_HOST>` проверены процессы, tasks и recovery-скрипты;
|
||||
- запущены:
|
||||
- `ActivityWatch Recovery`
|
||||
- `ActivityWatch Launch [SHARKON2025_user5]`
|
||||
- `ActivityWatch Launch [HOST-EXAMPLE_user5]`
|
||||
- отдельно перезапущен зависший `worktime-session-collector`.
|
||||
|
||||
Итог:
|
||||
|
||||
@@ -51,7 +51,7 @@
|
||||
| `<FIREWALL_HOST>` | `pfSense`, firewall, VPN, ACL, OpenVPN export target |
|
||||
| `<GATEWAY_HOST>` | `Proxmox/DetMirAuto`, web gateway, Telegram bot, operator entrypoint |
|
||||
| `<AW_SERVER_HOST>` | основной `AW-rus` server, health, worktime/reporting, `Hayabusa` server-side processing |
|
||||
| `<WINDOWS_HOST>` | `SHARKON2025`, Windows/RDP host, collectors, worktime session path, EVTX export |
|
||||
| `<WINDOWS_HOST>` | `HOST-EXAMPLE`, Windows/RDP host, collectors, worktime session path, EVTX export |
|
||||
|
||||
Практический вывод:
|
||||
|
||||
|
||||
@@ -0,0 +1,336 @@
|
||||
# Установка экземпляра для эксперта
|
||||
|
||||
Документ описывает воспроизводимый путь: чистая VM -> установка -> проверка ->
|
||||
ожидаемый результат. Он не использует адреса, домены и учетные данные
|
||||
боевого стенда.
|
||||
|
||||
## 1. Цель проверки
|
||||
|
||||
Эксперт должен получить развернутый экземпляр DetMir/AWatch-rus, убедиться,
|
||||
что ПО собирается из исходного кода, устанавливается на чистую Linux VM,
|
||||
запускает базовые сервисы и проходит smoke-проверки без приватной
|
||||
инфраструктуры правообладателя.
|
||||
|
||||
## 2. Минимальный стенд
|
||||
|
||||
Рекомендуемая чистая VM:
|
||||
|
||||
- Debian 12 или Ubuntu Server 24.04 LTS;
|
||||
- 2 vCPU;
|
||||
- 4 GB RAM для минимальной проверки, 8 GB RAM для проверки Grafana/Prometheus;
|
||||
- 30 GB свободного диска;
|
||||
- доступ в интернет для установки пакетов и Rust crates;
|
||||
- пользователь с правами `sudo`;
|
||||
- корректные DNS, NTP и системное время.
|
||||
|
||||
Опционально для полной проверки контура:
|
||||
|
||||
- отдельная Windows VM или физический Windows host для collector toolkit;
|
||||
- отдельный host или VM для Grafana/Prometheus, если они не ставятся на ту же
|
||||
Linux VM;
|
||||
- закрытая тестовая сеть с адресами, заданными в `ansible/inventory.ini`.
|
||||
|
||||
## 3. Подготовка чистой VM
|
||||
|
||||
Войти на VM под пользователем с `sudo` и установить базовые инструменты:
|
||||
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y \
|
||||
ca-certificates curl git jq unzip tar xz-utils \
|
||||
build-essential pkg-config libssl-dev sqlite3 \
|
||||
python3 python3-venv python3-pip ansible
|
||||
```
|
||||
|
||||
Проверить версии:
|
||||
|
||||
```bash
|
||||
git --version
|
||||
python3 --version
|
||||
ansible --version
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- команды завершаются без ошибок;
|
||||
- установлен Git, Python 3 и Ansible;
|
||||
- VM имеет доступ к пакетным репозиториям.
|
||||
|
||||
## 4. Установка Rust toolchain
|
||||
|
||||
Установить стабильный Rust toolchain:
|
||||
|
||||
```bash
|
||||
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
|
||||
. "$HOME/.cargo/env"
|
||||
rustup default stable
|
||||
rustc --version
|
||||
cargo --version
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- `rustc --version` и `cargo --version` выводят стабильную версию;
|
||||
- `$HOME/.cargo/bin` доступен в текущей shell-сессии.
|
||||
|
||||
## 5. Получение исходного кода
|
||||
|
||||
Склонировать репозиторий и перейти в рабочую директорию:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/igor04091968/AWatch-rus.git
|
||||
cd AWatch-rus
|
||||
git rev-parse --short HEAD
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- репозиторий склонирован;
|
||||
- команда `git rev-parse --short HEAD` выводит commit id проверяемой версии.
|
||||
|
||||
## 6. Проверка публичной гигиены поставки
|
||||
|
||||
Перед установкой выполнить быстрый контроль отсутствия приватных маркеров в
|
||||
публичных документах:
|
||||
|
||||
```bash
|
||||
PRIVATE_MARKERS_REGEX='<PRIVATE_HOSTNAME>|<PRIVATE_PUBLIC_DOMAIN>|<LOCAL_OPERATOR_HOME>|<ROOT_PRIVATE_PATH>'
|
||||
git grep -n -E "$PRIVATE_MARKERS_REGEX" -- \
|
||||
README.md docs REGISTER_RU_SOFTWARE.md PRODUCT_DESCRIPTION_RU.md \
|
||||
SECURITY_OVERVIEW_RU.md adk-rust/RUNBOOK.md || true
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- команда не должна находить реальные имена хостов, личные домены и личные
|
||||
пути оператора в публичных документах;
|
||||
- допустимы только нейтральные placeholders вроде `<AW_SERVER_HOST>`,
|
||||
`<PUBLIC_GATEWAY_FQDN>`, `HOST-EXAMPLE`.
|
||||
|
||||
## 7. Подготовка локальной конфигурации
|
||||
|
||||
Создать приватные файлы из примеров:
|
||||
|
||||
```bash
|
||||
cp private-config/deploy.env.example private-config/deploy.env
|
||||
cp ansible/inventory.example.ini ansible/inventory.ini
|
||||
```
|
||||
|
||||
Заполнить в `private-config/deploy.env` и `ansible/inventory.ini` только
|
||||
тестовые значения:
|
||||
|
||||
- адрес Linux VM;
|
||||
- адрес Windows host, если проверяются Windows collectors;
|
||||
- адрес Grafana/Prometheus, если они вынесены на отдельную VM;
|
||||
- тестовые учетные данные;
|
||||
- тестовые токены Telegram/Webhook, если проверяются уведомления.
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- приватная конфигурация существует локально;
|
||||
- приватные файлы не попадают в Git благодаря `.gitignore`;
|
||||
- в публичных файлах не появляются реальные пароли, IP и домены.
|
||||
|
||||
## 8. Сборка Rust-компонентов
|
||||
|
||||
Собрать workspace:
|
||||
|
||||
```bash
|
||||
cd adk-rust
|
||||
cargo build --release --workspace
|
||||
cd ..
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- сборка завершается кодом `0`;
|
||||
- release-бинарники появляются в `adk-rust/target/release/`;
|
||||
- отсутствуют ошибки компиляции Rust-компонентов.
|
||||
|
||||
## 9. Локальные тесты до установки
|
||||
|
||||
Запустить базовые проверки исходников:
|
||||
|
||||
```bash
|
||||
cd adk-rust
|
||||
cargo fmt --all -- --check
|
||||
cargo test --workspace
|
||||
cd ..
|
||||
```
|
||||
|
||||
Проверить Ansible syntax:
|
||||
|
||||
```bash
|
||||
ansible-playbook --syntax-check -i ansible/inventory.ini ansible/deploy_aw_server.yml
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- `cargo fmt` не сообщает diff;
|
||||
- `cargo test --workspace` завершается успешно;
|
||||
- Ansible syntax-check не находит ошибок YAML/playbook.
|
||||
|
||||
## 10. Установка минимального серверного экземпляра
|
||||
|
||||
Для чистой экспертной VM использовать inventory, где целевой Linux host
|
||||
указывает на эту же VM или на отдельный тестовый сервер.
|
||||
|
||||
Пример команды:
|
||||
|
||||
```bash
|
||||
ansible-playbook -i ansible/inventory.ini ansible/deploy_aw_server.yml
|
||||
```
|
||||
|
||||
Если playbook требует переменные окружения или группы hosts, задать их в
|
||||
локальном inventory, не меняя публичные файлы репозитория.
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- playbook завершается без failed tasks;
|
||||
- systemd units установлены на тестовый Linux host;
|
||||
- ActivityWatch server и DetMir helper-компоненты доступны локально на
|
||||
заданных портах;
|
||||
- конфигурация не содержит боевых адресов правообладателя.
|
||||
|
||||
## 11. Проверка сервисов после установки
|
||||
|
||||
На тестовом Linux host выполнить:
|
||||
|
||||
```bash
|
||||
systemctl --failed --no-pager
|
||||
systemctl status activitywatch-server --no-pager
|
||||
```
|
||||
|
||||
Если установлены Rust helper-бинарники:
|
||||
|
||||
```bash
|
||||
detmir-check --json
|
||||
detmir-status --json
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- `systemctl --failed` не показывает критичных failed units DetMir/AWatch-rus;
|
||||
- `activitywatch-server` находится в состоянии `active`;
|
||||
- `detmir-check --json` возвращает машинно-читаемый статус без критичных
|
||||
ошибок;
|
||||
- `detmir-status --json` показывает агрегированный статус установленного
|
||||
экземпляра.
|
||||
|
||||
## 12. Проверка HTTP API
|
||||
|
||||
Проверить ActivityWatch API:
|
||||
|
||||
```bash
|
||||
curl -fsS http://127.0.0.1:5600/api/0/info | jq .
|
||||
curl -fsS http://127.0.0.1:5600/api/0/buckets/ | jq 'keys | length'
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- `/api/0/info` возвращает JSON;
|
||||
- `/api/0/buckets/` возвращает JSON-объект;
|
||||
- ошибки `connection refused`, `403`, `500` отсутствуют.
|
||||
|
||||
## 13. Проверка Grafana/Prometheus
|
||||
|
||||
Если в экспертном стенде установлены Grafana/Prometheus:
|
||||
|
||||
```bash
|
||||
curl -fsS http://127.0.0.1:3000/api/health | jq .
|
||||
curl -fsS http://127.0.0.1:9090/-/ready
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- Grafana health API возвращает статус `ok` или `database: ok`;
|
||||
- Prometheus ready endpoint возвращает успешный HTTP status;
|
||||
- DetMir dashboards импортированы или доступны через documented provisioning
|
||||
path.
|
||||
|
||||
## 14. Проверка Windows collectors
|
||||
|
||||
Этот шаг нужен только для полной проверки контура.
|
||||
|
||||
На Windows host выполнить PowerShell deployment из `windows/` или Ansible
|
||||
playbook для Windows collectors, используя тестовый domain/hostname:
|
||||
|
||||
```powershell
|
||||
Get-ScheduledTask | Where-Object TaskName -like 'ActivityWatch*'
|
||||
```
|
||||
|
||||
На Linux server проверить появление buckets:
|
||||
|
||||
```bash
|
||||
curl -fsS http://127.0.0.1:5600/api/0/buckets/ | jq 'keys[]' | sort
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- Windows tasks созданы с тестовыми именами host/user;
|
||||
- ActivityWatch buckets получают события от Windows collectors;
|
||||
- в bucket names нет приватных имен боевого стенда.
|
||||
|
||||
## 15. Smoke-проверка портала оператора
|
||||
|
||||
Если установлен portal runtime:
|
||||
|
||||
```bash
|
||||
curl -fsS http://127.0.0.1:8080/health
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- health endpoint возвращает успешный HTTP status;
|
||||
- карточки портала открываются по локальным адресам стенда;
|
||||
- ссылки на Grafana/ActivityWatch/incident evidence используют значения из
|
||||
конфигурации, а не захардкоженные адреса.
|
||||
|
||||
## 16. Итоговый критерий приемки
|
||||
|
||||
Экземпляр считается установленным корректно, если:
|
||||
|
||||
- исходный код собирается командой `cargo build --release --workspace`;
|
||||
- локальные Rust tests проходят;
|
||||
- Ansible syntax-check проходит;
|
||||
- серверный playbook завершается без failed tasks;
|
||||
- ActivityWatch API отвечает JSON;
|
||||
- `systemctl --failed` не показывает критичных failures;
|
||||
- `detmir-check` и `detmir-status` отрабатывают;
|
||||
- публичные документы не содержат приватных IP, доменов, hostnames и путей;
|
||||
- third-party license inventory и release/SBOM checklist заполнены.
|
||||
|
||||
## 17. Сбор диагностического пакета для эксперта
|
||||
|
||||
После проверки сохранить артефакты:
|
||||
|
||||
```bash
|
||||
mkdir -p expert-check-output
|
||||
git rev-parse HEAD > expert-check-output/commit.txt
|
||||
systemctl --failed --no-pager > expert-check-output/systemd-failed.txt
|
||||
curl -fsS http://127.0.0.1:5600/api/0/info > expert-check-output/aw-info.json
|
||||
detmir-check --json > expert-check-output/detmir-check.json || true
|
||||
detmir-status --json > expert-check-output/detmir-status.json || true
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- в `expert-check-output/` есть commit id, systemd summary и JSON-проверки;
|
||||
- пакет не содержит паролей, токенов и приватных доменов.
|
||||
|
||||
## 18. Очистка тестового экземпляра
|
||||
|
||||
Для удаления тестовой VM достаточно уничтожить саму VM. Если нужно очистить
|
||||
только сервисы внутри VM, сначала сохранить diagnostic output, затем остановить
|
||||
установленные units:
|
||||
|
||||
```bash
|
||||
sudo systemctl stop activitywatch-server || true
|
||||
sudo systemctl list-units 'aw-*' 'detmir-*' --no-pager
|
||||
```
|
||||
|
||||
Ожидаемый результат:
|
||||
|
||||
- экспертский стенд можно воспроизвести заново из исходников и локальной
|
||||
конфигурации;
|
||||
- очистка не требует доступа к боевому стенду правообладателя.
|
||||
@@ -0,0 +1,277 @@
|
||||
# SBOM и release checklist
|
||||
|
||||
Документ фиксирует минимальный порядок подготовки публичного релиза
|
||||
DetMir/AWatch-rus: исходники, сборка, артефакты, сторонние компоненты,
|
||||
лицензии, публичная гигиена и экспертная проверка.
|
||||
|
||||
## 1. Идентификация релиза
|
||||
|
||||
Перед сборкой зафиксировать:
|
||||
|
||||
- product name: `DetMir, программный комплекс AWatch-rus`;
|
||||
- repository: `AWatch-rus`;
|
||||
- release tag: `vX.Y.Z`;
|
||||
- commit: вывод `git rev-parse HEAD`;
|
||||
- дата сборки;
|
||||
- ответственный правообладатель/maintainer;
|
||||
- состав release assets.
|
||||
|
||||
Команды:
|
||||
|
||||
```bash
|
||||
git status --short
|
||||
git rev-parse HEAD
|
||||
git tag --points-at HEAD
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- рабочее дерево не содержит незапланированных tracked-изменений;
|
||||
- tag указывает на проверенный commit;
|
||||
- release notes соответствуют фактическому составу поставки.
|
||||
|
||||
## 2. Публичная гигиена репозитория
|
||||
|
||||
Проверить отсутствие приватных идентификаторов в публичных документах:
|
||||
|
||||
```bash
|
||||
PRIVATE_MARKERS_REGEX='<PRIVATE_HOSTNAME>|<PRIVATE_PUBLIC_DOMAIN>|<LOCAL_OPERATOR_HOME>|<ROOT_PRIVATE_PATH>'
|
||||
git grep -n -E "$PRIVATE_MARKERS_REGEX" -- \
|
||||
README.md docs REGISTER_RU_SOFTWARE.md PRODUCT_DESCRIPTION_RU.md \
|
||||
SECURITY_OVERVIEW_RU.md adk-rust/RUNBOOK.md || true
|
||||
```
|
||||
|
||||
Проверить реальные IP в release-facing документах:
|
||||
|
||||
```bash
|
||||
git grep -n -E '10\\.10\\.10\\.|192\\.168\\.' -- \
|
||||
README.md docs REGISTER_RU_SOFTWARE.md PRODUCT_DESCRIPTION_RU.md \
|
||||
SECURITY_OVERVIEW_RU.md adk-rust/RUNBOOK.md || true
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- в документах нет приватных IP, доменов, usernames и live hostnames;
|
||||
- допускаются только placeholders: `<AW_SERVER_HOST>`, `<GRAFANA_HOST>`,
|
||||
`<PUBLIC_GATEWAY_FQDN>`, `HOST-EXAMPLE`, `WINDOWS_USER_EXAMPLE`;
|
||||
- приватные configs находятся только в ignored-файлах.
|
||||
|
||||
## 3. Контроль секретов
|
||||
|
||||
Проверить, что в репозиторий не попали secrets:
|
||||
|
||||
```bash
|
||||
git ls-files | grep -E '(^|/)secrets(/|$)|\\.env$|inventory\\.ini$' || true
|
||||
git grep -n -E 'sk_[A-Za-z0-9]|pk_[A-Za-z0-9]|BEGIN OPENSSH PRIVATE KEY|password\\s*=' -- . || true
|
||||
```
|
||||
|
||||
Рекомендуемый дополнительный контроль:
|
||||
|
||||
```bash
|
||||
gitleaks detect --source . --no-git --redact
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- директория `secrets/` не отслеживается Git;
|
||||
- `.env`, `inventory.ini`, tokens, passwords и private keys отсутствуют в
|
||||
tracked-файлах;
|
||||
- если секрет ранее был опубликован, он ротируется вне этого checklist.
|
||||
|
||||
## 4. Сборка Rust workspace
|
||||
|
||||
Собрать Rust-компоненты:
|
||||
|
||||
```bash
|
||||
cd adk-rust
|
||||
cargo fmt --all -- --check
|
||||
cargo test --workspace
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
cargo build --release --workspace
|
||||
cd ..
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- formatting clean;
|
||||
- tests green;
|
||||
- clippy без warnings;
|
||||
- release-бинарники собраны.
|
||||
|
||||
## 5. Проверка Python-исключений
|
||||
|
||||
Python в проекте допускается только как:
|
||||
|
||||
- Telegram runtime, который решено оставить на Python;
|
||||
- совместимые legacy fallbacks;
|
||||
- installer/ops helpers, пока они не являются ядром продукта;
|
||||
- тестовые и migration utilities.
|
||||
|
||||
Проверка:
|
||||
|
||||
```bash
|
||||
git ls-files '*.py'
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- Python-файлы имеют понятную роль;
|
||||
- ядро DetMir/AWatch-rus позиционируется как Rust-first;
|
||||
- README/registry docs не обещают отсутствие Python там, где он еще остается.
|
||||
|
||||
## 6. Third-party license inventory
|
||||
|
||||
Основной license inventory:
|
||||
|
||||
- [`../THIRD_PARTY_LICENSES_RU.md`](../THIRD_PARTY_LICENSES_RU.md)
|
||||
|
||||
Проверить минимум:
|
||||
|
||||
- ActivityWatch components: MPL-2.0 или лицензии конкретных upstream parts;
|
||||
- Grafana: AGPL-3.0 или актуальная лицензия используемой версии;
|
||||
- Prometheus: Apache-2.0;
|
||||
- Hayabusa: лицензия upstream и правила распространения;
|
||||
- Ansible: GPL-3.0-or-later;
|
||||
- Rust crates: по `cargo metadata`, `cargo about`, `cargo deny`;
|
||||
- Python dependencies: по `pip-licenses` или lock-файлам;
|
||||
- JavaScript/Node dependencies для Playwright/UI helpers: по `npm ls` и
|
||||
package metadata.
|
||||
|
||||
Критерий:
|
||||
|
||||
- для каждого крупного компонента указан upstream, license, роль и риск;
|
||||
- copyleft-компоненты не скрыты;
|
||||
- release notes не противоречат лицензиям.
|
||||
|
||||
## 7. SBOM
|
||||
|
||||
Сформировать машинные перечни зависимостей.
|
||||
|
||||
Rust:
|
||||
|
||||
```bash
|
||||
cd adk-rust
|
||||
cargo metadata --format-version 1 > ../sbom-cargo-metadata.json
|
||||
cargo tree --workspace > ../sbom-cargo-tree.txt
|
||||
cd ..
|
||||
```
|
||||
|
||||
Python, если используется виртуальное окружение:
|
||||
|
||||
```bash
|
||||
python3 -m pip freeze > sbom-python-freeze.txt
|
||||
```
|
||||
|
||||
Node/Playwright, если используется frontend smoke tooling:
|
||||
|
||||
```bash
|
||||
npm ls --all --json > sbom-npm-tree.json
|
||||
```
|
||||
|
||||
OS packages на эталонной VM:
|
||||
|
||||
```bash
|
||||
dpkg-query -W -f='${Package}\\t${Version}\\n' > sbom-debian-packages.tsv
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- SBOM artifacts приложены к release assets или сохранены в build archive;
|
||||
- SBOM не содержит секретов;
|
||||
- SBOM соответствует проверяемому commit/tag.
|
||||
|
||||
## 8. Release assets
|
||||
|
||||
Собрать install-kit и бинарные артефакты только из проверенного commit:
|
||||
|
||||
```bash
|
||||
scripts/rebuild_install_kit.sh
|
||||
scripts/validate_install_kit.sh
|
||||
```
|
||||
|
||||
Критерий:
|
||||
|
||||
- dated zip/tar.gz не лежат в корне tracked-репозитория;
|
||||
- архивы публикуются как GitHub Release assets;
|
||||
- checksum каждого asset зафиксирован.
|
||||
|
||||
Пример фиксации checksum:
|
||||
|
||||
```bash
|
||||
sha256sum dist/* install-kit-awindows-*.zip install-kit-awindows-*.tar.gz \
|
||||
> SHA256SUMS
|
||||
```
|
||||
|
||||
## 9. Документы для реестра российского ПО
|
||||
|
||||
Проверить наличие и актуальность:
|
||||
|
||||
- `REGISTER_RU_SOFTWARE.md`;
|
||||
- `PRODUCT_DESCRIPTION_RU.md`;
|
||||
- `THIRD_PARTY_LICENSES_RU.md`;
|
||||
- `docs/INSTALL_FOR_EXPERT_RU.md`;
|
||||
- `docs/ARCHITECTURE_RU.md`;
|
||||
- `docs/ADMIN_GUIDE_RU.md`;
|
||||
- `docs/OPERATOR_GUIDE_RU.md`;
|
||||
- `docs/OWNERSHIP_RU.md`;
|
||||
- `docs/REGISTRY_CHECKLIST_RU.md`.
|
||||
|
||||
Критерий:
|
||||
|
||||
- документы согласованы по названию продукта;
|
||||
- не заявляются DLP/SIEM/EDR/XDR/сертифицированная СЗИ как основной класс;
|
||||
- позиционирование: операционный контроль, технический аудит, автоматизация
|
||||
эксплуатации ИТ-инфраструктуры.
|
||||
|
||||
## 10. Экспертная установка
|
||||
|
||||
Проверить релиз на чистой VM по:
|
||||
|
||||
- [`INSTALL_FOR_EXPERT_RU.md`](INSTALL_FOR_EXPERT_RU.md)
|
||||
|
||||
Критерий:
|
||||
|
||||
- чистая VM проходит путь установка -> сборка -> проверка;
|
||||
- ActivityWatch API отвечает;
|
||||
- базовые DetMir checks работают;
|
||||
- diagnostic bundle собран;
|
||||
- инструкция воспроизводима без доступа к личному стенду разработчика.
|
||||
|
||||
## 11. GitHub metadata
|
||||
|
||||
Проверить публичную страницу репозитория:
|
||||
|
||||
- description заполнен;
|
||||
- website/homepage заполнен;
|
||||
- topics заполнены;
|
||||
- license отображается;
|
||||
- releases содержат бинарные/install-kit assets;
|
||||
- root README не содержит приватных адресов и личных путей.
|
||||
|
||||
Критерий:
|
||||
|
||||
- проект выглядит как поставляемое ПО, а не как личный стенд;
|
||||
- About/Topics/Website заполнены;
|
||||
- license detected на GitHub.
|
||||
|
||||
## 12. Финальный gate перед публикацией
|
||||
|
||||
Команды:
|
||||
|
||||
```bash
|
||||
git diff --check
|
||||
git status --short
|
||||
PRIVATE_MARKERS_REGEX='<PRIVATE_HOSTNAME>|<PRIVATE_PUBLIC_DOMAIN>|<LOCAL_OPERATOR_HOME>|<ROOT_PRIVATE_PATH>'
|
||||
git grep -n -E "$PRIVATE_MARKERS_REGEX" -- \
|
||||
README.md docs REGISTER_RU_SOFTWARE.md PRODUCT_DESCRIPTION_RU.md \
|
||||
SECURITY_OVERVIEW_RU.md adk-rust/RUNBOOK.md || true
|
||||
```
|
||||
|
||||
Критерий публикации:
|
||||
|
||||
- diff не содержит whitespace errors;
|
||||
- tracked changes входят в один понятный commit;
|
||||
- release-facing docs обезличены;
|
||||
- install-kit artifacts вынесены в Release assets;
|
||||
- SBOM/license checklist приложен или воспроизводим;
|
||||
- tag создан только после прохождения проверок.
|
||||
@@ -10,7 +10,7 @@ This document records the production-verified state of advanced content analysis
|
||||
- `contentAnalysis.regexPack`
|
||||
- `contentAnalysis.ocrEnabled`
|
||||
- `ioc.*`
|
||||
- Historical incidents in `aw-dlp-incidents_SHARKON2025` already contain enriched fields:
|
||||
- Historical incidents in `aw-dlp-incidents_HOST-EXAMPLE` already contain enriched fields:
|
||||
- `dictionaryMatches`
|
||||
- `regexMatches`
|
||||
- `ocrRequested`
|
||||
|
||||
@@ -27,8 +27,8 @@ Verified on `<AW_SERVER_HOST>`:
|
||||
- recent journal runs are clean
|
||||
- current runtime result is `sent=0` / `delivered=0` because no new incidents were generated since the last seen bucket event
|
||||
- `endpoint -> incident ingest`
|
||||
- `aw-dlp-endpoint-signals_SHARKON2025` fresh
|
||||
- `aw-dlp-incidents_SHARKON2025` exists and contains valid historical incidents
|
||||
- `aw-dlp-endpoint-signals_HOST-EXAMPLE` fresh
|
||||
- `aw-dlp-incidents_HOST-EXAMPLE` exists and contains valid historical incidents
|
||||
- `health/admin`
|
||||
- `/usr/local/bin/dlp-health-check --json` = `ok=true`
|
||||
- `/usr/local/bin/dlp-admin-cli.py health check` = policy/cases/aw OK
|
||||
|
||||
@@ -42,13 +42,13 @@ aw_windows_builtin_administrator_name: "Администратор"
|
||||
|
||||
Назначение: явно фиксировать локализованное имя встроенной учетной записи Administrator с SID `*-500`.
|
||||
|
||||
Для текущего Windows host `SHARKON2025` task name должен строиться как:
|
||||
Для текущего Windows host `HOST-EXAMPLE` task name должен строиться как:
|
||||
|
||||
```text
|
||||
ActivityWatch Launch [SHARKON2025_Администратор]
|
||||
ActivityWatch Launch [HOST-EXAMPLE_Администратор]
|
||||
```
|
||||
|
||||
Если task по `SHARKON2025_Administrator` не найден, recovery/deploy path обязан пробовать кириллическое имя `Администратор`. Это зафиксировано через:
|
||||
Если task по `HOST-EXAMPLE_Administrator` не найден, recovery/deploy path обязан пробовать кириллическое имя `Администратор`. Это зафиксировано через:
|
||||
|
||||
- default vars в `ansible/deploy_aw_windows.yml`;
|
||||
- `ansible/group_vars/aw_windows.yml`;
|
||||
@@ -60,7 +60,7 @@ ActivityWatch Launch [SHARKON2025_Администратор]
|
||||
|
||||
`ActivityWatch.Windows.Common.psm1` усилил recovery path:
|
||||
|
||||
- `Get-ActivityWatchBuiltInAdministratorName` сначала смотрит env override, затем SID-500 lookup, затем host-specific fallback `SHARKON2025 -> Администратор`;
|
||||
- `Get-ActivityWatchBuiltInAdministratorName` сначала смотрит env override, затем SID-500 lookup, затем host-specific fallback `HOST-EXAMPLE -> Администратор`;
|
||||
- `Normalize-ActivityWatchUsers` стабилизирован для pipeline/list cases;
|
||||
- удаление scheduled tasks стало устойчивее к частично удаленным task definitions;
|
||||
- recovery task может ориентироваться на live interactive session и запускаться в interactive logon context, когда это безопаснее для watcher'ов.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
### 1. Multi-user RDP host
|
||||
|
||||
Use this model on `SHARKON2025`-style hosts with multiple user sessions.
|
||||
Use this model on `HOST-EXAMPLE`-style hosts with multiple user sessions.
|
||||
|
||||
- `AWatchRusCollectorGuard` service:
|
||||
- runs under `LocalSystem`
|
||||
|
||||
@@ -191,7 +191,7 @@ Ansible playbook `ansible/deploy_aw_windows.yml` выполняет этот mig
|
||||
.\windows\deploy-domain-users.ps1 `
|
||||
-ServerHost <AW_SERVER_HOST> `
|
||||
-ServerPort 5600 `
|
||||
-Domain SHARKON2025 `
|
||||
-Domain HOST-EXAMPLE `
|
||||
-Users user2,user3,user4,user5 `
|
||||
-InstallRoot 'C:\Program Files\AWatch-rus\bin' `
|
||||
-StateRoot 'C:\ProgramData\AWatch-rus' `
|
||||
@@ -205,7 +205,7 @@ Single-user pilot в таком же стиле:
|
||||
.\windows\deploy-single-user.ps1 `
|
||||
-ServerHost <AW_SERVER_HOST> `
|
||||
-ServerPort 5600 `
|
||||
-TargetUser 'SHARKON2025\user1' `
|
||||
-TargetUser 'HOST-EXAMPLE\user1' `
|
||||
-InstallRoot 'C:\Program Files\AWatch-rus\bin' `
|
||||
-StateRoot 'C:\ProgramData\AWatch-rus' `
|
||||
-CustomRulesPath C:\Program Files\AWatch-rus\windows\web-category-rules.example.json `
|
||||
|
||||
@@ -20,7 +20,7 @@ Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
|
||||
C:\Program Files\AWatch-rus\windows\deploy-ensemble.ps1 `
|
||||
-ServerHost <AW_SERVER_HOST> `
|
||||
-ServerPort 5600 `
|
||||
-Domain SHARKON2025 `
|
||||
-Domain HOST-EXAMPLE `
|
||||
-Users user1,user2,user3,user4,user5 `
|
||||
-InstallRoot 'C:\Program Files\AWatch-rus\bin' `
|
||||
-StateRoot 'C:\ProgramData\AWatch-rus' `
|
||||
|
||||
@@ -43,7 +43,7 @@ Get-ScheduledTask -TaskName 'ActivityWatch*' |
|
||||
Точечная проверка:
|
||||
|
||||
```powershell
|
||||
Get-ScheduledTask | Where-Object TaskName -eq 'ActivityWatch Launch [SHARKON2025_user1]'
|
||||
Get-ScheduledTask | Where-Object TaskName -eq 'ActivityWatch Launch [HOST-EXAMPLE_user1]'
|
||||
Get-ScheduledTask | Where-Object TaskName -eq 'ActivityWatch Recovery'
|
||||
```
|
||||
|
||||
|
||||
@@ -13,8 +13,8 @@
|
||||
Подходит для расчета рабочего времени в толстых клиентах (1С, документы, админка).
|
||||
|
||||
```javascript
|
||||
events = flood(query_bucket("aw-watcher-window_SHARKON2025"));
|
||||
not_afk = flood(query_bucket("aw-watcher-afk_SHARKON2025"));
|
||||
events = flood(query_bucket("aw-watcher-window_HOST-EXAMPLE"));
|
||||
not_afk = flood(query_bucket("aw-watcher-afk_HOST-EXAMPLE"));
|
||||
not_afk = filter_keyvals(not_afk, "status", ["not-afk"]);
|
||||
|
||||
events = filter_period_intersect(events, not_afk);
|
||||
@@ -41,8 +41,8 @@ RETURN = sort_by_duration(work);
|
||||
`rootDomain=proxmox-webui`, `categoryGroup=work`, `category=Администрирование`.
|
||||
|
||||
```javascript
|
||||
web = flood(query_bucket("aw-detmir-web-category_SHARKON2025"));
|
||||
not_afk = flood(query_bucket("aw-watcher-afk_SHARKON2025"));
|
||||
web = flood(query_bucket("aw-detmir-web-category_HOST-EXAMPLE"));
|
||||
not_afk = flood(query_bucket("aw-watcher-afk_HOST-EXAMPLE"));
|
||||
not_afk = filter_keyvals(not_afk, "status", ["not-afk"]);
|
||||
|
||||
web = filter_period_intersect(web, not_afk);
|
||||
@@ -55,8 +55,8 @@ RETURN = sort_by_duration(web);
|
||||
## Sanity-check: «куда уходит время»
|
||||
|
||||
```javascript
|
||||
events = flood(query_bucket("aw-watcher-window_SHARKON2025"));
|
||||
not_afk = flood(query_bucket("aw-watcher-afk_SHARKON2025"));
|
||||
events = flood(query_bucket("aw-watcher-window_HOST-EXAMPLE"));
|
||||
not_afk = flood(query_bucket("aw-watcher-afk_HOST-EXAMPLE"));
|
||||
not_afk = filter_keyvals(not_afk, "status", ["not-afk"]);
|
||||
|
||||
events = filter_period_intersect(events, not_afk);
|
||||
@@ -68,7 +68,7 @@ RETURN = sort_by_duration(events);
|
||||
|
||||
## Замечания
|
||||
|
||||
- Для других хостов замените суффикс `_SHARKON2025` на нужный hostname.
|
||||
- Для других хостов замените суффикс `_HOST-EXAMPLE` на нужный hostname.
|
||||
- Если web-поток пустой, рабочее время в браузере корректно посчитать по доменам не получится. Тогда либо:
|
||||
- чинить/запускать browser collector;
|
||||
- либо временно считать браузер в `window` как «Интернет/Браузер» без разделения на work/personal.
|
||||
@@ -82,7 +82,7 @@ RETURN = sort_by_duration(events);
|
||||
«кто и когда вообще был в активной удалённой сессии».
|
||||
|
||||
```javascript
|
||||
sessions = flood(query_bucket("aw-worktime-sessions_SHARKON2025"));
|
||||
sessions = flood(query_bucket("aw-worktime-sessions_HOST-EXAMPLE"));
|
||||
sessions = filter_keyvals(sessions, "active", [true]);
|
||||
sessions = merge_events_by_keys(sessions, ["username", "sessionName", "state"]);
|
||||
RETURN = sort_by_duration(sessions);
|
||||
|
||||
Reference in New Issue
Block a user