Fehler bei der Verlinkung der Module

[ramsys]

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]

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]

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.

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]

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]

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]

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]

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]

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]

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]

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]

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) ...

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]

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]

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]

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]

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]

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]

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!

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]

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

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]

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]

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.