Suite et fin de ma migration 1.3 -> 1.5 : quelques bugs à remonter
Bonjour tous, Ayant pratiquement terminé ma migration 1.3 et 1.5, je souhaitais faire remonter les bugs suivants à l'équipe Wapt : 1. Bug de la double installation du package waptupgrade Le package waptupgrade check de manière erronée la version actuellement installée et dans certains cas, réinstalle l'agent alors que ce n'est pas nécessaire. Tous les infos pourront être trouvées dans le thread suivant : https://lists.tranquil.it/pipermail/wapt/2018-August/002888.html ainsi que ses réponses apportées (avec un patch tout crappy dans mon dernier post) 2. Bug de Lock ?? du fichier waptagent.exe lorsqu'il est hébergé sur un chemin UNC (sysvol) Lors de mes nombreux essaie de déploiement, j'ai tenté d'utiliser pendant un temps un script .bat qui avait pour paramètre --waptsetupurl=\\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe Si je lance à la main mon script sur une 1ere machine d'un site, tout se passe bien : WAPT version: 1.3.13.0 WAPT required version: 1.5.1.26 Wapt agent local path: \\pr.educationetformation.fr\sysvol\pr.educationetformati on.fr\Wapt\waptagent.exe SHA256 hash of downloaded setup file: 92f9[...] OK : Hash of waptagent match expected hash. Got version: 1.5.1.26 Install ... Si je lance en parallèle mon script sur une 2eme machine du même site (donc qui utilisera le même partage sysvol du même DC) : WAPT version: 1.3.13.0-1496 WAPT required version: 1.5.1.26 Wapt agent local path: \\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe Cleanup... An unhandled exception occurred at $00416608: EFOpenError: Unable to open file "\\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe" $00416608 $004164B0 $00440216 $004047C9 Dès que la 1ere machine a finie, et donc, a probablement libéré un LOCK sur le waptagent.exe, le script veut bien s'exécuter sur la 2eme machine. J'ai donc changé mon fusil d'épaule et j'ai spécifié un chemin https pour mon waptagent... Je n'ai malheureusement pas eu le temps de me pencher + sur ce problème 3. Bug sur la console du récapitulatif lors d'un upgrade Sur la console, si je sélectionne un poste Reachable et que je clique sur « Vérification des mises à jour », j'ai un message : « 1 actions launched, 0 errors, 0 skipped, 0 server errors ». Pas de problème Ensuite, je vérifie que le poste à bien terminé cette tâche, et en rafraichissant la console je vois qu'il y a des MAJ en attente. A ce moment, si je sélectionne le poste et que je clique sur « Lancer les installations », très souvent (80% du temps), le message affiché est : « 0 actions launched, 0 errors, 0 skipped, 0 server errors ». Pourtant, l'action upgrade est bien lancée et le poste se mets à jour.... 4. Bug du wapt-get qui interroge tous les dépots Ma topologie réseau est la suivante : le siège est en 10.1.0.0/16 et mes sites distants sont en 10.[2-20].0.0/16. Le serveur Wapt est en 10.1.4.80 (au siège) et tous les sites distants ont un dépôt en 10.X.76.203 Mes clients sont configurés avec : wapt_server= repo_url= dnsdomain=educationetformation.fr Etrangement, mes clients après avoir fait l'interrogation DNS, interrogent partiellement chacun des dépôts distants. Il en résulte non seulement une surcharge inutile du réseau mais aussi et surtout une certaine latence vu que de nombreux dépôts distants ont de petite liaison adsl. En pièces jointes, un exemple d'un wapt-get update -ldebug d'un poste situé au Siège (et donc qui devrait joindre directement et sans fioriture le serveur). J'ai également mis en capture d'écran la configuration DNS. 5. Wapt-get forget non documenté sur wapt-get -help J'ai découvert une commande « cachée » : wapt-get forget « nom du package » :) Ça serait cool un petit rajout dans wapt-get -help : https://github.com/tranquilit/WAPT/blob/master/wapt-get.py 70a71
forget <package> : forget installed packages
Par ailleurs, pour aider les autres utilisateurs, voici une liste des bugs « obscures » coté poste client que j'ai pu rencontrer : - Installation wapt 1.5 OK mais ensuite « pendule » permanente dans le champ « Reachable » -> Horloge pas à l'heure sur le poste client (sinon modifier le paramètre signature_clockskew sur le serveur) - GPO Startup qui ne s'applique pas + gpresult Acces Denied -> + de 259 caractères dans le paramètre de la commande - Et la dernière petite pépite pour la fin, un waptpython waptservice\waptservice -ldebug en tant que user System m'a ressurgir un vieux proxy oublié (et inactif) UNIQUEMENT sur le compte System ! Le paramétrage du proxy du compte system se trouve ici : HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections ... On en retrouve des belles parfois.... - Pour faire du debug d'une seule machine coté serveur : dans le fichier /etc/nginx/nginx.conf, dans la section events il faut rajouter l'ip a debug : events { worker_connections 768; debug_connection 192.168.1.45; } Bonne fin de vacances et bonne reprise à tous. Et longue vie à Wapt, encore un grand merci à toute la TranquilIt Team Bien cordialement
Bonjour Jordi, Merci pour ce travail. Nous regardons ce qui peut être fait pour améliorer les choses. Voir ci-dessous pour une première revue. Hubert Le 24/08/2018 à 14:52, MORILLO Jordi a écrit :
Bonjour tous,
Ayant pratiquement terminé ma migration 1.3 et 1.5, je souhaitais faire remonter les bugs suivants à l’équipe Wapt :
*1.****_Bug de la double installation du package waptupgrade_*
**
Le package waptupgrade check de manière erronée la version actuellement installée et dans certains cas, réinstalle l’agent alors que ce n’est pas nécessaire.
Tous les infos pourront être trouvées dans le thread suivant : https://lists.tranquil.it/pipermail/wapt/2018-August/002888.html ainsi que ses réponses apportées (avec un patch tout crappy dans mon dernier post)
C'est bizarre car dans setup.py, on splitte déjà sur le tiret : # get upgrade package informations *(package_wapt_version,package_packaging) = control.version.split('-')* package_packaging = int(package_packaging) if Version(installed_wapt_version,3) > Version(package_wapt_version,3): print('Your current wapt (%s) is more recent than the upgrade package (%s). Skipping...'%(installed_wapt_version,control.version)) Par contre, effectivement il y a réinstallation si les 3 premiers membres de la version sont identiques. je serais favorable à faire le test sur 4 membres avec >= : * if Version(installed_wapt_version,4) >= Version(package_wapt_version,4):** * print('Your current wapt (%s) is *same or more recent* than the upgrade package (%s). Skipping...'%(installed_wapt_version,control.version))
*2.****_Bug de Lock ?? du fichier waptagent.exe lorsqu’il est hébergé sur un chemin UNC (sysvol)_*
**
Lors de mes nombreux essaie de déploiement, j’ai tenté d’utiliser pendant un temps un script .bat qui avait pour paramètre --waptsetupurl=\\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe
Si je lance à la main mon script sur une 1ere machine d’un site, tout se passe bien :
/WAPT version: 1.3.13.0/
/WAPT required version: 1.5.1.26/
/Wapt//agent local path: \\pr.educationetformation.fr\sysvol\pr.educationetformati/
/on.fr\Wapt\waptagent.exe/
/SHA256 hash of downloaded setup file: 92f9[…]/
/OK : Hash of waptagent match expected hash./
/Got//version: 1.5.1.26/
/Install .../
Si je lance en parallèle mon script sur une 2eme machine du même site (donc qui utilisera le même partage sysvol du même DC) :
WAPT version: 1.3.13.0-1496
WAPT required version: 1.5.1.26
Waptagent local path: \\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe
Cleanup...
An unhandled exception occurred at $00416608:
EFOpenError: Unable to open file "\\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe"
$00416608
$004164B0
$00440216
$004047C9
Dès que la 1ere machine a finie, et donc, a probablement libéré un LOCK sur le waptagent.exe, le script veut bien s’exécuter sur la 2eme machine.
J’ai donc changé mon fusil d’épaule et j’ai spécifié un chemin https pour mon waptagent…
Je n’ai malheureusement pas eu le temps de me pencher + sur ce problème
ça doit dépendre des options de locks sur le partage windows. est-ce que ton partage est fait par un Windows ou un Samba ?
*3.****_Bug sur la console du récapitulatif lors d’un upgrade_*
**
Sur la console, si je sélectionne un poste Reachable et que je clique sur « Vérification des mises à jour », j’ai un message : « 1 actions launched, 0 errors, 0 skipped, 0 server errors ». Pas de problème
Ensuite, je vérifie que le poste à bien terminé cette tâche, et en rafraichissant la console je vois qu’il y a des MAJ en attente.
A ce moment, si je sélectionne le poste et que je clique sur « Lancer les installations », très souvent (80% du temps), le message affiché est : « 0 actions launched, 0 errors, 0 skipped, 0 server errors ».
Pourtant, l’action upgrade est bien lancée et le poste se mets à jour….
Je crois savoir d'où ciendrait ce problème. Si on lance Verification des mises à jour, les services Wapt des clients vont être occupés à récupérer l'index et vont réagir plus lentement pour prendre en compte la demande suivante (Lancer les installations). Le mécanisme des websockets est naturellement asynchrone. Donc l'acquittement que la commande a été prose en compte est un message envoyé par le client vers le serveur. Le serveur attend ce message d'acquittement peu de temps mais cela n'empêche pas l'action d'avoir été prise en compte. Entre l'envoi de la commande vers le client et le retour d'acquittement du client vers le serveur, le serveur positionne l'état de la machine avec la petite horloge, pour indiquer l'attente de l'acquittement.
4.*_Bug du wapt-get qui interroge tous les dépots_*
Ma topologie réseau est la suivante : le siège est en 10.1.0.0/16 et mes sites distants sont en 10.[2-20].0.0/16.
Le serveur Wapt est en 10.1.4.80 (au siège) et tous les sites distants ont un dépôt en 10.X.76.203
Mes clients sont configurés avec :
/wapt_server=/
/repo_url=/
/dnsdomain=educationetformation.fr/
Etrangement, mes clients après avoir fait l’interrogation DNS, interrogent partiellement chacun des dépôts distants.
Il en résulte non seulement une surcharge inutile du réseau mais aussi et surtout une certaine latence vu que de nombreux dépôts distants ont de petite liaison adsl.
*_En pièces jointes_*, un exemple d’un wapt-get update –ldebug d’un poste situé au Siège (et donc qui devrait joindre directement et sans fioriture le serveur). J’ai également mis en capture d’écran la configuration DNS.
Cela peut être considéré comme une régression... si un serveur / dépôt est dispo dans le même sous-réseau, il udrait éviter le scan des autres serveurs / dépôts trouvés dans la requête DNS. Le but initial était d'utiliser le temps d'interrogation (requête HEAD) de la date de Packages pour utiliser le dépôt disponible le plus réactif. Mais c'est dans ce cas une mauvaise idée. Nous avons dans la roadmap une feature qui vise à décrire explicitement dans la console pour chaque sous-réseau quels sont le serveurs / dépots à utiliser (à la manière des sites de l'Active Directory). Une autre évolution serait nécessaire. Actuellement, dans la base locale du client Wapt, chaque paquet a une seule URL de téléchargement, issue de la commande Update et du test au moment de l'update des dépôts disponibles. Il faudrait ne tester la disponibilité et calculer l'ordre de préférence parmi les dépots qu'au moment du téléchargement.
5.*_Wapt-get_**_forget non documenté sur wapt-get –help_*
*__*
J’ai découvert une commande « cachée » : wapt-get forget « nom du package » J
Ça serait cool un petit rajout dans wapt-get –help :
https://github.com/tranquilit/WAPT/blob/master/wapt-get.py
70a71
forget <package> : forget installed packages
Ajouté. Merci.
Par ailleurs, pour aider les autres utilisateurs, voici une liste des bugs « obscures » coté poste client que j’ai pu rencontrer :
-Installation wapt 1.5 OK mais ensuite « pendule » permanente dans le champ « Reachable » -> Horloge pas à l’heure sur le poste client (sinon modifier le paramètre signature_clockskew sur le serveur)
Voir point 4.
-GPO Startup qui ne s’applique pas + gpresult Acces Denied -> + de 259 caractères dans le paramètre de la commande
Demande spécifique à MS ;-)
-Et la dernière petite pépite pour la fin, un waptpython waptservice\waptservice –ldebug en tant que user System m’a ressurgir un vieux proxy oublié (et inactif) UNIQUEMENT sur le compte System !
Le paramétrage du proxy du compte system se trouve ici : HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections … On en retrouve des belles parfois….
Lié aussi à un bug dans la librairie client websocket python, qui utilise le proxy défini dans la base de registre même si on ne lui demande pas...
-Pour faire du debug d’une seule machine coté serveur : dans le fichier /etc/nginx/nginx.conf, dans la section events il faut rajouter l’ip a debug :
events {
worker_connections 768;
debug_connection 192.168.1.45;
}
Bonne fin de vacances et bonne reprise à tous.
Et longue vie à Wapt, encore un grand merci à toute la TranquilIt Team
Merci aux contributeurs.
Bien cordialement
_______________________________________________ WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
Bonjour Hubert, Voici quelques précisions en + : Sur le problème n°1 : Si je modifie comme ta suggestion (if Version(installed_wapt_version,4) >= Version(package_wapt_version,4)) Voici le résultat que j'obtiens : Your current wapt (1.5.1.26) is more recent than the upgrade package (1.5.1.26-8). A mon avis il y a un schmilblick quelques parts :-/ Sur le problème n°2 : Il s'agit d'un partage samba (4.7.6) déclaré très simplement : [sysvol] path = /var/lib/samba/sysvol read only = No guest ok = yes J'essayerai de faire ce même test sur un AD M$, voir si le problème persiste. Sur le problème n°3 : J'ai bien compris ton explication des websockets asynchrone mais le problème se produit également dans les 2 cas suivants : - J'édite une machine et ajoute un package, puis je clique sur « Enregistrer et appliquer » - J'édite une machine et ajoute un package, puis je clique sur « Enregister ». Je lance un update à partir de la console. J'attends 5min, je rafraichie la console. Aucune horloge a côté du poste en question, et celui-ci « voit » bien des MAJ en attente. Si je clique sur upgrade, il m'indique la plupart du temps 0 action launched. Pourtant, l'action est bien lancée sur le poste. Sur le problème n°4 : C'est donc dans les tuyaux d'une prochaine roadmap, cool :) merci beaucoup pour toutes tes explications ! Bonne semaine Bien cordialement Jordi De : WAPT <wapt-bounces@lists.tranquil.it> De la part de Hubert TOUVET Envoyé : lundi 27 août 2018 10:08 À : wapt@lists.tranquil.it Objet : Re: [Wapt] Suite et fin de ma migration 1.3 -> 1.5 : quelques bugs à remonter Bonjour Jordi, Merci pour ce travail. Nous regardons ce qui peut être fait pour améliorer les choses. Voir ci-dessous pour une première revue. Hubert Le 24/08/2018 à 14:52, MORILLO Jordi a écrit : Bonjour tous, Ayant pratiquement terminé ma migration 1.3 et 1.5, je souhaitais faire remonter les bugs suivants à l'équipe Wapt : 1. Bug de la double installation du package waptupgrade Le package waptupgrade check de manière erronée la version actuellement installée et dans certains cas, réinstalle l'agent alors que ce n'est pas nécessaire. Tous les infos pourront être trouvées dans le thread suivant : https://lists.tranquil.it/pipermail/wapt/2018-August/002888.html ainsi que ses réponses apportées (avec un patch tout crappy dans mon dernier post) C'est bizarre car dans setup.py, on splitte déjà sur le tiret : # get upgrade package informations (package_wapt_version,package_packaging) = control.version.split('-') package_packaging = int(package_packaging) if Version(installed_wapt_version,3) > Version(package_wapt_version,3): print('Your current wapt (%s) is more recent than the upgrade package (%s). Skipping...'%(installed_wapt_version,control.version)) Par contre, effectivement il y a réinstallation si les 3 premiers membres de la version sont identiques. je serais favorable à faire le test sur 4 membres avec >= : if Version(installed_wapt_version,4) >= Version(package_wapt_version,4): print('Your current wapt (%s) is same or more recent than the upgrade package (%s). Skipping...'%(installed_wapt_version,control.version)) 2. Bug de Lock ?? du fichier waptagent.exe lorsqu'il est hébergé sur un chemin UNC (sysvol) Lors de mes nombreux essaie de déploiement, j'ai tenté d'utiliser pendant un temps un script .bat qui avait pour paramètre --waptsetupurl=\\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe Si je lance à la main mon script sur une 1ere machine d'un site, tout se passe bien : WAPT version: 1.3.13.0 WAPT required version: 1.5.1.26 Wapt agent local path: \\pr.educationetformation.fr\sysvol\pr.educationetformati<file://pr.educationetformation.fr/sysvol/pr.educationetformati> on.fr\Wapt\waptagent.exe SHA256 hash of downloaded setup file: 92f9[...] OK : Hash of waptagent match expected hash. Got version: 1.5.1.26 Install ... Si je lance en parallèle mon script sur une 2eme machine du même site (donc qui utilisera le même partage sysvol du même DC) : WAPT version: 1.3.13.0-1496 WAPT required version: 1.5.1.26 Wapt agent local path: \\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe<file://pr.educationetformation.fr/sysvol/pr.educationetformation.fr/Wapt/waptagent.exe> Cleanup... An unhandled exception occurred at $00416608: EFOpenError: Unable to open file "\\pr.educationetformation.fr\sysvol\pr.educationetformation.fr\Wapt\waptagent.exe<file://pr.educationetformation.fr/sysvol/pr.educationetformation.fr/Wapt/waptagent.exe>" $00416608 $004164B0 $00440216 $004047C9 Dès que la 1ere machine a finie, et donc, a probablement libéré un LOCK sur le waptagent.exe, le script veut bien s'exécuter sur la 2eme machine. J'ai donc changé mon fusil d'épaule et j'ai spécifié un chemin https pour mon waptagent... Je n'ai malheureusement pas eu le temps de me pencher + sur ce problème ça doit dépendre des options de locks sur le partage windows. est-ce que ton partage est fait par un Windows ou un Samba ? 3. Bug sur la console du récapitulatif lors d'un upgrade Sur la console, si je sélectionne un poste Reachable et que je clique sur « Vérification des mises à jour », j'ai un message : « 1 actions launched, 0 errors, 0 skipped, 0 server errors ». Pas de problème Ensuite, je vérifie que le poste à bien terminé cette tâche, et en rafraichissant la console je vois qu'il y a des MAJ en attente. A ce moment, si je sélectionne le poste et que je clique sur « Lancer les installations », très souvent (80% du temps), le message affiché est : « 0 actions launched, 0 errors, 0 skipped, 0 server errors ». Pourtant, l'action upgrade est bien lancée et le poste se mets à jour.... Je crois savoir d'où ciendrait ce problème. Si on lance Verification des mises à jour, les services Wapt des clients vont être occupés à récupérer l'index et vont réagir plus lentement pour prendre en compte la demande suivante (Lancer les installations). Le mécanisme des websockets est naturellement asynchrone. Donc l'acquittement que la commande a été prose en compte est un message envoyé par le client vers le serveur. Le serveur attend ce message d'acquittement peu de temps mais cela n'empêche pas l'action d'avoir été prise en compte. Entre l'envoi de la commande vers le client et le retour d'acquittement du client vers le serveur, le serveur positionne l'état de la machine avec la petite horloge, pour indiquer l'attente de l'acquittement. 4. Bug du wapt-get qui interroge tous les dépots Ma topologie réseau est la suivante : le siège est en 10.1.0.0/16 et mes sites distants sont en 10.[2-20].0.0/16. Le serveur Wapt est en 10.1.4.80 (au siège) et tous les sites distants ont un dépôt en 10.X.76.203 Mes clients sont configurés avec : wapt_server= repo_url= dnsdomain=educationetformation.fr Etrangement, mes clients après avoir fait l'interrogation DNS, interrogent partiellement chacun des dépôts distants. Il en résulte non seulement une surcharge inutile du réseau mais aussi et surtout une certaine latence vu que de nombreux dépôts distants ont de petite liaison adsl. En pièces jointes, un exemple d'un wapt-get update -ldebug d'un poste situé au Siège (et donc qui devrait joindre directement et sans fioriture le serveur). J'ai également mis en capture d'écran la configuration DNS. Cela peut être considéré comme une régression... si un serveur / dépôt est dispo dans le même sous-réseau, il udrait éviter le scan des autres serveurs / dépôts trouvés dans la requête DNS. Le but initial était d'utiliser le temps d'interrogation (requête HEAD) de la date de Packages pour utiliser le dépôt disponible le plus réactif. Mais c'est dans ce cas une mauvaise idée. Nous avons dans la roadmap une feature qui vise à décrire explicitement dans la console pour chaque sous-réseau quels sont le serveurs / dépots à utiliser (à la manière des sites de l'Active Directory). Une autre évolution serait nécessaire. Actuellement, dans la base locale du client Wapt, chaque paquet a une seule URL de téléchargement, issue de la commande Update et du test au moment de l'update des dépôts disponibles. Il faudrait ne tester la disponibilité et calculer l'ordre de préférence parmi les dépots qu'au moment du téléchargement. 5. Wapt-get forget non documenté sur wapt-get -help J'ai découvert une commande « cachée » : wapt-get forget « nom du package » :) Ça serait cool un petit rajout dans wapt-get -help : https://github.com/tranquilit/WAPT/blob/master/wapt-get.py 70a71
forget <package> : forget installed packages
Ajouté. Merci. Par ailleurs, pour aider les autres utilisateurs, voici une liste des bugs « obscures » coté poste client que j'ai pu rencontrer : - Installation wapt 1.5 OK mais ensuite « pendule » permanente dans le champ « Reachable » -> Horloge pas à l'heure sur le poste client (sinon modifier le paramètre signature_clockskew sur le serveur) Voir point 4. - GPO Startup qui ne s'applique pas + gpresult Acces Denied -> + de 259 caractères dans le paramètre de la commande Demande spécifique à MS ;-) - Et la dernière petite pépite pour la fin, un waptpython waptservice\waptservice -ldebug en tant que user System m'a ressurgir un vieux proxy oublié (et inactif) UNIQUEMENT sur le compte System ! Le paramétrage du proxy du compte system se trouve ici : HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections ... On en retrouve des belles parfois.... Lié aussi à un bug dans la librairie client websocket python, qui utilise le proxy défini dans la base de registre même si on ne lui demande pas... - Pour faire du debug d'une seule machine coté serveur : dans le fichier /etc/nginx/nginx.conf, dans la section events il faut rajouter l'ip a debug : events { worker_connections 768; debug_connection 192.168.1.45; } Bonne fin de vacances et bonne reprise à tous. Et longue vie à Wapt, encore un grand merci à toute la TranquilIt Team Merci aux contributeurs. Bien cordialement _______________________________________________ WAPT mailing list WAPT@lists.tranquil.it<mailto:WAPT@lists.tranquil.it> http://lists.tranquil.it/listinfo/wapt
participants (2)
-
Hubert TOUVET -
MORILLO Jordi