Beiträge von kk

Die ist ab der nächsten Version schon geändert.

### BEGIN INIT INFO
# Provides:          liveconfig
# Required-Start:    $network $syslog $local_fs
# Required-Stop:     $network $syslog $local_fs
# Should-Start:      $time $named apache2 mysql
# Should-Stop:       $time $named apache2 mysql
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start and stop the LiveConfig server control panel
# Description:       This script controls the LiveConfig server control
#                    panel daemon "liveconfig"
### END INIT INFO

Damit sollte LiveConfig warten, bis u.a. MySQL (falls vorhanden) gestartet wurde.
Aktuell erweitern wir dennoch LiveConfig so, dass automatisch neue Verbindungsversuche gestartet werden. Dürfte somit die sauberste Lösung sein.

Wir haben die Ursache vermutlich gefunden: wenn LiveConfig "zu schnell" gestartet wird (also noch bevor MySQL bereit ist, Verbindungen entgegenzunehmen), dann werden keine weiteren Verbindungsversuche unternommen. Wenn die Verbindung zu MySQL dagegen im Betrieb abreißt (z.B. nach MySQL-Neustart) verbindet sich der LiveConfig-Client aber wieder automatisch.

Wir beseitigen das gerade.

-Klaus Keppler

Ja, in diesem Fall einfach die suPHP-Pakete entfernen - die von LiveConfig erzeugte vHost-Konfiguration greift in diesem Fall auf mod_php zurück.

Zitat von Nosxxx

Backup verwaltung (Mysql, Web-Ordner)

Ja, da ist schon was in Arbeit. Man wird sich quasi ein "Live-Backup" ziehen können, ohne dass dieses erst am Server zwischengespeichert werden muss (spart Speicherplatz). Auch ein Backup der LiveConfig-Einstellungen ist geplant (also alle Postfach- und Domaineinstellungen etc.)

Zitat

IPtables Verwaltung

Längerfristig gerne (ist auch sinnvoll), aber aktuell gibt es noch genug andere Bereiche mit höherer Priorität.
Bis dahin kann man die Grundsicherung über die bei der jeweiligen Distribution mitgelieferten Firewallsoftware konfigurieren (bei openSUSE ist ja beispielsweise alles erst mal "dicht")

So oder so - alle Vorschläge hier werden aufgenommen und bei uns archiviert & bewertet.

Viele Grüße

-Klaus Keppler

Das Paket "liveconfig-meta" enthält absichtlich nur die Abhängigkeiten zu den Zusatz-Paketen; wir bereiten noch verschiedene andere Metapakete vor, die z.B. nur alle Pakete für reine Webserver enthalten (ohne MySQL-Datenbank). So kann man sich die gewünschte Basisinstallation nach Belieben aussuchen.

Auf Ubuntu-Distributionen wurden uns noch vereinzelte Probleme bei der Installation über das Metapaket gemeldet; sobald das auch geklärt ist, wird dieses auch im "main"-Zweig im Repository bereitgestellt. Dann reicht ein Dreizeiler zur Installation von LiveConfig und allen Abhängigkeiten.

Ja, suPHP ist da zu Recht sehr vorsichtig. Da PHP-Scripte ohnehin immer mit der Berechtigung des jeweiligen Webspace-Benutzers ausgeführt werden, ist ohnehin kein "World-Writable" notwendig - auch nicht zur Installation von Webanwendungen (selbst wenn das in deren Dokumentation oft so gefordert wird)

Da das aber manche Endkunden verwirrt (die Fehlermeldung ist ja nicht besonders allgemeinverständlich formuliert), kann man diese Restriktionen in suPHP auch lockern - siehe /etc/suphp/suphp.conf:

; Security optionsallow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

Einfach von "false" auf "true" stellen, Apache neu starten - fertig.

Viele Grüße

Klaus Keppler

Danke für die ausführliche Beschreibung; wir testen das dann gleich mal durch.

Die Pfade der einzelnen Logs sind in /etc/apache2/accesslog.map hinterlegt (jeweils der "ServerName" aus dem entsprechenden vHost, sowie die dazugehörige Logdatei).
Wenn Sie darin etwas ändern, müssen Sie noch ein HUP-Signal an den lclogsplit-Prozess schicken (killall -HUP lclogsplit)

Eigentlich kümmert sich LiveConfig um eine korrekte Zuordnung der Logfiles und vHosts; falls Ihnen da ein Fehler auffällt, geben Sie bitte kurz Bescheid. Diese Konfiguration ist schon in Setups mit mehreren hundert vHosts im Einsatz, allerdings wurden da bisher offenbar weniger oder noch keine Domains gelöscht bzw. neu zugeordnet...

Viele Grüße

Klaus Keppler

Die error_log von Apache enthält leider keine Informationen, um Log-Einträge irgendwie automatisiert dem jeweils "verursachendem" Hosting-Vertrag (genauer: virtuellem Host) zuzuordnen. Man müsste also für jeden vHost eine eigene error_log definieren. Bei sehr vielen vHosts kann das allerdings dazu führen, dass der Hauptprozess von Apache zu viele Dateien gleichzeitig geöffnet hat (das Filehandle-Limit liegt häufig bei 1024).
(bei den "normalen" access-Logs kümmert sich ein eigener Prozess um das Aufsplitten der Logeinträge; bei LiveConfig ist das der "lclogsplit")

Wir planen, eine eigene Option für's Error-Log bei den Hostingangeboten aufzunehmen. Bei Verträgen, die diese Option dann aktiviert haben, soll der Kunde dann bei Bedarf selbständig das errorlog ein- oder ausschalten können. So hat LIveConfig auch einen Überblick darüber, bei wie vielen vHosts ein Errorlog aktiviert ist.
Für alternative oder ergänzende Ideen sind wir aber natürlich jederzeit offen.

HTTPS wird ab LiveConfig v1.5 (April/Mai) durch LiveConfig unterstützt; hier würde dann für SSL-Zugriffe ein getrenntes Log erzeugt werden (so wie es bei Apache üblich ist). Entsprechend würden wir auch eine zweite Webalizer-Konfiguration für eine Auswertung der SSL-Zugriffe einrichten.

Viele Grüße

Klaus Keppler

Zitat von Stefan

in den Server-Details wird nur eine CPU erkannt bzw. angezeigt

Ist auch korrekt; es handelt sich hierbei offenbar um einen virtuellen Server, dem nur eine CPU (bzw. ein Core) zugewiesen ist. Die CPU unterstützt jedoch Hypertreading (siehe CPU-Flag "ht"), daher werden zwei logische CPUs angezeigt.

Zitat

Edit: Hier noch ein Eintrag aus der "liveconfig.log".

Code

[2012/02/12 13:45:12.337157] [7116|1366664960] Can't get system informations: (null)

Diese Meldung wird erzeugt, wenn nicht auf die DMI-Informationen zugegriffen werden kann (ist oft bei virtuellen Systemen, insbes. bei XEN der Fall)

Viele Grüße

Klaus Keppler

Zitat von Nosxxx

Wie kann man die Fehlermeldung PW oder Benutzername falsch noch besser einbinden so in etwa wie beim Standart.

Bisher wird nur durch den Login-Code von LiveConfig ein Fehler-Popup per alert()-Funktion erzeugt. Ist aber eine gute Idee, das anzupassen - in der nächsten Version (1.3.1) werden wir für "eigene" Fehlermeldungen eine entsprechende Callback-Funktion vorbereiten (ist ja keine große Sache).

Viele Grüße

-Klaus Keppler

Genau; für das o.g. Setup wären eine Business-Lizenz sowie 14 Standard-Lizenzen nötig.
Eine Begrenzung hinsichtlich der Benutzer/Verträge/Domains/etc. besteht nicht.

Viele Grüße

Klaus Keppler

Hmm, das ist ein interessanter Fehler. :-/
Könnten Sie das vielleicht mit einem Beispiel beschreiben?
Ich habe mal versucht das zu rekonstruieren - aber (bisher) ohne Erfolg.
So wie ich das verstanden habe, haben Sie die Domain aus einem Hostingvertrag gelöscht (web1?), dann diesen Vertrag selbst gelöscht, und dann die Domain in einem anderen Hostingvertrag neu hinzugefügt?

Viele Grüße

-Klaus Keppler

Hmm, sehr komisch. Ist ein Quota-Modul geladen? (lsmod | grep quota).

Hallo!

Das muss nicht unbedingt ein Fehler sein. Zeigt "repquota -ag" eine (sinnvolle) Ausgabe an?
Ansonsten: ist SELinux aktiviert? (Befehl "getenforce")

So, fertig.
Fügen Sie an die Datei /etc/apt/sources.list.d/liveconfig.list noch den Eintrag " testing" hinzu:

deb http://repo.liveconfig.com/debian/ main main testing

Anschließend "aptitude update" ausführen. Das Paket "liveconfig-meta" sollte dann alle benötigten Pakete automatisch installieren.

Viele Grüße

Klaus Keppler
(PS: ich habe hier noch eine Mail von Ihnen, Antwort darauf erhalten Sie auch in Kürze)

Gerne. Wir bereiten ein Test-Repository vor; ich melde mich dann gleich noch mal.

Wir haben bereits ein Metapaket ("liveconfig-meta") vorbereitet, welches über dessen Abhängigkeiten alle anderen benötigten Pakete installiert. Wir müssen das nur noch unter ein paar verschiedenen Debian/Ubuntu-Versionen durchtesten, dann stellen wir das mit ins Repository.

Ab sofort steht für Debian/Ubuntu-basierte Installationen ein eigenes Repository zur Verfügung.
Wer künftig die Updates also mit einem einfachen "aptitude upgrade" erhalten möchte, kann das gerne ausprobieren. Alle Pakete sind natürlich GPG-signiert.

Mit folgenden Befehlen wird der GPG-Key importiert und das Repository hinzugefügt:

wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -
echo "deb http://repo.liveconfig.com/debian/ main main" > /etc/apt/sources.list.d/liveconfig.list

Aktuell steht "nur" die 64bit-Version vom LiveConfig-Server (liveconfig_1.3.0-r1332_amd64.deb) im Repository; die restlichen Dateien werden morgen mit aufgenommen, wenn diese durch die Staging-Tests durch sind.

Viele Grüße

Klaus Keppler

Die Version 1.3.0 wurde eben noch mal aktualisiert (r1331), da es einen Darstellungsfehler in den Mail-Statistiken gab, sowie das Bearbeiten von Subdomains mit leerem Hostnamen nicht mehr möglich war.

Viele Grüße

Klaus Keppler

Hallo,

Zitat von Nosxxx

Ich komm aus Österreich und besitze leider keine Kreditkarte, nur einen normalen Paypal Acc (Muss immer Geld drauf überweisen)

Wir erweitern den Shop in den nächsten Tagen um eine Zahlung per Überweisung (Vorkasse). Bis dahin können Sie einfach eine kostenlose Testlizenz nutzen (LiveConfig kann jederzeit von der Testlizenz auf eine "echte" Lizenz umgestellt werden, ohne dass noch mal irgendetwas neu installiert werden muss).

Zitat

Zum 2 gibt es vielleicht so etwas wie einen Installations/Einrichtungs Service ? Ich möchte einfach nur sichergehen das auch alles 100% läuft .

Wir selbst bieten sowas derzeit eigentlich nicht an; sollten Sie aber konkrete Probleme bei der Installation haben, wenden Sie sich einfach an uns (per Forum oder per Mail an info@liveconfig.com)
Eine sehr ausführliche Anleitung für Debian 6 finden Sie unter http://www.liveconfig.com/de/kb/8

Viele Grüße

-Klaus Keppler