+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega International Area (/forum-22.html)
+--- Forum: German Corner (/forum-26.html)
+--- Thread: ispcp_daemon / send_request() -> LDAP (/thread-4106.html)
ispcp_daemon / send_request() -> LDAP - gorkon - 08-24-2008 06:55 AM
Eine kurze - zugegeben auch etwas oberflächliche - Suche hat mir nicht sonderlich weitergeholfen, daher gleich einmal sorry, falls meine Frage in ähnlicher Form bereits vorkam.
Ich würde die Verwaltungsoberfläche von ispCP gerne nutzen, nur habe ein kleines Problem: Der Rest meiner Plattform ist verteilt, teilweise geclustert und alles bereits vorhandene wird über einen zentralen LDAP verwaltet. Systemaccounts für Reseller-Rollen oder gar "Endkunden" sind dabei an sich nicht vorgesehen, was mich auf ispCP bringt, das diesen Part mit hübschem Frontend übernehmen kann und dann, wie jetzt die einzelnen Daemons, dann in Richtung LDAP provisioniert.
Jetzt stellt sich die Frage wo ich es am besten ein/umbauen sollte. So weit ich es bisher überblickt habe, wird nach Änderungen stets send_request() aufgerufen, welches dann den als root laufenden ispcp_daemon dazu anweist, eine Reihe von Perl Scripts auszuführen, die dann die DB nach unfertigen Stati durchsuchen und die jeweiligen Daemons rekonfigurieren.
Also heruntergekürzt: Hat ispcp_daemon wirklich keine Aufgabe die über die Komplexität eines (x)inetd Scripts hinausgeht?
Was wäre von der LDAP Provisionierung betroffen?
* FTP. Ich nutze Pure-FTPd, der Auth, Quotas und optional QoS per LDAP bezieht.
* MTA,SMTP Auth: postfix per SASLauthd
* MDA,IMAP,POP3,Sieve: dovecot, unterstützt die Quotas auch entsprechend
* Jabber: ejabberd - ist mit den vHosts per LDAP ein kleiner Hack, aber gangbar
* DNS: Unabhängige Lösung. Vielleicht später einmal ein Hidden-Master Setup mit pdns
* MUA,Webmail: Hängt am IMAPd und ist dafür irrelevant
* HTTPd:... hier habe ich keine Lösung und könnte auch jene von ispCP nutzen, wobei dies dann der einzig verbleibende Grund für ispcp_daemon und die dadurch aufgerufenen Perl Scripts wäre.
Schema und ACL sehen vor, dass ein Flag die Konfiguration einer virtuellen Domain und der Accounts darunter durch andere DNs untersagt, ein Rücksync LDAP->icpCP-DB müsste für die dann per ispCP verwalteten Domains somit nicht erfolgen.
Drei Möglichkeiten gäbe es nach meiner derzeitigen Einschätzung für den Einbau:
1) In send_request()
Es ist zwar nicht besonders hübsch, dann in PHP während desselben Scriptdurchlaufs DB Werte zu setzen um sie danach wieder zu suchen, die LDAP Änderungen vorzunehmen, den Status auf "ok" zu setzen und danach für den Apachen noch ispcp_daemon aufzurufen, aber nur ein kleiner Eingriff.
Nachteil ist, dass die Trennung in den Perl Scripts nicht so eindeutig sein dürfte und dort auch ausgemistet werden müsste/sollte.
2) Bei allen Aufrufen von send_request()
Habe noch nicht alle durchgesehen. Die unspezifische Auslegung von send_request() an sich wird ja einen Grund haben, sonst würde das ja niemand so entwerfen. Ebendieser Grund erledigt auch diesen Ansatz. Wenn ihn jemand weiss wäre ich sehr dankbar wenn er mir die Suche ersparen könnte.
Ein zentrales include() wäre es dennoch, die Aufrufe wären dann vermutlich jeweils in der Nähe der INSERT oder UPDATE Statements der ispCP eigenen DB um möglichst synchron zu bleiben. Die aufgerufenen neuen Funktionen müssten dann vermutlich Rücksicht auf Synergien zu nehmen (nocheinmal prüfen was mit der Domain zusammenhängt und entsprechende Attribute in den LDAP mit kippen)
3) Im engine Verzeichnis, durch ispcp_daemon ausgeführt
Die entsprechenden Funktionen in den Perl Scripts umbauen. Hätte den Vorteil wieder am "unteren Ende" zu sein und die granular bleiben zu können. "Schön" ist es allerdings nicht gerade.
Hat jemand schon einmal Entsprechendes umgesetzt? Wenn ja, welchen Lösungsweg sollte ich einschlagen? Mit welchen nicht ganz so offensichtlichen Problemen wäre zu rechnen (ich kenne ispCP erst seit ein paar Stunden also irre mich sicher noch oft genug)? Dass SMTP, IMAP & FTP für die Traffic Quotas, sofern dies relevant wird, einen Rückkanal brauchen nehme ich an - hat aber viel geringere Priorität.
Quote:OS: Linux 2.6.x AMD64
RC/Revision: t.b.d, vermutlich 1.0.0 RC6 um nicht nebenher noch Nightly Probleme zu haben
Install date: 20080824
VM/Real Server: ESX
Netz: einzelne Port forward NATs