User anlegen via CLI?

[bernhard]

Ich würde gerne mehrere User via CLI anlegen - ist das irgendwie möglich?

Als Workaround würde ich den User via API anlegen. Das Problem, das ich damit habe, ist, dass es immer bis zu einer Minute dauert, bis KeyHelp die Änderungen mitbekommt. Oder kann ich das ändern? Ich dachte zum Beispiel daran, dass ich den Haupt-Cronjob manuell triggere, aber im root crontab -e gibt's keinen Eintrag. Ich weiß also nicht, welches Skript KeyHelp intern jede Minute ausführt, das zum finalen Setup neuer User verwendet wird.

Es geht mir hauptsächlich darum, dass wenn ich einen User angelegt habe, das Filesystem noch nicht so weit ist und beispielsweise der Ordner /home/users/mynewuser/www noch nicht existiert...

Ideal wäre ne CLI für diverse Tasks, zB "keyhelp user:add -name foo -password bar -quota 10GB"

Danke für eure Hilfe!


[Mod-Edit]
Verschoben nach Bedienung und Nutzung

[Alexander]

User Anlegen via CLI ist so direkt nicht möglich.

Man könnte das Anlegen über die API erledigen (über die CLI in deinem Script o.Ä. einen Request an die API absetzen) und zum sofortigen Triggern des entsprechenden Cronjobs anschließend den folgenden Befehl aufrufen:

Code: Select all

php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php --force-update

[bernhard]

Vielen Dank, das reicht mir schon als Lösung, dann kann ich mir meine eigene CLI bauen

[24unix]

wäre ne CLI für diverse Tasks, zB "keyhelp user:add -name foo -password bar -quota 10GB"

Wenn Du magst, kannst Du ja mal einen Blick auf meine bindAPI werfen.

Die kann via REST Api Domains anlegen, meine API ist kompatibel zur KeyHelp Api, kann man sicher schnell anpassen.

[Jolinar]

Wenn Du magst, kannst Du ja mal einen Blick auf meine bindAPI werfen.

Zu finden hier --> viewtopic.php?t=11109

[24unix]

User Anlegen via CLI ist so direkt nicht möglich.

Ich werde es in die bindAPI mit aufnehmen.

Könntest Du einen Endpoint /server/reload bauen, der das script auf den Panel auslöst?

Edit:

Ideal wäre ne CLI für diverse Tasks, zB "keyhelp user:add -name foo -password bar -quota 10GB"

Kannst Du mal aufschreiben, welche Parameter unterstützt werden sollen, und welche optional sein können?

[Alexander]

Könntest Du einen Endpoint /server/reload bauen, der das script auf den Panel auslöst?

Das ist leider nicht so einfach möglich, da die API-Requests beim Systemuser "keyhelp" auflaufen, die KeyHelp-Cronjobs über "root" laufen müssen.
Ich könnte maximal die Ausführung der Wartungsaufgaben über die API zur nächstmöglichen Ausführung markieren (Wie wenn man bei Wartungsintervalle auf das Play-Icon klickt). Einen zeitlichen Vorteil verschafft das aber nicht, da diese auch immer nur zur jeweils vollen Minute abgearbeitet werden und ohnehin nach Absetzten von API-Requests entsprechend automatisch getriggert werden.

[24unix]

Könntest Du einen Endpoint /server/reload bauen, der das script auf den Panel auslöst?

Das ist leider nicht so einfach möglich, da die API-Requests beim Systemuser "keyhelp" auflaufen, die KeyHelp-Cronjobs über "root" laufen müssen.
Ich könnte maximal die Ausführung der Wartungsaufgaben über die API zur nächstmöglichen Ausführung markieren (Wie wenn man bei Wartungsintervalle auf das Play-Icon klickt). Einen zeitlichen Vorteil verschafft das aber nicht, da diese auch immer nur zur jeweils vollen Minute abgearbeitet werden und ohnehin nach Absetzten von API-Requests entsprechend automatisch getriggert werden.

Äh, aber wenn ich das bei meiner letzten Frage richtig verstanden habe wird doch bei den Job aus der Oberfäche genau dafür sudo eingesetzt?

Müsste die API dann nich einfach ein exec("sudo <script>") ausführen können?

[Alexander]

Meine Antwort bezog sich wie gesagt auf folgenden Satz:

Könntest Du einen Endpoint /server/reload bauen, der das script auf den Panel auslöst?

Das kann man vielleicht auf 2 Arten verstehen:

1) Ich hab ihn im Kontext des Threadsverlauf folgendermaßen verstanden:
Ich dachte du wünscht dir für den Anwendungsfall eine Lösung, wenn über die API wird ein Benutzer angelegt wird. Bis dieser jedoch vollständig eingerichtet ist, vergeht bis zu 1 Minute, bis der KeyHelp-Cronjob diese Aufgabe ausgeführt hat. Diese Minute soll man aber nicht abwarten, sondern gleich über die API ein Kommando absetzen, dass die Abarbeitung sofort erfolgt.

(Also mehr oder weniger diesen Befehl triggert: "php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php --force-update")

Das würde wie in meinem letzten Beitrag dargelegt nicht funktionieren.
Und einfach nur einen Reload z.B. des Webservers auszuführen (was funktionieren würde über die API), würde nicht viel bringen, da KeyHelp zunächst die Konfigurationsdateien schreiben muss etc. (mit root-Privilegien).


2) Alternative Art der Interpretation: Wenn es jetzt einfach nur (losgelöst von der Frage des Threaderstellers) eine Bitte zum Hinzufügen des Endpunkts wäre - quasi einer Abbildung dieser Seite im KeyHelp: "Systemstatus" -> "Serverdienstverwaltung" - Dann wäre das umsetzbar, das ist korrekt. Die Frage wäre, hätte das allein überhaupt einen großen Nutzen, wenn ja, welches Szenario sollte damit abgedeckt werde.

[24unix]

Bis dieser jedoch vollständig eingerichtet ist, vergeht bis zu 1 Minute, bis der KeyHelp-Cronjob diese Aufgabe ausgeführt hat

OK, das war mir nicht bewusst.

Ich dachte, die Aufrufe der API seien atomar.
Wenn die auch mit den CronJobs interagieren bringt der Endpunkt keinen Benefit.

Danke für Deine Erläuterung.

[bernhard]

Hallo Alexander,

ich verstehe das Problem und wie KeyHelp das löst (mit dem master cron). Das war ja auch Teil meiner ursprünglichen Frage. Jetzt programmiere ich selbst gerade eine PHP Applikation wo ich im Hintergrund diverse Tasks mit sudo ausführen muss. exec() innerhalb meines PHP das als web-user läuft ist damit raus. Die Variante mit nem Cronjob, wo es immer eine Minute bis zur nächsten Ausführung dauert, finde ich aber nicht optimal.

Ich habe deshalb nach alternativen gesucht und bin heute mehr oder weniger zufällig auf diesen Artikel gestoßen: https://www.algotech.solutions/blog/php ... obs-alive/

Könnte das nicht eine super Lösung auch für KeyHelp sein? Was aktuell der master cron jede Minute erledigt, könnte der background worker immer sofort erledigen, wenn eine neue Aufgabe ansteht (zB user wurde angelegt --> erstelle den vhost)

Ich werde das Konzept mal für meine App testen...

[Alexander]

Ja die Möglichkeit gibt es, steht soweit auch schon auf der ToDo, aber das würde ich nicht für alles einsetzen wollen.

Folgendes Szenario: Ein User aktualisiert zig Domains auf deinem Server. Er klickt jede Domain an, und klickt auf "Speichern". Nun wird nehmen wir mal an die sofortige Ausführung von Aufgaben wäre bereits implementiert.

Was jetzt passiert, für jede Domain/Subdomain, die er speichert, werden Apache und PHP-FPM jeweils neu geladen. Jedes mal bewirkt das einen kleinen Schluckauf auf dem Server, der sämtliche andere Domains, die auf dem Server zum Einsatz kommen ebenso Mitleidenschaft zieht.

Das Verhalten lässt sich zum Beispiel auch im KeyHelp beobachten, wenn man genau in dem Moment, wenn der Reload des Webservers aufgerufen wird versucht eine Seite im KeyHelp aufzurufen. Es erscheint ein 503 Error und man muss die Seite neu laden.

Aktuell ist es so umgesetzt, das KeyHelp alle Konfiguration die neu geschrieben werden müssen bündelt und so nur maximal 1 mal pro Minute den Webserver + PHP-FPM neu läd. Wäre die sofortige Ausführung von Aufgaben aktiv, passiert das Ganze dann im schlimmstenfalls viel häufiger. Man stelle sich nun vor 2-3 Benutzer sind gleichzeitig im KeyHelp aktiv und ändern fleißig Domaineinstellungen.

[24unix]

Was jetzt passiert, für jede Domain/Subdomain, die er speichert, werden Apache und PHP-FPM jeweils neu geladen. Jedes mal bewirkt das einen kleinen Schluckauf auf dem Server, der sämtliche andere Domains, die auf dem Server zum Einsatz kommen ebenso Mitleidenschaft zieht.

Beim Apachen gibt es doch die option graceful, evtl. gibt es so etwas auch für den FPM?

[Alexander]

Ich führe ohnehin nur reloads durch - diese sollten immer graceful sein, trotzdem kommt der 503. Restarts werden nur in Ausnahmefällen durchgeführt, sollte der Prozess hängen.

[bernhard]

Hallo Alexander,

ich bin alles andere als ein Experte auf diesem Gebiet, aber für mich liest sich die Apache Doc so, als sollte das auch ohne Unterbrechung möglich sein?!

Graceful Restart
Signal: USR1
apachectl -k graceful
The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.

https://httpd.apache.org/docs/2.4/en/stopping.html

Oder verstehe ich da was falsch bzw. gibt es noch andere Sachen zu bedenken? Ich glaub euch schon, dass ihr euch das gut überlegt hab - würde nur gerne dazulernen und verstehen, warum die Dinge so sind, wie sie sind Danke!