Beiträge von kk

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

Haben Sie dem Benutzer "web1" in LiveConfig ein Quota zugeordnet (wenn ja, wie viel?), oder steht das dort auf "unbegrenzt"?

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:

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

Was genau liefert denn der folgende Befehl:

repquota -ag | grep web1

Mich irritiert die Meldung "Numerical result out of range" - da wäre interessant, ob LiveConfig tatsächlich den Quota-Wert nicht verarbeiten kann oder ob das Problem ganz woanders liegt.

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.

Zitat von Umbriel

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

Viele Grüße

-Klaus Keppler

Zitat

- liveconfig: License error (9): certificate is not yet valid

Der Server hat eine ziemlich falsche Uhrzeit - bitte korrigieren und am besten auch mal "ntp" installieren.
(siehe auch http://www.liveconfig.com/de/h…/server.requirements.html)

Legen Sie dieses Verzeichnis bitte einfach an und kopieren dann die php.ini dort hinein.

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

Ja, ohne CGI-Berechtigung dürfen konsequenterweise auch keine Programme/Scripte via PHP ausgeführt werden.
Einfach CGI im entsprechenden Vertrag aktivieren und dann bitte noch mal versuchen.

Bin Donnerstag (heute) und Freitag auf der CeBIT unterwegs. Um 16:00 Treffpunkt für Interessierte in der Webciety-Lounge (Halle 6) - wir werden uns schon irgendwie erkennen
Nächste Gelegenheit ist dann 20.-21. März auf den WHD.Global.

Viele Grüße

-Klaus Keppler

Dann schauen Sie bitte mal mit "grep IhreDomain.de /etc/apache2/sites-enabled/*", wo und wie genau die Domain nun tatsächlich im Apache konfiguriert ist.

Viele Grüße

-Klaus Keppler

Schaut auf den ersten Blick tatsächlich nach einem Fehler aus. Da wir aber schon häufig Angebote über API angelegt haben (und anschließend Verträge damit), dürfte das Problem tiefer sitzen.
Können Sie herausfinden, ob bzw. welchen Wert Sie für "maxcustomers" setzen, wenn Sie HostingPlanAdd() ausführen?

Sie können in LiveConfig doch problemlos verschiedene Domains im selben Webspace-Verzeichnis starten lassen... oder verstehe ich das falsch?
Fügen Sie im LC also einfach z.B. die Domain "outpost.cnc-hq.de" hinzu und legen Sie das selbe Webspace-Verzeichnis wie bei der Hauptdomain fest.

Viele Grüße

-Klaus Keppler

Hallo,

mit einem Apache-Neustart hat das nichts zu tun - wenn die Datei /etc/php5/cgi.d/php.ini neuer ist als /var/www/benutzer/conf/php5/php.ini und irgendeine Web-Einstellung beim Benutzer geändert wird, dann wird dessen php.ini neu erzeugt.
Wenn es um eine Einstellung geht, die für alle Kunden gelten soll, tragen Sie diese einfach in /etc/php5/cgi.d/php.ini ein. Sind es benutzerspezifische Einstellungen, dann kopieren Sie die /var/www/benutzer/conf/php5/php.ini nach /var/www/benutzer/.php5/php.ini - die wird von LiveConfig nicht angefasst.
Mit dem nächsten Update (v1.6.2) gibt es (endlich :)) die in LiveConfig integrierte php.ini-Verwaltung, mit der kundenspezifische Einstellungen dann direkt im Panel verwaltet werden können.

Viele Grüße

-Klaus Keppler

Vielen Dank für den Hinweis - genau das brauchen wir
Derzeit haben wir bis zu 200 Spam-Registrierungen täglich... Die meisten Accounts schalten wir zwar "richtig" frei, ab und zu kann es aber passieren, dass mal einer zu viel gelöscht wird.
Nächste Woche wird ein Kollege das Plugin mal einrichten.

Viele Grüße

-Klaus Keppler

Ach ja, die HTML-Datei für diese LiveConfig-Fehlerseite ("Die Domain ### ist nicht verfügbar...") liegt unter /usr/share/liveconfig/html/not-available.(s)html.