Beiträge von kk

    Hallo,


    entschuldigen Sie bitte die späte Antwort - das Problem ist nun aber gefunden.
    Ubuntu 13 bringt Postfix 2.10 mit - dort gab es eine (leider) inkompatible Änderung in der Konfiguration. Ab dieser Version erwartet Postfix die Konfigurationseinstellung "smtpd_relay_restrictions". Wenn diese nicht gesetzt ist, lehnt Postfix das Relaying von Mails komplett ab. :(
    Die Lösung ist, in der /etc/postfix/main.cf einfach noch die Zeile

    Code
    smtpd_relay_restrictions =


    anzufügen (wenn diese Einstellung auf einen leeren Wert gesetzt wird, heißt das, dass die selben Einstellungen wie für "smtpd_recipient_restrictions" verwendet werden sollen.


    In unseren Augen ist das ein Fehler in Postfix, wenn eine neue Option eingeführt wird, die eine Standardeinstellung enthält, welche bestehende Konfigurationen unbrauchbar macht. :(


    LiveConfig berücksichtigt die neue Option ab v1.6.4-r2394 (in Kürze als Preview erhältlich).


    Viele Grüße


    -Klaus Keppler

    1. Ein Webmailer hat in unseren Augen mit einem Controlpanel nichts zu tun (nur weil Confixx ein Webmail integriert hatte, heißt das nicht, dass das gut war ;)
      Für diesen Zweck kann man - wie schon beschrieben - z.B. Roundcube bequem installieren und allen Kunden zur Verfügung stellen.
    2. Von einer Verlinkung des Webmailers aus dem Controlpanel heraus halten wir auch nichts - wer sich im Webmail anmelden will, der sollte dazu nicht vorher durch's Controlpanel durch gehen müssen. Vor allem meldet sich im Webmail immer der jeweilige E-Mail-Kunde an, während im LiveConfig eigentlich nur der Admin/Webmaster etwas zu tun hat.
    3. Zitat

      Ja das ist einfach möglich, das Problem ist doch das Anlegen von Accounts,
      und bei Confixx hatte ich das Problem, dass wenn Accounts bestehen, neu angelegte E-mails
      wiederrum nicht automatisch hinzugefügt werden, was wiederum den Kunden verwirrt..


      Das verstehe ich nicht ganz... Sobald im LiveConfig ein Postfach eingerichtet wird, kann man sich quasi sofort mit dessen Zugangsdaten (E-Mail-Adresse & Postfach-Passwort) per IMAP/POP3/SMTP und somit auch per Webmail daran anmelden. Der Webmailer ist quasi nur ein "dummer" IMAP-Client - welche Postfächer existieren oder nicht ist dem völlig egal - das prüft der Mailserver während der Anmeldung.

    Wenn Sie irgendeine Postfix-Einstellung im LC bearbeiten und auf "speichern" klicken, dann wird die Postfix-Konfiguration auch neu geschrieben. Nach maximl 60 Sekunden wird Postfix dann neu gestartet.


    Was genau heißt, dass Postfix bei Ihnen "tot" ist? Was geht nicht? Was steht in /var/log/mail.log?

    LiveConfig ist normalerweise nur über HTTPS erreichbar - daher macht es auch keine Weiterleitung per HTTP (und hat diese auch noch nie gemacht).
    Für die Weiterleitung von "/" nach "/liveconfig/login" verwendet LiveConfig immer den Hostnamen bzw. die IP aus der ursprünglich aufgerufenen Adresse.
    Beispiel: https://123.123.123.123:8443 -> https://123.123.123.123:8443/liveconfig/login
    https://LiveConfig.Domain.de:8443 -> https://LiveConfig.Domain.de:8443/liveconfig/login

    UPDATE: Version 1.6.3 wurde eben noch mal kurzfristig aktualisiert (Build 2381 -> 2383), da es einen Fehler in der SOAP-Funktion HostingMailboxAdd() gab (beim Import von E-Mail-Postfächern gab es eine Fehlermeldung).


    Viele Grüße


    -Klaus Keppler

    Bitte öffnen Sie künftig für neue Themen auch einen neuen Thread - das macht es allen Beteiligten einfacher. ;)


    Zum Problem: ich tippe darauf, dass Sie für "FcgidMaxRequestLen" in der Apache-Konfiguration noch einen zu niedrigen Wert eingestellt haben. Falls Sie Debian verwenden: in der Datei /etc/apache2/mods-available/fcgid.conf z.B. folgenden Wert einstellen:

    Code
    FcgidMaxRequestLen 67108864


    Viele Grüße


    -Klaus Keppler

    Das deutet darauf hin, dass das Update-Script vielleicht mehr Ressourcen braucht als für den Kunden erlaubt sind.
    Ändern Sie einfach mal in /var/www/<Kunde>/conf/php5/php.ini den Wert für "log_errors" von "off" auf "on" und lassen dann noch mal das Update laufen - danach sollte eigentlich eine Logdatei namens /var/www/<Kunde>/logs/php/php5_errors.log erzeugt werden, in der ein entsprechender Hinweis zu finden ist.
    Alternativ setzen Sie die Werte für max_execution_time und memory_limit mal etwas herauf.

    Führen Sie in der LiveConfig-Datenbank bitte folgenden Befehl aus:

    SQL
    UPDATE USERS SET U_OTPTYPE=0 WHERE U_LOGIN='admin';


    Wir bauen das ins nächste Update mit ein, dass beim Aufruf mit "--init" auch die OTP-Anmeldung wieder deaktiviert wird.


    Viele Grüße


    -Klaus Keppler

    Ab sofort steht die Preview für LiveConfig v1.6.3 (r2381) zum Download bereit. Es handelt sich hierbei hauptsächlich um eine Bugfix-Release.


    Wir testen derzeit noch alles durch; voraussichtliche produktive Freigabe erfolgt dann am Montag (03.06.2013).


    Viele Grüße


    -Klaus Keppler

    Ein Kunde meldete sich, dass "angeblich" sein Mail-Quota erreicht ist.


    Was heißt "angeblich" - wo/wie genau kommt der Kunde darauf, dass sein Quota erreicht sei?
    Im Zweifelsfall ist das ausschlaggebend, was beim Bearbeiten des Postfachs angezeigt wird (in dem Popup-Fenster mit den Postfach-Einstellungen kann das Quota ja eingestellt werden, dort wird auch noch mal der aktuelle Verbrauch angezeigt)


    Zitat

    Wenn ich mich aber als Kunde einlogge (oder er sich) erscheint in der obersten Zeile ein Speicherverbrauch von derzeit knapp über 10GB.


    Das bedeutet nur, dass rund 10 GB an Postfachgrößen zugewiesen wurde (z.B. 10 Postfächer á 1 GB Quota angelegt wurden).


    Viele Grüße


    -Klaus Keppler

    Hallo,


    bei mod_php kann man technisch bedingt keine verschiedenen php.ini's pro Kunde definieren. LiveConfig löst das, indem alle "individuellen" Einstellungen per php_admin_value in die jeweilige vHost-Konfiguration von Apache geschrieben werden.
    In der phpinfo() der Kunden müssten Sie also beispielsweise unterschiedliche Verzeichnisse für open_basedir, upload_dir usw. sehen.


    Zitat

    Alle Kunden sind auf mod_php eingestellt...


    Bei normalem "Shared Hosting" (wo Sie den Kunden also nicht uneingeschränkt vertrauen) sollten Sie aus Sicherheitsgründen lieber FastCGI einsetzen (hat praktisch die selbe Performance wie mod_php, ist aber deutlich sicherer).


    Viele Grüße


    -Klaus Keppler

    Wenn man sich ein neues Passwort einrichtet (über die "Passwort vergessen"-Funktion bei der Anmelde-Maske) wird beim erfolgreichen Zurücksetzen auch die Zwei-Faktor-Authentifizierung wieder deaktiviert. (Im nächsten Handbuch-Update wird nun auch darauf hingewiesen.)


    Für mehr Sicherheit ist geplant, das Zurücksetzen von Passwörtern optional für Accounts zu verbieten - dann dürfte nur noch der jeweilige Reseller oder Admin ein Passwort zurücksetzen (siehe LC#90).

    Wie erkennst Du eine bessere Performance? Ich konnte bei der Nutzung von SQLite keine Einbußen erkennen


    Unserer Erfahrung nach lohnt sich MySQL ab ca. 200 Webspaces auf einem Server. Bis dahin reicht die Performance von SQLite in der Regel völlig aus. "Eng" wird es eben immer dann, wenn von allen Webspaces die Statistikdaten (Webspace-Belegung, Traffic, etc.) eingesammelt und in der Datenbank verarbeitet werden - das passiert alle fünf Minuten.
    Für Server mit nur einer Hand voll Webspaces gibt es unserer Ansicht nach keinen Grund, auf MySQL umzusteigen, da man mit SQLite eben unabhängig von der Verfügbarkeit des RDBMS ist.


    Viele Grüße


    -Klaus Keppler

    Aber bei mir funktioniert der Bind9 Dienst auch manuell nicht mehr, nachdem LC die Verwaltung übernommen hat.


    So lange Sie keine eigenen Domains mit BIND verwalten, brauchen Sie diesen Dienst auch nicht.
    (Die DNS-Verwaltung kommt "erst" mit der nächsten LC-Version, siehe https://www.liveconfig.com/dev/issues/34)


    Zitat

    May 30 12:05:56 x named[18793]: /etc/bind/named.conf:9: open: /etc/bind/named.conf.options: permission denied


    Das hier hilft:

    Code
    chmod 0640 /etc/bind/named.conf.options


    Viele Grüße


    -Klaus Keppler