Beiträge von kk

Mit LiveConfig hat das jeweils nichts zu tun.

Warum das Compilieren fehlschlägt lässt sich mit den o.g. Infos beim besten Willen nicht sagen, vermutlich fehlt irgendeine Bibliothek (Tipp: die vollständige Fehlermeldung lesen)
Entpacken: wenn in dem Archiv (ich tippe mal auf .tar.gz?) die Dateien mit einer User-ID eingepackt wurden die dem web2 entspricht, dann werden die auch so wieder entpackt. Der "tar"-Befehl hat viele Optionen - eine davon dient dazu, Dateien beim entpacken einem anderen Benutzer zuzuordnen oder die User-ID einfach zu ignorieren.

Viele Grüße

-Klaus Keppler

Das liegt daran, dass es diese Funktion derzeit noch nicht gibt.

Mail-Templates sind für eines der kommenden Updates (ab v1.7.1) eingeplant.

Viele Grüße

-Klaus Keppler

Zitat von janwego

Also ich hab r2509 und jetzt steht es wieder da... der Punkt Arbeitsspeicher war vorher nicht zu sehen ... komisch

Ich schaue mal ob wir das vielleicht noch als Anmerkung irgendwo ins Handbuch aufnehmen können: die Speichernutzung wird in einer RRD-Tabelle verwaltet (damit man den Speicherverlauf theoretisch auch mal über die Zeit hinweg betrachten kann). Die Anzeige erfolgt (aktuell) erst dann, wenn mindestens ein RRD-Satz geschrieben wurde, also nach 5 oder 15 Minuten (ich weiß das gerade nicht auswendig welches Intervall wo gilt).
Daher also das o.g. Verhalten - es hat einfach ein wenig gebraucht, bis LC soweit war.

Seppelchen: das erklärt aber nicht, warum bei Ihnen noch immer keine Daten angezeigt werden. Das kann eigentlich nur dann der Fall sein, wenn der LiveConfig-Client-Prozess gar keine Daten an den Serverprozess liefert - sprich: sich aufgehängt hat.
Werden denn aktuelle Trafficdaten oder CPU-Daten angezeigt? Läuft die aktuellste LiveConfig-Version? (v1.6.4-r2509)

Viele Grüße

-Klaus Keppler

Hallo,

bitte fügen Sie in /usr/lib/liveconfig/lua/postfix.lua in Zeile 487 noch die Zeichen "> 0" ein und starten Sie LiveConfig anschließend neu:

if LC.bits.band(opts.sslmode, 4) [U][B]> 0[/B][/U] then

Lua wertet auch ein numerisches "0" in diesem Fall als "wahres" (true) Ergebnis.
Fehler ist in der nächsten Version beseitigt.

Viele Grüße

-Klaus Keppler

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

Zitat von c4yolli

Wird seitens Liveconfig da irgendwas beschränkt?

Kurz gesagt: nein.

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,

Zitat von denis49

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:

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