Upgrade Serveur WAPT 2.6 → 2.7
Publié : 02 nov. 2026 - 17:00
Bonjour,
Nous préparons la migration de notre serveur principal WAPT Enterprise de la version 2.6.1.17870 vers la 2.7.0.19598.
Contexte : environ 3 400 postes, un serveur principal sous Debian [version], 9 sites équipés d'un dépôt secondaire, authentification de la console et du Self-Service via l'AD.
Serait-il possible d'avoir votre retour sur les points suivants ?
Compatibilité pendant la transition
1. Des agents 2.6 restent-ils pleinement fonctionnels (inventaire, installation de paquets, audit, WUA) face à un serveur 2.7.0.19598 ? Pendant combien de temps cette situation mixte est-elle supportée ?
2. Des consoles 2.6 peuvent-elles se connecter à un serveur 2.7 ?
3. Un retour arrière du serveur vers la 2.6 (snapshot ou pg_dump) est-il supporté si des agents 2.7 se sont déjà connectés ?
4. Quelle version viser : 2.7.0.19598 ou une version plus récente ? Les deux bugs de la 19593 (Self-Service en UPN, « database not opened » sur wapt-scanpackages) sont-ils bien corrigés, sans autre régression connue ?
Comptes, LDAP et Self-Service
La documentation de mise à jour indique :
5. Cette exigence est-elle déjà en vigueur en 2.6.1, ou ne s'applique-t-elle qu'à partir de la 2.7 ? Si elle s'applique déjà, comment se fait-il qu'un Self-Service en bind simple fonctionne encore chez nous aujourd'hui ?
6. Est-elle limitée au Self-Service, ou concerne-t-elle aussi l'authentification des administrateurs dans la console ?
7. Existe-t-il une procédure documentée de migration depuis un bind LDAP simple : paramètres de waptserver.ini à modifier, contenu de /etc/krb5.conf, prérequis côté AD (compte de service, keytab, jonction au domaine) ?
8. Kerberos et SASL GSSAPI sont-ils tous deux utilisables avec un serveur qui n'est pas joint au domaine ? Lequel conseillez-vous ?
9. Peut-on préparer et tester cette configuration sur le serveur encore en 2.6.1, pour ne pas cumuler les changements le jour de l'upgrade ?
10. user_acls_fallback_without_domain = True : ce paramètre est-il supporté et recommandé pendant la transition ? Jusqu'à quelle version restera-t-il disponible ?
Comportement des agents
11. Maturités additives : existe-t-il un moyen officiel de lister, avant l'upgrade, les paquets de configuration qui cumulent des maturities ?
12. Le renommage ad_groups_use_nested_group → use_ad_nested_groups s'applique-t-il aussi dans wapt-get.ini ? L'ancien nom est-il encore lu en 2.7 ?
13. PATH Windows : seul <pf86>\wapt\bin est désormais ajouté. Existe-t-il une option pour conserver l'ancien comportement pendant la transition ?
Dépôts secondaires et ProxyCache
14. Calendrier : nous prévoyons de garder nos dépôts secondaires en 2.7.0, puis de migrer vers ProxyCache dans un changement séparé, avant de passer en 2.7.1. Ce séquencement vous paraît-il correct ? Pouvez-vous confirmer que les dépôts secondaires seront bien supprimés en 2.7.1, et qu'ils restent pleinement fonctionnels en 2.7.0 d'ici là ?
15. Existe-t-il une procédure officielle de migration d'un dépôt secondaire vers ProxyCache ? Faut-il d'abord désinstaller le dépôt secondaire, ou les deux peuvent-ils cohabiter le temps de la bascule ?
16. Quels flux et ports sont nécessaires (serveur de site vers serveur principal, poste vers serveur de site) ? Quelle URL faut-il saisir dans la liste d'URL de la règle ?
17. tis-proxycache est-il installable sur un serveur de site Debian existant ? Quelles dépendances apporte-t-il ?
18. Quel est le comportement quand « No fallbacks » est coché et que le serveur de site est indisponible ? Les postes basculent-ils vers le serveur principal ?
19. Des agents 2.6 peuvent-ils utiliser un ProxyCache 2.7 ? Des dépôts secondaires encore en 2.6 sont-ils utilisables avec un serveur principal en 2.7 ?
20. Comment retirer proprement un dépôt secondaire, côté console et côté serveur de site ?
21. Le ProxyCache intégré au serveur principal (question posée par le postconf) est-il utile dans notre cas, où chaque site dispose de son propre serveur ?
Sécurité et exploitation
22. Les données d'audit existantes sont-elles migrées à l'identique, puis purgées au-delà de 90 jours ? Les paramètres default_host_audit_data_expiration_days et max_package_log_size gardent-ils le même nom et le même fonctionnement ?
23. Quelle augmentation de RAM et de CPU faut-il prévoir avec uWSGI activé par défaut ? Existe-t-il un dimensionnement indicatif pour environ 3 400 postes ?
Merci d'avance pour vos retours.
Cordialement,
Nous préparons la migration de notre serveur principal WAPT Enterprise de la version 2.6.1.17870 vers la 2.7.0.19598.
Contexte : environ 3 400 postes, un serveur principal sous Debian [version], 9 sites équipés d'un dépôt secondaire, authentification de la console et du Self-Service via l'AD.
Serait-il possible d'avoir votre retour sur les points suivants ?
Compatibilité pendant la transition
1. Des agents 2.6 restent-ils pleinement fonctionnels (inventaire, installation de paquets, audit, WUA) face à un serveur 2.7.0.19598 ? Pendant combien de temps cette situation mixte est-elle supportée ?
2. Des consoles 2.6 peuvent-elles se connecter à un serveur 2.7 ?
3. Un retour arrière du serveur vers la 2.6 (snapshot ou pg_dump) est-il supporté si des agents 2.7 se sont déjà connectés ?
4. Quelle version viser : 2.7.0.19598 ou une version plus récente ? Les deux bugs de la 19593 (Self-Service en UPN, « database not opened » sur wapt-scanpackages) sont-ils bien corrigés, sans autre régression connue ?
Comptes, LDAP et Self-Service
La documentation de mise à jour indique :
Kerberos (recommandé) ou LDAP SASL bind over GSSAPI (2e choix) doivent être utilisés.Avec la version 2.6 de WAPT, Self-Service n'a plus besoin d'une simple authentification LDAP bind.
5. Cette exigence est-elle déjà en vigueur en 2.6.1, ou ne s'applique-t-elle qu'à partir de la 2.7 ? Si elle s'applique déjà, comment se fait-il qu'un Self-Service en bind simple fonctionne encore chez nous aujourd'hui ?
6. Est-elle limitée au Self-Service, ou concerne-t-elle aussi l'authentification des administrateurs dans la console ?
7. Existe-t-il une procédure documentée de migration depuis un bind LDAP simple : paramètres de waptserver.ini à modifier, contenu de /etc/krb5.conf, prérequis côté AD (compte de service, keytab, jonction au domaine) ?
8. Kerberos et SASL GSSAPI sont-ils tous deux utilisables avec un serveur qui n'est pas joint au domaine ? Lequel conseillez-vous ?
9. Peut-on préparer et tester cette configuration sur le serveur encore en 2.6.1, pour ne pas cumuler les changements le jour de l'upgrade ?
10. user_acls_fallback_without_domain = True : ce paramètre est-il supporté et recommandé pendant la transition ? Jusqu'à quelle version restera-t-il disponible ?
Comportement des agents
11. Maturités additives : existe-t-il un moyen officiel de lister, avant l'upgrade, les paquets de configuration qui cumulent des maturities ?
12. Le renommage ad_groups_use_nested_group → use_ad_nested_groups s'applique-t-il aussi dans wapt-get.ini ? L'ancien nom est-il encore lu en 2.7 ?
13. PATH Windows : seul <pf86>\wapt\bin est désormais ajouté. Existe-t-il une option pour conserver l'ancien comportement pendant la transition ?
Dépôts secondaires et ProxyCache
14. Calendrier : nous prévoyons de garder nos dépôts secondaires en 2.7.0, puis de migrer vers ProxyCache dans un changement séparé, avant de passer en 2.7.1. Ce séquencement vous paraît-il correct ? Pouvez-vous confirmer que les dépôts secondaires seront bien supprimés en 2.7.1, et qu'ils restent pleinement fonctionnels en 2.7.0 d'ici là ?
15. Existe-t-il une procédure officielle de migration d'un dépôt secondaire vers ProxyCache ? Faut-il d'abord désinstaller le dépôt secondaire, ou les deux peuvent-ils cohabiter le temps de la bascule ?
16. Quels flux et ports sont nécessaires (serveur de site vers serveur principal, poste vers serveur de site) ? Quelle URL faut-il saisir dans la liste d'URL de la règle ?
17. tis-proxycache est-il installable sur un serveur de site Debian existant ? Quelles dépendances apporte-t-il ?
18. Quel est le comportement quand « No fallbacks » est coché et que le serveur de site est indisponible ? Les postes basculent-ils vers le serveur principal ?
19. Des agents 2.6 peuvent-ils utiliser un ProxyCache 2.7 ? Des dépôts secondaires encore en 2.6 sont-ils utilisables avec un serveur principal en 2.7 ?
20. Comment retirer proprement un dépôt secondaire, côté console et côté serveur de site ?
21. Le ProxyCache intégré au serveur principal (question posée par le postconf) est-il utile dans notre cas, où chaque site dispose de son propre serveur ?
Sécurité et exploitation
22. Les données d'audit existantes sont-elles migrées à l'identique, puis purgées au-delà de 90 jours ? Les paramètres default_host_audit_data_expiration_days et max_package_log_size gardent-ils le même nom et le même fonctionnement ?
23. Quelle augmentation de RAM et de CPU faut-il prévoir avec uWSGI activé par défaut ? Existe-t-il un dimensionnement indicatif pour environ 3 400 postes ?
Merci d'avance pour vos retours.
Cordialement,