Beiträge von kk

    Ah, Backports... ok, für Dovecot 2 wird diese Einstellung tatsächlich nicht in die Config-Datei übernommen.
    Ich habe das eben korrigiert - bitte aktualisieren Sie die Datei dovecot.lua und starten LiveConfig neu:

    Code
    wget http://download.liveconfig.com/tmp/dovecot.lua
    mv dovecot.lua /usr/lib/liveconfig/lua/
    /etc/init.d/liveconfig restart


    Wenn Sie danach in LiveConfig erneut die Dovecot-Einstellung abspeichern, sollte die Konfiguration korrekt aktualisiert werden.


    Viele Grüße


    -Klaus Keppler

    Welche Dovecot-Version (bzw. Linux-Distribution) setzen Sie ein?
    Der Eintrag "mail_max_userip_connections" erfolgt in /etc/dovecot/dovecot.conf - ich habe das hier eben mit Debian 6 & Dovecot 1.x durchgetestet, funktioniert einwandfrei.


    Viele Grüße


    -Klaus Keppler

    Funktion ist ab v1.6.2-r2181 enthalten, steht voraussichtlich ab morgen (Freitag) Abend als Preview bereit.


    Viele Grüße


    -Klaus Keppler

    Welche Anwendung genau wollten Sie denn installieren? xtcModified?
    Das Verzeichnis /var/www/<Vertrag>/apps/shoptest existiert?
    Die Meldung "destination not a directory" ist eigentlich recht eindeutig - das Installationsscript hat festgestellt, dass das angegebene Ziel kein Verzeichnis ist oder nicht existiert. :(

    Hallo,


    Zitat

    Fehler: "Kein Datenbankserver für diesen Vertrag verfügbar"


    Haben Sie die Verwaltung der Datenbank möglicherweise erst im LiveConfig aktiviert, nachdem Sie den betroffenen Hostingvertrag angelegt hatten?
    Wählen Sie in diesem Fall bitte noch mal den Vetrag des Kunden aus, klicken auf "Vertrag bearbeiten..." und dort gleich wieder auf "speichern" (somit wird intern die Zuordnung aktualisiert, so dass Datenbanken anlegbar sein sollten).


    Zitat

    Erstaunlicherweise steht weder beim FTP noch bei DB der Benutzer in der Auswahl. In den FAQs wird immer der Benutzer laut Screenshot z.B. web1 db1 vorangestellt, dass steht bei mir gar nicht.


    Hierzu muss in den Wiederverkäufer-Einstellungen (Einstellungen -> Wiederverkäufer) ein Präfix für Datenbanken, FTP-Benutzer usw. konfiguriert werden, siehe Handbuch.


    Viele Grüße


    -Klaus Keppler

    Mit dem aktuellen Update installiert Ubuntu 12.04 LTS die Version 2.3.5 von vsftpd. Das ist sicher gut gemeint, aber eine gaaaaanz schlechte Idee: ab 2.3.5 verhält sich vsftpd nämlich "anders" und lässt standardmäßig keine schreibbaren chroot-Verzeichnisse mehr zu (in diesem Fall dürften FTP-Verzeichnisse, die als Startverzeichnis für virtuelle LiveConfig-FTP-Accounts dienen, nicht schreibbar sein).
    Erst ab vsftpd 3.0 gibt es Abhilfe in Form der Option "allow_writeable_chroot=YES" - ein Backport oder anderweitigen Bugfix wird es für Ubuntu 12.04 wohl nicht geben.


    Wir empfehlen daher, unter Ubuntu entweder ProFTPd einzusetzen oder vsftpd 3.x aus den Backports zu installieren. LiveConfig unterstützt ab v1.6.2-r2170 die o.g. Konfigurationseinstellung, falls es auf vsftpd 3.x stößt (betrifft z.B. auch OpenSUSE 12.2).


    Viele Grüße


    -Klaus Keppler

    vsftpd hat eine neue (fragwürdige) "Sicherheitseinstellung", welche hier in die Suppe spuckt.
    Als kurzfristigen Workaround fügen Sie bitte folgende Zeile an die /etc/vsftpd.conf an:

    Code
    allow_writeable_chroot=YES


    und starten vsftpd dann neu.


    Diese Einstellung gibt es ab vsftpd v3.0 - im kommenden LiveConfig-Update (v1.6.2) berücksichtigt LiveConfig das dann gleich.


    Viele Grüße


    -Klaus Keppler

    Zitat

    Darf ich als Vertriebspartner hier im Forum/ Threads kommerzielle Angebote an User aussprechen, wenn der Einsatz von LiveConfig beabsichtigt/ geplant ist?


    Klar, kein Problem.

    Und wie bekomm ich LiveConfig nun dazu
    1) längere Vertragsnamen zuzulassen (ich würde da gern immer den Domain-Namen eintragen)


    Wird in einer der nächsten Versionen (frühestens ab 1.7.0) möglich sein; ab da werden dann viele interne Vorgaben (u.a. auch Passwort-Längen etc.) konfigurierbar gemacht. Kurzfristig lässt sich das leider nicht ändern.
    Unabhängig davon ist es aus Sicherheitsgründen nicht empfehlenswert, den Benutzernamen gleich dem Domainnamen zu setzen.


    Zitat

    2) den htdocs root für angelegte Verträge immer auf /var/www zu setzen
    2) customer nach dem Schema %WWW-ROOT/sites/%CONTRACT-NAME anzulegen


    Das ginge schon, hierzu müssten Sie aber die Lua-API nutzen. Kurz gesagt: erstellen Sie eine "custom.lua"-Datei, mit der Sie die Funktion "apache.configureVHost" auf eine eigene Funktion umbiegen. Damit können Sie die VirtualHosts nach eigenen Vorstellungen konfigurieren.
    Das von Ihnen beschriebene Setup sollte allerdings ausschließlich dann zum Einsatz kommen, wenn Sie jedem Ihrer Drupal-"Kunden" absolutes und uneingeschränktes Vertrauen schenken - damit so etwas funktioniert, muss PHP als Apache-Modul bzw. auf allen Verträgen mit den selben Benutzerrechten laufen. Im klassischen "Shared Webhosting" gelten ziemlich hohe Sicherheitsansprüche, die gemeinsame Verzeichnisse mehrerer Benutzer (fast) unmöglich machen.


    LiveConfig ist eben ein Hosting Control Panel und leider kein Drupal Control Panel.


    Wenn es Ihnen hilft können Sie aber LiveConfig immer noch nutzen um E-Mail-Accounts, Datenbanken usw. bequem zu verwalten, und alle Webspace-Konfigurationen manuell (oder durch eigene Scripte) vornehmen.


    Viele Grüße


    -Klaus Keppler

    Das ist kein Fehler, sondern so beabsichtigt: ein Reseller (und das ist im weitesten Sinne auch der "Admin"-Account) soll lediglich seine "eigenen" Kunden sehen dürfen, und nicht unbedingt beliebig tief auch deren weitere Unter-Kunden.


    Bzgl. der exklusiven IP funktioniert das so: als Admin weist man die IP-Gruppe exklusiv dem betroffenen Reseller zu. Der Reseller hat dann wiederum in seiner Vertragsübersicht ("Mein Hosting" -> zugeordneten Reseller-Vertrag wählen) eine Liste der ihm exklusiv zugewiesenen IPs, die er dann wahlweise "gemeinsam" (shared) verwenden oder exklusiv einem seiner Kunden zuweisen kann.


    Ich weiß - das ist leider etwas stolprig, bietet unserer Meinung nach so aber die maximale Flexibilität (der Admin weist dem Reseller exklusiv eine IP zu, der kann diese wieder wahlweise shared oder exklusiv nutzen, usw...)


    Ich schätze mal, wir müssen das noch etwas besser dokumentieren... :rolleyes:


    Viele Grüße


    -Klaus Keppler

    Ich mache gleich mal einen entsprechenden Feature Request auf - künftig soll das konfigurierbar sein; kurzfristig lässt sich das leider noch nicht anders lösen.


    Viele Grüße


    -Klaus Keppler


    EDIT: da es sich hier auch nicht um einen Fehler handelt, habe ich das Thema mal ins entsprechende Forum verschoben...

    Ich denke das kommt letztendlich auch darauf an, wie stark die einzelnen Drupal-"Kunden" voneinander getrennt werden sollen. So lange es ok ist, wenn alle prinzipiell die Möglichkeit haben auch auf die Inhalte der "anderen" Kunden zugreifen zu dürfen, dann müsste es reichen, einen einzelnen Hostingvertrag anzulegen und in diesem dann Drupal zu betreiben.


    Sofern die Kunden ordentlich isoliert werden sollen, ist eine zentrale Installation aus Sicherheitsgründen ohnehin nicht zu empfehlen.


    Viele Grüße


    -Klaus Keppler