Es ist nicht möglich, einen internen Server als externes Repository hinzuzufügen

[TomTomGo]

Guten Morgen,

Seit dem Update eines WAPT-Servers von Version 2.4 auf 2.5.5.15697 kann ich diesen Server nicht mehr als externes Repository von einem anderen Server hinzufügen, der ebenfalls in Version 2.5.5.15697 läuft (in Version 2.4 funktionierte dies einwandfrei).
Repository-Konfiguration:

Repoconf.png (20,99 KB) 4015 Aufrufe

Wenn wir versuchen, ein Paket aus diesem Repository zu importieren:

Repoconf3.png (6 KB) 4015 Aufrufe

Ich gehe daher davon aus, dass dies mit der Aktivierung der SSL-Clientauthentifizierung seit Version 2.5 zusammenhängt, sehe aber nicht, wie die Administrationskonsole eines Servers A durch Hinzufügen eines externen Repositorys zu einem Server B authentifiziert werden kann. Die Agenten der an ihre jeweiligen Server angeschlossenen Maschinen funktionieren auf der Ebene der SSL- und Kerberos-Clientauthentifizierung korrekt.

Umgebung: WAPT Debian 11 Server (aktuell), WAPT 2.5.5.15697 Discovery
Betriebssystem des Administrationsrechners: Windows Server 2019 (aktuellste Version)

Vielen Dank und einen schönen Tag noch

[dcardon]

Hallo Thomas,

du hast das Problem richtig erkannt. Die Clientzertifikatsauthentifizierung wird derzeit in der Paketimportschnittstelle nicht unterstützt. Die einfachste Lösung ist meiner Meinung nach, einen zweiten virtuellen Host auf dem Server ohne Clientzertifikatsauthentifizierung, aber mit Einschränkungen der Quell-IP-Adresse zu definieren und die anderen Server darauf zu verweisen.

Normalerweise ist die Einrichtung mehrerer WAPT-Server nur in sehr großen Organisationen mit delegierten Zugriffsrechten erforderlich. Bei entfernten Standorten empfiehlt es sich, sekundäre Repositories einzurichten und die Aktualisierung des Inventars zentral auf demselben Server durchzuführen.

Alternativ stehen in der Enterprise-Version Skripte zur Synchronisierung zwischen WAPT-Servern zur Verfügung.

Viele Grüße,

Denis

[TomTomGo]

Hallo Denis,

ja, das hatte ich vermutet, danke für die Bestätigung.
Ich werde mir die VHOST-Lösung ansehen. Ansonsten habe ich eine etwas unsaubere, aber temporäre Lösung gefunden: Ich habe das Clientzertifikat und den privaten Schlüssel von „C:\Program Files (x86)\wapt\private“ auf Server A abgerufen und auf Server B kopiert. Anschließend habe ich sie in den Repository-Einstellungen unter „Erweiterte Einstellungen > Pfad zum Client-SSL-Zertifikat“ und „Erweiterte Einstellungen > Pfad zum Client-SSL-Schlüssel“ hinterlegt.
Wir arbeiten mit einer etwas veralteten Methode: Wir verwenden einen WAPT-Server für die Entwicklung, um Pakete auf einigen Rechnern zu testen, bevor wir sie auf den WAPT-Server für die Produktion importieren. Mir ist bewusst, dass dies nicht optimal ist, und ich dränge meine Vorgesetzten regelmäßig dazu, auf einen Enterprise-Server mit all seinen zusätzlichen Funktionen umzusteigen, aber nun ja …

Schönen Tag noch!

[vCardon]

Guten Abend TomTomGo,

wir möchten Sie natürlich weiterhin ermutigen, Ihre Entscheidungsträger von einem Upgrade auf Enterprise zu überzeugen. Da Sie in La Chapelle-sur-Erdre ansässig sind, können wir Sie gerne persönlich dabei unterstützen – oder umgekehrt.

Kurzfristig scheint das Konzept der „Reife“ Ihre Anforderungen zu erfüllen.

Wenn Sie in diesem Forum nach diesem Begriff suchen, finden Sie zahlreiche Beiträge, die die Notwendigkeit diskutieren, Pakete zunächst in einem kleinen Teil des Netzwerks zu testen, bevor sie flächendeckend eingeführt werden, ohne dass ein zweiter WAPT-Server erforderlich ist.

[TomTomGo]

Hallo Vincent,

vielen Dank für deine Nachricht. Wir wohnen ja quasi in der Nachbarschaft und werden uns bezüglich einer Firmenplatzierung gerne direkt mit dir in Verbindung setzen.

In der Zwischenzeit werde ich mir die Option „Reifegrad“ ansehen, die ich zwar schon kannte, aber bisher noch nicht näher geprüft habe.

Schönen Tag noch.

Herzliche Grüße,

Thomas