Ruhiges IT-Forum

Hallo zusammen,

im Rahmen einer Wapt-Bereitstellung für einen Kunden muss ich mehreren Benutzern die Möglichkeit geben, Pakete auf dem Server (interne Entwicklung) zu erstellen und zu veröffentlichen.
Leider erhalte ich während des Uploads die Fehlermeldung „FATAL ERROR SSL writing timeout“, die anscheinend mit dem Benutzerkonto zusammenhängt (Mitglied der Self-Service-Gruppe, nicht der lokale Administrator des Rechners).
Wenn ich den Befehl mit den Wapt-Administratorrechten erneut ausführe, funktioniert es.
Liegt also ein Konfigurationsproblem vor, oder ist nur das Wapt-Administratorkonto für diese Art von Operation berechtigt?

Okay, ich komme voran!

In den Spezifikationen der Unternehmensversion habe ich eine Funktion entdeckt, die meinen Anforderungen entsprechen würde (Gruppenpaketierung), aber die ist weit außerhalb meines Budgets.

Dank des Threads „Benutzer und Passwort als Argumente für wapt-get“ konnte ich den Upload jedoch zum Laufen bringen. Die Zugangsdaten liegen aber natürlich unverschlüsselt in wapt-get.py. Hat jemand eine Möglichkeit, das sicherer zu gestalten?

Ich verstehe Ihr Anliegen nicht ganz.

Möchten Sie Pakete automatisch erstellen?

Soweit ich das verstehe, ist es nicht möglich, Konten oder Gruppen zum Hochladen zu autorisieren. Siehe die Spezifikationen der Unternehmensversion: „Unterscheidene Rechte zwischen denjenigen, die die Pakete erstellen, und denjenigen, die sie bereitstellen.“

Kurz gesagt, ich möchte dem Entwicklerteam ermöglichen, seine Anwendungspakete zu erstellen und auf den Server hochzuladen, ohne ihnen die Administratorrechte des Servers geben zu müssen. Dadurch soll die Authentifizierung während des Upload-Prozesses (wapt-get build-upload) automatisiert werden.
Dies erreiche ich, indem ich die entsprechenden Felder in der Datei wapt-get.py ausfülle.

+parser.add_option("--wapt-server-user", dest="wapt_server_user", default="admin", help="Benutzername zum Hochladen von Paketen auf den Wapt-Server. (Standard: %default)")
+parser.add_option("--wapt-server-passwd", dest="wapt_server_passwd", default="my_password", help="Passwort zum Hochladen von Paketen auf den Wapt-Server. (Standard: %default)")

Da dies aber offensichtlich für jeden zugänglich ist, der weiß, wonach er suchen muss, suche ich nach einer Methode, um es sicherer zu machen.

Sie sollten die Unterstützung mehrerer Repositories prüfen:

https://www.wapt.fr/fr/doc/Multi-depot/index.html

Ihre Paketentwickler erhalten ein eigenes WAPT-Repository für die „Dev“-Pakete.

Dieses Repository kann der WAPT-Agent-Konfiguration auf allen Clients als zusätzliches Repository hinzugefügt werden (mithilfe des öffentlichen Zertifikats, das dem privaten Schlüssel der Entwickler entspricht):

https://www.wapt.fr/fr/doc/Installation ... pt-get-ini.

Am besten definieren Sie eine Testumgebung, bevor Sie die Dev-Pakete in die Produktionsumgebung übertragen.

WAPT-Entwickler können dann in ihrem „Dev“-Repository mit ihrem Passwort Pakete erstellen (dies stellt kein Problem mehr dar), und Sie können die Pakete anschließend qualifizieren, bevor Sie sie in das Haupt-Repository verschieben.

Vielen Dank für die Antwort, ich schaue mir das an!

Könnten Sie bitte genauer erklären, was Sie mit „WAPT-Entwickler können daher Pakete in ihrem ‚Dev‘-Repository mit ihrem Passwort erstellen (dies ist kein Problem mehr)“ meinen?
Bedeutet das, dass ihr AD-Benutzerkonto die Authentifizierung auf dem Server für den Upload ermöglicht, oder impliziert die Erstellung eines zweiten Repositorys die Anfertigung eines separaten „Admin“-Kontos für dieses Repository (das keinen Zugriff auf die Administration/Konsole gewährt)?

Nochmals vielen Dank!

Nicolas C schrieb: ↑24. Nov. 2017 - 12:12 Bedeutet das Erstellen eines zweiten Repositorys, dass ein spezielles "Admin"-Konto für dieses Repository erstellt werden muss (und das keinen Zugriff auf die Administration/Konsole gewährt)?

Das ist alles, das sekundäre Repository ist lediglich eine (Apache/Nginx/ISS-)Instanz. Wir können den Zugriff auf dieses Repository für Uploads beliebig konfigurieren (SFTP, SMB, Rsync) und die Authentifizierung nach unseren Wünschen durchführen – z. B. per AD oder Basic Auth.