Forum IT Tranquillo

Questa versione può essere utilizzata in produzione su un nuovo server?

Ciao,
utilizziamo Wapt 1.5.1.8 in produzione presso il server Debian

Hubert dei nostri clienti.

Su alcune macchine, dopo aver disinstallato il vecchio agente e reinstallato quello nuovo, il pulsante "Verifica aggiornamenti" o "Applica aggiornamenti" è disattivato e non capisco il perché.

Qualche suggerimento?
Grazie.

guigeek ha scritto: ↑5 dic 2017 - 17:06 Su alcuni computer in cui ho disinstallato il vecchio agente e reinstallato quello nuovo, il pulsante "Verifica aggiornamenti" o "Applica aggiornamenti" è disattivato e non capisco perché.

Qualche idea?
Grazie,

Infatti, tutti i client installati risultano "irraggiungibili"...

Ho la sensazione che sia il WebSocket a non funzionare... nei log di WaptService sul client trovo questo:
Errore nella connessione socket io ConnectionError (codice di stato imprevisto (401 Non autorizzato)).

I permessi sul server in /var/www/wapt sono corretti.
Sono un po' perplesso

Eccomi di nuovo a spammare.
A quanto pare manca un file: "
/var/www/wapt-host/45EC4D56-BA0D-3CFF-6F8C-8C1E31C46A3A.wapt" non riuscito (2: Nessun file o directory di questo tipo).

Come posso ricrearlo?

Ciao,

il messaggio "(codice di stato imprevisto (401 Non autorizzato))" significa che la connessione WebSocket non è autorizzata perché il computer non è registrato sul server oppure la chiave pubblica memorizzata nel database del server non corrisponde alla chiave privata del computer.

Infatti, nella versione 1.5, il computer crea una coppia di chiavi pubblica/privata (utilizzando il suo FQDN come oggetto) e invia il certificato X.509 con la chiave pubblica al server durante la registrazione iniziale (quando si installa il client waptagent.exe).

Questa coppia di chiavi viene quindi utilizzata per autenticare gli inventari inviati dal client e per autenticare le connessioni WebSocket.

Se la coppia di chiavi viene generata dopo l'avvio del servizio waptservice, il computer risulterà disconnesso fino al riavvio del servizio waptservice.

Se il computer non è registrato correttamente o non è registrato affatto, è possibile provare a eseguire "wapt-get register -ldebug" sul client con privilegi di amministratore e riavviare il servizio ("net stop"). "waptservice" "net start waptservice"

Se la chiave non corrisponde, puoi provare a rimuovere il client dall'inventario (questo rimuoverà il certificato/chiave pubblica del client in questione dal database) e a registrarlo nuovamente.

Se ancora non funziona, si tratta di un bug...

----

Per quanto riguarda il secondo punto, il messaggio
"/var/www/wapt-host/45EC4D56-BA0D-3CFF-6F8C-8C1E31C46A3A.wapt" non riuscito (2: Nessun file o directory di questo tipo)"
è normale finché non hai creato una configurazione per la macchina nella console.

La macchina tenta di recuperare la sua configurazione di destinazione ad ogni aggiornamento.

In wapt 1.3, i pacchetti della macchina erano denominati con il FQDN della macchina.

In wapt 1.5, i pacchetti della macchina sono denominati per impostazione predefinita con l'UUID della macchina.

Uno script consente di ricreare i pacchetti della macchina in blocco, se necessario. (/opt/wapt/waptserver/scripts/migrate-hosts.py )

Grazie,
ho eseguito `wapt-get register` in modalità debug e tutto è andato liscio. Dice "successo". Ma sul lato server, non ho ancora l'UUID.wapt...

Per il repository Wapt 1.5 di CentOS, i pacchetti sono disponibili qui: https://wapt.tranquil.it/centos7/wapt-1.5/
Richiedono PostgreSQL 9.4 e Nginx

: https://www.wapt.fr/fr/doc-1.5/Installa ... _wapt.html

guigeek ha scritto: ↑6 dic 2017 - 10:20 Grazie,
ho eseguito `wapt-get register` in modalità debug e tutto è andato liscio. Dice "successo". Ma sul lato server, non ho ancora l'UUID.wapt...

A quanto pare, in seguito a un aggiornamento del server, il problema sembra essere stato risolto...