[Wapt] Retour expérience migration 1.8

Mon Mar 2 15:03:26 CET 2020

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.html#postgresql-reindex)
>
>  
>
> -          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:
>
>
>  
>
> o   Ligne 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 :
>
> o   Remplacer 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 :
>
> o   j’avais déjà des dépôts secondaires avec du nginx et du rsync. Le
> répertoire web associé à wapt est /var/www/wapt/
>
> o   Sur ces dépôts, j’installe l’agent linux. Tous mes dépôts
> remontent dans la console, parfait !
>
> o   J’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/ »,
>
> o   A 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 !!
>
> o   le 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é
>
> o   Pour 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.
>
> o   Dans 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 :
>
> o   Sur la page
> https://www.wapt.fr/fr/doc/wapt-replication/wapt-replicate-to-multiple-repositories/index.html,
> 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.
>
> o   Sur la page
> https://www.wapt.fr/fr/doc/wapt-configuration/wapt-deploy/waptagent-linux.html,
> 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 at 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tranquil.it/pipermail/wapt/attachments/20200302/6373d730/attachment.html>