---
title: "Operação"
description: "A operação do dia a dia de um TrustBridge implantado: o que monitorar, o que ler nos logs, como se comportam os reinícios, as atualizações e a ordem de atualização entre Servidor e estações de trabalho, a atualização da frota pelo Servidor e a manutenção recorrente necessária."
canonical: "https://docs.lacunasoftware.com/articles/trustbridge/operations"
locale: "pt-BR"
product: "TrustBridge"
last_updated: "2026-10-13"
---

# Operação

A operação do dia a dia de um TrustBridge implantado: o que monitorar, o que ler nos logs, como um
reinício e uma atualização se comportam, como manter a frota numa versão que o Servidor aceita e a
manutenção recorrente que uma implantação exige.

## Saúde e monitoramento

| Probe | O que comprova | Para que usar |
|---|---|---|
| `GET /healthz` | Uma ida e volta ao SQL. `Healthy` (200) ou `Unhealthy` (503), e nada mais no corpo. Anônimo, não auditado. | Monitoramento de disponibilidade e alertas. Um 503 é um container no ar com um banco de dados fora do ar. |
| `GET /` | O container está vivo. Responde 200 mesmo sem o banco de dados. | Um gatilho de reinício, onde a plataforma tiver um (o Health check do App Service). |
| Entrar em `/admin` | O caminho que uma requisição real percorre, passando pelo banco de dados. | A verificação depois de toda implantação e atualização. |

O `/healthz` **não** informa nada sobre a frota: um Servidor sem nenhuma estação de trabalho conectada
está `Healthy`. A presença de uma máquina é assunto da tela da frota.

**O Servidor inicia e continua no ar com o banco de dados inacessível depois da inicialização**, para
que uma instabilidade momentânea do banco não vire uma indisponibilidade que uma pessoa precise
resolver. Enquanto o banco de dados está fora, a porta de entrada responde 200, o contrato falha e o
cofre fica fechado. Crie alertas sobre o `/healthz`, não sobre o container.

Como o Servidor aplica o próprio schema na inicialização, um container em execução já comprovou que
acessou o SQL pelo menos uma vez; um banco de dados inacessível **na** inicialização resulta numa
inicialização recusada depois de cerca de noventa segundos.

### O que o console administrativo informa

- **A faixa de status**, no topo de toda página administrativa, conta as estações de trabalho
  conectadas, as máquinas cujo protocolo o Servidor não aceita mais (*N exigem atualização*), as
  sessões ativas, as assinaturas e as falhas das últimas 24 horas e os certificados que vencem em 30
  dias. Cada chip abre a tela que resume. **N falhas (24 h)** abre a Trilha de Auditoria filtrada nas
  falhas desde o momento em que a contagem começou; é o caminho mais curto entre "algo está errado" e
  as linhas que dizem o quê.
- **Um banner em todas as páginas administrativas** significa uma de três coisas: a licença da PKI do
  Servidor foi recusada, então nada na frota nem no cofre consegue assinar
  ([renove-a](https://docs.lacunasoftware.com/articles/trustbridge/operations#renovação-da-licença-do-pki-sdk)); as gravações de auditoria estão caindo para o Log do
  Servidor; ou as ACs de teste da Lacuna são confiáveis.
- **Por que uma estação de trabalho se desconectou** está na linha `workstation.disconnect` dela, e ao
  lado de cada desconexão no painel da máquina na tela da frota: `timed-out` (o Servidor deixou de
  ouvi-la; veja [`Workstations:ClientTimeout`](https://docs.lacunasoftware.com/articles/trustbridge/configuration#workstationsclienttimeout)), `closed`,
  `revoked`, `returned-to-queue`, `server-stopping` ou `error`, com o transporte que ela usava. Um
  `closed` em `LongPolling` também pode ser uma máquina que ficou em silêncio: o long polling não sofre
  timeout, e um proxy que não transporta WebSockets é o motivo mais comum para uma máquina estar nele.

### Avisos que merecem um alerta

| Linha do Log do Servidor, em `Warning` | O que significa |
|---|---|
| `Workstation … holds a candidate certificate for this session but is connected at protocol 4 …` | Uma máquina ainda no Workstation 1.4.x foi ignorada na criação de uma sessão. Ela conta como offline até rodar a 1.5.0. Veja [Ordem de atualização](https://docs.lacunasoftware.com/articles/trustbridge/operations#ordem-de-atualização-primeiro-o-servidor-depois-a-frota). |
| `Workstation … has given N PIN Proof(s) for CPF … that did not check …` | Uma máquina esgotou o seu limite de provas com falha para um titular (`Sessions:MaxPinFailures` dentro de `Sessions:PinFailureWindow`). Nada é pedido a ela para esse CPF até as falhas saírem da janela. Registrado na auditoria como `pin.proof-budget-spent`. |
| `The Certificate Vault has tried N password(s) for CPF … that opened nothing …` | O mesmo limite, esgotado pelo cofre. Também registrado como `pin.proof-budget-spent`, com *Certificate Vault* como nome do titular. |
| `Passwords are switched off on this Server's admin console …` | Registrado em toda inicialização enquanto `Admin:CertificateSignIn:Required` está ligado. Conta as contas habilitadas sem CPF vinculado e quantas delas são de Administradores. **Quando esse número chega ao número de Administradores habilitados, ninguém consegue administrar a plataforma.** |
| `Forwarded headers: honoured from whoever connects …, and this Server is not on App Service` | Uma implantação Docker que ainda usa `ASPNETCORE_FORWARDEDHEADERS_ENABLED`. Cite o proxy em [`ForwardedHeaders:TrustedProxies`](https://docs.lacunasoftware.com/articles/trustbridge/configuration#forwardedheaderstrustedproxies) e remova a variável. |
| `… pings every 00:00:15, but Workstations:ClientTimeout is …` | Uma máquina envia pings com menos frequência do que o timeout permite, então é desconectada e se reconecta sem parar. |

Um limite esgotado não é o bloqueio de PIN do titular: um PIN errado custa à própria máquina do
titular uma prova com falha por certificado dele que ela guarda, então uma máquina pode ser ignorada
antes de o bloqueio disparar. Os dois se resolvem conforme as falhas saem da janela.

### A trava do cofre

Num Servidor com `Vault:Enabled`, as verificações de inicialização do cofre leem o banco de dados.
Quando o Servidor sobe antes de o banco de dados responder, o cofre **fica travado fechado**, em vez de
o host recusar a inicialização:

```text
warn: TrustBridge.Server.Common.Vault.VaultReadiness[0]
      The Certificate Vault is on, but its start-time checks could not read the database, so the
      vault is closed until they have run. Nothing will be signed with a certificate this Server
      holds and nothing new will be imported until then; the checks are retried at the first
      attempt to use it (ADR-0024 §8).
```

Um cofre fechado é um Servidor com aparência saudável que recusa toda assinatura com um certificado
guardado no servidor e toda importação, enquanto o nível das estações de trabalho funciona
normalmente. As verificações são repetidas na primeira tentativa de usar o cofre, e um banco de dados
que voltou as conclui com o cofre aberto. O que um cofre fechado nunca pode fazer é gerar uma chave
nova, o que deixaria órfão tudo o que está armazenado: é por isso que a trava existe.

## Leitura dos logs

**A saída do console é o registro.** Envie-a para um lugar com a retenção que você escolheu: o logging
driver do container no Docker, o Application Insights ou um workspace do Log Analytics no App Service.
O arquivo rotativo em `/tmp/trustbridge-logs` alimenta a tela **Log do Servidor** do console
administrativo e é uma conveniência, não uma cópia a guardar.

Estas categorias trazem as linhas que um operador deve reconhecer, todas visíveis no nível padrão:

| Linha | Categoria | Quando |
|---|---|---|
| Quais migrações foram aplicadas, ou por que o schema foi recusado | `…Persistence.SchemaUpgrade` | Toda inicialização |
| Qual Protetor do Chaveiro está selando, o thumbprint dele e quantos aposentados estão legíveis | `…KeyRings.KeyRingPosture` | Toda inicialização |
| Se o cofre está desligado, aberto ou travado fechado | `…Vault.VaultReadiness` | Toda inicialização, e quando a trava se abre |
| Em quais proxies reversos o Servidor confia para o endereço de quem chama, numa linha que começa com `Forwarded headers:` | `…Http.TrustedProxies` | Toda inicialização |
| Quantas contas não têm CPF vinculado enquanto as senhas estão desligadas | `…Admin.CertificateSignInPosture`, em `Warning` | Toda inicialização com `Admin:CertificateSignIn:Required` ligado |
| Uma linha de auditoria não conseguiu chegar ao banco de dados, **com a própria linha** | `…Audit.AuditLog`, em `Critical` | Sempre que o banco de dados recusa uma gravação |
| A licença do PKI SDK foi recusada: vencida, corrompida ou não é uma licença | `TrustBridge.Pki.Validation.LacunaPkiRuntime`, em `Critical` | Toda inicialização, com ou sem cofre, e quando uma licença vence com o Servidor em execução |
| Os overrides do Administrador não puderam ser relidos depois da etapa do schema | `…Persistence.SchemaGate` | Uma inicialização em que a tabela de configurações não respondeu |
| Uma máquina ignorada na criação de uma sessão: no protocolo 4, ou com o limite de provas com falha esgotado | `…Sessions.CreateSession.Handler`, em `Warning` | Sempre que acontece |

Toda resposta HTTP traz um `X-Correlation-Id`, e toda linha de log gravada durante o atendimento dela
traz o mesmo id, assim como as linhas da Trilha de Auditoria que ela gerou. A reclamação de um
cliente, uma linha de log e uma linha de auditoria se encontram por esse id.

**O fallback da auditoria faz parte da sua retenção de logs, e não dos seus backups.** Uma linha de
auditoria que o banco de dados não aceitou é gravada no Log do Servidor no nível `Critical` e em
nenhum outro lugar, e o console administrativo mostra um alerta. A trilha tem um buraco exatamente
onde o banco de dados estava fora; as linhas `Critical` são o que o preenche.

## A Trilha de Auditoria

A retenção é `Audit:RetentionDays` (365), que aceita override na tela **Configurações e usuários**.
Uma limpeza diária exclui as linhas mais antigas. Ajuste-a ao prazo de contestação da implantação. A
limpeza sobre uma tabela `AuditEvents` grande também é o que torna alguma migração ocasional demorada,
e é para isso que servem o `WEBSITES_CONTAINER_START_TIME_LIMIT=1800` no App Service e o prazo de
trinta minutos por comando.

**Relatórios e consultas escritos diretamente sobre o banco de dados precisam de duas mudanças desde o
Servidor 1.11.0:**

- **`certificate.encoding-dropped` e `certificate.announcement-refused` gravam uma linha por snapshot**,
  e não uma por certificado. Os detalhes passam a ser `{ count, entries: [...] }`. As linhas gravadas
  antes da 1.11.0 mantêm os campos planos, então tudo o que interpreta esses detalhes precisa ler os
  dois formatos. O `cpf` da linha só é preenchido quando todas as entradas citam o mesmo titular; uma
  linha que cobre vários é encontrada pela máquina, não pelo CPF.
- **`Workstations.EnrolledAt` agora é `Workstations.FirstSeenAt`.** Só o nome da coluna mudou; o
  console administrativo já dizia "Vista pela primeira vez".

## Reinícios e atualizações

**Uma única instância, então todo reinício é uma indisponibilidade visível de um ou dois minutos.** O
que sobrevive:

| | Sobrevive a um reinício do Servidor |
|---|---|
| Conexões das estações de trabalho | As máquinas se reconectam sozinhas, com backoff |
| Sessões de Assinatura vinculadas a estações de trabalho | **Sim**, intactas: o PIN em que se apoiam está em cache na máquina |
| Sessões de Assinatura vinculadas ao cofre | **Não.** Terminam como `Stranded`; os clientes recebem `SESSION_EXPIRED` e criam novas com o mesmo PIN |
| Logins de Administradores | Sim: o chaveiro das sessões web está no banco de dados |
| Requisições de assinatura em andamento | Não; falham de forma que podem ser repetidas. Uma Operação de Assinatura que ficou em `Pending` é encerrada por uma varredura como `Failed`, com `RUN_STRANDED` |
| Overrides de configuração do Administrador | Sim |

No App Service, a plataforma reinicia containers para a própria manutenção, então uma cadência de
reinícios que não é sua fica visível para a assinatura com o cofre. Deixe `DOCKER_ENABLE_CI`
desligado e faça deploy de forma deliberada.

**Atualizar o Servidor** é usar uma nova tag de imagem: `docker compose pull && docker compose up -d`,
ou uma nova imagem no App Service, por exemplo `trustbridge-server:1.13.0`. A nova imagem aplica as
próprias migrações na inicialização e as cita no log. Com `Database:MigrateOnStart=false`, aplique-as
antes, ou a nova imagem não inicia.

**Faça backup do banco de dados antes de toda atualização: é o único caminho de volta.** Toda release do
Servidor da 1.9.0 à 1.13.0 migra o schema, e uma imagem mais antiga não inicia sobre um banco de dados
que uma mais nova migrou. Reverter, portanto, é restaurar o backup de antes da atualização e implantar
a imagem anterior, nunca só trocar a tag. Uma frota que já passou para um protocolo de estação de
trabalho mais novo também não consegue se conectar ao Servidor mais antigo.

**Atualizando a partir do Servidor 1.6.x**: defina `Certificates:Validation:License` antes. Todo
Servidor desde a 1.7.0 precisa da licença da PKI, com ou sem cofre, e não inicia sem ela.

### Ordem de atualização: primeiro o Servidor, depois a frota

O Servidor aceita duas versões do protocolo das estações de trabalho: a dele e a anterior. Uma máquina
num protocolo mais antigo é recusada com *update required*; uma num protocolo mais novo é recusada com
*update the Server first*. As duas recusas ficam registradas na linha da máquina na tela da frota e na
Trilha de Auditoria como um `workstation.connect` com falha, e uma máquina recusada não assina nada.

| Servidor | Aceita os protocolos | Versões do Workstation que aceita |
|---|---|---|
| 1.6.x | 1–2 | 1.0.x |
| 1.7.0 – 1.8.0 | 2–3 | 1.0.x, 1.1.0 – 1.3.0 |
| 1.9.0 – 1.12.0 | 3–4 | 1.1.0 – 1.3.0, 1.4.x |
| 1.13.0 | 4–5 | 1.4.x (conecta, mas não atende sessões novas), **1.5.0** |

O Workstation 1.0.x fala o protocolo 2, da 1.1.0 à 1.3.0 o protocolo 3, da 1.4.0 à 1.4.2 o protocolo 4,
e a 1.5.0 o protocolo 5.

**Dentro de uma janela de protocolos, a regra é: atualize primeiro o Servidor, depois as estações de
trabalho, com no máximo uma release de diferença.** Uma máquina à frente do seu Servidor não consegue
se conectar: o Servidor mais antigo a recusa com *update the Server first*, não lhe entrega a licença
da PKI, e todo certificado dessa máquina aparece como `UNTRUSTED` no Tray App até o Servidor ser
atualizado. Um Servidor à frente de uma máquina que ainda está na janela dele é suportado.

**O protocolo 5 é a exceção: o Servidor 1.13.0 e o Workstation 1.5.0 andam juntos.** No protocolo 5 o
Servidor não envia mais o PIN da aplicação cliente a nenhuma estação de trabalho: ele desafia cada
máquina que tem um certificado candidato e confere a Prova de PIN (PIN Proof) com que a máquina
responde. Uma máquina no protocolo 4 (Workstation 1.4.x) ainda se conecta ao Servidor 1.13.0, recebe a
licença, busca as Autoridades Certificadoras Confiáveis, anuncia os certificados, assina para as
sessões já vinculadas a ela e pode receber a oferta de uma versão. **Ela nunca recebe um desafio de PIN
nem uma solicitação de PIN, então, para a criação de sessões, conta como offline.** Um titular cujas
máquinas estão todas ainda na 1.4.x recebe `422 WORKSTATION_OFFLINE` até que uma delas seja
atualizada, e o Servidor registra um `Warning` cada vez que ignora uma máquina assim. A atualização é,
portanto, uma indisponibilidade para todo titular cujas máquinas forem atualizadas com atraso. Uma
máquina na 1.3.0 ou anterior é recusada de vez.

Uma atualização para o Servidor 1.13.0, na ordem:

1. **Faça backup do banco de dados.**
2. **Planeje as máquinas que o Servidor não consegue atualizar**: as que estão no Workstation 1.3.0 ou
   anterior, e as cuja Diretiva de Grupo desliga as atualizações pelo Servidor. Elas precisam do
   Workstation 1.5.0 instalado à mão ou por Diretiva de Grupo, na mesma janela de manutenção, porque
   uma máquina na 1.5.0 não se conecta a um Servidor anterior à 1.13.0.
3. **Atualize o Servidor.**
4. **Envie o `TrustBridge-Workstation-1.5.0-x64.msi`** na tela **Versões da Estação de Trabalho** e
   ofereça-o com **Entregar a todas ainda não atualizadas…** na tela **Estações de Trabalho**. O envio
   precisa esperar a atualização: um Servidor recusa uma versão que fala um protocolo mais novo que o
   dele.
5. **Acompanhe a coluna *Versão do serviço* da tela da frota** e as linhas `Warning` que citam máquinas no
   protocolo 4, até toda máquina rodar a 1.5.0. Depois, se quiser que máquinas que sumiram apareçam
   como offline mais cedo, reduza
   [`Workstations:ClientTimeout`](https://docs.lacunasoftware.com/articles/trustbridge/configuration#workstationsclienttimeout) para `00:00:15`: toda
   máquina que consegue se conectar à 1.13.0 envia pings com frequência suficiente para isso.

Nada muda para as aplicações cliente: o SignSession Contract não mudou e o PIN continua chegando em
`POST /v1/sessions`. Agora ele não passa do Servidor.

**Atualizar as estações de trabalho à mão** é instalar um MSI mais novo sobre o antigo, sem
propriedades. Veja [Instalação das estações de trabalho](https://docs.lacunasoftware.com/articles/trustbridge/workstation-installation#atualizando). A
partir do Workstation 1.4.0, uma máquina também pode receber uma versão do seu Servidor: veja
[Atualização da frota pelo Servidor](https://docs.lacunasoftware.com/articles/trustbridge/operations#atualização-da-frota-pelo-servidor).

## Atualização da frota pelo Servidor

Desde o Servidor 1.9.0, um Administrador pode entregar uma Versão da Estação de Trabalho à frota pelo
console administrativo, e uma máquina com o Workstation 1.4.0 ou posterior a instala sozinha.

1. **Envie a versão** na tela **Versões da Estação de Trabalho**: o MSI assinado, de até 256 MB. O
   Servidor lê do próprio arquivo a versão, o protocolo que ela fala e o assinante, e a armazena no
   banco de dados. Ele recusa, citando o motivo e sem armazenar nada, um arquivo que não é um MSI, um
   pacote não assinado, um assinado por um certificado que o Publisher Pin dele não lista, uma versão
   que não são três números, um pacote que não declara protocolo (toda versão anterior ao Workstation
   1.3.0), um protocolo fora da janela do Servidor e uma versão já armazenada. Cada recusa é uma linha
   `admin.workstation-release-uploaded` com falha na Trilha de Auditoria. No App Service, o envio é uma
   única requisição e precisa terminar dentro do timeout de quatro minutos do front end.
2. **Ofereça-a** na tela **Estações de Trabalho**: **Oferecer versão…** para as máquinas selecionadas,
   ou **Entregar a todas ainda não atualizadas…**, que lista toda máquina que a versão alcança para você
   desmarcar o que quiser antes de confirmar. Uma oferta só alcança uma máquina Admitida, no protocolo
   4 ou posterior, abaixo da versão, cujo Publisher Pin lista o assinante da versão e cuja Diretiva de
   Grupo deixa as atualizações ligadas. As demais aparecem com o motivo e mantêm o que tinham.
3. **Cada máquina a instala sozinha**: depois de uma espera aleatória de até dez minutos, baixa o
   pacote do Servidor, verifica-o, espera até não haver assinatura em andamento nem solicitação de PIN
   aberta, e o instala. Ela informa o resultado no próximo handshake, como *installed*, *failed* (com o
   código de saída do `msiexec` e o final do log dele) ou *refused* (citando a verificação que falhou).
   Cada resultado é uma linha `workstation.update-installed`, `-failed` ou `-refused` na Trilha de
   Auditoria.

**Uma versão que falhou ou foi recusada não é tentada de novo até ser oferecida de novo.** Corrija a
causa e ofereça a mesma versão à máquina outra vez, ou use **Entregar a todas ainda não
atualizadas…**, que oferece de novo a toda máquina que seleciona. Uma máquina que estava offline quando
a versão foi oferecida de novo tenta no próximo handshake. Uma instalação que o Windows Installer
estava ocupado demais para iniciar (código 1618) é repetida pela própria máquina cerca de quinze
minutos depois.

**Retirar** a oferta interrompe toda máquina que ainda não começou a instalação: **Retirar oferta**
para as máquinas selecionadas, **Retirar de todas** na tela **Versões da Estação de Trabalho** para uma
versão. Uma versão oferecida a alguma máquina não pode ser excluída até as ofertas serem retiradas.
Uma máquina que já instalou uma versão continua nela.

**Quem o Servidor não alcança** aparece na tela **Estações de Trabalho**: **Atualizações desativadas
por diretiva** para uma máquina cuja diretiva *Receber atualizações do Servidor TrustBridge* está
desativada, e **Precisa de atualização manual** para uma cuja versão não recebe atualizações do
Servidor. O Workstation 1.3.0 e anteriores nunca recebem uma versão por esse caminho. Essas máquinas
recebem a versão à mão ou por Diretiva de Grupo.

Os downloads têm um limite próprio,
[`WorkstationReleases:MaxConcurrentDownloads`](https://docs.lacunasoftware.com/articles/trustbridge/configuration#workstationreleasesmaxconcurrentdownloads)
(20); uma máquina acima dele é informada de quando voltar. Eles não contam para o throttling das
aplicações cliente, então uma distribuição não faz o contrato responder `429`.

## Rotação do Protetor do Chaveiro

A rotação é **aditiva**: um protetor novo sela as chaves novas e nunca re-cifra o que já está
armazenado.

1. Mova o base64 do protetor que está saindo para `KeyRingProtector__RetiredCertificates__0__Certificate`
   (com `…__0__CertificatePassword` ao lado, se ele tiver senha). Um segundo protetor aposentado usa o
   índice `1`, e assim por diante.
2. Coloque o novo em `KeyRingProtector__Certificate`.
3. Reinicie. A linha `KeyRingPosture` deve passar a citar o novo thumbprint e `1 retired protector(s)`.
4. Guarde o PKCS#12 antigo nos seus backups, **permanentemente**. Não existe um momento em que a
   rotação "termina".

Nunca coloque uma entrada aposentada vazia num template: uma entrada que resulta numa string vazia
recusa a inicialização.

## Renovação da licença do PKI SDK

**A licença fica só no Servidor, e o Servidor a entrega à frota inteira.** Toda estação de trabalho
Admitida recebe a licença do Servidor ao se conectar e a mantém apenas em memória. Não há nada a
configurar nas máquinas: nenhuma propriedade do MSI e nenhum valor de Diretiva de Grupo traz uma
licença.

A licença do Lacuna PKI SDK vence numa data, e nada avisa antes disso. Depois que ela vence, o Servidor
registra uma linha `Critical`, toda página administrativa mostra um banner, e nada na frota nem no
cofre consegue assinar: os certificados passam a informar `UNTRUSTED`, e a criação de sessões é
recusada com `CERT_NOT_ACTIVE`. Leia o vencimento no arquivo e coloque-o no calendário que acompanha as
renovações de certificados:

```bash
base64 -d license.base64 | grep -o '<Expiration>[^<]*'
```

**Para renovar**, substitua `Certificates__Validation__License` pelo novo base64 e reinicie o
Servidor: no Docker, troque o `PKI_LICENSE` no `.env` e recrie o container; no App Service com uma
referência do Key Vault, crie uma nova versão do secret e reinicie. O reinício é o que chega à frota:
toda máquina conectada se reconecta e aplica a nova licença, e uma máquina que estava offline a recebe
quando se conectar de novo.

## Rotação da Installer Key

Só para uma implantação que gerou uma Installer Key própria. O Servidor aceita todas as chaves
que lista, então uma troca é uma distribuição gradual, e não uma virada num dia marcado: adicione a
nova chave pública ao lado da antiga em `Admission:InstallerKeys`, reinicie o Servidor, aponte o
`INSTALLER_KEY` das máquinas para a nova por um reparo silencioso, no ritmo de cada uma, e então remova
a entrada antiga e reinicie de novo.

## Rotação das chaves de API

Emita uma nova chave para a Aplicação Cliente na tela **Aplicações Cliente**, implante-a no cliente e
depois revogue a antiga. Todas as chaves aceitas de uma aplicação são equivalentes, então a troca é
invisível para as sessões em andamento.

## Gerenciamento da frota

- **Uma máquina que nunca aparece na fila** quase sempre tem um problema de URL ou de cadeia TLS; leia
  primeiro o log **Aplicativo** do Visualizador de Eventos dela. Veja
  [Instalação das estações de trabalho](https://docs.lacunasoftware.com/articles/trustbridge/workstation-installation#se-a-máquina-nunca-aparece-na-fila).
- **Uma máquina desativada** deve ser revogada na tela da frota, tenha sido desinstalada ou não. A
  revogação não depende da cooperação da máquina.
- **Uma máquina reinstalada** é uma máquina nova, com uma impressão digital nova, e chega de novo à
  fila. Uma atualização ou um reparo continua sendo a mesma máquina.
- **Uma máquina recusada com *update required*** roda uma versão mais antiga que a janela do Servidor:
  no Servidor 1.13.0, o Workstation 1.3.0 ou anterior. Instale nela a versão atual à mão ou por
  Diretiva de Grupo.
- **Uma máquina que mostra *Atrasada*** na coluna de Autoridades Certificadoras Confiáveis se reconecta
  e busca o conjunto de novo sozinha.
- **Desvio de relógio.** Uma máquina cujo relógio está mais de `Workstations:ClockSkewTolerance`
  (60 s) fora não consegue se conectar, e o log do Servidor a cita em `Warning`:
  `A workstation assertion was refused: Expired` ou `NotYetValid`, com o thumbprint da chave da máquina
  e a diferença, positiva quando a máquina está atrasada em relação ao Servidor e negativa quando está
  adiantada. A solução é a sincronização de horário.

## Os diretórios temporários

O Servidor grava três diretórios em `/tmp` dentro do container, e nada mais:

| Caminho | Contém | Se for perdido |
|---|---|---|
| `/tmp/trustbridge-pki` | O cache do PKI SDK com os emissores e LCRs baixados, e a licença entregue ao SDK como arquivo | Nada. A validação baixa de novo o que precisa, a cerca de 1,15 s por passagem em vez de 140 ms |
| `/tmp/trustbridge-logs` | O arquivo de log rotativo que a tela **Log do Servidor** lê | Nada. Toda linha foi gravada primeiro no console |
| `/tmp/trustbridge-releases` | Uma cópia de cada Versão da Estação de Trabalho armazenada, de onde saem os downloads da frota, e um envio enquanto o Servidor o lê | Nada. Cada cópia é refeita a partir da linha da versão no banco de dados no próximo download |

Um sistema de arquivos somente leitura é tolerado, com duas exceções. O SDK só lê uma licença a partir
de um arquivo, então um container **sem nenhum** diretório temporário gravável inicia um Servidor cuja
licença o SDK nunca leu: nada consegue assinar, e o console administrativo avisa. E um envio na tela
**Versões da Estação de Trabalho** é gravado em `trustbridge-releases` antes de ser lido, então, onde
esse diretório não pode ser gravado ou está cheio, todo envio é recusado com o motivo e o log do
Servidor cita o diretório. Os downloads continuam funcionando sem ele, lidos do banco de dados.

Monte um `tmpfs` sobre `/tmp` por causa da licença. O diretório de versões cresce cerca de 100 MB por
versão armazenada, e um `tmpfs` conta no limite de memória do container; por isso, onde houver versões
armazenadas, monte um volume em disco sobre o próprio `/tmp/trustbridge-releases`. Para mover os três,
defina `TMPDIR`.

Só apague o diretório de logs com o Servidor parado: o sink mantém o arquivo do dia aberto, e um
arquivo removido por baixo dele continua recebendo linhas que ninguém consegue ler até a próxima
rotação.

## Backups, numa tabela

| O quê | Onde | Frequência |
|---|---|---|
| O banco de dados | Os seus backups do SQL Server | Contínuo ou diário, conforme a sua política, e **antes de toda atualização** |
| O `.pfx` do Protetor do Chaveiro e cada um dos aposentados | Fora da plataforma, onde ficam as coisas insubstituíveis | Uma vez cada; eles nunca mudam |
| O certificado TLS (Docker) | Onde ficam os seus certificados | A cada emissão |
| O fluxo do Log do Servidor | A retenção do seu pipeline de logs | Contínuo |

Restaure o banco de dados e o protetor juntos. Nada mais precisa ser restaurado; as estações de
trabalho se reconectam, e o estado delas fica nas próprias máquinas. As Versões da Estação de Trabalho
armazenadas também estão no banco de dados.