Ruhiges IT-Forum

Guten Morgen,

Distributor-ID: Debian
Beschreibung: Debian GNU/Linux 10 (buster)
Version: 10
Codename: Buster
Postgres 11.2

Dieses Ticket folgt dem Ticket viewtopic.php?t=3766

Version 2.5.4 behebt den Fehler, der bei der Ausführung des Nachkonfigurationsskripts auftrat. Der Server wurde erfolgreich auf Version 2.5.4.15337 migriert
WAPT-Serverversion: 2.5.4.15337
WAPT-Agent-Version: 2.2.3.12463
WAPT-Setup-Version: 2.5.4.15337
WAPT Deploy Version: 2.5.4.15337
Datenbankstatus: OK

Ich habe nun ein Problem mit der Konsole, die ich vom Server heruntergeladen und nach der Deinstallation von Version 2.2.3 installiert habe:
1) WAPTConsole zeigt die Discovery-Version an, obwohl wir eine Enterprise-Lizenz besitzen
2) Das Inventar ist leer, ebenso das private Schließfach

Ich habe die Serviceprotokolle angehängt Könnten Sie mir bitte helfen, die Ursache des Problems zu finden? Vielen Dank.

Aufrichtig,

Hallo Mohamed,

es scheint, als könne der Client keine Verbindung zum Server herstellen (zumindest nicht über Socket.IO).

Hast du postconf nach dem Upgrade neu gestartet?

Viele Grüße,

Denis

Hallo Denis,

was meinst du mit „postconf“?
Ich habe ebenfalls auf Version 2.5.4.15342 aktualisiert (und warte auf etwas Stabilität), aber meine Konsole ist leer (keine verbundenen Rechner).

Viele Grüße,

Hallo David,

Version usw. (siehe Forenregeln). Ist das Inventar leer oder sind die Workstations getrennt? Falls die Konsole leer ist, handelt es sich um einen anderen Fehler; bitte eröffne dazu ein neues Thema. Falls du WAPTServer unter Windows verwendest (was nicht erwähnt wurde), gibt es kein Postconf-Skript, da es vom Windows-Installer gestartet wird.

Viele Grüße,

Denis

Entschuldigung: Ich verwende wapt unter Windows (Version 2.5.4.15342)

in der Konsole, in der alle Arbeitsstationen vom Netzwerk getrennt sind (siehe beigefügtes Bild). Die Agentenaktualisierung scheint jedoch zu laufen, daher warte ich auf den Neustart der Arbeitsstationen.

Entschuldigung, ich habe es erst im Nachhinein bemerkt. Anscheinend hatte ich die Option „Zertifikat überprüfen“ aktiviert gelassen.

Ich melde mich morgen früh wieder, je nachdem, wie die Netzwerkverbindung ist. Ansonsten melde ich mich zurück.

Viele Grüße

Hallo David,

Für den Server unter Windows ist dies in Ordnung. Das Postconf-Skript wird am Ende der Installation/Aktualisierung des WAPT-Servers unter Linux ausgeführt.

Das Protokoll im betreffenden Screenshot stammt von Ihrem letzten Update, Version 2.4.0. Könnten Sie bitte versuchen, das Upgrade über die Befehlszeile auf einem Rechner auszuführen?
Waren Ihre Agenten für HTTP oder HTTPS konfiguriert? Falls HTTPS, mit oder ohne Zertifikatsprüfung?

Aufrichtig,

Denis

dcardon schrieb: ↑15. Feb. 2024 - 15:56 Uhr Hallo Mohamed,

es scheint, als könne der Client keine Verbindung zum Server herstellen (zumindest nicht über Socket.IO).

Hast du postconf nach dem Upgrade neu gestartet?

Viele Grüße,

Denis

Hallo Denis,

Ich entschuldige mich für die späte Antwort.
Ja, ich konnte die Postkonfigurationsdatei erfolgreich ausführen, sie läuft fehlerfrei. Daher ist dieses Problem im Vergleich zu Version 2.5 behoben.
Die in den Zertifikatsinformationen am Ende angezeigten FQDNs stimmen jedoch nicht mit den FQDNs in der Server-URL überein. Die Namen sind unterschiedlich. Könnte dies die Ursache für das Problem mit der Konsolenverbindung in Version 2.5.4 sein?

Ich konnte jedoch die auf meinem Rechner installierte Konsole und ihren Agenten verbinden, indem ich den Servernamen in der URL (https) durch die IP-Adresse ersetzte und die Zertifikatsprüfung deaktivierte (verify_cert=0).
In der Konsole sind alle Stationen (in 2.2.3) getrennt, weil sie immer noch versuchen, eine Verbindung mit dem in ihrer ini konfigurierten FQDN herzustellen.

Was raten Sie mir, um das Problem zu lösen? Vielen Dank.

Bei weiteren Fragen stehe ich Ihnen gerne zur Verfügung. Vielen Dank.

Aufrichtig,

Hallo zusammen,

ich habe vor dem Update eine VM wiederhergestellt (ja, mea culpa, ich hätte einen Snapshot machen sollen... autsch, nicht hauen! )
. Anschließend habe ich eine INI-Datei neu bereitgestellt, um die beiden Variablen

`check_certificates_validity=0`
und `verify_cert=0`

Die Maschinen haben sich nach und nach wieder verbunden.
Schließlich habe ich auch die neue Agentenversion per Gruppenrichtlinie verteilt.

Ich glaube, dass ich beim ersten Update die Option für das Zertifikat aktiviert gelassen habe, und das hat die Probleme verursacht.
Eine Woche später läuft es jetzt stabil, aber zum Glück habe ich nicht 3000 Maschinen.

Viele Grüße.