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

# Установка службой ОС

> Установка сервера авторизации Veriqa из архива — юнитом systemd или службой Windows, без Docker и без .NET на машине.

Это тот же отдельный сервер авторизации, что и в
[self-hosted quickstart](/docs/ru/quickstart/self-hosted), только без Docker: архив с
**самодостаточным** исполняемым файлом плюс установщик, который регистрирует его юнитом systemd или
службой Windows. На целевой машине .NET не нужен.

Эта страница — про **установку**: где лежат файлы, как регистрируется служба, как её обновить и
удалить. Что писать в конфигурацию (хранилища, сертификаты, клиенты, каналы) от способа поставки не
зависит и остаётся в [self-hosted quickstart](/docs/ru/quickstart/self-hosted).

<Note>
  **После установщика у вас работающая служба, а не продакшен.** Он пишет стартовую конфигурацию —
  хранилище в памяти и два самоподписанных сертификата токенов, — чтобы служба сразу отвечала на
  `/health/live`, а не отказывалась стартовать. Всё, что делает её продакшен-инстансом, —
  [шаг 6](#6-переход-в-продакшен).
</Note>

## 1. Скачайте архив и проверьте его

В релизе три архива и один файл сумм:

| Файл | Что это |
| - | - |
| `veriqa-authserver-<версия>-linux-x64.tar.gz` | Linux, x86-64 |
| `veriqa-authserver-<версия>-linux-arm64.tar.gz` | Linux, ARM64 |
| `veriqa-authserver-<версия>-win-x64.zip` | Windows, x86-64 |
| `veriqa-authserver-<версия>-SHA256SUMS.txt` | Суммы SHA-256 трёх архивов |

Это ассеты релиза, и база их адреса постоянна — `permalink/latest` всегда указывает на последний
релиз:

```
<репозиторий>/-/releases/permalink/latest/downloads/veriqa-authserver-<версия>-linux-x64.tar.gz
```

Имя файла несёт версию, поэтому адрес целиком постоянной ссылкой **не** является: как только выйдет
следующий релиз, пути с предыдущей версией среди ассетов `permalink/latest` не будет и скачивание
ответит 404. Поэтому адрес репозитория и текущую версию каждый раз берите на
[veriqa.app/source](https://veriqa.app/source), а не сохраняйте готовый URL:

```bash theme={null}
VERIQA_VERSION=0.6.0    # версия релиза, который ставите
VERIQA_DOWNLOADS=…      # …/-/releases/permalink/latest/downloads, с veriqa.app/source

curl -fLO "$VERIQA_DOWNLOADS/veriqa-authserver-$VERIQA_VERSION-linux-x64.tar.gz"
curl -fLO "$VERIQA_DOWNLOADS/veriqa-authserver-$VERIQA_VERSION-SHA256SUMS.txt"

sha256sum --ignore-missing -c "veriqa-authserver-$VERIQA_VERSION-SHA256SUMS.txt"
```

`--ignore-missing` здесь обязателен, если скачан один архив: в файле сумм перечислены все три, и без
флага `sha256sum` падает на двух недостающих.

На Windows:

```powershell theme={null}
$version = "0.6.0"
$expected = (Select-String -Path ".\veriqa-authserver-$version-SHA256SUMS.txt" -Pattern "win-x64\.zip").Line.Split(" ")[0]
(Get-FileHash ".\veriqa-authserver-$version-win-x64.zip" -Algorithm SHA256).Hash -eq $expected
```

`True` — архив целый.

## 2. Установка на Linux

Архив распаковывается в один каталог `veriqa-authserver/` и несёт свой установщик `install.sh`.
Запустите его от root **из этого каталога**:

```bash theme={null}
tar -xzf "veriqa-authserver-$VERIQA_VERSION-linux-x64.tar.gz"
cd veriqa-authserver
sudo ./install.sh
```

Установщик заводит системного пользователя `veriqa` (без оболочки входа, домашний каталог не создаётся),
копирует программу, создаёт каталоги конфигурации и данных, генерирует сертификаты токенов, пишет
стартовую конфигурацию, кладёт unit-файл и включает службу. Запускать её он **не** запускает:
стартовую конфигурацию нужно прочитать до первого старта, а не после.

| Параметр | По умолчанию | Что задаёт |
| - | - | - |
| `--install-directory <path>` | `/opt/veriqa` | Каталог программы |
| `--config-directory <path>` | `/etc/veriqa` | Каталог конфигурации |
| `--urls <urls>` | `http://127.0.0.1:8080` | Адреса, на которых слушает служба |
| `--service-name <name>` | `veriqa` | Имя юнита systemd |

<Note>
  **Каталог программы принадлежит только этой установке.** Оба установщика пишут в него, ничего
  предварительно не расчищая: файл из архива перезаписывает свой аналог, всё остальное остаётся на
  месте — и удаление зеркально: `--uninstall` / `-Uninstall` забирает ровно те файлы, которые
  установщик скопировал, и больше ничего, а сам каталог оставляет, если в нём осталось что-то ещё.
  Укажите в `--install-directory` / `-InstallDirectory` отдельный каталог — тогда установка снимается
  одним шагом.
</Note>

Умолчание `--urls` — **только loopback**: инстанс доступен с этой же машины и с reverse-proxy на
ней, и больше ниоткуда.

<Warning>
  **TLS нужен самому API, а не только чтобы открыть инстанс наружу.** По обычному HTTP эндпоинт
  токена отвечает `400 invalid_request` — «This server only accepts HTTPS requests»
  ([ID2083](https://documentation.openiddict.com/errors/ID2083)), — поэтому бэкенд, вызывающий API
  подтверждений, не получит токена даже с этой же машины. Сделайте [шаг 7](#7-https) до первого
  вызова: поставьте перед хостом reverse-proxy или дайте Kestrel сертификат.
</Warning>

Запускайте службу, прочитав то, что напечатал установщик:

```bash theme={null}
sudo systemctl start veriqa
systemctl status veriqa
```

<Warning>
  Установщик отказывается работать поверх уже зарегистрированной службы с тем же именем
  (`use --uninstall first`), а не пересоздаёт её молча. Обновление существующей установки —
  [Обновление](#обновление).
</Warning>

## 3. Установка на Windows

Распакуйте `.zip` и запустите `install.ps1` из распакованного каталога в PowerShell **от
администратора** (работает и Windows PowerShell 5.1, и PowerShell 7):

```powershell theme={null}
Expand-Archive ".\veriqa-authserver-$version-win-x64.zip" -DestinationPath .
cd .\veriqa-authserver
.\install.ps1
```

| Параметр | По умолчанию | Что задаёт |
| - | - | - |
| `-InstallDirectory <path>` | `%ProgramFiles%\Veriqa` | Каталог программы |
| `-Urls <urls>` | `http://127.0.0.1:8080` | Адреса, на которых слушает служба |
| `-ServiceName <name>` | `Veriqa` | Имя службы Windows |

Служба регистрируется с автозапуском под виртуальной учётной записью `NT SERVICE\<ServiceName>` —
своя учётная запись и пароль не нужны. Каталог конфигурации — `%ProgramData%\Veriqa`; его список
доступа строится заново, без наследования, поэтому группа `Users` к лежащим там секретам доступа не
получает. Как и на Linux, служба зарегистрирована, но не запущена:

```powershell theme={null}
Start-Service Veriqa
Get-Service Veriqa
```

## 4. Что даёт первый запуск

Установка сознательно доведена ровно до состояния «стартует», и не дальше:

* хранилище OpenIddict — `InMemory`: зарегистрированные клиенты, выданные токены и журнал
  **теряются при каждом рестарте**;
* сертификаты токенов самоподписанные, RSA-2048, сроком на два года, сгенерированы на этой машине;
* ни один канал и ни один OIDC-клиент не настроены, поэтому настоящий вход пока не завершится.

Оба эндпоинта здоровья в этом состоянии отвечают 200:

```bash theme={null}
curl -f http://127.0.0.1:8080/health/live
curl -f http://127.0.0.1:8080/health/ready
```

`/health/ready` отвечает 200 потому, что стартовая конфигурация не объявляет ни одной внешней
зависимости для проверки, — а не потому, что инстанс готов к продакшену.

## 5. Где что лежит

Конфигурация, ключи Data Protection и сертификаты токенов живут **вне** каталога программы, чтобы её
замена их не трогала.

| Что | Linux | Windows |
| - | - | - |
| Программа | `/opt/veriqa` | `%ProgramFiles%\Veriqa` |
| Конфигурация | `/etc/veriqa/appsettings.Production.json` | `%ProgramData%\Veriqa\appsettings.Production.json` |
| Шаблон продакшен-конфигурации | `/opt/veriqa/appsettings.Production.sample.json` | `%ProgramFiles%\Veriqa\appsettings.Production.sample.json` |
| Ключи Data Protection | `/var/lib/veriqa/keys` | `%ProgramData%\Veriqa\keys` |
| Сертификаты токенов | `/var/lib/veriqa/certs` | `%ProgramData%\Veriqa\certs` |
| Описание службы | `/etc/systemd/system/veriqa.service` | Ключ реестра службы `Veriqa` |

На Linux `/etc/veriqa` — `root:veriqa` `0750`, а `/var/lib/veriqa` — `0700` с владельцем `veriqa`: там
секреты, и читает их только учётная запись службы.

**Почему каталог ключей не опционален.** Ключи Data Protection защищают cookie входа и всё, что хост
шифрует. Без каталога ключей и без Redis хост держит их в памяти, и каждый рестарт делает
недействительным выданное предыдущим процессом — пользователей выбрасывает из начатых входов. Поэтому
установщик задаёт `Veriqa:DataProtection:KeysDirectory` в окружении самой службы, а каталог переживает
и обновление, и обычное удаление.

Служба регистрируется с четырьмя переменными окружения — им место именно в окружении, потому что они
говорят, откуда читается конфигурация:

| Переменная | Linux | Windows |
| - | - | - |
| `ASPNETCORE_ENVIRONMENT` | `Production` | `Production` |
| `ASPNETCORE_URLS` | значение `--urls` | значение `-Urls` |
| `VERIQA_CONFIG_DIRECTORY` | `/etc/veriqa` | `%ProgramData%\Veriqa` |
| `Veriqa__DataProtection__KeysDirectory` | `/var/lib/veriqa/keys` | `%ProgramData%\Veriqa\keys` |

### Каталог конфигурации

`VERIQA_CONFIG_DIRECTORY` называет каталог, а не файл. Из него хост читает `appsettings.json` и
`appsettings.Production.json` — оба необязательные — и накладывает их **поверх** файлов, поставляемых
с программой. Порядок источников, от слабого к сильному:

1. `appsettings.json` каталога программы;
2. `appsettings.Production.json` каталога программы;
3. `appsettings.json` каталога конфигурации;
4. `appsettings.Production.json` каталога конфигурации;
5. переменные окружения (`Veriqa__OpenIddict__…`);
6. аргументы командной строки.

Поэтому единственная строка, которую пишет установщик, — `Provider` = `InMemory` — побеждает
`Provider` = `PostgreSQL` из каталога программы, а всё, что передано через окружение, по-прежнему
побеждает оба файла.

Если переменная называет несуществующий каталог, хост не стартует и говорит об этом:
`VERIQA_CONFIG_DIRECTORY points to '/etc/veriqa', which does not exist.` Существующий каталог без
файлов ошибкой не является.

<Note>
  В self-hosted quickstart собственные настройки интегратора лежат в `config/veriqa.json`, который
  ищется относительно корня контента. У службы корень контента — каталог **программы**, а его
  заменяет обновление, поэтому в этом способе поставки кладите свои настройки в каталог конфигурации.
</Note>

## 6. Переход в продакшен

Рядом с программой установка кладёт шаблон `appsettings.Production.sample.json`. В нём те же ключи,
что в self-hosted quickstart, со значениями-плейсхолдерами `REPLACE_ME`. Используйте его как
**образец** и правьте файл, написанный установщиком, а не затирайте этот файл шаблоном: в шаблоне нет
путей к сертификатам, сгенерированным на этой машине, а каждый `REPLACE_ME` в нём — значение, которое
вам ещё предстоит задать.

```bash theme={null}
sudo cp /etc/veriqa/appsettings.Production.json /root/appsettings.Production.json.bak
sudo nano /etc/veriqa/appsettings.Production.json   # образец: /opt/veriqa/appsettings.Production.sample.json
sudo systemctl restart veriqa
```

Копию кладите **вне** `/etc/veriqa`: начиная с правки ниже в ней лежат секреты — токен бота, строки
подключения, пароли сертификатов, — а [полное удаление](#удаление) её на Linux не заберёт, на
Windows же, наоборот, не пощадит: `%ProgramData%\Veriqa` уходит целиком.

Что именно туда писать, описано один раз, для обоих способов поставки:

* **хранилища** — реляционный провайдер со строкой подключения и сток аудита:
  [self-hosted, шаг 2](/docs/ru/quickstart/self-hosted#2-настройте-его);
* **сертификаты токенов** — настоящие вместо самоподписанной пары от установщика:
  [self-hosted, шаг 3](/docs/ru/quickstart/self-hosted#3-предоставьте-сертификаты-токенов);
* **OIDC-клиенты** — [self-hosted, шаг 4](/docs/ru/quickstart/self-hosted#4-объявите-свой-клиент);
* **каналы** — [self-hosted, шаг 7](/docs/ru/quickstart/self-hosted#7-включите-каналы) и
  [Настройка каналов](/docs/ru/guides/channels) от начала до конца.

<Warning>
  Замена сертификатов токенов делает недействительными все токены, подписанные старой парой, а
  переключение хранилища с `InMemory` на базу начинает с пустой: клиенты, зарегистрированные в памяти,
  придётся объявить в конфигурации. Сделайте и то и другое до того, как через инстанс пойдут реальные
  входы.
</Warning>

### SQL Server на Windows

В архиве для Windows нет `Microsoft.Data.SqlClient.SNI.dll` — нативной сетевой библиотеки, через которую
драйвер SQL Server работает на Windows: она принадлежит Microsoft, распространяется по Microsoft
Software License Terms, и Veriqa её не распространяет. PostgreSQL она не нужна, Linux — тоже. Если
для какого-либо хранилища выбран `SqlServer`, а библиотеки нет, служба не стартует, а сообщение
называет версию `Microsoft.Data.SqlClient` и даёт ссылку на её страницу на nuget.org.

Возьмите библиотеку из NuGet-пакета `Microsoft.Data.SqlClient.SNI.runtime` — в версии, указанной на
этой странице в разделе **Dependencies**, — и положите рядом с программой. Скачивая её, вы принимаете
условия Microsoft:

```powershell theme={null}
$sniVersion = "…"   # из Dependencies пакета Microsoft.Data.SqlClient на nuget.org
$package = "microsoft.data.sqlclient.sni.runtime"
Invoke-WebRequest "https://api.nuget.org/v3-flatcontainer/$package/$sniVersion/$package.$sniVersion.nupkg" -OutFile "$env:TEMP\sni.zip"
Expand-Archive "$env:TEMP\sni.zip" -DestinationPath "$env:TEMP\sni" -Force
Copy-Item "$env:TEMP\sni\runtimes\win-x64\native\Microsoft.Data.SqlClient.SNI.dll" "$env:ProgramFiles\Veriqa\"
Restart-Service Veriqa
```

Установщик удаляет из каталога программы только те файлы, которые положил сам, поэтому библиотека
переживает [обновление](#обновление); после него сверьте, что драйвер нового релиза указывает ту же
версию, которую вы скопировали. При [полном удалении](#удаление) удалите её вручную.

## 7. HTTPS

Хост говорит по HTTP на адресах из `--urls` / `-Urls`, а OpenIddict отдаёт `/connect/token` и
остальной протокол **только по `https`**, поэтому шаг не факультативный, открыт инстанс наружу или
нет. Поставить перед ним TLS можно двумя путями.

**(а) Reverse-proxy на той же машине.** Оставьте `--urls` равным `http://127.0.0.1:8080`,
терминируйте TLS в NGINX / Caddy / IIS и проксируйте на loopback. Чтобы OpenIddict строил `https`-URL,
proxy должен передавать `X-Forwarded-Proto` и `X-Forwarded-For`, а самому proxy нужно доверять — та же
секция `ForwardedHeaders`, что в
[self-hosted, шаг 6](/docs/ru/quickstart/self-hosted#6-поставьте-за-reverse-proxy), в файле конфигурации
установки:

```json appsettings.Production.json theme={null}
{
  "ForwardedHeaders": {
    "KnownProxies": [ "127.0.0.1" ]
  }
}
```

По умолчанию доверие есть только к loopback, так что proxy на той же машине покрыт и без этой секции —
явная запись делает границу доверия видимой прямо в конфигурации. Proxy на **другом** хосте не покрыт:
впишите сюда его адрес или его сеть в `KnownIPNetworks`. На proxy же лежит и ограничение частоты по
IP — см. [Продакшн-харденинг](/docs/ru/guides/hardening#rate-limiting-и-anti-abuse).

**(б) Сертификат прямо в Kestrel**, без proxy вообще. Это обычная конфигурация ASP.NET Core в том же
файле ([Kestrel endpoints](https://learn.microsoft.com/aspnet/core/fundamentals/servers/kestrel/endpoints)):

```json appsettings.Production.json theme={null}
{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://0.0.0.0:8443",
        "Certificate": {
          "Path": "/var/lib/veriqa/certs/server.pfx",
          "Password": "…"
        }
      }
    }
  }
}
```

Секция `Kestrel:Endpoints` **заменяет** адреса из `ASPNETCORE_URLS`, а не добавляется к ним, поэтому
переустановка не нужна — но HTTP-эндпоинт, заданный установщиком через `--urls`, вместе с этим
пропадает. Если он всё ещё нужен (например, для локальных проб здоровья), объявите рядом эндпоинт
`Http`. Серверный сертификат держите читаемым только учётной записью службы, рядом с сертификатами
токенов.

## 8. Проверка

```bash theme={null}
curl -f http://127.0.0.1:8080/health/live     # процесс поднят
curl -f http://127.0.0.1:8080/health/ready    # настроенные зависимости отвечают
curl https://auth.your-domain.com/.well-known/openid-configuration
```

Discovery должен вернуться с `https`-URL; если вернулся с `http` — proxy не в доверенных,
[шаг 7](#7-https). Полный чек-лист развёрнутого инстанса, включая первый вход, —
[self-hosted, шаг 8](/docs/ru/quickstart/self-hosted#8-проверьте).

На Linux лог службы — в журнале:

```bash theme={null}
journalctl -u veriqa -n 200 --no-pager
```

На Windows неудачный старт фиксирует Service Control Manager в «Просмотре событий» → «Журналы
Windows». Чтобы увидеть сообщение самого хоста, запустите исполняемый файл в консоли **из каталога
программы**, с тем же окружением:

```powershell theme={null}
$env:ASPNETCORE_ENVIRONMENT = "Production"
$env:VERIQA_CONFIG_DIRECTORY = "$env:ProgramData\Veriqa"
# При запуске руками корень контента — рабочий каталог: `appsettings*.json` и `wwwroot` читаются
# из него, поэтому перейдите в каталог программы, а не запускайте по полному пути.
Set-Location "$env:ProgramFiles\Veriqa"
.\Veriqa.Core.AuthServer.Host.exe
```

## Обновление

Обновление заменяет **программу** и сохраняет конфигурацию, ключи Data Protection и сертификаты
токенов: они специально живут вне каталога программы.

```bash theme={null}
sudo ./install.sh --uninstall          # из распакованного архива установленной версии
tar -xzf "veriqa-authserver-$VERIQA_VERSION-linux-x64.tar.gz"   # новая версия
cd veriqa-authserver && sudo ./install.sh
sudo systemctl start veriqa
```

На Windows те же два шага: `.\install.ps1 -Uninstall` из распакованного архива установленной версии,
затем `.\install.ps1` из нового архива и `Start-Service Veriqa`.

Повторный запуск не перезаписывает существующий `appsettings.Production.json` и не перегенерирует
существующие сертификаты — он сообщает, что оставил их. Если вы ставили с нестандартными
`--service-name`, `--install-directory` или `--config-directory`, передайте те же значения обоим
запускам.

`--urls` / `-Urls` устанавливающему запуску нужно повторить тоже, и по другой причине: это значение
нигде не хранится, прочитать его установщику неоткуда. Юнит-файл — на Windows окружение службы —
пишется заново при каждой установке, поэтому установка без него возвращает службе адрес по умолчанию
`http://127.0.0.1:8080`, и экземпляр перестаёт отвечать где-либо, кроме loopback.

## Удаление

**Обычное удаление** убирает службу и программу и **сохраняет** конфигурацию, ключи Data Protection и
сертификаты, чтобы установка поверх них сохранила текущие входы и секреты:

```bash theme={null}
sudo ./install.sh --uninstall
```

```powershell theme={null}
.\install.ps1 -Uninstall
```

Запускать нужно **из распакованного архива установленной версии**: по этому архиву установщик и
определяет, какие файлы в каталоге программы его собственные, — их он и забирает. Каталог программы
уходит вместе с ними, если после этого он пуст; если в нём осталось что-то ещё, каталог сохраняется,
и установщик об этом сообщает, а не расчищает его. Без архива рядом установщик снимает службу и
предупреждает, что файлы программы отличить не смог, — угадывать он не станет.

**Полное удаление** дополнительно сносит написанную установщиком конфигурацию, каталог данных и
(на Linux) пользователя `veriqa`:

```bash theme={null}
sudo ./install.sh --uninstall --remove-data
```

```powershell theme={null}
.\install.ps1 -Uninstall -RemoveData
```

<Warning>
  Полное удаление делает **недействительными все выданные cookie** — ключи Data Protection уходят
  вместе с каталогом, — а токены, подписанные удалёнными сертификатами, перестают приниматься.
  Сохраните копию `/etc/veriqa/appsettings.Production.json` (или
  `%ProgramData%\Veriqa\appsettings.Production.json`), если эта установка ещё вернётся, — и
  **храните её вне этих каталогов**: копия рядом с конфигурацией бэкапом не является. На Windows
  она уйдёт вместе с `%ProgramData%\Veriqa`, а на Linux останется лежать вместе с секретами:
  каталог сохраняется, а установщик не называет, что в нём осталось.
</Warning>

На Linux `/var/lib/veriqa` уходит целиком, а `/etc/veriqa` теряет написанный установщиком
`appsettings.Production.json` и удаляется только тогда, когда в нём ничего не осталось. На Windows
все три вещи лежат в `%ProgramData%\Veriqa`, и он уходит целиком.

`--remove-data` / `-RemoveData` без ключа удаления отклоняется, и ничего не меняется. Удалять дважды
безопасно: службы уже нет, установщик сообщает об этом и забирает то, что осталось от установки.

## Типичные отказы

| Симптом | Причина | Что делать |
| - | - | - |
| Бэкенд получает от `/connect/token` `400 invalid_request`, «This server only accepts HTTPS requests» | Обращение идёт по обычному HTTP: OpenIddict отдаёт протокол только по `https` | Поставьте перед хостом TLS или сделайте proxy доверенным, чтобы читался `X-Forwarded-Proto`, — [шаг 7](#7-https) |
| Windows: служба не стартует, в логе — `Microsoft.Data.SqlClient.SNI.dll` не найдена | Для хранилища выбран `SqlServer`, а нативную библиотеку Microsoft для него архив не везёт | Положите библиотеку рядом с программой — [SQL Server на Windows](#sql-server-на-windows) |
| После рестарта пропали зарегистрированные клиенты и выданные токены | Стартовая конфигурация осталась как есть: `Veriqa:OpenIddict:Database:Provider` = `InMemory` — это энергозависимое хранилище | Перейти на реляционный провайдер — [шаг 6](#6-переход-в-продакшен) и [self-hosted, шаг 2](/docs/ru/quickstart/self-hosted#2-настройте-его) |
| Служба активна, но каждый рестарт выбрасывает пользователей из входов | Хост держит ключи Data Protection в памяти: `Veriqa:DataProtection:KeysDirectory` не действует (окружение службы правили или хост запущен не под менеджером служб) | Проверить четыре переменные из [шага 5](#5-где-что-лежит); на Linux — `systemctl show veriqa -p Environment` |
| Страница входа показывает тексты без переводов | Корень контента — не каталог программы. Под менеджером служб он им всегда является; при запуске руками из другого каталога это рабочий каталог, а `wwwroot/locales` читается относительно корня контента | Запускать службу через `systemctl` / `Start-Service` либо сначала перейти в каталог программы |
| Discovery отдаёт `http`-URL, `/connect/authorize` отвечает `invalid_request` | Proxy не в доверенных, `X-Forwarded-Proto` игнорируется | Добавить proxy в `ForwardedHeaders:KnownProxies` — [шаг 7](#7-https) |
| После обновления экземпляр отвечает только на loopback, хотя служба активна | Устанавливающий запуск сделан без `--urls` / `-Urls`: юнит-файл (на Windows — окружение службы) записан заново с адресом по умолчанию `http://127.0.0.1:8080` | Переустановите с нужным адресом: `./install.sh --uninstall`, затем `./install.sh --urls <адреса>` из архива — [Обновление](#обновление) |
| `Access denied` к каталогу ключей | Каталог создан не учётной записью службы — руками от root или под другим `--service-name` / `-ServiceName`, которому на Windows соответствует другая виртуальная учётная запись | Linux: `chown -R veriqa:veriqa /var/lib/veriqa`. Windows: `.\install.ps1 -Uninstall -ServiceName <имя>`, затем `.\install.ps1 -ServiceName <имя>` из архива — обоим запускам нужно то имя, под которым ставили службу (и тот же `-InstallDirectory`, если установка шла с ним), иначе они сработают по службе `Veriqa` и каталогу `%ProgramFiles%\Veriqa` по умолчанию. Переустановка строит списки доступа заново и сохраняет конфигурацию, ключи и сертификаты (поверх зарегистрированной службы установщик не запускается) |

Отказы, которые роняют хост **на старте** — нет сертификата, неполный клиент, канал без токена,
неизвестное значение провайдера, — одинаковы в обоих способах поставки и перечислены в
[self-hosted, шаг 9](/docs/ru/quickstart/self-hosted#9-типичные-ошибки-первого-запуска). На Linux сообщение
лежит в `journalctl -u veriqa`.

## Сборка архивов из исходников

Для релизных архивов в репозитории есть пара скриптов с одинаковым поведением —
`build/publish-host.sh` и `build/publish-host.ps1`:

```bash theme={null}
./build/publish-host.sh                      # все три RID, Release
./build/publish-host.sh --rid linux-x64      # один из них
```

Они публикуют хост self-contained и однофайловым для `linux-x64`, `linux-arm64` и `win-x64`,
упаковывают каждый результат вместе с файлами установки его ОС и кладут архивы и
`veriqa-authserver-<версия>-SHA256SUMS.txt` в `artifacts/host/`. Версия берётся из
`build/Versions.props`. На выходе — ровно то, что ставится по этой странице: та же раскладка, тот же
`appsettings.Production.sample.json` и никакого `appsettings.Development.json`.

## Дальше

<CardGroup cols={2}>
  <Card title="Self-hosted quickstart" icon="server" href="/docs/ru/quickstart/self-hosted">
    Хранилища, сертификаты, клиенты и каналы — сама конфигурация.
  </Card>

  <Card title="Настройка каналов" icon="comments" href="/docs/ru/guides/channels">
    MAX, Telegram, WhatsApp, другие мессенджеры и Email — от начала до конца.
  </Card>

  <Card title="Справочник конфигурации" icon="list" href="/docs/ru/reference/configuration">
    Каждая секция, ключ и дефолт в одном месте.
  </Card>

  <Card title="Продакшн-харденинг" icon="shield-check" href="/docs/ru/guides/hardening">
    Что проверить перед выкаткой.
  </Card>
</CardGroup>


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