Beiträge von kk

Hallo,

auf welcher Distribution (&Version) laufen Client und Server jeweils? Läuft auf dem Client der "lcclient"-Prozess?
Gibt es im Log des Clients (/var/log/liveconfig/lcclient.log) irgendwelche Meldungen?

Viele Grüße

-Klaus Keppler

Hallo,

die Verwaltung von SSL-Zertifikaten sowie von "exklusiven" IP-Adressen für Kunden fällt direkt zusammen und ist bereits fast abgeschlossen (Sie können noch im März damit rechnen).

Um eigene vHost-Einstellungen einzurichten gibt es derzeit einen Trick: legen Sie im Webspace-Verzeichnis des Kunden eine Datei ".httpd.conf" an (zB. /var/www/web1/.httpd.conf) - Besitzer root:root - und tragen Sie dort die gewünschten Einstellungen ein.
Anschließend öffnen Sie im LiveConfig diesen Kunden, gehen links im Menü auf "Domains", öffnen eine beliebige (Sub-)Domain zur Bearbeitung und klicken gleich wieder auf "speichern". Damit wird die vHost-Konfiguration des Kunden neu erzeugt (zB. /etc/apache2/sites-available/web1.conf), und die "eigene" .httpd.conf per Include aufgenommen.

Vielleicht könnten Sie mir per PM oder E-Mail (kk@liveconfig.com) eine Liste der "besonderen" Einstellungen zuschicken - ich würde gerne mal schauen inwiefern wir das direkt mit in die Oberfläche integrieren könnten.

Viele Grüße

Klaus Keppler

Hallo,

ja, das ist quasi noch so beabsichtigt. Das Problem wäre weniger das Anlegen der neuen Domainzone im BIND, als vielmehr die Frage, wie sekundäre Nameserver verwaltet werden.
Wenn die Domain "sauber" konfiguriert werden soll, und LiveConfig der Primary-DNS für eine Domain sein soll, dann muss diesem auch beigebracht werden, welche Server für einen Zonentransfer (AXFR) berechtigt sind - in der Regel sind das nur die zuständigen Secondary-DNS. Und wenn man das ganz vorbildlich lösen will (was unser Ziel ist ;)) dann sollten Zonentransfers auch gleich noch signiert ablaufen (TSIG).
Wir implementieren das gerade in mehreren Schritten. Teil 1 (kurz nach der CeBIT) sieht vor, dass entsprechend berechtigte Kunden eine Liste von Secondary-DNS verwalten können (einfache Listen aus Servername und IPv4/IPv6-Adressen). Damit lässt sich schon mal eine gültige Zone generieren, die BIND dann auch an die Slaves verteilen kann (und z.B. auch Notifies bei anstehenden Zonenupdates sendet).
Schritt 2 sieht vor, dass LiveConfig-Server auch als DNS-Slaves für einzelne Zonen eingerichtet werden können, und LiveConfig sich somit komplett um die korrekten Einstellungen kümmert (ca. Mai). Und der letzte Schritt sieht eine API vor, bei der Zonen automatisiert bei Drittanbietern über deren API hinzugefügt werden können.

Falls Sie Domains vorab schon im BIND einrichten möchten, müssten Sie diese noch "von Hand" konfigurieren; diese lassen sich dann später aber in die Datenbank übernehmen. Gerne helfen wir Ihnen da auch kostenlos im konkreten Einzelfall weiter (ggf. einfach Mail an support@liveconfig.com)

Falls Sie noch andere Ideen oder Vorschläge zur Handhabung der Primary/Secondary-DNS haben, lassen Sie es uns bitte einfach wissen.

Viele Grüße

-Klaus Keppler

Hallo,

die vorgeschlagenen Punkte sind alle schon in Arbeit. (1) und (2) sind in Kürze erledigt, zu (3) und (4) wird es zusätzliche Einstellungsmöglichkeiten geben.
Es gibt manche Admins, die "freie" User/Datenbanknamen möchte, und manche möchten das mit Präfix. Wir machen also einfach beides möglich.
Hier laufen gerade die CeBIT-Vorbereitungen auf Hochtouren (Pressemappen zusammenstellen, Standtechnik prüfen und einpacken, usw.) - ich bitte um Ihr Verständnis für etwas längere Reaktionszeiten.

Bzgl der Testlizenz erhalten Sie gleich eine Mail von mir.

Viele Grüße

Klaus Keppler

Ja, das Problem haben heute vermutlich alle, welche die normalen Security-Updates von Debian nutzen.
Die Datei "security.debian.org_dists_squeeze_updates_main_binary-amd64_Packages" ist fehlerhaft (da stehen einige ungültige "None"-Einträge). Ich denke mit einem der nächsten Updates seitens der Debian-Maintainer dürfte das erledigt sein.

Hat aber nichts mit dem LiveConfig-Repository zu tun - das läuft nach wie vor korrekt.

Nachtrag: um den Fehler vorab manuell zu beseitigen, einfach mit folgendem Befehl die ungültigen Einträge entfernen:

sed -ie 's/^None$//' /var/lib/apt/lists/security.debian.org_dists_squeeze_updates_main_binary-amd64_Packages

Nach noch mal "aptitude update" - und gut ist's.

Das sieht so aus als ob nicht mal die WSDL-Info abgerufen werden konnte - vermutlich falscher Benutzername/Passwort.
Haben Sie schon ein SOAP-Passwort eingerichtet? (liveconfig mit "--init" und LCINITSOAP aufgerufen? siehe Handbuch)

Sie können das einfach testen, indem Sie versuchen die WSDL-URL direkt im Browser zu öffnen:
:8443/liveconfig/soap?wsdl&l=admin&p=PaSsWoRt"]https://(...):8443/liveconfig/soap?wsdl&l=admin&p=PaSsWoRt

Soeben wurde LiveConfig 1.3.3 veröffentlicht. Die Änderungen gegenüber 1.3.1/1.3.2 betreffen praktisch nur die SOAP-API.

Außerdem steht in der Wissensdatenbank nun eine Anleitung zur Migration von Parallels® Confixx® zu LiveConfig zur Verfügung. Das dazugehörige Migrationsscript kann unter http://downloads.liveconfig.com/tools/cfximport.php heruntergeladen werden.

Mit diesem Script können die meisten Daten der Reseller und Endkunden aus einem Confixx-System automatisiert zu einem LiveConfig-Server umgezogen werden; ausführlichere Informationen dazu sowie aktuelle Einschränkungen finden sich in dem eben erwähnten Artikel.

Wir freuen uns sehr über Feedback und Anregungen. Da auf Confixx nur lesend zugegriffen wird, kann man jederzeit mal die Migration auf einen (frischen) (virtuellen) Server mit LiveConfig ausprobieren.

Viele Grüße

-Klaus Keppler

Parallels® und Confixx® sind eingetragene Marken der SWSoft Holdings Ltd. (n. Gesetz d. Staates Bermuda), USA.

CatchAll-Adressen sind zwar die reinsten Spam-Magneten, aber wer's unbedingt braucht: ab Version 1.4 (zur CeBIT) gibt's dann auch CatchAll-Adressen.

Danke für's Feedback & viele Grüße

Klaus Keppler

Sooo, liveconfig-meta wurde auch aktualisiert und in den "main"-Zweig mit aufgenommen. Nach der Installation des Metapakets (also aller Abhängigkeiten) werden nun auch die benötigten Apache-Module automatisch aktiviert, sowie die Apache-Einstellungen "ServerTokens" und "TraceEnable" auf sichere Werte gesetzt.

Eine entsprechend gekürzte Installationsanleitung wird demnächst bereitgestellt.

Zur Installation eines typischen Webhosting-Servers unter Debian/Ubuntu reichen nun folgende Befehle (unter Ubuntu ggf. um "sodu" ergänzen):

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
aptitude update
aptitude install liveconfig-meta liveconfig

(ist nun doch ein Vierzeiler geworden ;))

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