Ruhiges IT-Forum

Hallo,

mein WAPT-Server läuft unter Debian mit WAPT-Version 1.5.1.21.

Ich teste gerade die Verwendung mehrerer Repositories. Ich bin Ihrer Dokumentation gefolgt:
https://www.wapt.fr/fr/doc/Replicate_Mu ... index.html.
Auf meinem Entwicklungsrechner (Windows 10) habe ich die Datei wapt-get.ini manuell aktualisiert. Da sie ursprünglich für die Verwendung des primären Repositorys konfiguriert war, habe ich die repo_url auf die Adresse des sekundären Repositorys geändert.
Anschließend habe ich den Rechner neu gestartet, um sicherzustellen, dass der gesamte WAPT-Dienst korrekt läuft.

Von diesem Entwicklungsrechner aus habe ich ein Paket erstellt, das die Repository-Adresse mithilfe von inifile_writestring automatisch aktualisiert, wie in Ihrer Dokumentation beschrieben. Ich habe dieses Paket per Build-Upload hochgeladen, was einwandfrei funktionierte.
Ich setze „einwandfrei“ in Anführungszeichen, da das Paket trotz meiner Änderungen an wapt-get.ini zwar an das primäre, aber nicht an das sekundäre Repository gesendet wurde. Die Synchronisierung des sekundären Repositorys verlief jedoch korrekt.
PROBLEM 1: Wapt-get scheint in der Konsole die Änderungen in der wapt-get.ini nicht zu berücksichtigen.

Hinweis: Ich habe absichtlich die Parameter der waptconsole.ini-Datei im Verzeichnis AppDATA\local meines Benutzers nicht geändert, um zu sehen, ob sie berücksichtigt werden, ob sich das Paket nach der Änderung der wapt-get.ini automatisch aktualisiert oder ob es nach der Paketinstallation mit inifile_writestring aktualisiert wird.

FRAGE: Liest wapt-get die wapt-get.ini-Datei anscheinend nicht? Liest es die waptconsole.ini-Datei im Benutzerverzeichnis? Wird die waptconsole.ini-Datei durch den Befehl inifile_writestring des Pakets aktualisiert, oder muss ich dies manuell (oder mit einem zusätzlichen Python-Befehl in setup.py) tun?

Wenn ich dieses Paket jedoch auf meinem Entwicklungsrechner (immer derselbe) über die Konsole (ebenfalls auf diesem Rechner gestartet) anwende, erhalte ich einen SSL-Fehler: „Fehler beim Abrufen des Paketindex von https://my-secondary-repo SSLError...“.
PROBLEM 2: Ich habe noch keine Möglichkeit gefunden, das (derzeit selbstsignierte) Zertifikat aus dem neuen Repository zu importieren.

Entschuldigung für den langen Beitrag; ich wollte alles in einem Beitrag zusammenfassen. Falls Sie separate Beiträge für jedes Problem bevorzugen, lassen Sie es mich wissen, dann werde ich das beim nächsten Mal berücksichtigen.

Vielen Dank im Voraus für Ihre Hilfe
.

Zur weiteren Erläuterung:

Ich habe diesmal versucht, das Paket über meine Konsole (WAPT-Administrations-PC) auf dem Entwicklungsrechner zu installieren, den ich in meinem vorherigen Beitrag erwähnt habe.
Es gab keine Fehlermeldungen, aber das Paket wurde weder in der Aufgabenliste (ausstehend, abgeschlossen oder fehlerhaft) noch im Tab „Allgemein“ angezeigt, auch nicht nach dem Aktualisieren.

wapt-get.exe liest die Datei wapt-get.ini für Befehle, die den lokalen Rechner betreffen (Aktualisieren, Aktualisieren, Installieren, Entfernen usw.)
, verwendet aber die Benutzerdatei „waptconsole.ini“ (sofern vorhanden; andernfalls wird wapt-get.ini verwendet) für Befehle zur Paketentwicklung (Erstellen von Vorlagen, Bearbeiten, Hochladen von Paketen usw.).

Mit der Option „-c“ kann die Verwendung der Konfigurationsdatei erzwungen werden.

Die Datei waptconsole.ini wird beim ersten Start der Wapt-Konsole aus der Datei wapt-get.ini erstellt, falls sie noch nicht existiert.

Danach haben Änderungen an wapt-get.ini keine Auswirkungen mehr auf waptconsole.ini.

Ein SSLError in einem Repository bedeutet in der Regel, dass die SSL-Zertifikatsprüfung fehlgeschlagen ist.

Um zu testen, ob dies der Fall ist, setzen Sie den Parameter "verify_cert=0" in der Datei wapt-get.ini

Wenn es funktioniert, überprüfen Sie das bereitgestellte Zertifikat:
Der Parameter verify_cert muss den Pfad zu einer ".pem"-Datei (ein oder mehrere "vertrauenswürdige" x509-Zertifikate im PEM-Format) angeben, die die Überprüfung der Serverzertifikatsignatur ermöglicht.

Der einfachste Fall ist das Abrufen der Serverzertifikatskette.
Der Befehl „wapt-get enable-check-certificate“ ruft die Zertifikatskette für den Wapt-Server (Parameter [global] / wapt_server) ab. Dies gilt jedoch nicht für sekundäre Repositories. Hier muss die Zertifikatskette manuell abgerufen werden.


Überprüfen Sie, ob der FQDN (mondepot.mondomaine.lan) des Servers oder Repositorys im Parameter repo_url tatsächlich der des Servers ist und dem Attribut "CN" (Common Name) des Serverzertifikats entspricht.

Wenn Sie ein separates Repository für Maschinenkonfigurationen deklariert haben (Abschnitt [wapt-host]), haben Sie das Zertifikat zur Überprüfung der Verbindung zum Repository deklariert?
Oder

Erlauben Sie mir, mich anzuschließen

Ich glaube, ich habe ein ähnliches Problem wie Erict; ich habe versucht, es hier zu beschreiben viewtopic.php?f=10&t=1177&p=3942&hilit=certificate#p3942
Und ich glaube auch, dass die Antwort hier liegt

htouvet schrieb: ↑11. Apr. 2018 - 10:57
Ein SSLError in einem Repository bedeutet im Allgemeinen, dass die SSL-Zertifikatsprüfung fehlgeschlagen ist.
[...]
Im einfachsten Fall muss die Serverzertifikatskette abgerufen werden.
Der Befehl „wapt-get enable-check-certificate“ ruft die Zertifikatskette für den Wapt-Server (Parameter [global] / wapt_server) ab. Dies

gilt jedoch nicht für sekundäre Repositories. Hierfür muss dies manuell erfolgen.

Könnten Sie hier beschreiben, wie man die Zertifikatskette manuell vom Server des "sekundären Repositorys" abruft?

DANKE !!!

In Ihrem Fall können Sie eine Wirtschaftsprüfung durchführen lassen

Die Zertifizierungsstelle signiert das Zertifikat sowohl für den Server als auch für das sekundäre Repository. Dadurch benötigen Sie ein einziges Zertifikat für alle Ihre Repositories.

Andernfalls müssen Sie tatsächlich Folgendes zur wapt-get.ini-Datei der Rechner hinzufügen:
Zum Abrufen des Zertifikats können Sie beispielsweise Firefox verwenden (siehe beigefügtes Bild)

Ich möchte diese Gelegenheit auch nutzen, um einen Tipp zu geben.

Im Abschnitt:
Sie können die Adresse des WAP-Servers und nicht die des sekundären Repositorys verwenden.

Das sekundäre Repository synchronisiert daher keine unnötigen Maschinenpakete mehr, sondern nur noch Softwarepakete