Beiträge von kk

    Aaargh! Sorry, ich hatte nicht genau genug hingesehen.


    Der vHost-Konfiguration nach zu urteilen ist für www.domain2.cc gar kein HTTPS-Webspace konfiguriert, daher landen Sie bei dessen Aufruf auf dem Standard-SSL-Webspace (der zuerst konfigurierte SSL-Webspace).


    Aktivieren Sie im LiveConfig einfach auf für www.domain2.cc SSL (auch wenn das Zertifikat nur auf den Namen "domain2.cc" ausgestellt sein sollte - das ist egal). Damit sollte es klappen.
    Alternativ aktivieren Sie in /etc/apache2/mods-enabled/ssl.conf die Einstellung "SSLStrictSNIVHostCheck" - damit werden "unbekannte" SNI-Zugriffe abgewiesen.


    Viele Grüße


    -Klaus Keppler

    Wo/wie haben Sie mod_php aktiviert?


    Im Prinzip müssen Sie mod_php beim Apache selbst aktivieren ("a2enmod php"). Danach Apache neu starten - fertig.
    In der vHost-Konfiguration (s.o. - /etc/apache2/sites-enabled/webXXX.conf) sehen Sie, wie PHP für diesen Webspace konfiguriert ist.


    mod_php sollte nur dann eingesetzt werden, wenn sich nicht mehrere Personen/Kunden einen Server teilen.

    Ist in der kommenden v1.7.0 bereits erledigt.
    Workaround: führen Sie in der LiveConfig-Datenbank folgenden SQL-Befehl aus:

    Zitat

    UPDATE MAILBOXES SET MB_STATUS=1 WHERE MB_STATUS >3;


    Damit wird das "gelöscht"-Flag zurückgesetzt; Sie können die betroffenen Postfächer dann erneut löschen.
    Das Problem wird entstanden sein, während der Client-Prozess von LiveConfig hing; das wiederum müsste mit dem aktuellen Update (v1.6.4-r2509) erledigt sein.


    Viele Grüße


    -Klaus Keppler

    Ganz ehrlich: im "Mass Shared Hosting" geht die Tendenz dahin, die Dienste auf einzelne (ggf. virtuelle) Server zu verteilen und zentrale Services (insbes. zentrale Storage) zu vermeiden. Somit entfällt der "single point of failure", die Installation ist sicherer (da eventuelle Intrusions auf ein einzelnes System begrenzt sind) und vor allem ist das Ganze i.d.R. auch deutlich günstiger.


    Ein häufig bei unseren größeren Kunden beobachtetes Setup sieht z.B. so aus:
    - zentraler MySQL-Server (optimiert mit SSDs und viiiel RAM)
    - zentraler Mailserver (macht Einsatz von Autodiscover einfacher)
    - mehrere (virtualisierte) Webserver-Nodes mit jeweils "lokaler" Storage. Mehr Performance dann bei Bedarf via Hostsystem zuweisen.


    Letztendlich immer eine Frage der Risikoverteilung. Setups mit LoadBalancer usw. sehen wir eigentlich nur bei "non-shared-Hosting"-Szenarios. Ein Master/Slave-Failover mit DRBD ist an sich nie verkehrt und kann in jedem Szenario gut eingesetzt werden.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    in den letzten zwei Wochen hatten wir hier recht viel um die Ohren (RZ-Umzug). Alle direkten Support-Anfragen werden und wurden zeitnah beantwortet. Wenn es aber um vier Bildschirmseiten lange Fragen rund um eine Webhosting-Architektur geht, dann hat das weniger etwas mit Support als vielmehr mit Consulting zu tun. So gerne wir da behilflich sind, das geht leider nur wenn dazu gerade etwas Zeit ist.


    Viele Grüße


    -Klaus Keppler

    Es gibt da irgendwo tatsächlich noch einen Fehler - ein anderer Kunde berichtete uns kürzlich von Traffic im dreistelligen Terabyte-Bereich (den es definitiv nicht gab) :)


    Die Traffic-Berechnung ist ein wenig komplexer - die Daten selbst werden dafür aus verschiedenen RRD-Tabellen ausgelesen. Dem Verhalten nach tippe ich da auf einen JOIN-Fehler in einem SQL. Ich mache gleich ein Bug-Ticket auf - da das vermutlich keine große Sache ist dürfte das im nächsten Update erledigt sein.


    Viele Grüße


    -Klaus Keppler

    Danke für die Rückmeldung!


    Werden wir machen. Ab v1.7 wird es dann voraussichtlich eigene Repos für die verschiedenen CentOS-Versionen geben, da "dovecot-pigeonhole" erst ab CentOS 6 verfügbar ist. Soweit ich weiß kennt RPM leider keine Möglichkeit, ein Paket nur dann zu installieren wenn es im Repository existiert.

    Mehrere SSL-Zertifikate mit nur einer IP klappt nur, wenn sowohl Webserver als auch Browser "SNI" (Server Name Indication) unterstützen. Mit dem IE (egal welcher Version) klappt's unter Windows XP grundsätzlich nicht.


    Bitte posten Sie mal die Ausgabe von "liveconfig --diag"


    Viele Grüße


    -Klaus Keppler

    Hallo,


    eben wurde LiveConfig v1.6.4-r2509 freigegeben. Diese Version enthält gegenüber 1.6.4-r2488 keine neuen Funktionen, beseitigt aber zwei Fehler:

    • im Client-Paket (lcclient) ist nun auch das Tool "mailquota.sh" enthalten - das wird benötigt, wenn Mailquota aktiviert ist und entsprechende Info-Mails an die Postfachbesitzer gesendet werden sollen sobald das Quota erreicht ist
    • ein Programmfehler wurde beseitigt, der unter bestimmten Umständen zu einem "Deadlock" in einem LiveConfig-Prozess führen konnte. In der Praxis zeigte sich das dadurch, dass ein Prozess 100% CPU-Last (auf einem Kern) zog und keine Konfigurationsaufgaben mehr ausgeführt wurden


    Wir empfehlen also allen Anwendern, das Update einzuspielen.


    Sollte mit dieser Version noch mal irgendwo beobachtet werden, dass ein LiveConfig-Prozess hängt, nehmen Sie bitte Kontakt mit uns auf.


    Viele Grüße


    -Klaus Keppler

    Mir ist aufgefallen dass die Funktion LC.log.print() die message nur nach STDOUT ausgibt, statt sie auch im LC-Logfile anzuhängen. Ich schätze das weitere Funktionen aus der LC-Bibliothek auch entsprechend modifiziert wurden.


    Jein; LC.log.print() gibt eine Log-Meldung über einen frei definierbaren Handler aus. Wenn Lua-Scripte im Kontext von liveconfig/lcclient ausgeführt werden, registriert dieses seinen Log-Handler in LC.log. Das "stand-alone"-Programm lclua hat keine Ahnung von irgendwelchen Logfiles und gibt daher standardmäßig alles auf STDOUT aus. Man kann sich diese Funktion aber bei Bedarf umbiegen und die Daten in eine eigene Logdatei ausgeben lassen.


    Zitat

    Im Handbuch ist klar definiert das das Programm lclua primär zum testen gedacht ist. Gibt es einen Ausblick wann lclua oder ein alternatives Programm/ Parameter standalone mit LC-Bibliothek genutzt werden kann?


    Bei lclua handelt es sich im Grunde "nur" um den normalen Lua-Interpreter, erweitert um einige LC-Bibliotheken (LC.expect, LC.mutex, Shared-Memory-Tabellen für IPC, etc.). Oder anders gesagt: lclua ist nur eine Auskopplung des in LiveConfig integrierten Lua-Interpreters. Ein Ausbau in ein "größeres" Tool ist derzeit nicht geplant (ich sehe hierfür derzeit auch keinen konkreten Anwendungsfall).


    Zitat

    http://www.liveconfig.com/de/h…lua.reference.expect.html
    Beim Listenpunkt "LC.expect:expect" sollte in der Zeile mit dem Prototyp wohl die Funktion expect() stehen.


    Danke, wird beim nächsten Handbuch-Update aktualisiert.


    Viele Grüße


    -Klaus Keppler

    So, heute stehen noch mal Wartungsarbeiten an, zwischen ca. 23:30 und 00:30 werden einige Server (Webserver, Demo, Forum) kurzzeitig nicht erreichbar sein. Der Lizenzserver (license.liveconfig.com) ist davon nicht betroffen. Dann haben wir's aber geschafft. :)


    Vielen Dank für Ihr Verständnis.


    Viele Grüße


    -Klaus Keppler

    Öffnen Sie bitte die Datei /usr/lib/liveconfig/lua/mysql.lua. In Zeile 82 fügen Sie in die Liste der gesuchten Pakete dann noch "mysql" hinzu:


    Code
    pkg, v = LC.distribution.hasPackage('mysql-community-server', 'mariadb'[COLOR=#b22222][U][B], 'mysql'[/B][/U][/COLOR])


    Starten Sie LiveConfig anschließend neu - nun sollte MySQL eigentlich erkannt werden.


    Wir nehmen diesen Paketnamen auch noch mit in die "offizielle" mysql.lua auf, so dass Ihre Änderung bei künftigen Updates nicht wieder rückgängig gemacht wird.


    Viele Grüße


    -Klaus Keppler

    Ich habe das hier eben mit CentOS 6 durchgetestet - funktioniert einwandfrei.
    Achten Sie bitte darauf, dass Sie nicht von der selben Adresse aus eine Testmail senden, bei der auch der Autoresponder eingerichtet ist (er antwortet nämlich nicht "an sich selbst"). Außerdem wird immer nur eine automatische Antwort pro Tag an den selben Absender gesendet.


    Viele Grüße


    -Klaus Keppler

    Das nennt sich nun "dovecot-pigeonhole".


    Steht bereits auf der ToDo-Liste, das ins Meta-Paket und/oder mit in die Doku aufzunehmen.


    Viele Grüße


    -Klaus Keppler

    Schaut auf den ersten Blick eigentlich nicht verkehrt aus.
    Existiert denn auch eine php.ini in /var/www/web1/conf/php54 ?
    Falls nicht, einfach mal die aus ../php5/ kopieren.


    Dann in der php.ini mal "log_errors=on" und "log_startup_errors" (oder so ähnlich) auch auf "on" setzen. Im Log (~/logs/priv/php_errors.log) sollte dann mehr auftauchen.


    Welche Distribution nutzen Sie?