# Fehler bei der Verlinkung der Module



## ramsys (20. März 2013)

Wenn im Template bei einem Kunden sämtliche Web-Limits einschließlich DB, FTP usw. deaktiviert sind, hat der Kunde darauf keinen Zugriff mehr. Einstellungen können nur noch vom Admin vorgenommen werden. Im Interface des Kunden sind dann im Modul nur noch die beiden Menüpunkte "Web Zugriff" und "Statistik" vorhanden.

Allerdings verlinkt ein direkter Klick auf das Modul auf den ersten Eintrag im Menü. In der vor beschriebenen Konstellation auf den Menüpunkt "Webseiten", obwohl dieser Menüpunkt aufgrund der Limitbeschränkungen gar nicht vorhanden ist. Dadurch hat der Kunde über die Hintertür Zugriff auf die Konfiguration der Webseite/Domain, die er eigentlich nicht haben soll.

Aus meiner Sicht ein nicht unerheblicher Bug. Der Klick auf ein Modul in der oberen Navigation sollte nur auf einen tatsächlich bei dem jeweiligen Kunden vorhandenen Menüpunkt verlinken.


----------



## Till (20. März 2013)

Wenn der Kunde bei Limits 0 stehen hat, dann kann er auch keine Webseite anlegen. Ob der menüpunkt da ist oder nicht speilt da keine Rolle,wir haben ihn nur aus optischen Gründen ausgeblendet, das ausblenden ist also nicht die Sicherung ob der Kunde etwas anlegen kann oder nicht, denn das wird separat abgefangen. Probier es einfach aus, setze das Limit für webseiten auf 0 und dann lege als Kunde mal eine neue Webseite an, Du wirst feststellen dass es nicht geht da Du eine Fehlermeldung erhältst dass Du keine weiteren webs anlegen darfst.

Des weiteren, wenn Der Kunde keine webs anlegen darf, dann deaktiviert man das komplette webseiten Modul für den CP User des Kunden. Der Fehler hier liegt also eher in einer fehlbedienung, wenn Du nicht möchtest dass der User überhaupt webseiten selbst administriert, dann ist das siets Modul für den Kunden zu deaktivieren.


----------



## ramsys (20. März 2013)

Zitat von Till:


> Wenn der Kunde bei Limits 0 stehen hat, dann kann er auch keine Webseite anlegen.


Korrekt, aber der Admin kann die Webseite anlegen. Und über diese Hintertür kann der Kunde die Webseite ungewollt bearbeiten und verändern.



Zitat von Till:


> Des weiteren, wenn Der Kunde keine webs anlegen darf, dann deaktiviert man das komplette webseiten Modul für den CP User des Kunden.


Das war ja auch mein ursprünglicher Gedanke. Aber dann hat der Kunden auch keinen Zugriff mehr auf die Statistik (Transfer, Webspace). Auch wenn die Website technisch gesehen nicht vom Kunden selbst administriert wird, muss der Kunde doch Einsicht in seine Verbräuche haben, da diese unter Umständen für die Abrechnung relevant sind. Außerdem sollte er schon einen Überblick (mit Link direkt zur URL) über seine gebuchten Webseiten/Domains haben.

Der Kunde dürfte bei diesen Limits also die Webseite/Domain gar nicht öffnen und bearbeiten können, wenn auch der Datensatz als solcher angezeigt wird.


----------



## Till (20. März 2013)

> Korrekt, aber der Admin kann die Webseite anlegen. Und über diese Hintertür kann der Kunde die Webseite ungewollt bearbeiten und verändern.


Nein, kann er nicht. Denn vom admin angelegte Seiten sind für den Kunden für Änderungen gesperrt, er kann sie also nur sehen und nicht ändern. Deshalb wird in einem solchen Fall das Limit der Webs nicht auf 0 gesetzt.



> Der Kunde dürfte bei diesen Limits also die Webseite/Domain gar nicht öffnen und bearbeiten können, wenn auch der Datensatz als solcher angezeigt wird.


Das sehe ich anders, der Administrator darf das Kundenlimit nicht auf 0 setzen wenn er für den Kunden ein Web angelegt hat.


----------



## ramsys (20. März 2013)

Zitat von Till:


> der Administrator darf das Kundenlimit nicht auf 0 setzen wenn er für den Kunden ein Web angelegt hat.


Welches Limit meinst genau? Die max. Anzahl von Webdomains oder (auch) andere Limits?


----------



## Till (20. März 2013)

Es geht um alle Limits. Wenn Du für einen Kunden Webs als admin anlegst dann musst Du als admin sicherstellen dass dies innerhalb der Limits geschieht. Für Kunden überprüft ispconfig das, für den Admin ist diese Überprüfung absichtlich deaktiviert damit er Limits temporär überschreiten kann z.B. beim umziehen von Seiten.


----------



## ramsys (20. März 2013)

In diesem Zusammenhang:

a) Beim Kunden ist der Tab "Backup" vorhanden, obwohl diese Option laut Handbuch (und Logik) nur für den Admin sichtbar sein sollte.

b) Im Tab "Backup" werden die Backups für die Webseite und die Datenbank aufgelistet. Tatsächlich vorhanden sind aber nur die Backups der Webseiten, die Datenbanken fehlen komplett.


----------



## Till (20. März 2013)

a) Du scheinst kein aktuelles Handbuch zu haben.
b) Dann stimmt was mit Deiner Konfiguration nicht so dass das erstellen der DB Backups fehlgeschlagen ist oder Du nutzt einen _ in den DB Prefixes welches beim Backup zu einem Fehler führt.


----------



## ramsys (20. März 2013)

Zitat von Till:


> a) Du scheinst kein aktuelles Handbuch zu haben.


Soll das bedeuten, dass dieses Verhalten geändert wurde und jeder Kunde nun Zugriff auf die Konfiguration der Backup-Erstellung hat?

Version 1.4 for ISPConfig 3.0.5 - Last edited 2013-02-22


----------



## Till (20. März 2013)

> Soll das bedeuten, dass dieses Verhalten geändert wurde und jeder Kunde nun Zugriff auf die Konfiguration der Backup-Erstellung hat?


Ja. Die Backup Funktionen wurden komplett neu implementiert.



> Version 1.4 for ISPConfig 3.0.5 - Last edited 2013-02-22


Das ist aktuell, schau ich mir mal an wenn es da noch falsch drin steht.


----------



## ramsys (20. März 2013)

Zitat von Till:


> Ja. Die Backup Funktionen wurden komplett neu implementiert.


Und wie kann man das beim Kunden deaktivieren?

a) Wenn der Kunde seine Webseite nicht selber administriert bzw. administrieren soll oder keinen FTP-Account hat, nützt ihm diese Funktion nichts sondern verwirrt.

b) Der Anbieter übernimmt den Restore gegen Entgelt. Wenn der Kunde dies nun selber machen kann, geht eine "Einnahmequelle" verloren.

c) Wenn der Kunde selber entscheiden kann, wie viele Backups er wie lange vorhält, kann das die Mischkalkulation des Anbieters gefährden, da diese von festen Werten ausgeht.

d) Wenn der Kunde die Möglichkeit hat selber einen quasi vom Anbieter zur Verfügung gestellten Restore einzuspielen, kann dies vorhandene SLA's stören.

e) ...



Zitat von Till:


> Das ist aktuell, schau ich mir mal an wenn es da noch falsch drin steht.


Seite 120 -> Backup: (This tab is visible only for the ISPConfing admin user.)


----------



## Till (20. März 2013)

a-e) Wie von mir bereits mehrfach erwähnt, wenn der Kunde die Funktionen des wenn Moduls nicht nutzen können soll, dann ist das web Modul für den Kunden unter CP Benutzer zu deaktivieren.


----------



## ramsys (20. März 2013)

Zitat von Till:


> wenn der Kunde die Funktionen des wenn Moduls nicht nutzen können soll, dann ist das web Modul für den Kunden unter CP Benutzer zu deaktivieren.


Das ist schon klar, nur geht es hier um eine für den eigentlichen Betrieb einer Webseite eher nebensächliche Funktion. Nur um den Kunden nicht die Möglichkeit zu geben, die Erstellung von Backups zu manipulieren, kann ich nicht ALLE anderen Funktionen auch deaktivieren.

Datensicherung hat erstmal nichts direkt mit der Erstellung und Administration einer Website zu tun. Ich sehe da keinen stringenten Zusammenhang: Wenn die Anzahl der zur Verfügung gestellten Backups vom Anbieter festgelegt wird, dann darf der Kunde auch keine SSL-Zertifikate mehr aktivieren, Software installieren oder sich über die Auslastung seines Webspace informieren 

Warum wurde das geändert, was war der Grund?


----------



## ramsys (20. März 2013)

Zitat von Till:


> b) Dann stimmt was mit Deiner Konfiguration nicht so dass das erstellen der DB Backups fehlgeschlagen ist oder Du nutzt einen _ in den DB Prefixes welches beim Backup zu einem Fehler führt.


Eigentlich sieht alles richtig aus. Die Datenbanken befinden sich lediglich auf einem eigenen ISPConfig DB-Server. Muss bei den Datenbanken eventuell die IP des Master-Servers für den entfernten Zugriff eingetragen werden? Aktuell ist dort nur die IP des Web-Servers, die automatisch von ISPConfig vorgeschlagen wird.


----------



## Till (20. März 2013)

Die Funktion wurde von vielen Usern gewünscht, daher wurde sie implementiert. Die meisten user erachten Backups übrigens als wichtige Funktion und das Kunden Backups selbst zurückspielen können ist inzwischen standard bei den meisten Hostern. Eine zusätzliche Limitierung der Backups über die Kundenlimits ist geplant wie Du im Bugtracker sehen kannst.

Ich kann es nur wiederholen, das web Modul ist *NUR* für Kunden zu aktivieren die Ihre Webs selbst verwalten, es wurde ausschließlich dafür gemacht. So wie Du es verwendest sollte es nicht verwendet werden und ist in dem Fall zu deaktivieren.


----------



## Till (20. März 2013)

> Eigentlich sieht alles richtig aus. Die Datenbanken befinden sich lediglich auf einem eigenen ISPConfig DB-Server. Muss bei den Datenbanken eventuell die IP des Master-Servers für den entfernten Zugriff eingetragen werden? Aktuell ist dort nur die IP des Web-Servers, die automatisch von ISPConfig vorgeschlagen wird.


Ich hab gesehen dass es da noch einen Fehler bzgl. externer db server gibt, werden wir in einem der nächsten patch releases beheben. Damit das backup dann funktioniert muss das mysql root pw auf dem web und db server gleich sein.


----------



## ramsys (20. März 2013)

Bitte nicht falsch verstehen, ich will nicht nerven sondern das System und die Philosophie hinter ISPConfig vor einem produktiven Einsatz nur richtig verstehen. Ein falsches Setup können und wollen wir uns nicht erlauben 

Nebenbei bemerkt scheint ISPConfig 3 unseren Anforderungen aber sehr nahe zu kommen! Insbesondere die Flexibilität und die Möglichkeiten einer API!



Zitat von Till:


> So wie Du es verwendest sollte es nicht verwendet werden und ist in dem Fall zu deaktivieren.


Wie im Eingangsposting erwähnt, war das auch meine erste Überlegung bis zu dem Hinweis hier, dass der Kunde die vom Admin angelegte Webseite sowieso nicht mehr verändern kann. Was allerdings nur teilweise stimmt, da ja Umleitungen, Statistiken und Backups dennoch direkt vom Kunden geändert werden können.

Dann bleibt nur die Frage nach den Informationen über Traffic und vor allem über die Auslastung des Webspace. Kann man diese Informationen dem Kunden trotzdem irgendwie zur Verfügung stellen?


----------



## ramsys (20. März 2013)

Sorry wenn ich hier noch mal hinterfrage, aber unser Setup sollte langfristig funktionieren und ausbaufähig bleiben:



Zitat von Till:


> Damit das backup dann funktioniert muss das mysql root pw auf dem web und db server gleich sein.


a) Während der Installation von MySQL wird auf jedem Server das Passwort für den Benutzer "_root_" eingegeben. Dieses Passwort ist auf allen Servern identisch.

b) Während der Installation von ISPConfig 3 wird auf jedem Server als erstes dieses Passwort aus a) für den Benutzer "_root_" eingegeben.

c) Anschließend erstellt ISPConfig 3 die Datenbank "_dbispconfig_" mit dem Benutzer "_ispconfig_". Hier kann das vorgeschlagene neue Passwort (random) übernommen werden.

d) In einer Multiserver-Umgebung wird auf dem Master-Server für jeden der beteiligten Server ein Benutzer "root" manuell angelegt (root@IP und root@Domain). Ist das ein völlig neuer Benutzer oder das Passwort aus a) ?

e) Während der Installation von ISPConfig 3 wird nach "_Shall this server join an existing ISPConfig multiserver setup_" der Host des Master-Servers eingegeben. Sowie das Passwort aus a) für den Benutzer "_root_" des Master-Servers.

Soweit alles korrekt, auch für zukünftige Releases?


----------



## ramsys (21. März 2013)

Da ich gerade eine neue Multiserver-Umgebung aufsetzen möchte wäre es nett, wenn jemand die vorgenannten Punkte (unter Berücksichtigung zukünftiger Releases) bestätigen oder ggf. korrigieren könnte. Insbesondere die Frage aus d) und e) ist ja für einen reibungslosen Betrieb entscheidend.


----------



## Till (21. März 2013)

a) Das ist ok, sie müssen aber nicht identisch sein außer beim db und wen server wenn Du DB backups nutzen möchtest.

b) Ja.

c) Ja.

d) Ja. Es ist ein root Benutzer um sich vom slave auf dem master einloggen kann, ob der neu ist oder ob er schon vorj´handen ist macht keinen Unterschied. Der Login  muss nur funktionieren.

e) Es ist egal von welchem User das ist, der Login muss halt funktionieren und root Rechte haben damit der Installer neue mysql User anlegen darf.


----------



## ramsys (21. März 2013)

Danke Till!


----------



## ramsys (26. März 2013)

Zitat von Till:


> wenn der Kunde die Funktionen des Moduls nicht nutzen können soll, dann ist das Modul für den Kunden unter CP Benutzer zu deaktivieren.


Dann noch ein Verbesserungsvorschlag bzw. Feature-Request:

Wenn ein Modul beim Kunden deaktivert ist, sollten in der Übersicht beim Kunden auch die jeweiligen Limits nicht erscheinen.


----------



## ramsys (27. Apr. 2013)

Zitat von Till:


> Damit das backup dann funktioniert muss das mysql root pw auf dem web und db server gleich sein.


Ist das immer noch aktuell?

In einem Multiserver-Setup gibt es 20 Webserver und 10 DB-Server. Die DB-Server haben keine direkte Zuordnung zu einem bestimmten Webserver. Demnach müssten ja alle 30 Root-Passwörter identisch sein, was durchaus ein Sicherheitsrisiko darstellt.


----------



## Till (27. Apr. 2013)

Ja.

Die Alternative wäre dass du die root Passworte aller mysql server auf allen Webservern hinterlegen müsstest, was es auch nicht viel besser macht. Normalerweise verteilst ma die Datenbanken aber nicht "wild" im cluster sondern ordnet web und db Server einander zu, so dass z.B. jeweils 2 webserver und 1 DB Server das gleiche Passwort nutzen.


----------



## ramsys (27. Apr. 2013)

Zitat von Till:


> Die Alternative wäre dass du die root Passworte aller mysql server auf allen Webservern hinterlegen müsstest


Mit den root-user, die ja bereits für den Zugriff der Slave-Server auf den Master-Server bei der Installation angelegt wurden, geht dies dann vermutlich auch nicht?



Zitat von Till:


> Normalerweise verteilst ma die Datenbanken aber nicht "wild" im cluster sondern ordnet web und db Server einander zu


Sofern möglich schon. Allerdings kann nicht ausgeschlossen werden, dass die Datenbanken einer Website je nach Auslastung auch mal auf einen anderen DB-Server landen.


----------



## Till (27. Apr. 2013)

> Mit den root-user, die ja bereits für den Zugriff der Slave-Server auf den Master-Server bei der Installation angelegt wurden, geht dies dann vermutlich auch nicht?


Die werden aus Sicherheitsgründen nirgends gespeichert und dienen nur der Installation bzw. späterd em update. Da in den wenigsten Fällen der master server auch der db server istwürde das spechern bei dem prblem auch nicht helfen.

Ich wedre nochmal überlegen ob es da eine bessere alternative gibt, ihr könnt auch gerne vorschläge machen.

Problemstellung ist:

auf dem webserver läuft ein script, diese erszeugt das backup de webs und auch eines der zu dem web gehörenden db und um das db backup zu erzeigen muss man da irgendwie ran kommen. wenn man kein root pw speichern möchte könnte man unter umständen eine art read-only backup user erzeugen.


----------



## ramsys (27. Apr. 2013)

Zitat von Till:


> und um das db backup zu erzeigen muss man da irgendwie ran kommen


Das Backup selber wird ja schon erzeugt (auch mit verschiedenen Passwörtern), im Backup-Verzeichnis des DB-Servers. Nur der Restore bzw. das Zurückkopieren des Backups in das Backup-Verzeichnis der Webseite funktioniert so nicht.


----------

