> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations

> Feature toggles, webhooks, sign-in recovery, the license, logs and certificates on a running installation

Once the installation runs, Command Center and its [API](https://docs.2501.ai/0.19/api/overview.md) handle most changes. The commands below use the namespace in `$NS` and, on Docker Swarm, the stack name in `$STACK`: the name you deploy the stack with, `ai-2501` in [Deploy](https://docs.2501.ai/0.19/deployment/docker-swarm.md#deploy), or the CLI's stack name for an installation [moved from the CLI](https://docs.2501.ai/0.19/deployment/migrate-from-cli.md).

## Feature toggles

Toggles switch optional and experimental behaviors for the whole installation. You change them in the database, then restart the engine: see [Feature Toggles](https://docs.2501.ai/0.19/deployment/feature-toggles.md), which lists them and gives the SQL. The first run of a new installation sets two of them from `values.yaml`: satellite clusters from `features.satellites`, and Elasticsearch logging when `elasticsearch.mode` is not `none`.

## Webhooks

A ticketing system notifies 2501 through a webhook. Create, list and delete them through the API (`/api/v1/webhooks`). Creating one returns its secret once. For ServiceNow, it also returns the Business Rule to add to your instance, which you send to your instance's Table API with a ServiceNow account allowed to create Business Rules. Or send that account in the create request as `servicenow_admin`, and 2501 creates the Business Rule itself: it uses the account for that request only and stores it nowhere. See [Webhooks](https://docs.2501.ai/0.19/configure/webhooks.md).

## Sign-in recovery

When no administrator can sign in, for example because single sign-on is broken or an authenticator is lost, run the `2501` command in the engine container (not the 2501 CLI). It needs access to the cluster or the Swarm, not to Command Center.

```bash theme={null}
# Let a tenant-level administrator sign in with their password again on a tenant that is on single sign-on only
kubectl -n "$NS" exec deploy/engine -- 2501 sso-exempt admin@example.com
# Give that administrator a password, when they have none
read -rs PASSWORD
printf %s "$PASSWORD" | kubectl -n "$NS" exec -i deploy/engine -- 2501 set-password admin@example.com
# Clear a user's two-factor authentication
kubectl -n "$NS" exec deploy/engine -- 2501 reset-two-factor user@example.com
```

On Docker Swarm, run it on the node that runs the engine, through the loader that reads the engine's secrets (the last lines of the `compose.yaml` header show the same):

```bash theme={null}
engine=$(docker ps -q -f "label=com.docker.swarm.service.name=${STACK}_engine")
docker exec "$engine" sh /tmp/2501-LOAD_SECRET_FILES 2501 sso-exempt admin@example.com
read -rs PASSWORD
printf %s "$PASSWORD" | docker exec -i "$engine" sh /tmp/2501-LOAD_SECRET_FILES 2501 set-password admin@example.com
```

Use `sso-exempt` when single sign-on is broken: the administrator then signs in with their password, and their two-factor authentication if they have one. An administrator who only ever signed in through single sign-on has no password, and `sso-exempt` says so: give them one with `set-password`, which reads it from its input, never from the command line. `read -rs` takes it without showing it or writing it to the shell history. `set-password` only sets a first password, on an exempted administrator, and signs out their other sessions; an existing password is changed in Command Center.

Use `reset-two-factor` when someone has lost their authenticator. Only an active tenant-level administrator can be exempted from single sign-on, and `reset-two-factor` refuses an exempted account, which is a recovery account: lift its exemption on the Command Center Users page first. So do not run the two one after the other on the same administrator. Resetting two-factor authentication signs every device out of that account.

## License

Apply the license token 2501 issues in Command Center, under **Settings > License**. An expired license does not block that page. The key licenses are checked with ships with the chart. See [Licensing & Usage](https://docs.2501.ai/0.19/configure/licensing.md).

## Logs

The commands, and how to export logs for a bug report, are in [Troubleshooting](https://docs.2501.ai/0.19/deployment/troubleshooting.md#viewing-logs).

## Certificates

The engine serves plain HTTP unless you turned on [HTTPS to the engine](https://docs.2501.ai/0.19/deployment/kubernetes.md#https-to-the-engine). Then the engine and Command Center read its certificate when they start.

* **Kubernetes**: replace the secret (`kubectl create secret tls ... --dry-run=client -o yaml | kubectl apply -f -`), then restart both with `kubectl rollout restart deploy/engine deploy/command-center`.
* **Docker Swarm**: create the renewed certificate under new secret names, change them in your `site.yaml` (or in `engine.tls.existingSecret`, with a `values.yaml`), and deploy again.

## Settings outside the chart

Everything the installation runs with comes from your settings (your `values.yaml` on Kubernetes and OpenShift, your `.env` on Docker Swarm) and its secrets. Engine settings the chart does not set go in `engine.extraEnv`, or in the `engine-extra-env` Secret on Kubernetes: see [Engine settings the chart does not set](https://docs.2501.ai/0.19/deployment/kubernetes.md#engine-settings-the-chart-does-not-set). After a change to `values.yaml` or `.env`, apply the same build again.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.