Procedura di risoluzione dei problemi

Lo scopo di questa pagina è fornire alcune raccomandazioni di base per risolvere i problemi riscontrati di frequente con Cyberwatch.

L’applicazione non si avvia

Questa procedura può essere utile se l’applicazione non si avvia dopo l’esecuzione di cyberwatch configure o cyberwatch restart:

Verificare se i servizi sono stati avviati:
```
sudo cyberwatch status
```
Verificare se le immagini sono presenti:
```
docker images
```
Verificare il docker pull:
```
docker pull harbor.cyberwatch.fr/cbw-on-premise/olympe:latest
```
Qualsiasi problema durante il docker pull può derivare da:
- autenticazione non valida su harbor.cyberwatch.fr
- spazio esaurito sul dispositivo
- assenza di flussi verso harbor.cyberwatch.fr
Verificare la configurazione applicata:
```
sudo cyberwatch show-config
```
Un errore indica un file di override non valido nella directory /etc/cyberwatch/configs-enabled, ad esempio un override che punta a un servizio assente dal nodo.

A partire dalla versione 5.32 della piattaforma di base, se il download delle nuove immagini non riesce, il comando cyberwatch restart visualizza un avviso e riavvia l’applicazione con le immagini già presenti sul nodo. In tal caso l’applicazione non viene aggiornata. Correggere la causa del problema, quindi eseguire nuovamente sudo cyberwatch restart.

Kibana non funziona

In caso di problemi gravi con Elastic o Kibana, è possibile eliminare tutti i dati e ripartire da zero.

sudo cyberwatch stop
docker volume rm cbwonpremise_esdata
sudo cyberwatch restart

Il job incaricato di popolare i dati verrà avviato dopo il riavvio.

L’interfaccia restituisce un errore 502 o 503 dietro una Gateway API

Su Kubernetes, quando l’applicazione è esposta tramite Gateway API, la Gateway verifica il certificato presentato da Nginx grazie alla BackendTLSPolicy creata dal chart. Se questa verifica non riesce, tutte le richieste restituiscono un errore 502 o 503, anche se i pod sono pronti e l’HTTPRoute e la BackendTLSPolicy restano nello stato Accepted.

Consultare i log di accesso della Gateway. Con Envoy Gateway, ad esempio:
```
kubectl -n envoy-gateway-system logs -l gateway.envoyproxy.io/owning-gateway-name=<nom-de-la-gateway> --tail=50
```
Un errore CERTIFICATE_VERIFY_FAILED indica un problema di certificato tra la Gateway e Nginx: certificate has expired per un certificato scaduto, SAN matcher per un nome assente dal certificato.
Visualizzare la data di scadenza e i nomi del certificato di Nginx:
```
kubectl -n cyberwatch get secret cbw-nginx-frontend-tls -o jsonpath='{.data.tls\.crt}' | \
  base64 -d | openssl x509 -noout -enddate -ext subjectAltName
```
Con un certificato personalizzato, sostituire cbw-nginx-frontend-tls con il secret indicato in nginx.tls.existingSecret.

Se il certificato generato da Helm è scaduto, eliminarlo e rilanciare la distribuzione. Helm genera un nuovo certificato e riavvia Nginx:

kubectl -n cyberwatch delete secret cbw-nginx-frontend-tls
helm -n cyberwatch upgrade cyberwatch oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart -f values.yml

Con un certificato personalizzato, verificare che non sia scaduto, che il nome indicato in httpRoute.backendTLSPolicy.hostname (per impostazione predefinita nginx.cyberwatch.svc) figuri tra i suoi nomi, e che l’autorità di certificazione che l’ha firmato sia presente nella ConfigMap httpRoute.backendTLSPolicy.caConfigMap.

Il browser segnala un certificato scaduto su Kubernetes

Se non viene fornito alcun certificato, Helm genera il certificato presentato agli utenti:

con un Ingress, nel secret {hostname}-tls, dove {hostname} è il valore di ingress.hosts[].hostname;
senza Ingress né Gateway API, con Nginx esposto direttamente sulle porte dei nodi, nel secret cbw-nginx-frontend-tls.

Visualizzare la data di scadenza del certificato:

kubectl -n cyberwatch get secret <nom-du-secret> -o jsonpath='{.data.tls\.crt}' | \
  base64 -d | openssl x509 -noout -enddate

Se il certificato è scaduto, eliminare il secret e rilanciare la distribuzione. Helm genera un nuovo certificato:

kubectl -n cyberwatch delete secret <nom-du-secret>
helm -n cyberwatch upgrade cyberwatch oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart -f values.yml

Non eliminare un secret fornito dall’amministratore (ingress.hosts[].tls.secret, nginx.tls.existingSecret): Helm non lo ricrea. Un certificato di questo tipo si rinnova secondo la documentazione sulla configurazione TLS per Kubernetes.

I certificati generati da Helm sono validi 365 giorni e non vengono rinnovati automaticamente. Per verificare e rinnovare l’insieme di questi certificati, seguire la procedura di rinnovo dei certificati TLS su Kubernetes.