ISPConfig 3.0.3 allgem.

[mbsouth]

Vorweg - Gratulation an die ISPConfig Entwickler[!]

Ich werde ISPC im Produktivumfeld unseres Unternehmens einsetzen und mich auch als Subscriber anmelden; zuvor habe ich aber noch einige Fragen:

a) In der DNS Verwaltung können TXT-Records nur mit einer Länge von 256 Zeichen angegeben werden (lt. RFC - 1024 Zeichen). 256 Zeichen reichen nicht für DKIM-Keys aus. Wo kann ich diese Restriktion ändern (ohne mich im Quellcode durchkämpfen zu müssen)?

b) Wir verwenden in den VHOSTs durchwegs "Apache2 mit mySQL Authentifizierung" zur Absicherung von DIRs. Kann ich diese Funktion durch Eintragung des entsprechenden Scriptcodes (Apache Config) in die Textarea "Apache Direktiven" im Bereich "Domains/Optionen" erreichen? Die manuelle Verwaltung der Tabellen und User vorausgesetzt. (Vorschlag für ISPC Erweiterung ?)

c) Bei der Erstellung neuer Kunden werden Parameter, wie beispielsweise "client7", "web12", "web", "tmp" etc. automatisch gesetzt (Ich nehme an, dass sind auto increments aus der DB). Wie kann ich darauf Einfluss nehmen? Ich hätte gerne "Kundennummer (buchhaltärisch)", "domain.tld", "docroot", "tmp" etc. (zB: /var/www/00273/domain.tld/docroot/",
/var/www/00273/foo.tld/docroot/ ...").
Mit der Kundennummer (buchhaltärisch) könnte ich eine Schnittstelle zur internen Faktura erstellen....

d) Bei der Erstellung eines Webdav-Users wird der Pfad "webdav/" vorangestellt. In welcher Relation steht diese Angabe? Ist der Zugriff auf die gesamte Document-Root [des Kunden] möglich?

e) Detto [ Punkt c) ] bei der Erstellung einer neuen Datenbank wird wiederum "c" + clientID verwendet. (zB. c7+DBNAME). Kundennummer+DBNAME wäre optimal.

f) Weitere Vorschläge:
Weitere Angaben für Zahlungsmodalitäten des Kunden je Site (Kosten, MWSt., Abrechnungszeitraum, nächste fällige Zahlung, Rechnungsvorlage etc.)
Als Admin kann ich nicht sehen, welcher Reseller für welche Site zuständig ist.




Lösungsansatz (c)) + (e)):
Bei der Erstellung eines neuen Kunden ein zusätzliches Feld: Kundennummer (CustomerID).

Kundennummer => wird die ClientID (anstelle von "client7" ich nehme an - ident mit der "Group")
Username => wird (X)User (anstelle von "web12" ich nehme an - ident mit dem "User")

Wäre eine eventuelle Anpassung der oben genannten Parameter für eine der nächsten ISPC Version denkbar? Wie hoch wären die Kosten für eine Änderung (meine E-Mailadresse habt Ihr ja eh...!)?

mbsouth

 

[Till]

a) Die Begrenzung ist durch mydns verursacht. Wenn Du einen anderen DNS Server einsetzt, kannst Du das Datenbankfeld in der DB vergrößern und den Regulären Ausdruch in der form Datei für die txt records im DNS Modul.

b) sollte gehen.

c) geht so nicht. Erstens kann die Domain nicht im Pfad stehen, da es ansonsten Probleme gibt wenn die Domain einer Webseite geändert wird. Die KundenID's sind mysql auto increments und können auch nicht beeinflußt werden. ISPConfig verwendet für die einfache Navigation auf der Shell symlinks, daher speilen die realen Pfade keine Rolle.

d) In der aktuellen Implementierung kann man nicht auf das gesamte docroot zugreifen sondern nur auf die webdav Ordner.

f) Dafür wird zur Zeit bereits das billing modul entwickelt, welches in ein bis 2 Monaten als addon für ISPConfig veröffentlicht wird.

http://www.howtoforge.com/forums/showthread.php?t=44577&highlight=billing

Lösungsansatz (c)) + (e)):
Bei der Erstellung eines neuen Kunden ein zusätzliches Feld: Kundennummer (CustomerID).

Ja, könnte man sich überlegen. Es muss nur sichergestellt sein dass sie der Wert nach dem erstmaligen anlegen des Kunden nicht mehr editieren lässt.

 

[mbsouth]

Hallo Till, danke für die ausführliche Antwort!

a) Sorry, war mein Fehler: 255 Char reichen auch für DKIM-Keys aus. Die Länge wird mit 65535 Bytes (RFC1464) definiert.

b) OK, danke

c) Schade! Noch eine Frage dazu:
Bei der Erstellung eines neuen Clients werden Username und Pwd angegeben. Bei der Erstellung eines FTP-, Shell- bzw. Webdav-Users wird dieser Username (Clientname) dem FTP-, Shell-, Webdav-User voran gestellt. Wie sieht die empfohlene Syntax bei der Namensvergabe aus? Dient das Voranstellen nur zur übersichtlicheren Zuordnung? Ich kann sonst keinen Vorteil erkennen.

f) Billing Modul klingt gut, geht als AddOn aber immer "baden".
Warum?
Im professionellen Umfeld finden firmeninterne Faktura und internes Verrechnungswesen ihre Anwendung. Rechnungen werden ausschließlich mit diesen Tools erstellt, ebenso wird die Kundenverwaltung (Clients) ausschließlich dort durchgeführt (CRM). Detailangaben zu Clients (Adresse, Telefon etc.) in ISPC sind für den einen vielleicht nützlich, für die Rechnungslegung aber irrelevant. Niemand verwaltet zwei Kundendatenbanken. Nützlich wären zusätzliche Informationen wie: Kundennummer (ident mit interner Faktura - foreign key), Zahlungsmodalität, Kosten, letzte Zahlung, nächste Zahlung, Sondervereinbarung ... Dann könnte (mit geeigneter Schnittstelle) ein Datenaustausch zwischen ISPC und Faktura erfolgen und alle wären glücklich. Für den professionellen Einsatz (auch für eine kostenpflichtige ISPC Version) wäre eine entsprechende Schnittstelle im Vorteil gegenüber eines Billing Moduls (Insel-Lösung).


mbsouth

 

[Till]

c) Usernamen auf einem Server müssen ja immer einzigartig (unique) für den kompletten Server sein. Da jeder Kunde dazu tendiert einen User "admin" für z.B. FTP anzulegen, bekommst Du ohne Prefix schnell Probleme. Denn beim ersten Kunden klappt es, beim 2. Kunden gibt es den Fehler "Dieser benutzername existiert bereits" und dann wird der Kunde den Support anrufen, denn er hat ja noch garkeinen User "admin" angelegt. Daher also prefixes, denn dann kann jeder user seinen "Admin" anlegen ohne Konflikte mit den anderen Kunden auf dem gleichen Server.

f) Das betrifft wenn dann nur Deutschland. Bin auch schon ein paar Jahre in dem Business, betreue aber fast nur mit Kunden (ISP's) aus dem Ausland insbesondere USA und dort wird es halt anders gehandhabt. Die verwenden nur eine Lösung für das Server managemnt und Billinng inkl. Payment Gateway Anbindung wie es das ISPConfig Billing System bietet und nicht eine separate Billing Lösung.

Für den professionellen Einsatz (auch für eine kostenpflichtige ISPC Version) wäre eine entsprechende Schnittstelle im Vorteil gegenüber eines Billing Moduls (Insel-Lösung).

Eine API zur Anbindung von ISPConfig an Fremdappliktionen gibt es ja bereits und wird auch von zahlreichen providern genutzt.