Beiträge von kk

Wir haben nun LiveConfig 1.3.1 zum Download freigegeben. Bei den Änderungen handelt es sich in erster Linie um Bugfixes und Verbesserungen, u.a.:

• Installation über Repository (Debian/Ubuntu) nun reibungslos möglich (keine doppelte Abfrage des Lizenzschlüssels)
• Startreihenfolge des LiveConfig-Daemons auf LSB-Systemen (u.a. Debian, Ubuntu) optimiert - LiveConfig wartet nun ggf. auf MySQL & Apache
• /cgi-bin/-URLs funktionierten noch nicht bei Domains, die in ein Unterverzeichnis konfiguriert waren
• defekten Link zu Webstatistiken beseitigt, wenn diese nicht mit einer Subdomain konfiguriert waren
• Fehler in apache.lua beseitigt, der zu verwaisten Einträgen in der Datei accesslog.map führte wenn die letzte Domain eines Vertrags gelöscht wurde
• vorübergehende Deaktivierung von Cron-Jobs funktionierte nicht
• Javascript-API zur Einbindung des Logins in eigene Webseiten optimiert
• Konfiguration für Dovecot 2.x korrigiert

Viele Grüße

-Klaus Keppler

Ist in der nächsten Version (1.3.1) ebenfalls beseitigt.

Der Fehler wurde gefunden und beseitigt.
Wenn aus einem Hostingvertrag die letzte darin konfigurierte Domain gelöscht wurde, dann wurde diese nicht aus der accesslog.map-Datei entfernt, was zum beschriebenen Verhalten führt.
Sollte man also solche verwaisten Einträge in der /etc/apache2/accesslog.map finden, dann kann man diese getrost von Hand löschen.

Voraussichtlich morgen geben wir dann die Version 1.3.1 frei.

Wir haben inzwischen schon öfter die Anfrage erhalten, inwiefern vielleicht mpm_peruser oder mpm_itk unterstützt werden könnten.
Wir werden das mittelfristig in der Erzeugung der Apache-vHost-Konfigurationen berücksichtigen (mit entsprechenden <IfModule>-Abschnitten).

Wer das bis dahin experimentell ausprobieren möchte, kann Folgendes machen (funktioniert mind. seit LiveConfig 1.2.5):

1. In dem Hauptverzeichnis des jeweiligen vHost-Webspaces eine Datei ".httpd.conf" anlegen, welche die notwendige Konfiguration enthält, z.B. also /var/www/web1/.httpd.conf
   
   
   Code

   <IfModule mpm_peruser_module>
     ServerEnvironment web1 web1
   </IfModule>

   
   bzw.
   

   Code

   <IfModule mpm_itk_module>
     AssignUserId web1 web1
   </IfModule>

   
   

2. Anschließend in LiveConfig die Domaineinstellungen des Kunden öffnen ("Hosting" -> "Domains"), dort irgendeine Domain des betroffenen Hostingvertrags auswählen, und in dem Popup einfach auf "speichern" klicken (geht auch obwohl der Button deaktiviert scheint). Dadurch wird die vHost-Konfiguration des Vertrags neu erzeugt, und die .httpd.conf per Include-Anweisung mit aufgenommen.

Das Ganze setzt natürlich voraus, dass das gewünschte mpm vollständig installiert und vorkonfiguriert ist. Bei mpm_peruser müssen die notwendigen "Processor"-Anweisungen noch in irgendeine "globale" Konfiguration aufgenommen werden (dazu kann man unter Debian z.B. einfach eine Datei /etc/apache2/conf.d/mpm_peruser anlegen).

Die Datei .httpd.conf darf nicht durch den Endkunden beschreibbar sein (sonst kann sich dieser frei in der Apache-Konfiguration austoben).

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.