v1.18

Added

• --check-config CLI flag (#13) - validate config.toml and exit without starting the server. Container-friendly equivalent of install.sh test-config for podman/docker users who do not run the bash installer: podman run --rm -v ./config.toml:/etc/zabbix-mcp/config.toml:ro ghcr.io/initmax/zabbix-mcp-server:latest --config /etc/zabbix-mcp/config.toml --check-config. Reports TOML syntax errors, semantic errors (wrong types, invalid values), missing file, and permission errors with clear messages, exits 0 on success and 1 on any validation failure.

Fixed

• Admin portal first-run bootstrap now works in containers (#13) - deploy/install.sh auto-generates a random admin password and writes [admin.users.admin] into config.toml via its setup_admin step, but container deployments do not use the installer. A fresh container started from config.example.toml had admin.enabled = true but no [admin.users.*], so the admin portal was reachable yet every login attempt failed and the operator was locked out unless they manually hashed a password and edited the mounted config. Fixed with a new zabbix_mcp.admin_bootstrap module that runs at server startup: if the admin portal is enabled and no users exist, it generates a cryptographically random 16-character password, scrypt-hashes it (n=16384, r=8, p=1, identical format to install.sh and admin/auth.py), writes [admin.users.admin] into config.toml via tomlkit (preserving comments and formatting), and prints the credentials prominently to stderr AND the logger (WARNING level, framed banner) so operators can find them with podman logs / docker logs / journalctl. Idempotent, non-fatal (a failure is logged and startup continues), and a no-op on host installs (where install.sh already wrote the user) and on subsequent container restarts.
• Custom report templates now persist across container restarts (#13) - v1.17 moved custom templates from /var/log/zabbix-mcp/templates/ to /etc/zabbix-mcp/templates/, but the container setup never caught up with the new path. Dockerfile did not create /etc/zabbix-mcp/templates/ with the correct ownership, docker-compose.yml did not mount it as a persistent volume, and the legacy-to-current migration only ran in deploy/install.sh (which containers do not use). A custom template created via the admin portal inside a container would be written to a non-persistent path and lost on the next restart, and v1.16 -> v1.17 container upgrades stranded existing templates in the old logs volume. Dockerfile now creates /etc/zabbix-mcp/templates/ with zabbix-mcp:zabbix-mcp ownership and mode 0750, docker-compose.yml mounts it as a named volume (templates), and a new zabbix_mcp.template_migration module runs the equivalent of the bash migration at server startup: moves *.html files from the legacy location to the current one (preserving content and timestamps, skipping any file that already exists at the destination), rewrites template_file paths in [report_templates.*] config sections via tomlkit (preserves comments and formatting), and removes the legacy directory if it ends up empty. The migration is idempotent, non-fatal (any failure is logged as a warning, startup continues), and a no-op on fresh installs or when nothing needs to be moved. The reporting feature remains in beta.