[Wapt] Suite et fin de ma migration 1.3 -> 1.5 : quelques bugs à remonter
Hubert TOUVET
htouvet at tranquil.it
Mon Aug 27 10:07:52 CEST 2018
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 at lists.tranquil.it
> http://lists.tranquil.it/listinfo/wapt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tranquil.it/pipermail/wapt/attachments/20180827/cdb37d6e/attachment.html>
More information about the WAPT
mailing list