Forum IT Tranquillo

Ciao,


finalmente ho deciso di dedicare del tempo all'aggiornamento della mia versione WAPT 1.8.2 Enterprise alla WAPT 2.0 Enterprise.

Utilizzo due server:
- Un server di test con Debian 10.
- Un server di produzione con Windows Server.

Logicamente, ho iniziato aggiornando il server di test con Debian.
Dopo aver riscontrato alcuni problemi durante l'aggiornamento, sono riuscito ad aggiornare a WAPT 2.0.

Successivamente ho proceduto alla rifirma degli host e dei pacchetti.
Nessun problema con gli host.
Tuttavia, la console ha mostrato diversi errori di "timeout di lettura" per vari pacchetti (alcuni dei quali di oltre 4 GB).
Quindi, ho seguito il metodo descritto nella documentazione e ho provato a rifirmare direttamente dal server tramite riga di comando.
Diversi pacchetti che inizialmente non erano stati firmati correttamente sono stati rifirmati con successo, ad eccezione di tre che avevano dimensioni di 5,7 GB, 5,7 GB e 6,6 GB.
L'errore visualizzato è: BadZipFile('Numero magico non valido per l'intestazione del file').

Ho riscontrato spesso questo errore durante il deployment di pacchetti di grandi dimensioni e sono riuscito a evitarlo modificando il parametro client_max_body_size nel file /etc/nginx/sites-enabled/wapt.conf del server. Il file è ancora configurato correttamente (non è cambiato dopo l'aggiornamento) e il problema persiste.

Avete qualche suggerimento su come posso distribuire questi pacchetti senza dover ricompilare e installare una nuova versione, operazione che comporterebbe un aggiornamento su tutte le macchine (e, viste le dimensioni del pacchetto, non vorrei proprio arrivare a questo punto)?

Grazie.

Continuando la saga:

ho provato ad aggiornare il server WAPT a Windows 2.0.

Dopo l'aggiornamento, non riuscivo ad avviare la console...

Ho dovuto ripristinare la VM e ricominciare da capo, e chissà perché... Ha funzionato la seconda volta...

Tuttavia, non riuscivo a firmare nuovamente i pacchetti tramite la console (ricevevo un messaggio di "Timeout di lettura" non appena un pacchetto superava i 400 MB)...
E ovviamente, non c'è nessuna documentazione che spieghi come firmarli nuovamente dal server (Windows), a differenza di Linux...

Mi aspettavo di avere problemi durante l'aggiornamento alla versione 2.0, ma non a questo livello... Sono piuttosto deluso...

Non è molto affidabile.

Quindi probabilmente dovrò pagare per i ticket di supporto solo per aggiornare alla versione 2.0... E francamente, lo trovo un po' eccessivo...

Una soluzione più economica sarebbe quella di ricompilare i pacchetti che non funzionano... Ci vorrà del tempo, ma probabilmente è quello che farò per evitare 900 € di ticket di supporto...

Nel file Nginx - /etc/nginx/sites-enabled/wapt.conf
Attenzione, ci sono due posti in cui si trova client_max_body_size.

Non so perché Tranquil IT non imposti questa opzione su client_max_body_size 0 per impostazione predefinita;
Ma sicuramente c'è una ragione.

Ho fatto delle ricerche per scoprire perché il mio pacchetto windows10-upgrade-data non veniva caricato correttamente sul server WAPT

Jacky

Christophe0110 ha scritto: ↑9 giugno 2021 - 11:04 Salve,


finalmente ho deciso di dedicare del tempo all'aggiornamento della mia versione di WAPT dalla 1.8.2 Enterprise alla 2.0 Enterprise.

Utilizzo due server:
- Un server di test con Debian 10.
- Un server di produzione con Windows Server.

Logicamente, ho iniziato aggiornando il server di test con Debian.
Dopo aver riscontrato alcuni problemi durante l'aggiornamento, sono riuscito ad aggiornare a WAPT 2.0.

Poi è arrivato il momento di rifirmare gli host e i pacchetti.
Nessun problema con gli host.
Tuttavia, tramite la console, ho ricevuto diversi errori di "timeout di lettura" su diversi pacchetti (i più grandi dei quali erano, in alcuni casi, superiori a 4 GB).
Quindi ho seguito il metodo della documentazione provando una rifirma direttamente dal server tramite un comando.
Diversi pacchetti che inizialmente non erano riusciti sono stati rifirmati correttamente, tranne tre di essi, che erano di 5,7 GB; 5,7 GB e 6,6 GB.
L'errore visualizzato è: BadZipFile('Bad magic number for file header').

Ho riscontrato spesso questo errore durante la distribuzione di pacchetti di grandi dimensioni e sono riuscito a evitarlo modificando il parametro client_max_body_size nel file /etc/nginx/sites-enabled/wapt.conf del server. Il file è ancora configurato correttamente (non è cambiato dopo l'aggiornamento) e il problema persiste.

Avete qualche suggerimento su come posso distribuire questi pacchetti senza dover ricompilare e installare una nuova versione, il che comporterebbe un aggiornamento su tutte le macchine (e, viste le dimensioni del pacchetto, non vorrei proprio arrivare a questo punto)?

Grazie.

Grazie per la risposta, jacky35!

Sì, su Linux sono riuscito a modificare quel file e entrambe le posizioni.

Su Windows ho trovato un file (con una sola posizione al suo interno) in cui era presente quel parametro.

Tuttavia, non cambia nulla; la console WAPT sembra avere una vera e propria avversione per i pacchetti di grandi dimensioni.
Non lo capisco; sicuramente non sono l'unico ad avere pacchetti più grandi di 400 MB...

Vabbè, pazienza, dovrò fare come ho detto e ricompilare gli 11 pacchetti che non funzionano...

Christophe0110 ha scritto: ↑9 giugno 2021 - 11:04 Ho riscontrato spesso questo errore durante il deployment di pacchetti di grandi dimensioni e sono riuscito ad evitarlo modificando il parametro `client_max_body_size` nel file `/etc/nginx/sites-enabled/wapt.conf` del server. Il file è ancora configurato correttamente (non è cambiato dopo l'aggiornamento) e il problema persiste.

Se client_max_body_size in nginx non è stato modificato dopo l'aggiornamento, è perché non hai avviato postconf e quindi non hai seguito la procedura fino alla fine (client_max_body_size non è ancora parametrizzato nel template nginx).

jacky35 ha scritto: ↑10 giugno 2021 - 15:55 Nel file Nginx - /etc/nginx/sites-enabled/wapt.conf
Attenzione, ci sono due punti in cui puoi trovare client_max_body_size.

Non so perché Tranquil IT non imposti questa opzione su client_max_body_size 0 per impostazione predefinita;
ma sicuramente c'è un motivo.

Il server deve memorizzare i file nella cache da qualche parte. Consentire caricamenti illimitati rischia di saturare lo spazio su disco temporaneo o la RAM disponibile, con il rischio di un attacco DoS. Quindi sì, c'è un motivo. Tuttavia, questa impostazione verrà memorizzata in waptserver.ini in futuro e utilizzata automaticamente nel file di configurazione di nginx.

Christophe0110 ha scritto: ↑11 giugno 2021 - 13:59 Grazie per la risposta, jacky35!

Sì, su Linux sono riuscito a modificare quel file e quelle due posizioni.

Su Windows ho trovato un file (con una sola posizione al suo interno) in cui si trovava quel parametro.

Tuttavia, non cambia nulla; la console WAPT sembra essere completamente allergica ai pacchetti di grandi dimensioni.
Non capisco; sicuramente non sono l'unico ad avere pacchetti più grandi di 400 MB...

Vabbè, non importa, dovrò fare come ho detto e ricompilare gli 11 pacchetti che non funzionano...

Nota: Nginx deve avere abbastanza spazio su disco disponibile per archiviare i blocchi di file durante il caricamento.

Ciao Christophe,

Christophe0110 ha scritto: ↑10 giugno 2021 - 10:22 Quindi probabilmente dovrò pagare per i ticket di supporto solo per aggiornare alla versione 2.0... E francamente, lo trovo un po' eccessivo...

Una soluzione più economica sarebbe quella di ricostruire i pacchetti difettosi... Ci vorrà del tempo, ma probabilmente è quello che farò per evitare 900 € di ticket di supporto...

Informazioni riservate: Tranquil IT è un produttore di software, non un'azienda di servizi IT. Non cerchiamo di incentivare la vendita dei biglietti; non è la nostra principale fonte di reddito (nemmeno lontanamente). E voglio sottolineare che la maggior parte delle richieste di supporto che riceviamo sono documentate nella documentazione WAPT, quindi, in un certo senso, si tratta più che altro di far risparmiare tempo ai clienti (il tempo è denaro)... Cerchiamo di coprire il maggior numero possibile di scenari durante il processo di aggiornamento (e ci richiede molto tempo), ma non possiamo tenere conto di tutte le stranezze che le persone fanno sulla loro rete (la creatività, necessaria o superflua, non conosce limiti) o di tutti gli errori che le persone commettono nel seguire le procedure.

Sinceramente,

Denis Cardon

Buongiorno,

dcardon ha scritto: ↑15 ​​giugno 2021 - 10:49 Se client_max_body_size in nginx non è stato modificato dopo l'aggiornamento, è perché non hai avviato il postconf e quindi non hai seguito la procedura fino alla fine (client_max_body_size non è ancora parametrizzato nel template di nginx).

Se parliamo del comando /opt/wapt/waptserver/scripts/postconf.sh, sì, l'ho avviato e ho seguito la procedura fino alla fine.
Ho quindi letto (sempre all'interno della procedura) la seguente istruzione appena sopra il comando:

Se hai personalizzato la configurazione di Nginx, non rispondere Sì quando postconf ti chiede di configurare Nginx

Poiché le cose stavano così, non ho risposto "Sì" e, quindi, è probabile che sia per questo che la configurazione di nginx non è cambiata nel mio caso...

dcardon ha scritto: ↑15 ​​giugno 2021 - 10:53 Nota: Nginx deve avere spazio su disco sufficiente per memorizzare i blocchi di file durante il caricamento.

Se parliamo dello spazio rimanente sul server Windows su cui è installato WAPT, ci sono 443 GB di spazio libero... Non credo quindi che questa sia la causa del problema.

dcardon ha scritto: ↑15 ​​giugno 2021 - 11:06 Ciao Christophe,

Informazioni riservate: Tranquil IT è un editore di software, non un'azienda di servizi IT. Non cerchiamo di spingere la vendita di ticket; non è la nostra principale fonte di reddito (nemmeno lontanamente). E voglio sottolineare che la maggior parte delle richieste di supporto che riceviamo sono documentate nella documentazione WAPT, quindi in un certo senso si tratta più che altro di far risparmiare tempo ai clienti (il tempo è denaro)... Cerchiamo di coprire il maggior numero possibile di scenari nei processi di aggiornamento (e questo ci richiede molto tempo), ma non possiamo tenere conto di tutte le stranezze che le persone fanno sulla loro rete (la creatività, necessaria o superflua che sia, non ha limiti) o di tutti gli errori che le persone commettono seguendo le procedure.

Cordiali saluti,

Denis Cardon

Non considero i miei pacchetti qualcosa di insolito. Sono piuttosto basilari e, quando voglio distribuire un pacchetto AutoCAD in massa (e non posso essere l'unico in questa situazione), mi sembra logico che il pacchetto superi i 400 MB... E per quanto riguarda la procedura, posso dirti che l'ho seguita alla lettera (e nel caso del server Windows, due volte, come ho spiegato prima). Non mi dispiace pagare ticket di supporto se devo reinstallare un server e riscontro un problema, o se provo a creare un pacchetto che non funziona. Ma dover pagare per il supporto per un aggiornamento che non funziona, anche se ho seguito correttamente la documentazione, non credo sia giusto. Questa è solo la mia opinione.


Cristoforo.

Tuttavia, la documentazione afferma chiaramente che un server Linux è più adatto per la produzione.

Scrivo qui per sottolineare a chiunque legga questo post che un server WAPT con Windows è una cortesia, non un obbligo.

La soluzione al tuo problema è già presente nel tuo primo post. Perché non utilizzare Debian 10 per il tuo ambiente di produzione, come fai con successo per l'ambiente di pre-produzione? Se la tua dirigenza insiste sull'utilizzo di un sistema operativo supportato per l'ambiente di produzione, allora Red Hat sarà la scelta migliore.