Operations¶

Last update: October 13, 2026

This page covers day-to-day operations of Tolk for Cisco UC — starting and stopping the server, monitoring, reverse proxy, backup & restore, upgrades, licensing, key rotation, integrity verification, and support bundle generation.

Starting & Stopping¶

# Start the service
docker compose up -d

# Stop the service
docker compose down

# Restart the service
docker compose restart

# Check service status
docker compose ps

# Follow logs
docker compose logs -f

# Restart on the new image after an upgrade
docker compose up -d

Docker includes a built-in health check that monitors the container every 30 seconds via HTTPS GET on /health. View health status with:

docker inspect --format='{{.State.Health.Status}}' tolk-for-cisco-uc

Data preservation

docker compose down removes the container but preserves all volume data (secrets, clients, logs, backups). Use docker compose down -v only if you want to delete everything.

Startup Sequence¶

At every startup, the server performs the following steps automatically:

Step	Action
1	Load and validate `.env` configuration
2	Initialize structured logging (`app.log` + `audit.log`)
3	Sync default RBAC profiles (`profiles/_default/` → `profiles/`)
4	Run software integrity check (`manifest.json` + `manifest.sig`)
5	Verify / generate TLS certificate
6	Verify RSA key pair — generate if absent
7	Synchronize clients (create / update / purge per `AUTH_CLIENTS`)
8	Verify license (`secrets/license.jwt`)
9	Load product modules (conditional on license tier)
10	Start background watchdogs (License, Integrity, Backup)
11	Start ASGI server (HTTPS)

Graceful shutdown

The server handles SIGTERM (docker stop) and SIGINT. All background watchdog threads are stopped cleanly via atexit handlers before the process exits.

Monitoring & Observability¶

Log Files¶

File	Location	Content
`app.log`	`LOGGING_DIR` (default `./logs/`)	Application events: startup, module loading, errors, info
`audit.log`	`LOGGING_DIR`	Security audit trail: all auth events, tool calls, credential operations

Both files use structured JSON format — one JSON object per line — for easy ingestion into SIEM or log aggregation tools (Elastic, Splunk, Loki, etc.).

Log rotation: triggered when app.log or audit.log exceeds LOGGING_ROTATE_SIZE bytes (default ~5 MB). Up to LOGGING_ROTATE_FILES compressed archives are kept alongside the active file.

Console output: enabled by default (LOGGING_CONSOLE_ENABLED=1). Output is colorized by log level for interactive use.

Health & Status Endpoints¶

Endpoint	Auth	Description
`GET /health`	None	Liveness probe — returns `ok`. Safe for load balancer checks.
`GET /status`	Bearer	Full server status JSON

/status response includes:

Server version and uptime
License state (VALID / GRACE / EXPIRED / INVALID), tier, expiry date, enabled products
Backup status (last backup timestamp and filename)
Current blacklisted IP count (Fail2Ban)
Loaded product modules
Statistics (statistics, no history): last statistics reset, clients active over the last 5 minutes, peaks since start (active clients, MCP req/min) and the last hour of the Pipeline — MCP requests/errors, end-to-end success, auth/authz failure rates, total/errors per stage and per product. Longer windows are on /metrics
TLS certificates of the MCP endpoint (tls) and of the admin Web UI (tls_admin_ui)

# Example status check
curl -sk -H "Authorization: Bearer <token>" \
  https://mcp.domain.com:8443/status | python -m json.tool

Prometheus Metrics¶

GET /metrics — no authentication required. Exposes metrics in Prometheus text format.

Available metrics:

Metric	Description
Request counters	By client, tool name, and status
Auth failure counters	Total and by client
Rate limit counters	By client, product, and service (plus global rejections by host, product, service via `mcp_global_rate_limit_hits_total`)
Watchdog status	License, integrity, backup watchdog state
Statistics (`mcp_stats_*`)	Admin Statistics pages data, gauges labelled `window` = `1h` / `24h` / `7d` / `30d`: KPIs (`mcp_stats_mcp_requests`, `_mcp_errors`, `_end_to_end_success_percent`, `_auth_failure_percent`, `_authz_failure_percent`, `_active_clients`, `_tools_used`, `_ip_bans`), pipeline (`mcp_stats_stage_`, `mcp_stats_stage_breakdown_`), products / services (`mcp_stats_product_`, `mcp_stats_service_`), top 10 (`mcp_stats_top_*`, `board` = clients / tools / profiles / destinations / error_types), client and tool first / last seen, `mcp_stats_reset_timestamp_seconds`

Scrape interval

A 15-second scrape interval is recommended. The /metrics endpoint is lightweight and does not perform any Cisco UC queries.

Audit Log Event Categories¶

Every security-relevant event is written to audit.log in structured JSON. Events are organized by category:

Category	What is logged
`AUTH`	Login success/failure, token issued/revoked, source IP, client identity
`ACTIONS`	Every MCP tool call — client, tool name, target host, result, execution time
`RATE_LIMITED`	Rate limit violations — per client (`RATE_LIMITED`) and global per destination host (`RATE_LIMITED_GLOBAL`)
`CREDENTIAL`	Store / update / delete credential operations
`TRUSTED`	SSH fingerprint trust and reject decisions
`WRITTEN` / `EXPORTED`	Report generation and PDF export events
`SERVER`	Startup, shutdown, license state transitions
`TRANSPORT`	TLS alerts, invalid `Host`/`Origin` headers, DNS rebinding attempts

Audit log integrity

audit.log is an append-only structured log. It is never modified after an event is written. Treat it as an immutable audit trail and forward it to a SIEM for long-term retention.

Reverse Proxy (HAProxy)¶

A web reverse proxy can publish Tolk behind a VIP (e.g. tolk-vip.domain.com): MCP clients on port 8443, Admin Web UI on port 9443. The examples below use HAProxy, with the Tolk server tolk.domain.com (or tolk-1 / tolk-2) and the proxies 10.0.0.1 / 10.0.0.2.

Reverse Proxy Certificate¶

The certificate presented by the reverse proxy must contain the VIP FQDN in its SANs (e.g. tolk-vip.domain.com).

The proxy validates the Tolk server certificate (verify required, verifyhost): the CA that signed it must be in the proxy ca-file, and the certificate must contain the Tolk server FQDN (tolk.domain.com) — it does by default, as the AUTH_ISSUER host is its CN.

Tolk Server Settings¶

Set from the Admin Web UI (Global settings), then Apply & restart:

Tab / group	Setting	Value (example)	Purpose
Server › Reverse proxy	`MCP_SERVER_PUBLIC_URL`	`https://tolk-vip.domain.com:8443`	Public URL advertised to the clients; the VIP FQDN is added implicitly to the allowed hosts / origins (`MCP_SERVER_SECURITY_ALLOWED_HOSTS` / `_ORIGINS`)
Server › Reverse proxy	`TRUSTED_PROXY_IPS`	`10.0.0.1,10.0.0.2`	Proxies whose `X-Forwarded-For` identifies the real client (logs, blacklist, statistics, admin allow-list); never blacklisted
Admin UI › Transport	`ADMIN_UI_TRUSTED_IPS`	`10.0.0.1/32,10.0.0.2/32,10.1.0.0/24`	Proxy IPs (HTTPS health checks of `/admin/health`, sent without `X-Forwarded-For`) and admin PC IPs / networks (evaluated on the forwarded client address)
Server › Other	`SERVER_HEALTHCHECK_STATUS_RESPONSE`	`ok` (default)	`status` value returned by `/health`, tested by the proxy health check

MCP client URL

With MCP_SERVER_PUBLIC_URL set, the URL given to the clients (OAuth discovery, client connection URL) becomes https://tolk-vip.domain.com:8443/mcp.

HAProxy Frontend¶

The ACLs below go in the HTTPS frontend presenting the VIP certificate (listening on 8443 and 9443):

# TOLK Frontend
acl ACL_tolk hdr(host) -i tolk-vip.domain.com:8443
http-request del-header X-Forwarded-For if ACL_tolk
http-request set-header X-Forwarded-Proto https if ACL_tolk
http-request set-timeout client 1h if ACL_tolk   # if HA-Proxy >=3.0
use_backend tolk_back if ACL_tolk
# TOLK Frontend (admin)
acl ACL_tolk-admin hdr(host) -i tolk-vip.domain.com:9443
acl ACL_tolk-admin_urls path_dir -i /admin
http-request del-header X-Forwarded-For if ACL_tolk-admin
http-request set-header X-Forwarded-Proto https if ACL_tolk-admin
http-request set-timeout client 1h if ACL_tolk-admin   # if HA-Proxy >=3.0
use_backend tolk-admin_back if ACL_tolk-admin ACL_tolk-admin_urls

del-header X-Forwarded-For drops any header sent by the client; option forwardfor (backend) then adds the real client address — a client cannot spoof its IP.
set-timeout client 1h keeps long MCP streams open (HAProxy ≥ 3.0; otherwise raise timeout client on the frontend).
Only the /admin paths are forwarded to the admin backend.

HAProxy Backends¶

The backends run a Layer 7 health check: TLS certificate of the Tolk server (verify required, verifyhost), HTTP code and response text.

Single Tolk serverLoad balancing (several Tolk servers)

# TOLK Backend
backend tolk_back
    description BACKEND - TOLK
    timeout server 1h
    option forwardfor
    option httpchk
    http-check send meth GET uri /health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:8443"
    http-check expect status 200
    http-check expect string "\"status\":\"ok\",\"ready\":true"
    server tolk tolk.domain.com:8443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk.domain.com) verifyhost tolk.domain.com check-sni tolk.domain.com inter 10s fall 2 rise 2

backend tolk-admin_back
    description BACKEND - TOLK (admin)
    option forwardfor
    option httpchk
    http-check send meth GET uri /admin/health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:9443"
    http-check expect status 200
    http-check expect string "ok"
    server tolk tolk.domain.com:9443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk.domain.com) verifyhost tolk.domain.com check-sni tolk.domain.com inter 10s fall 2 rise 2

# TOLK Backend
backend tolk_back
    description BACKEND - TOLK
    timeout server 1h
    option forwardfor
    option httpchk
    http-check send meth GET uri /health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:8443"
    http-check expect status 200
    http-check expect string "\"status\":\"ok\",\"ready\":true"
    server tolk-1 tolk-1.domain.com:8443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-1.domain.com) verifyhost tolk-1.domain.com check-sni tolk-1.domain.com inter 10s fall 2 rise 2
    server tolk-2 tolk-2.domain.com:8443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-2.domain.com) verifyhost tolk-2.domain.com check-sni tolk-2.domain.com inter 10s fall 2 rise 2
    balance roundrobin
    stick-table type ip size 10m expire 30m
    stick match src
    stick store-request src

backend tolk-admin_back
    description BACKEND - TOLK (admin)
    option forwardfor
    option httpchk
    http-check send meth GET uri /admin/health ver HTTP/1.1 hdr Host "%[srv_name].domain.com:9443"
    http-check expect status 200
    http-check expect string "ok"
    server tolk-1 tolk-1.domain.com:9443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-1.domain.com) verifyhost tolk-1.domain.com check-sni tolk-1.domain.com inter 10s fall 2 rise 2
    server tolk-2 tolk-2.domain.com:9443 check ssl verify required ca-file /etc/ssl/certs/Root-CA.cer sni str(tolk-2.domain.com) verifyhost tolk-2.domain.com check-sni tolk-2.domain.com inter 10s fall 2 rise 2
    balance roundrobin
    stick-table type ip size 10m expire 30m
    stick match src
    stick store-request src

The source-IP stickiness keeps each client on the same Tolk server: an MCP session or an Admin Web UI session is only valid on the server that opened it. Each Tolk server is configured as above (MCP_SERVER_PUBLIC_URL, TRUSTED_PROXY_IPS, ADMIN_UI_TRUSTED_IPS).

The Host header is essential

The health check Host header (%[srv_name].domain.com:<port>, i.e. tolk.domain.com:8443) must match an entry of MCP_SERVER_SECURITY_ALLOWED_HOSTS: without it, the HTTPS checks are rejected by the DNS-rebinding protection (HTTP 421). The server name (tolk, tolk-1…) must therefore be the short host name of the Tolk server.

Expected response text

/health (MCP) returns JSON, e.g. {"status":"ok","ready":true,…}: the ok value of the http-check expect string must match SERVER_HEALTHCHECK_STATUS_RESPONSE (ok by default). The server is taken out of the pool when its license is expired / invalid ("ready":false) or once maintenance mode has drained its clients ("status":"maintenance").
/admin/health (Admin Web UI) always returns ok (plain text), as long as the proxy IP is in ADMIN_UI_TRUSTED_IPS (otherwise 403).

Backup & Restore¶

Backup Encryption Model¶

Layer	Algorithm
Archive encryption	AES-256-GCM (random session key)
Session key wrapping	RSA-4096 OAEP (server public key)
Integrity verification	SHA-512 sidecar file

The server can create backups using the public key only. Restoring requires the RSA private key.

Triggering a Backup¶

Backups run automatically at the interval configured in BACKUP_INTERVAL_HOURS (default: 168 hours). The next periodic backup is scheduled one interval after the most recent archive (or one interval after startup when no archive exists or the slot is already past). The Next backup line of the Backup / Restore page shows this slot. To trigger a backup sooner, either:

Click Backup now on the Backup / Restore page of the admin web UI, or
Temporarily reduce BACKUP_INTERVAL_HOURS and restart

Restore — Safe Extract¶

Extract and decrypt a backup without touching the live installation. The script writes to an auto-generated folder named restore_<backup_id>/ in the project root — no --output flag is needed:

docker compose exec tolk python scripts/backup_restore.py \
  --file backups/backup_202605_hostname_20260508_001207.tar.gz.enc \
  --key secrets/rsa_private.pem

Inspect the extracted contents in ./restore_202605_hostname_20260508_001207/ before deciding to apply them.

Restore — In-Place (`--replace`)¶

Replace live files with backup contents. Keep the container running — the script detects the server process, prompts for confirmation, stops it, performs the in-place extraction, then you restart the stack:

docker compose exec tolk python scripts/backup_restore.py \
  --file backups/backup_202605_hostname_20260508_001207.tar.gz.enc \
  --key secrets/rsa_private.pem \
  --replace

docker compose up -d

The script stops the server before writing

--replace mode detects the running server PID inside the container, asks for an interactive yes confirmation, then issues SIGTERM before extracting. Do not run docker compose down beforehand — the exec command would fail because the container would be stopped.

Restore After RSA Key Rotation¶

If the backup was created before a key rotation, use the archived key:

docker compose exec tolk python scripts/backup_restore.py \
  --file backups/old_backup.enc \
  --key secrets/rsa_private.pem.archived.20260512

Archived keys are preserved in secrets/ with a .archived.YYYYMMDD suffix after rotation.

Upgrade¶

Overview¶

A new release is delivered as the same .tar.gz archive as the initial install (pre-built Docker image + supporting files). It is extracted over the installation directory, then the tolk-setup.sh script loads the new image and runs the upgrade tool (scripts/upgrade.py, from the new image) which reconciles your .env with the .env.example of the release.

Your data is preserved: the archive ships no .env, and never writes into secrets/, clients/ (except the reference clients/_default/), logs/, backups/, servers-data/ or profiles/*/_live/.

Read the dry-run output first

Always run ./tolk-setup.sh --dry-run before applying an upgrade. It shows the .env changes without writing anything.

Step-by-Step Upgrade Procedure¶

Step 1 — Verify the package integrity

Before installation, verify the archive using the DNS-published SHA-512 checksum:

From LinuxFrom Windows

# 1. Query the DNS TXT record published by the editor (uses a computer with public DNS resolution)
dig tolk-for-cisco-uc-<version>.sha512.check.consulting.sourdeau.com txt +short

# 2. Compute the SHA-512 hash of the downloaded archive
sha512sum tolk-for-cisco-uc-<version>.tar.gz

# 3. Compare both values — they must match exactly

# 1. Query the DNS TXT record published by the editor (uses a computer with public DNS resolution)
nslookup -q=txt tolk-for-cisco-uc-<version>.sha512.check.consulting.sourdeau.com

# 2. Compute the SHA-512 hash of the downloaded archive
Get-FileHash -Algorithm SHA512 tolk-for-cisco-uc-<version>.tar.gz

# 3. Compare both values — they must match exactly

Do not skip this step

If the values do not match, do not proceed. Contact tolk@sourdeau.com immediately.

Step 2 — Prepare (recommended)

From the admin Web UI: take a backup (Backup page), then switch the maintenance mode on (System › Maintenance mode) to drain the MCP sessions in progress before the restart.

Step 3 — Extract the release over the installation

cd ~/tolk
tar --no-overwrite-dir -xzf tolk-for-cisco-uc-<version>.tar.gz
rm -f tolk-for-cisco-uc-<version>.tar.gz*

--no-overwrite-dir keeps the permissions of the existing directories.

Step 4 — Preview (dry-run)

./tolk-setup.sh --dry-run

The script loads the new Docker image (then deletes the image archive) and prints the upgrade report: installed and release versions, .env keys updated / added, keys no longer used by the release. Nothing is written. The running service is not affected.

Step 5 — Apply

./tolk-setup.sh

The upgrade tool:

Checks the versions — a downgrade is refused (unless --force); re-running on the same version is harmless;
Backs up .env to backups/env/.env.bak-<UTC timestamp>;
Updates .env (see the merge rules below);
Flags the added settings as new in the admin Web UI;
Logs the operation to logs/upgrade.log.

Step 6 — Restart on the new image

docker compose up -d
docker image prune -f    # optional: remove the previous image

docker compose up -d recreates the container on the new image (no docker compose down needed). The maintenance mode, if enabled, survives the restart: switch it off from the admin UI once the service is checked.

Step 7 — Review the new settings

A blue New settings tile appears in the admin UI header; blue dots flag the menus and tabs holding them, and their rows are highlighted in blue. Review their default values and adjust them if needed.

`.env` Key Merge Behavior¶

Key Category	Behavior
Project identity	`PROJECT_NAME`, `PROJECT_CREATOR`, `PROJECT_VERSION` — always taken from the release (not editable)
New keys	Added with their default value and comment, at the same place as in `.env.example` (with the section header for a new section)
Existing customer keys	Never modified — always preserved exactly as configured
Obsolete keys	Keys no longer used by the release are listed in the report, never removed

Your configuration is safe

The upgrade tool never overwrites customer-configured keys. Your cluster credentials, client definitions, and custom settings survive every upgrade.

New-settings notices — a setting added by the upgrade stays flagged in blue until:

an admin clicks Mark as seen on the New settings page (header tile; write access on the Settings or Products page), or
the setting is edited (any saved value), or
7 days after the upgrade.

Upgrade Options¶

Option	Description
`--dry-run`	Preview the `.env` changes without writing anything
`--force`	Allow a downgrade or an unrecognised version (not recommended)

License¶

License States¶

The server monitors its license continuously and operates in one of four states:

State	Meaning	Server behavior
✅ VALID	License is current and all checks pass	Full operation
⚠️ GRACE	License has expired but within the grace period	Full operation — renewal reminder logged
❌ EXPIRED	License has expired and grace period is over	Product modules disabled — infra and common modules still available
🚫 INVALID	License file is missing, tampered, or hostname mismatch	Product modules not loaded

Renewal¶

The license is renewed from the Admin Web UI (administrator with write access to the Licensing page):

Obtain a new license.jwt from the editor, as for the initial license.
Open the Licensing page and expand the Import license card.
Select the license.jwt file (or paste the token). The signature is validated and the new license is previewed (customer, tier, expiry, products, max clients, hostname binding — a red dot means the binding does not match this server's hostname).
Click Import license and confirm the replacement of the current license.
The new license is staged: click Apply & restart in the banner to activate it (see Apply & restart).
After the restart, the Licensing page shows the new expiry date and the VALID status.

Note

Until the restart, the running server keeps the license it loaded (products, client limit).
A token with an invalid signature or without an expiry date is rejected: the current license is left intact.
Renew before the grace period ends to avoid any interruption. If the license is already EXPIRED or INVALID, the Admin Web UI remains available as a recovery console and the same procedure restores the product modules.

RSA Key Rotation¶

When to Rotate¶

Periodically as a security best practice (e.g., annually)
Immediately after a suspected key compromise

Rotation Procedure¶

The RSA key pair is regenerated from the Admin Web UI (administrator with write access to Global settings):

Open Global settings → Authentication tab. In the RSA keys group, click Regenerate keypair and confirm.

The server runs the following steps in order and shows the outcome of each one in a banner:

Step	Action
1. Full-system backup	Backup encrypted with the current key — the pre-rotation state stays recoverable
2. Archive current keypair	Current pair archived in the RSA keys scope of the Backup / Restore page
3. Generate new keypair	New RSA key pair (`AUTH_RSA_KEY_SIZE`, 4096 bits by default)
4. Reissue client tokens	A new JWT token is issued for every client

If a step fails, the ceremony stops: the current key pair is left in place (or archived) and the error is shown. 3. On the Clients page, retrieve the new token of each client with its one-time View credentials button. 4. Click Apply & restart in the banner to activate the new key pair (see Apply & restart). 5. Send the new tokens to the AI agent users.

Impact of Key Rotation¶

Component	Impact
JWT tokens	New tokens issued during the regeneration; the old ones are rejected by the MCP endpoint after the restart
OAuth2 client secrets	Unaffected (bcrypt-based, not RSA-dependent) — clients request a new access token
Backups encrypted before rotation	Decryptable with the archived key (RSA keys scope of the Backup / Restore page)
New backups	Encrypted with the new public key

Redistribute tokens after rotation

From the restart on, JWT clients are rejected until their configuration is updated with the new token: plan the Apply & restart and the token redistribution together. Old tokens are permanently invalid.

Software Integrity Verification¶

Every project file is covered by an SHA-512 manifest (manifest.json) signed with RSA-PSS (RSA-4096), producing manifest.sig.

Automatic Verification¶

At startup: integrity check runs before any module is loaded
Background watchdog: re-runs every 24 hours

Any tampering is logged to both app.log and audit.log with CRITICAL severity.

Manual Verification¶

The integrity state is shown in the Admin Web UI:

Dashboard and System & reload pages — the Integrity indicator gives the result of the last automatic check (Verified, Violation or Not yet checked) and the date of the next one.
Apply configuration changes page — opened with Apply / Restart (card Pending changes / Restart of the System & reload page, even without pending change) or with Apply & restart in the banner. Its Integrity check section verifies every file against the signed manifest when the page opens, then refreshes automatically:
- ✅ Integrity OK — N files match the signed manifest.
- ❌ Integrity FAILED — each affected file is listed as MODIFIED: <path> or MISSING: <path>.

Integrity violation

A violation detected by the background watchdog triggers a graceful shutdown of the server, and a server whose integrity check fails cannot start. Do not restart the server while the Integrity check section reports a failure: reinstall the release files (see Upgrade) or contact the editor.

Show Tech (Support Bundle)¶

Show tech assembles a diagnostic bundle for support submissions. It is generated from the Admin Web UI (administrator with write access to the Logs page):

Open the Logs page → Diagnostics tab.
In the Generate report card, keep or uncheck Include log files (unchecked: smaller bundle, without the logs/ directory), then click Run show-tech and confirm.
The Collection progress card follows the collection (one at a time; it can take a few minutes).
The bundle show_tech_<hostname>_<timestamp>.zip appears in the Show-tech reports list: click Download.

Bundles are stored in <BACKUP_DIR>/show_tech/ and purged automatically after LOGGING_SHOW_TECH_BACKUP_RETENTION days (30 by default, 0 = never); the Auto-delete in column shows the days left. Delete removes a bundle immediately.

What Is Included¶

Item	Included
Server version, Python version, OS info	Yes
`.env` configuration (credentials and secrets redacted)	Yes (IPv4 addresses partially masked)
Pending changes (staged, not applied yet)	Yes (values redacted)
`app.log` and `audit.log`	Yes (unless Include log files is unchecked, IPv4 addresses partially masked)
Manifest verification result	Yes
License state (no license file content)	Yes
Client list (profile, auth mode, token / reveal / last-connection dates)	Yes (no secret content)
Backup directory listing (size, date, SHA-512)	Yes (archive contents never included)
Python dependency versions	Yes

What Is Never Included¶

Sensitive data is never collected

Show tech explicitly excludes the following — they are never present in any support bundle:

RSA private keys
JWT tokens or OAuth client secrets
Encrypted backup archives
Cisco UC credentials (AXL passwords, SSH passwords)
The secrets/license.jwt file

Submitting a Bundle¶

Send the bundle to tolk@sourdeau.com with a description of the issue.