Erreur resignature paquets (Passage WAPT 2.0)

Questions about WAPT Packaging / Requêtes et aides autour des paquets Wapt.
Règles du forum
Règles du forum communautaire
* English support on www.reddit.com/r/wapt
* Le support communautaire en français se fait sur ce forum
* Merci de préfixer le titre du topic par [RESOLU] s'il est résolu.
* Merci de ne pas modifier un topic qui est taggé [RESOLU]. Ouvrez un nouveau topic en référençant l'ancien
* Préciser version de WAPT installée ( 1.6.1 / 1.7.4 / 1.8.2 / etc.) AINSI QUE l'édition Enterprise / Community
* Préciser OS du serveur (Linux / Windows) et version (Debian Stretch/Buster - CentOS 7 - Windows Server 2012/2016/2019)
* Préciser OS de la machine d'administration/création des paquets (Windows 7 / 10)
* Comme tout forum communautaire, le support est fait bénévolement par les membres. Si vous avez besoin d'un support commercial, vous pouvez contacter Camille ou Faustine au service commercial Tranquil IT au 02.40.97.57.55
Christophe0110
Messages : 50
Inscription : 11 juin 2019 - 12:04

09 juin 2021 - 11:04

Bonjour,


Je me suis enfin décidé à prendre le temps de passer ma version WAPT 1.8.2 Entreprise vers WAPT 2.0 Entreprise.

J'utilise 2 serveurs :
- Un serveur de test sous Debian 10.
- Un serveur de prod sous Windows Server.

J'ai commencé, en toute logique, par la mise à jour du serveur de test sous Debian.
Après quelques problèmes rencontrés durant la mise à jour, j'ai réussi à passer sous WAPT 2.0 avec succès.

Vient alors la resignature des hosts et des paquets.
Coté hosts, aucun problème.
Coté paquets, via la console, plusieurs erreurs "Read timeout" sur plusieurs paquets (les plus volumineux faisant, pour certains, plus de 4 GB).
J'ai donc suivi la méthode de la doc en essayant un resign directement depuis le serveur par commande.
Plusieurs paquets n'étant pas passés au départ sont passés sauf 3 d'entre eux faisant 5,7 GB ; 5,7 GB et 6,6 GB.
L'erreur affichée est la suivante : BadZipFile('Bad magic number for file header').

J'ai déjà souvent rencontré cette erreur lors du déploiement de gros paquets et j'avais pu éviter cette erreur en éditant le paramètre client_max_body_size dans le fichier /etc/nginx/sites-enabled/wapt.conf du serveur. Le fichier est toujours bien configuré (il n'a pas changé suite à la mise à jour) et le problème reste présent malgré tout.

Avez-vous une idée pour me permettre de passer ces paquets sans devoir faire un rebuild et donc une nouvelle version qui provoquera une mise à jour sur tous les postes (et vu la taille du paquet, j'ai pas vraiment envie de passer par là) ?

Merci.
Christophe0110
Messages : 50
Inscription : 11 juin 2019 - 12:04

10 juin 2021 - 10:22

Suite de l'aventure :

J'ai ensuite essayé de passer le serveur WAPT sous Windows en 2.0

Après la mise à jour, impossible de démarrer la console...

J'ai du restauré la VM et recommencer et aller savoir pourquoi... Ca a fonctionné à la deuxième fois...

Cependant, impossible de resigner les paquets via la console (message "Read timed out" dès qu'un paquet fait + de 400 MB)...
Et évidemment, aucune doc expliquant comment les resigner autrement depuis le serveur (Windows) contrairement à sous Linux...

Je m'attendais à avoir des problèmes lors de la mise à jour en 2.0 mais à ce point là... Je suis plutôt déçu...

Pas très fiable.

Je vais donc probablement devoir payer des tickets de support seulement pour passer en version 2.0... Et franchement, je trouve ça un peu fort... :roll:

Une solution meilleur marché serait de rebuild les paquets ne passant pas... Ca va prendre du temps mais c'est surement ce que je vais faire pour m'éviter 900 euros de ticket...
jacky35
Messages : 12
Inscription : 17 sept. 2020 - 17:51

10 juin 2021 - 15:55

Dans le fichier Nginx - /etc/nginx/sites-enabled/wapt.conf
Fait attention il y a deux endroits ou on retrouve client_max_body_size.

Après je ne sais pas pourquoi Tranquil IT ne mais pas par défaut cette option en client_max_body_size 0;
Mais il y a certainement une raison.

J'ai un peu cherché pourquoi mon paquet windows10-upgrade-data ne voulait pas s'uploader correctement sur le serveur WAPT ;)

Jacky
Christophe0110 a écrit : 09 juin 2021 - 11:04 Bonjour,


Je me suis enfin décidé à prendre le temps de passer ma version WAPT 1.8.2 Entreprise vers WAPT 2.0 Entreprise.

J'utilise 2 serveurs :
- Un serveur de test sous Debian 10.
- Un serveur de prod sous Windows Server.

J'ai commencé, en toute logique, par la mise à jour du serveur de test sous Debian.
Après quelques problèmes rencontrés durant la mise à jour, j'ai réussi à passer sous WAPT 2.0 avec succès.

Vient alors la resignature des hosts et des paquets.
Coté hosts, aucun problème.
Coté paquets, via la console, plusieurs erreurs "Read timeout" sur plusieurs paquets (les plus volumineux faisant, pour certains, plus de 4 GB).
J'ai donc suivi la méthode de la doc en essayant un resign directement depuis le serveur par commande.
Plusieurs paquets n'étant pas passés au départ sont passés sauf 3 d'entre eux faisant 5,7 GB ; 5,7 GB et 6,6 GB.
L'erreur affichée est la suivante : BadZipFile('Bad magic number for file header').

J'ai déjà souvent rencontré cette erreur lors du déploiement de gros paquets et j'avais pu éviter cette erreur en éditant le paramètre client_max_body_size dans le fichier /etc/nginx/sites-enabled/wapt.conf du serveur. Le fichier est toujours bien configuré (il n'a pas changé suite à la mise à jour) et le problème reste présent malgré tout.

Avez-vous une idée pour me permettre de passer ces paquets sans devoir faire un rebuild et donc une nouvelle version qui provoquera une mise à jour sur tous les postes (et vu la taille du paquet, j'ai pas vraiment envie de passer par là) ?

Merci.
Christophe0110
Messages : 50
Inscription : 11 juin 2019 - 12:04

11 juin 2021 - 13:59

Merci pour ta réponse jacky35 !

Oui, sous linux j'avais pu éditer ce fichier et les 2 endroits.

Sous windows, j'ai trouvé un fichier (avec seulement un endroit dans le fichier) où se trouvait ce paramètre.

Cependant, ça ne change rien, le console WAPT semble définitivement allergique aux paquets volumineux.
Je ne comprends pas, je ne dois quand même pas être le seul avec des paquets de plus de 400MB...

Mais bon, tant pis, je vais devoir faire comme j'ai dis et faire un rebuilt des 11 paquets ne passant pas...
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 680
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

15 juin 2021 - 10:49

Christophe0110 a écrit : 09 juin 2021 - 11:04 J'ai déjà souvent rencontré cette erreur lors du déploiement de gros paquets et j'avais pu éviter cette erreur en éditant le paramètre client_max_body_size dans le fichier /etc/nginx/sites-enabled/wapt.conf du serveur. Le fichier est toujours bien configuré (il n'a pas changé suite à la mise à jour) et le problème reste présent malgré tout.
Si le client_max_body_size dans nginx n'a pas été modifié suite à la mise à jour, c'est que vous n'avez pas lancé le postconf et donc pas suivi la procédure jusqu'au bout (le client_max_body_size n'est pas encore paramètrisé dans le template nginx).
Denis Cardon - Tranquil IT
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 680
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

15 juin 2021 - 10:52

jacky35 a écrit : 10 juin 2021 - 15:55 Dans le fichier Nginx - /etc/nginx/sites-enabled/wapt.conf
Fait attention il y a deux endroits ou on retrouve client_max_body_size.

Après je ne sais pas pourquoi Tranquil IT ne mais pas par défaut cette option en client_max_body_size 0;
Mais il y a certainement une raison.
le serveur doit bien stocker les fichiers quelques part en cache. Laisser des uploads illimité ça risque de saturer son espace temporaire sur disque ou sa ram dispo et donc se faire un DoS soit même. Donc oui il y a une raison. Par contre ce paramètre va être stocké dans le futur dans waptserver.ini pour être repris automatiquement dans le fichier de conf nginx.
Denis Cardon - Tranquil IT
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 680
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

15 juin 2021 - 10:53

Christophe0110 a écrit : 11 juin 2021 - 13:59 Merci pour ta réponse jacky35 !

Oui, sous linux j'avais pu éditer ce fichier et les 2 endroits.

Sous windows, j'ai trouvé un fichier (avec seulement un endroit dans le fichier) où se trouvait ce paramètre.

Cependant, ça ne change rien, le console WAPT semble définitivement allergique aux paquets volumineux.
Je ne comprends pas, je ne dois quand même pas être le seul avec des paquets de plus de 400MB...

Mais bon, tant pis, je vais devoir faire comme j'ai dis et faire un rebuilt des 11 paquets ne passant pas...
note : Il faut que le nginx ait suffisamment d'espace disque dispo pour stocker les chunks du fichier durant l'upload.
Denis Cardon - Tranquil IT
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Avatar de l’utilisateur
dcardon
Expert WAPT
Messages : 680
Inscription : 18 juin 2014 - 09:58
Localisation : Nantes
Contact :

15 juin 2021 - 11:06

Bonjour Christophe,
Christophe0110 a écrit : 10 juin 2021 - 10:22 Je vais donc probablement devoir payer des tickets de support seulement pour passer en version 2.0... Et franchement, je trouve ça un peu fort... :roll:

Une solution meilleur marché serait de rebuild les paquets ne passant pas... Ca va prendre du temps mais c'est surement ce que je vais faire pour m'éviter 900 euros de ticket...
Insider info : Tranquil IT est un éditeur, pas une SSII. On ne cherche pas à pousser à la vente de ticket, c'est pas notre principal centre de revenu (et de loin). Et je tiens à souligner que la majeure partie des demandes que l'on a au support sont documentée dans la doc WAPT, et donc d'une certaine manière ça sert plus à faire gagner du temps aux clients (le temps c'est de l'argent)... On essaye de prendre le maximum de cas de figure dans les process d'upgrade (et ça nous prend beaucoup de temps), mais on ne peut pas prendre en compte toutes les bizarreries que les gens font sur leur réseau (la créativité, nécessaire ou superflue, n'a pas de limite) ou prendre en compte toutes les erreurs que les gens font en suivant les procédures.

Cordialement,

Denis Cardon
Denis Cardon - Tranquil IT
Communiquez autour de vous sur WAPT! Envoyez nous vos url de blog et d'articles dans la catégorie votre avis du forum, nous les mettrons en avant sur le site WAPT
Christophe0110
Messages : 50
Inscription : 11 juin 2019 - 12:04

17 juin 2021 - 08:59

Bonjour,
dcardon a écrit : 15 juin 2021 - 10:49 Si le client_max_body_size dans nginx n'a pas été modifié suite à la mise à jour, c'est que vous n'avez pas lancé le postconf et donc pas suivi la procédure jusqu'au bout (le client_max_body_size n'est pas encore paramètrisé dans le template nginx).
Si on parle de la commande /opt/wapt/waptserver/scripts/postconf.sh , si, je l'ai bien lancée et j'ai bien suivi la procédure jusqu'au bout.
J'ai donc bien lu (toujours dans la procédure), l'indication suivante juste au-dessus de la commande :
si vous avez personnalisé la configuration de Nginx, ne pas répondre Oui lorsque postconf vous demande de configurer Nginx
Puisque c'était le cas, je n'ai donc pas répondu "Oui" et donc, c'est probablement la raison pour laquelle la configuration de nginx n'a pas changée dans mon cas...
dcardon a écrit : 15 juin 2021 - 10:53 note : Il faut que le nginx ait suffisamment d'espace disque dispo pour stocker les chunks du fichier durant l'upload.
Si on parle de la place restante sur le serveur Windows sur lequel est installé WAPT, il reste 443 GB d'espace libre... Je ne pense pas, du coup, que ce soit la cause du problème.
dcardon a écrit : 15 juin 2021 - 11:06 Bonjour Christophe,

Insider info : Tranquil IT est un éditeur, pas une SSII. On ne cherche pas à pousser à la vente de ticket, c'est pas notre principal centre de revenu (et de loin). Et je tiens à souligner que la majeure partie des demandes que l'on a au support sont documentée dans la doc WAPT, et donc d'une certaine manière ça sert plus à faire gagner du temps aux clients (le temps c'est de l'argent)... On essaye de prendre le maximum de cas de figure dans les process d'upgrade (et ça nous prend beaucoup de temps), mais on ne peut pas prendre en compte toutes les bizarreries que les gens font sur leur réseau (la créativité, nécessaire ou superflue, n'a pas de limite) ou prendre en compte toutes les erreurs que les gens font en suivant les procédures.

Cordialement,

Denis Cardon
Je ne considère pas faire des bizarreries avec mes paquets. Ils sont plutôt basiques et lorsque je veux déployer en masse un paquet AutoCad (et je ne dois pas être le seul dans le cas), ça me parait logique que le paquet fasse plus de 400MB... Et pour ce qui est de suivre la procédure, je peux vous dire que je l'ai suivie à la lettre (et dans le cas du serveur Windows, 2 fois comme je l'ai expliqué plus haut). Je ne suis pas contre payer pour des tickets de support dans le cas où j'aurais du réinstaller un serveur et que je rencontrais une difficulté ou encore lorsque j'essaye de réaliser un paquet qui ne fonctionne pas. Mais devoir payer du support pour une mise à jour qui ne fonctionne pas en suivant pourtant bien la doc, je ne trouve pas ça normal. C'est juste mon avis.


Christophe.
Avatar de l’utilisateur
vcardon
Expert WAPT
Messages : 187
Inscription : 06 oct. 2017 - 22:55
Localisation : Nantes, FR

18 juin 2021 - 17:17

Pourtant la documentation spécifie bien qu'un serveur Linux est mieux adapté pour de la production.

J'interviens ici pour bien insister auprès des lecteurs qui tomberaient sur ce billet qu'un serveur WAPT fonctionnant avec Windows est une facilité accordée et non un engagement.

Vous avez la solution à votre problème dans votre premier post. Pourquoi ne pas utiliser Debian10 pour votre prod, comme vous le faites avec réussite pour votre preprod ? Si votre management insiste pour utiliser un OS supporté pour votre prod, alors RedHat sera votre meilleur choix.
Vincent CARDON
Tranquil IT
Répondre