Forum Tranquil IT

Bonjour,

Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Postgres 11.2

Ce ticket fait suite au ticket viewtopic.php?t=3766

La version 2.5.4 a résolu le problème d'erreur rencontré pendant l'exécution du script de post configuration. Le serveur est bien migré en 2.5.4.15337 :
Version WAPT Server : 2.5.4.15337
Version WAPT Agent : 2.2.3.12463
Version WAPT Setup : 2.5.4.15337
Version WAPT Deploy : 2.5.4.15337
Statut de la base : OK

Je rencontre maintenant un problème avec la console que j'ai télécharger depuis le serveur, et installé après avoir désinstallé la version 2.2.3 :
1) WAPTConsole indique la version Discovery alors que nous avons une licence Enterprise
2) L'inventaire est vide ainsi que le dépôt privé

J'ai mis en pièce jointe les logs du service Pouvez vous svp m'aider à comprendre d'où peut venir le problème ? Je vous remercie.

Cordialement,

Bonjour Mohamed,

il semble que le client n'arrive pas à se connecter au serveur (au moins la partie socketio).

Est ce que vous avez bien relancé le postconf après l'upgrade?

Cordialement,

Denis

bonjour Denis,

qu'appelez-vous postconf ?
j'ai aussi upgradé en 2.5.4.15342 (attendant une certaine stabilité) et ma console est vide (poste non connectés)

cordialement,

Bonjour David,

version etc. (cf. forum rules). Est ce que l'inventaire est vide ou bien les postes sont en déconnectés? Si la console est vide, c'est pas le même bug, merci d'ouvrir un nouveau topic. Si vous êtes sous WAPTServer sous Windows (ce qui n'est pas mentionné), il n'y a pas de script postconf à lancer car il est lancé par l'installeur Windows.

Cordialement,

Denis

pardon pardon: wapt sous windows (version 2.5.4.15342)

console dans laquelle tous les postes sont déconnectés (cf image jointe). Cependant, il semble que la tâche d'upgrade de l'agent soit en cours de déploiement, donc je vais attendre le redémarrage des postes.

désolé je l'ai vu après. il semble que j'ai laissé la case cochée de vérifier le certificat...

je ferai un update demain matin selon comment évolue le parc. Sinon, je ferai un retour arrière.

cdlt

Bonjour David,

ok pour le serveur sous Windows. Le postconf est un script qu'on lance à la fin de l'install / mise à jour pour le serveur WAPT sous Linux.

Le log de la capture d'écran en question était pour votre dernière mise à jour 2.4.0. Est ce vous pourriez essayer de lancer l'upgrade en ligne de commande sur un poste :
Est ce que vos agents étaient configurés en http ou en https? Si en https, c'était avec ou sans vérification de certificat?

Cordialement,

Denis

dcardon a écrit : ↑15 févr. 2024 - 15:56 Bonjour Mohamed,

il semble que le client n'arrive pas à se connecter au serveur (au moins la partie socketio).

Est ce que vous avez bien relancé le postconf après l'upgrade?

Cordialement,

Denis

Bonjour Denis,

Je m'excuse de la réponse tardive.
Oui j'ai bien lancé le postconfig qui s'exécute sans erreurs. Donc ce problème est résolu par rapport à la version 2.5.
Par contre dans les infos du certificat affiché à la fin, les FQDN affichés ne correspondent pas au FQDN dans l'url du serveur. Les noms sont différents. Est ce que c'est de là que vient le problème de connexion de la console en 2.5.4 ?

Par contre j'ai pu connecter la console installée sur mon poste et son agent en changeant dans l'url (https) le nom du serveur par son adresse ip et en désactivant la vérification du certificat (verify_cert=0).
Dans la console tous les postes (en 2.2.3) sont déconnectés car ils tentent toujours de se connecter avec le FQDN paramétré dans leur ini.

Que me conseillez vous pour résoudre le problème ? Je vous remercie.

N'hésitez pas à me demander si vous avez besoin d'autre info,. Merci.

Cordialement,

bonjour à tous,

pour ma part, j'ai restauré une VM avant mise à jour (oui mea culpa j'aurai dû faire un snapshot.... aïe pas taper )
Puis j'ai redéployé un fichier ini afin de mettre ces deux variables à 0 puis relancer le service wapt.

check_certificates_validity=0
verify_cert=0

Les postes se sont reconnectés progressivement
Enfin j'ai aussi poussé par GPO la nouvelle version de l'agent.

Je pense que lorsque j'ai fait la première mise à jour j'ai dû laissé la case cochée sur le certificat et cà m'a mis le bazar.
Voilà, une semaine après, c'est stable, mais heureusement que je n'ai pas 3000 machines

cdlt