Beiträge von kk

Hallo,

ab sofort steht Version 1.6.2-r2210 als Preview zum Download bereit. Die Änderungen sind im Changelog aufgeführt, zu den wichtigsten neuen Funktionen zählen:

• E-Mail-Login (einfach beim Postfach das Häkchen bei "Web-Login" setzen, dann kann man sich mit der E-Mail-Adresse und dem POP3/IMAP-Passwort im LiveConfig anmelden - dort kann das Passwort geändert, Autoresponder bearbeitet und Greylisting ein/ausgeschaltet werden)
• error.log für Kunden: unter dem Punkt "Webspace" können Kunden ab sofort ein "eigenes" error.log aktivieren. Damit das nicht den Server unnötig zumüllt, wird das error.log nach 24 Stunden automatisch wieder gestoppt (mittelfristig möchten wir da noch ein paar weitere Optionen bieten).
• Live Log Viewer: sowohl das error.log als auch das access.log können quasi "live" im Browser beobachtet werden - Entwickler und Webmaster werden diese Funktion lieben, da so nun zur Fehlersuche nicht immer erst das error.log aufwendig per FTP heruntergeladen werden muss.

Derzeit wird noch an der Fertigstellung der php.ini-Verwaltung gearbeitet; sobald das abgeschlossen ist, erfolgt die "Stable Release".

Viele Grüße

-Klaus Keppler

Diese Meldungen sind im Grunde unkritisch (tritt dann auf, wenn sich in den eigentlichen RRD-Daten nichts geändert hat - durch einen Programmfehler wird dann der UPDATE-Befehl als "nicht erfolgreich" gewertet, dann ein INSERT versucht, und das schlägt natürlich fehl...).

Seit r2151 ist dieses Problem beseitigt; mit dem nächsten LiveConfig-Update sollte das also verschwinden.

Viele Grüße

-Klaus Keppler

Diese Nachrichten nennen sich Delivery Status Notification (DSN) und werden üblicherweise nur versendet, wenn eine Zustellung fehlgeschlagen ist.
Man kann Postfix im Grunde schon erlauben, auch bei Erfolg eine solche Nachricht zu versenden (ich glaube im Mail-Client muss das dann auch irgendwo noch aktiviert werden) - hierzu muss in der postfix.conf die Zeile "smtpd_discard_ehlo_keyword = silent-discard, dsn" auskommentiert/entfernt werden.

Das Problem ist jedoch, dass man Postfix nicht beibringen kann, dass nur "eigene" (authentifizierte) Mail-User eine DSN bei erfolgreicher Zustellung anfordern können - auch jeder beliebige andere (externe) Absender kann damit Zustellbestätigungen bei diesem Mailserver anfordern. Diese DSNs enthalten wiederum manchmal Informationen, die nicht unbedingt für die Öffentlichkeit gedacht sind.

Man kann Postfix so konfigurieren, dass DSNs nur von bestimmten IP-Adressen aus angefordert werden dürfen (smtpd_discard_ehlo_keyword_address_maps) - mit LiveConfig ist das aber nicht möglich. In der Praxis wird diese Einstellung (fast?) nie genutzt; in den seltenen Fällen, in denen man eine Zustellung prüfen möchte, kann man das ja anhand des Log-Files (/var/log/mail.log) tun.

Viele Grüße

-Klaus Keppler

Äh - das klingt in der Tat merkwürdig.
Wenn Sie auf "Serververwaltung" klicken, sollte ja eine Liste der Server erscheinen.
Verstehe ich das richtig, dass dort nur ein Server ("localhost") angezeigt wird?
Sind Sie als "admin" angemeldet, oder als ein anderer Benutzer?

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:

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.

Wie viele Weiterleitungen wären denn Ihrer Ansicht nach notwendig?

Da haben wir's ja schon - der Webserver hat kein Recht, den Verzeichnisinhalt zu lesen.
Bitte korrigieren Sie die Berechtigung (chmod 755 /var/www/web1/htdocs/www).

Entschuldigen Sie bitte, ich hatte beim ls-Befehl noch das "-d" vergessen (mich interessieren die Rechte für das www-Verzeichnis selbst):

ls -ld /var/www/web1/htdocs/www

"Permission denied" klingt vielmehr nach fehlenden Zugriffsberechtigungen des Webservers auf das www-Verzeichnis.
Was genau gibt denn folgender Befehl (als "root" ausgeführt) aus?

ls -l /var/www/web1/htdocs/www

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