Elenco di controllo per l'aggiornamento di Expressway 15.5.20

Aggiornamento interrotto dal controllo preparazione

Il programma di installazione si arresta prima del riavvio quando il certificato, la verifica TLS o i requisiti di identità peer non riescono. I nodi autonomi superano il controllo di identità peer.

Allarme dopo l'accensione di un nodo

Una frammentazione della ricrittografia del database cluster può generare un allarme di errore di comunicazione del cluster. Dagli tempo di finire. Escalate se rimane attivo.

L'amministratore non può accedere

Trattare questo problema separatamente da un errore di installazione. Le password scadute, riutilizzate o utilizzate per il primo accesso bloccano la sessione. Non significa che l'immagine sia fallita.

Errore certificato o identità peer

1. Scaricare uno snapshot di sistema completo dal nodo arrestato. Aprire install-error nella directory tmp della copia istantanea.
2. Se il messaggio riguarda l'identità dei peer, verificare la presenza di una combinazione di indirizzi IP e FQDN o di un elenco di peer vuoto. Fare in modo che ogni peer utilizzi un unico formato, attendere la replica, verificare che il cluster sia integro e riprovare. Non modificare il formato di identità durante un aggiornamento in sequenza.
3. Se il messaggio riguarda il certificato, confrontarlo con la regola della nota sulla versione: l'FQDN del sistema deve essere nella SAN o nel CN solo quando la SAN è vuota. Non è consentito eseguire il fallback alla rete SAN attuale.
4. Riemettere il certificato con ogni nome DNS o indirizzo IP richiesto nel tipo di SAN corretto. Rifiutare un nome che contiene un NUL incorporato.
5. Confermare che il nuovo certificato sia in data, attendibile, RSA 2048+ o P-256+ e firmato con SHA-2. Non allegare la chiave privata alla richiesta.
6. Impostare la verifica TLS su Imponente, verificare che il cluster sia integro e ripetere l'aggiornamento sul nodo interrotto.
7. Continuare l'aggiornamento in sequenza solo dopo che il nodo è integro. Non aggiornare i nodi rimanenti mentre un nodo è interrotto in questo controllo.

Allarme cluster durante o subito dopo l'aggiornamento

1. Verificare che l'aggiornamento sia stato completato e che il nodo si trovi in X15.5.20.
2. Cercare nel registro eventi i messaggi developer.upgrade relativi alla ricrittografia dei campi di ClusterDB, quindi "Salvataggio dei dati migrati nel CDB".
3. Aspettate che l'allarme scompaia. Il materiale di formazione afferma che viene cancellato al termine della ricrittografia.
4. In caso affermativo, raccogliere lo stato del cluster, gli allarmi e un'istantanea da ogni peer. Non copiare i cookie del cluster o il materiale della chiave nelle note della richiesta.
5. Confermare che i protocolli TCP 4371 e 4372 siano aperti solo tra peer e che il protocollo TLS reciproco abbia esito positivo. Un firewall che consente l'uso di 4371 da qualsiasi luogo non è la soluzione.

Problemi di accesso dopo l'attivazione del nodo

• L'interfaccia utente Web reindirizza a una modifica della password. È necessario immettere la password corrente e la nuova password deve essere diversa. Questo è previsto al primo accesso alla GUI dopo un'installazione o un reset di fabbrica e quando una password locale è scaduta.
• SSH: tastiera interattiva/PAM non riuscita e non apre mai una shell. È necessario modificare una password locale scaduta. La sessione precedente non è concessa.
• REST restituisce 401. Previsto per un amministratore locale scaduto. Il registro eventi può visualizzare la mancata corrispondenza delle password o l'errore taa-chkpasswd per l'area di autenticazione API. Modificare la password, quindi riprovare.
• Nuova password rifiutata. Si trova nella cronologia (ultimo 12 per impostazione predefinita) oppure non è riuscita a rispettare le regole di complessità correnti.
• L'amministratore LDAP ha perso il ruolo previsto. Confrontare il gruppo configurato con il nome esatto del gruppo restituito da LDAP. Una corrispondenza parziale o di sottostringa non concede più il ruolo. Un amministratore di sola lettura non può modificare l'attendibilità del provider di identità SAML.
• Nessuna password di root predefinita in una nuova installazione o in una reimpostazione di fabbrica. Non cercare o distribuire credenziali predefinite. L'aggiornamento non cancella la password corrente dell'amministratore.

Attenzione: Il ripristino in fabbrica non è il passaggio di aggiornamento-ripristino. Elimina l'identità e i cookie del cluster. Una reimpostazione avviata dal sistema dopo il declustering o un database cluster incoerente mantiene l'indirizzo IP e le password di amministrazione e radice, cancella altre configurazioni e registri e restituisce il nodo al relativo certificato temporaneo. Utilizzarlo solo quando richiesto dalle note sulla versione e solo dopo l'esistenza di un backup.

Prove da raccogliere nel caso in cui sia necessario un TAC

1. Versione del software e ruolo di ogni nodo, oltre al nodo arrestato.
2. Snapshot completo del sistema dal nodo non riuscito, incluso tmp/install-error.
3. Testo certificato server (openssl x509 -text -noout). Nessuna chiave privata.
4. Stato del cluster, allarmi e se TlsVerify del cluster xConfiguration mostra Permissive o Enforce.
5. Righe del registro eventi per l'aggiornamento e, se pertinente, errori di autenticazione sshd o httpd. Redigere password e cookie.
6. Utilizzo di amministratori locali, LDAP o SAML, di Smart Licensing e di qualsiasi automazione API.

Dopo l'aggiornamento

In ogni nodo

1. Versione: la build X15.5.20 prevista.
2. Il nodo è raggiungibile con il relativo indirizzo di gestione e viene caricata l'interfaccia utente Web.
3. Non viene lasciato alcun avviso di nuovo hardware, disco o applicazione. (Dopo la ricrittografia viene cancellato un allarme di comunicazione del cluster.)
4. Dopo la stabilità del cluster viene eseguito un nuovo backup.

Solo cluster

1. Ogni peer è attivo, nel cluster e la replica è integra.
2. I peer comunicano con Mutual TLS su TCP 4371 e 4372. (Una connessione senza un certificato client valido deve avere esito negativo).
3. TlsVerify del cluster applicato.

   Autorizzazione non supportata. Un valore di tipo Permissive legacy potrebbe essere ancora visibile, ma non ignora la convalida. Impostare Enforcement e verificare che il cluster rimanga integro.

4. Il firewall consente ancora il protocollo TCP 4371 solo dagli indirizzi peer.

5. Nessun cookie del cluster o segreto di diagnostica viene visualizzato nei log o nelle note dello snapshot caricate.

Controlli del servizio in base all'oggetto in uso