[RISOLTO] Dispositivi disconnessi dall'aggiornamento 2.5

[morvan-n]

Server Debian 12
versione wapt 2.5.2.15207

Buongiorno,

Dopo l'aggiornamento alla versione 2.5, tutte le mie postazioni di lavoro sono in stato disconnesso nella console.

Ho provato la procedura descritta nell'altro post senza successo.

Codice: Seleziona tutto

net stop waptservice
suppression des fichiers C:\Program Files (x86)\wapt\log\waptservicestate et C:\Program Files (x86)\wapt\log\waptservicestate.html
net start waptservice

I comandi wapt-get update e wapt-get upgrade funzionano da un client.

Ho abilitato l'autenticazione del certificato durante l'aggiornamento alla versione 2.5 e ho generato un nuovo agente per aggiornare i miei client.

Ecco il messaggio di errore che ricevo nel file waptserveur.log:

Codice: Seleziona tutto

connection refused for uuid xxx, sid xxx: SocketIO connection not authorized, invalid token: No authorization token, instance

Grazie per l'aiuto
Nicolas

[Crous Strasburgo]

Ciao,

ho avuto lo stesso problema.

SOLUZIONE ALTERNATIVA:
Durante il PostConf sul server, puoi scegliere di non controllare il certificato e selezionare: "
Non controllare il certificato client HTTPS (legacy)".

In questo modo i computer client appariranno nella tua console. Tuttavia, incontrerai un altro bug: i computer rimarranno CONNESSI nonostante l'aggiornamento.
Dovrai quindi reimpostare la connessione eseguendo un "Reset delle connessioni WebSocket stabilite" nella console sull'host in questione.

SOLUZIONE:
Questa soluzione mi è stata suggerita da Tranquil It. Tuttavia, ho trovato una soluzione al problema iniziale: utilizzavo Debian 11 e ho effettuato l'aggiornamento a 12. Questo ha risolto il problema.

Buona giornata,
Matthieu

[morvan-n]

Ciao,

grazie per il tuo feedback. In effetti, selezionando "Non controllare il certificato client HTTPS (legacy)", riesco a visualizzare nuovamente i dispositivi connessi nella console, ma il ripristino del WebSocket non risolve il problema e tutti i miei dispositivi risultano ancora connessi...

In definitiva, al momento non esiste una soluzione perfetta.

Cordiali saluti,
Nicolas

[bkolovljanovic]

Ciao Nicolas,

questi problemi sono stati risolti nella versione 2.5.3

[morvan-n]

Ciao,

sì, con la versione 2.5.3 tutto funziona di nuovo correttamente.

Nicolas

[kvnwsr]

Salve,

abbiamo lo stesso problema.
Abbiamo installato la versione 2.5.3, ma il problema persiste.

Il server è AlmaLinux release 8.9 (Midnight Oncilla).

Nessuna soluzione alternativa ha funzionato per noi.

Grazie per l'aiuto,
Kevin

[dcardon]

Ciao Kevin,

hai un reverse proxy davanti al tuo server WAPT, un firewall/WAF con funzione di filtraggio o qualcos'altro?

La connessione è HTTPS? La convalida del certificato è abilitata sul client?

Nella versione 2.5.3 abbiamo rimosso l'opzione "Non controllare il certificato client HTTPS (legacy)", che disabilita l'autenticazione SSL a livello di Nginx (che poi la delega agli script Python). Questa opzione in realtà causa più problemi di quanti ne risolva. Cordiali

saluti,

Denis

[kvnwsr]

Ciao Denis,

grazie per la risposta.

Non utilizziamo un reverse proxy.
Ho provato a disabilitare il firewall, ma non è cambiato nulla.

La connessione viene stabilita tramite HTTPS e la convalida del certificato non è abilitata sui client.
La nostra configurazione funzionava correttamente nella versione 2.4.

Posso tornare alla versione 2.4, dato che alcuni client hanno già effettuato l'aggiornamento alla versione 2.5.3?

[Cristoforo]

Ciao,
ho esattamente lo stesso problema di Kevin dopo l'aggiornamento alla versione 2.5.3.
Per tua informazione, utilizzo un server Windows.
Non abbiamo un reverse proxy e il firewall è disabilitato sul client.

Per ora, sono tornato alla versione 2.4 (snapshot).
Ho creato una copia completa del nostro server e di un client per testare la versione 2.5.3 su una rete isolata. Ma non riesco a capire da dove provenga il problema.

[Cristoforo]

Errore mio, non mi ero reso conto che anche i miei client dovevano avere la versione 2.5 per essere nuovamente disponibili sul server.

Il problema dovrebbe quindi essere risolto per i PC aggiunti al dominio tramite i criteri di gruppo per l'installazione dell'agente, ma come faccio a installare il client 2.5 sui PC non appartenenti al dominio?