Wo haben Sie denn Ihre rewrite-Regeln stehen? In einer .htaccess-Datei?
LiveConfig hat mit htaccess so ziemlich gar nichts zu tun, daher denke ich nicht, dass das in einem direkten Zusammenhang steht.
Prüfen Sie bitte, ob mod_rewrite überhaupt aktiviert ist ("a2enmod rewrite").
Viele Grüße
-Klaus Keppler
Hallo,
das kann derzeit leider nicht ausgeblendet werden, ist für's übernächste Update (v1.7.1) geplant (siehe LC#87).
Wenn aber mod_php nicht auf dem Server installiert ist, kann es auch kein Kunde nutzen.
Viele Grüße
-Klaus Keppler
Noch eine Idee, für den Fall, dass die o.g. .frm-Dateien nicht mehr vorhanden sind: fahren Sie Ihre MySQL-Datenbank herunter. Importieren Sie das LiveConfig-MySQL-Schema auf einem *anderen* Server in eine leere Datenbank. Kopieren Sie dann von dort die .frm-Dateien (/var/lib/mysql/<Datenbank>/ACCOUNTBLACKLIST.frm usw.) auf Ihren "gecrashten" Server. Fahren Sie dann die Datenbank wieder hoch, sprechen Sie ein Stoßgebet aus und hoffen, dass die Tabellen wieder da sind.
Diese Tabellen werden beim Update nicht angerührt. Die Tabellen APPREPO, APPS, APPTEXTS und ACCOUNTBLACKLIST wären nicht besonders dramatisch - die könnte man aus dem MySQL-Schema (/usr/share/doc/liveconfig/db-mysql.sql.gz) wiederherstellen. Nicht so einfach ist das mit "ACCOUNTS" - da stehen alle System- und (virtuelle) FTP-Accounts drin. :-/
Sie könnten mal prüfen, ob die Tabellendefinitionen an sich vielleicht noch in /var/lib/mysql/<Datenbankname>/ vorhanden sind; vielleicht ließen sich die Daten dann noch mit irgendwelchen InnoDB-Tools wiederherstellen?
Die o.g. Tabellen sind übrigens (alphabetisch betrachtet) die ersten fünf Tabellen. Sind APPVARS und APPVERSIONS noch vorhanden?
Falls Sie keine Möglichkeit haben die Daten in ACCOUNTS wiederherzustellen, gibt es zwei Möglichkeiten:
a) eine neue (leere) LiveConfig-Datenbank aufsetzen und alle Kunden/Webspaces/Accounts noch mal neu anlegen (die bislang existierenden Systemaccounts und Dateien können beibehalten werden; die Postfächer müssen da etwas gesondert behandelt werden: erst /etc/dovecot/passwd sichern, dann /var/mail in /var/mail.OLD umbenennen, danach die Postfächer neu anlegen und anhand der Zuordnung aus de "gesicherten" Dovecot-passwd-Datei entsprechend wiederherstellen;
b) die Tabelle ACCOUNTS manuell neu füllen (für Details bitte kurze Mail an support@liveconfig.com). Lohnt sich nur bei einer überschaubaren Anzahl Account. Die sonstigen fehlenden Tabellen einfach aus dem o.g. Datenbank-Schema importieren.
Viele Grüße
-Klaus Keppler
(PS: wenn der erste Schock vorüber ist: Yesterday)
Ich habe das eben mal unter Debian 7 untersucht. Das Problem ist die Lade-Reihenfolge der Apache-Module "php" und "suphp" - beide registrieren jeweils einen Handler für application/x-httpd-php
Im nächsten LiveConfig-Update wird eine Konfigurationsanweisung enthalten sein, um mod_php auch gleichzeitig mit suPHP nutzen zu können.
Bis dahin deaktivieren Sie am besten das Modul suPHP (a2dismod suphp), dann funktioniert mod_php.
Viele Grüße
-Klaus Keppler
(PS: mir ist kein Fall in der Praxis bekannt, in dem mod_php und suPHP gleichzeitig Sinn machen)
(PPS: Hintergrundinfos zu mod_php, suPHP und FastCGI haben wir hier zusammengestellt: http://www.liveconfig.com/de/kb/17)
v1.6.4-r2509 basiert auf dem 1.6.4-Branch (r2488), daher sind die andere Commits darin nicht enthalten. Im nächsten "offiziellen" Update aus dem "Trunk" ist's dann dabei (also zB. in der kommenden Preview-Version).
Viele Grüße
-Klaus Keppler
Hallo,
Ich suche nach der Funktion automatisch eine Mail an den neuen Kunden mit seinen Daten zu senden.
diese Funktion gibt es derzeit noch nicht, an einigen Stellen ist das nur schon vorbereitet (so z.B. auch die Paketbeschreibung in den Hostingangeboten). Die Bildschirmmasken für die E-Mail-Templates sind schon fertig, ich denke dass das spätestens in v1.7.1 mit drin ist (September/Oktober).
Viele Grüße
-Klaus Keppler
Die logrotate-Verwaltung ist schon fertig und in v1.7.0 mit dabei (Preview kommt in Kürze):
forum.liveconfig.com/cms/attachment/11/
Derzeit können die Einstellungen nur vom Admin/Reseller über den Vertrag bearbeitet werden. Eine Bearbeitung direkt durch den Kunden halte ich persönlich nicht für besonders sinnvoll - falls es da eine große Nachfrage gibt können wir das aber auch noch einbauen (dann natürlich so, dass das limitierbar ist)
Ja, das sind für Computer zwei völlig verschiedene Sachen (die sind da nunmal ziemlich pingelig ;))
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
Die Konfiguration schaut eigentlich sauber aus, SNI wird auch unterstützt.
Welchen Browser (exakte Version) verwenden Sie?
Schicken Sie mir ggf mal die beiden Domainnamen (per PN oder an support@liveconfig.com), dann rufen ich das hier mal auf.
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:
ZitatUPDATE 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
Ich habe eben eine 32bit-Version bereitgestellt, der KB-Artikel (#15) wurde entsprechend aktualisiert:
http://download.liveconfig.com/tools/lcdbdump_i386
Viele Grüße
-Klaus Keppler
Verwenden Sie eventuell ein 32bit-Linux? ("uname -a" ausführen)
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.
