Bonjour,
voici la configuration qui fonctionne chez nous.
waptdeploy à l'ouverture et fermeture de sessions.
Avec comme paramètre :
waptdeploy.exe --hash=hash --waptsetupurl=http://serveur/wapt/waptagent.exe --minversion=1.8.1.6742 --wait=15
waptdeploy stocké
\domaine.dom\SysVol\domaine.dom\Policies{ID GPO}\Machine\Scripts\Startup
Sur certains postes il a fallu forcer la GPO.
Si cela peux aider.
Bonne journée,
----------------------------------------------------------------------------------------------
*Gaëtan SEGAT * Gestionnaire Parc Informatique Inserm| DRSI Toulouse CHU Purpan – BP 3048 | 31024 Toulouse cedex 3 Tél. 05 62 74 83 58
Le 02/03/2020 à 15:03, Evan BLAUDY a écrit :
Bonjour Jordi,
Tout d'abord merci pour ton retour minutieux.
Cela tombe bien je travaille sur un refactoring à ce niveau là !
Je te répond point par point dans ton message :)
Le 27/02/2020 à 13:02, MORILLO Jordi a écrit :
Bonjour à tous,
Voici mon retour d’expérience d’une migration 1.7 à 1.8 :
Avant la migration de wapt, j’ai migré d’une Stretch à une Buster sans aucun soucis. Par ailleurs, en suivant les préco concernant la ré-indexation, j’ai pu mettre à jour le moteur PostgreSQL également sans soucis (https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en...)
-local_repo_sync_task_period : la doc en ligne https://www.wapt.fr/fr/doc/wapt-replication/wapt-replicate-to-multiple-repositories/index.html indique qu’il faut définir une valeur en minutes (ex : 25) alors que les commentaires du packages tis-repo-conf https://wapt.tranquil.it/store/details-tis-remote-repo-conf_1-1.wapt indique qu’il est possible de mettre des valeurs de type « 10m » (10 minutes) ou bien « 1d » (1 day). La doc serait en retard ou bien le package est en avance ? J
La doc est bel et bien en retard ! (On peut d'ailleurs aussi mettre "10h" pour toutes les 10h, "1w" pour toutes les semaines). Par défaut, c'est toutes les 10 minutes (donc "10m"). Après modifier ce paramètre n'est à faire que dans des cas précis, l'agent ne fait qu'une requête HEAD sur le fichier sync.json du serveur s'il n'y a pas eu de changements de celui-ci. Ce n'est pas non plus hyper consommateur. C'est plus au niveau des plages horaires qu'il faut faire du paramétrage si l'on veut désactiver la synchro pendant une période donnée. Je vais voir pour rallonger ce paramètre toutes les 2h car comme on va le voir dans le point suivant il n'est pas très utile!
D'ailleurs petit point de précision pour le paquet tis-remote-repo-conf https://wapt.tranquil.it/store/tis-remote-repo-conf: si jamais vous laissez à None une des valeurs du dictionnaire conf cela ne mettra rien dans le wapt-get.ini et prendra donc les valeurs par défaut.
-Concernant ce même sujet de synchro, mes dépôts secondaires sont configurés avec la valeur « 30m ». Si je pousse un nouveau package depuis la console, tous mes dépôts secondaires récupèrent immédiatement ce nouveau package. Est-ce normal ? cela ne devrait-il pas respecter la valeur de local_repo_sync_task_period ?
Oui, car si une connexion websocket est trouvée depuis le serveur vers l'agent alors le serveur va dire à l'agent de se synchroniser ! Il est vrai que le paramètre précédent n'est que très peu utile. Cependant si vous avez paramétré local_repo_sync_task_start et stop si jamais il n'est pas dans la plage l'agent ne se synchronisera pas. On peut donc comprendre que si la plage est de 21h à 22h avec une périodicité de 10 minutes, au maximum il réessaiera 6 fois (dans les faits un peu moins car il faut déduire le temps passé à faire la synchro). Je vois donc deux choses à améliorer : mettre par défaut 2h pour local_repo_sync_task_period et ajouter un paramètre dans le waptserver.ini (donc côté serveur) qui permet de désactiver le fait que le serveur "prévienne" les agents qu'il faut qu'ils se synchronisent.
-Mes dépôts secondaires utilisent un certificat wildcard sur l’HTTPS. Je vous propose le petit « bypass » suivant dans le package https://wapt.tranquil.it/store/details-tis-remote-repo-nginx_1-1_linux.wapt:
oLigne 96 : « if crt.cn != fqdn: » à transformer en « if crt.cn != fqdn and crt.cn[0] != '*': »
Cela évitera la création de nouveaux certificat/clé en cas de détection d’un certificat wildcard dans /opt/wapt/ssl/
-Pour ceux et celles qui utiliseraient les serveurs des dépôts secondaires pour héberger d’autres sites, je vous propose la modif suivante dans le fichier wapt.nginxconfig.template du package tis-remote-repo-nginx :
oRemplacer les 2 « server_name _ ; » par « serveur_name {{ fqdn }} ; »
Cela permettra d’héberger d’autres VirtualHost plus proprement
Bonne idée je vais voir pour intégrer cela dans le tis-remote-repo-nginx pour Linux. Dans windows c'est dénué d'intérêt.
-Le plus gros problème rencontré à mes yeux est le suivant :
oj’avais déjà des dépôts secondaires avec du nginx et du rsync. Le répertoire web associé à wapt est /var/www/wapt/
oSur ces dépôts, j’installe l’agent linux. Tous mes dépôts remontent dans la console, parfait !
oJ’installe sur ces dépôts les packages remote-repo-conf + remote_repo_nginx dont remote-repo-conf contient 'local_repo_path': « /var/www/wapt/ »,
oA la fin de l’installation des 2 packages, les dépôts se resynchronisent immédiatement MAIS retéléchargement l’intégralité dans /opt/wapt/repository !!
ole process waptservice n’a pas été restart à la fin de l’installation des 2 packages repo et par conséquent, le process resynchronise tout sur /opt/wapt/repository avec un download conséquent à la clé
oPour pallier à ce download massif non désiré, il suffit juste de restart le process waptservice a la fin de l’installation des 2 packages, afin que celui-ci interprète bien la valeur 'local_repo_path' du fichier /opt/wapt/wapt-get.ini.
oDans ce cas, pas besoin de download massif, seulement un calcul des SHA… J
§Peut-être faudrait-il implémenter un waptservice restart dans le package remote-repo-conf ou bien préciser cette subtilité dans la doc ?
Pour ce cas précis tu avais bien paramétré dans le wapt-get.ini dans la section [repo-sync] les deux en même temps ? (à savoir enable_remote_repo et local_repo_path en même temps).
Si non c'est normal puisque /opt/wapt/repository c'est le local_repo_path par défaut sous un agent Linux. La synchro aurait donc démarré avec la paramètre par défaut.
Si oui, peut-être à vérifier que la synchro arrive à se lancer entre le moment ou enable_remote_repo est paramétré et local_repo_path. Mais cela me semble étonnant. Je vais faire des tests. Si jamais c'est le cas une autre solution est de paramétrer local_repo_path avant enable_remote_repo donc d'inverser l'ordre dans le dict de tis-remote-repo-conf. Si jamais j'obtiens le même problème je proposerai une solution dans le paquet.
-Quelques petites modifications à apporter dans la doc :
oSur la page https://www.wapt.fr/fr/doc/wapt-replication/wapt-replicate-to-multiple-repos..., il faudrait remonter la section « Utiliser des règles de dépôt sur les agents WAPT » plus haut car c’est une étape nécessaire à effectuer, avant toute chose.
oSur la page https://www.wapt.fr/fr/doc/wapt-configuration/wapt-deploy/waptagent-linux.ht..., indiquer que si le certificat est signé par une autorité publique, verify_cert doit être à 1 (verify_cert=1)
Pour le moment, je n’ai pas encore compilé l’agent 1.8 pour mes postes clients.
La suite au prochain épisode, en espérant que mes remarques vous seront utiles J
Bien cordialement
Jordi
WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
En tout cas merci pour toutes tes remontées !
Bonne continuation :)
-- *Evan BLAUDY, Développeur* Tranquil IT 12 avenue Jules Verne (Bât. A) 44230 Saint Sébastien sur Loire (FRANCE) tel: +33 (0) 240 975 755
/Retrouvez-nous sur les réseaux :/ twitter https://twitter.com/TRANQUIL_IT linkedin https://www.linkedin.com/company/3108003/ youtube
https://www.youtube.com/channel/UCl45FZItnoOlXsaWUa3UrTw
Tranquil IT https://youtu.be/dX_5vIvTvxM?t=564
WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt