Eine 1.6.5 wird es nicht geben, da sich die größten Änderungen (DNS, mehr Optionen bei der Vertragsverwaltung) im selben Entwicklungszweig befinden. Eine Preview wird's aber bald geben, um die neuen Funktionen schon mal antesten zu können.
Es wird auch in der Ferienzeit hier durchgehend an LiveConfig weiter entwickelt (es sind nicht alle Leute gleichzeitig im Urlaub :)).
Viele Grüße
-Klaus Keppler
Die Datei php-fcgi-starter wird potenziell bei jeder Aktualisierung der vHost-Konfiguration überschrieben (z.B. könnte sich ja das max_upload_limit in der php.ini geändert haben, was dann ebenfalls in der FastCGI-Datei berücksichtig wird).
In dem von arnoldB erwähnten Thread wird beschrieben, wie Sie zusätzliche (alternative) FastCGI-Starter-Scripte anlegen können; die werden nicht überschrieben.
Viele Grüße
-Klaus Keppler
Danke, das ist eine gute Idee. Wurde eben in die Konfiguration aufgenommen (ist also mit dem nächsten Update enthalten).
Viele Grüße
-Klaus Keppler
Hallo,
Ihrem Server fehlen die CA-Zertifikate.
Installieren Sie bitte das Paket "ca-certificates", dann sollte es klappen.
Ich denke, wir werden das mal in die Anleitung mit aufnehmen - die Frage kommt häufiger. 
Viele Grüße
-Klaus Keppler
Hallo,
kurz eine Information in eigener Sache: heute Nacht zwischen 00:00 und 01:00 werden die LiveConfig-Server (Website, Forum, Lizenzserver) für insgesamt ca. 10 Minuten nicht erreichbar sein.
Hintergrund sind Arbeiten an der Stromverkabelung einiger Systeme.
Für die Lizenz- und Repository-Server wird derzeit übrigens eine geographische Redundanz vorbereitet, dazu dann aber mehr wenn die Arbeiten abgeschlossen sind.
Viele Grüße
-Klaus Keppler
Das Bearbeiten der Einstellungen pro Vertrag ist in der nächsten Preview schon mit drin:
forum.liveconfig.com/cms/attachment/10/
Bis zur fertigen Version 1.7.0 ist dann auch das Bearbeiten der Einstellungen durch Kunden mit drin (die Masken werden gerade programmiert).
Viele Grüße
-Klaus Keppler
i.d.R. ist für die Nutzung von nginx kein extra IP nötig, ein Portswitching wäre ausreichend.
Ist dies geplant?
Nein, ist nicht geplant. Da viele Firewalls in Firmen und Behörden nur Port 80 und 443 für ausgehende Web-Verbindungen durch lassen, macht die Verwendung abweichender Ports nur selten Sinn. Auch hier kann man aber ggf. mit eigenen Lua-Funktionen einen Workaround bauen.
ZitatDesweiteren möchte ich nginx reverse nutzen, dazu müssen vhosts automatisch angelegt werden.
Welche Datei/Script erstellt derzeit die Apache vhost Dateien ?
So könnte ich es ändern, dass es auch nginx vhost anlegt..
/usr/lib/liveconfig/lua/apache.lua
Bitte nicht überschreiben, sondern eigene Funktionen in eine "custom.lua" schreiben und die entsprechenden Original-Funktionen umbiegen (dann ist das auch Update-sicher).
Da ein Reverse-Proxy aber zusätzliche Komplexität und mögliche Probleme mit sich bringt, empfehle ich, lieber direkt NGINX zu nutzen. Noch benötigte Konfigurationsanpassungen kann man über die oben beschriebene "~/conf/nginx.conf" vornehmen.
NGINX wird bei uns priorisiert sobald das DNS-Management fertig ist.
Viele Grüße
-Klaus Keppler
chown liveconfig:liveconfig /var/lib/liveconfig/liveconfig.db
chmod 600 /var/lib/liveconfig/liveconfig.db
Im Log müsste noch ein bisschen mehr stehen als diese zwei Zeilen... bitte geben Sie alles an, was ab dem LiveConfig-Start ins Log geschrieben wird.
Ich habe eben mal nachgesehen was beim Upgrade auf r2455 passiert - da wird lediglich der Befehl "ANALYZE" auf der SQLite-Datenbank ausgeführt.
In Ihrem Fall ist also offenbar die SQLite-Datenbank korrupt (wurde der Server evtl. mal irgendwann "ausgeschaltet"? Stromverlust? Festplatte voll?)
Zum Reparieren gehen Sie bitte wie folgt vor:
root@xxx:/root# [B]sqlite3 /var/lib/liveconfig/liveconfig.db
[/B]SQLite version 3.7.3
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> [B].mode insert[/B]
sqlite> [B].output /root/liveconfig.dump.sql[/B]
sqlite> [B].dump[/B]
sqlite> [B].exit[/B]
root@xxx:/root#cd /var/lib/liveconfig
mv liveconfig.db liveconfig.db.OLD
sqlite3 liveconfig.db </root/liveconfig.dump.sqlViele Grüße
-Klaus Keppler
- welche LiveConfig-Version? (liveconfig -v)
- welche Distribution & Version?
- was steht in /var/log/liveconfig/liveconfig.log?
Häufigster Fehler ist, dass man beim Upgrade die Konfigurationsdatei (liveconfig.conf) überschreiben lässt und somit z.B. alte/falsche Datenbankdaten gelten - prüfen Sie also bitte, ob die Einstellungen in /etc/liveconfig/liveconfig.conf noch korrekt sind.
Bei SQLite als Backend wird die Datenbank vor dem Upgrade immer gesichert (/var/lib/liveconfig/liveconfig.db.*)
Viele Grüße
-Klaus Keppler
Haben Sie den Text gelesen und verstanden, bevor Sie statt dem vorgeschlagenen Wert ("Nein") mit "Ja" geantwortet haben?
Bitte schauen Sie ins Verzeichnis /etc/liveconfig. Dort wurde Ihre liveconfig.conf durch eine neue Datei ersetzt; die vorherige Datei müsste da noch mit einer zusätzlichen Dateiendung herumliegen (weiß ich gerade nicht auswendig). Alternativ setzen Sie einfach die Datenbank-Einstellungen in der liveconfig.conf auf Ihre vorherigen Werte zurück.
Um ein abweichendes PHP-Binary zu setzen, kommt es eigentlich nur drauf an, ob suPHP oder FastCGI verwendet wird.
Nachfolgend die Anleitung (ungetestet, aus dem Stegreif):
Grundsätzlich im jeweiligen Kunden-Webspace eine Datei namens ".httpd.conf" anlegen (zB. /var/www/web123/.httpd.conf). Diese Datei muss "root:root" gehören und chmod=644 haben.
Im nachfolgenden Beispiel gehe ich mal davon aus, dass man z.B. PHP 5.4 bereitstellen will, und das unter /usr/local/php54/ installiert ist.
suPHP_AddHandler application/x-httpd-suphp54
AddType application/x-httpd-suphp54 .php .php5
In die Datei /etc/suphp/suphp.conf im Abschnitt "Handlers" folgende Zeile hinzufügen:
application/x-httpd-suphp54="php:/usr/local/php54/bin/php-cgi"FCGIWrapper /var/www/webxxx/conf/php54/php-fcgi-starter .php
FCGIWrapper /var/www/webxxx/conf/php54/php-fcgi-starter .php5
Ins Verzeichnis /var/www/webxxx/conf wechseln, dort "php5" in "php54" kopieren (cp -a php5 php54). Dann die Datei php54/php-fcgi-starter entsprechend anpassen, so dass auf die "neue" php.ini sowie das neue PHP-Binary verwiesen wird, z.B.:
#!/usr/bin/sh
umask 0022
PHPRC=/var/www/webxxx/conf/php54/
export PHPRC
exec /usr/local/php54/bin/php-cgiDanach Apache neu starten und im LiveConfig irgendeine Einstellung des betroffenen Hostingvertrags neu speichern (so dass dessen vHost-Konfiguration neu erzeugt und damit die .httpd.conf per Include aufgenommen wird). Danach mit einer phpinfo() prüfen, ob das Ergebnis passt.
Die notwendigen Änderungen zur Verwaltung verschiedener php-Versionen sind unsererseits fast abgeschlossen, so dass das auch in einer der nächsten 1.7er-Versionen mit drin ist. Noch ein wenig Arbeit gibt es da für die notwendige GUI (PHP-Versions-Auswahl).
Viele Grüße
-Klaus Keppler
Dabei handelt es sich um Webspaces mit Verzeichnis-Passwortschutz.
Rufen Sie das Importscript bitte zusätzlich mit dem Parameter "--verbose" auf, dann sollten Sie mehr Details bekommen.
Viele Grüße
-Klaus Keppler
Mit "curl -I" machen Sie einen HEAD-Request. Das WSDL wird aber nur bei einem GET-Request ausgeliefert.
Soll heißen, wenn Sie das "-I" weg lassen, bekommen Sie auch das WSDL. Oder wenn Sie die URL im Browser aufrufen.
(hat mich eben ziemlich erschrocken, ich hab's auch erst auf den zweiten Blick bemerkt... ;))
Vielen Dank für die Rückmeldungen.
Ab sofort ist v1.6.4-r2488 auch im "stable"-Repository enthalten.
Viele Grüße
-Klaus Keppler
PS: für Technikfreaks: die Option SQLITE_ENABLE_STAT3 sorgt derzeit für viele Sorgen mit dem neuen Query Planner und ist offenbar nicht vollständig durchgetestet. Wir haben diese vorerst deaktiviert.
PPS: nobody's perfect - das gilt übrigens auch für MySQL. Der "offizielle" MySQL C-Client von der MySQL-Website enthält etliche, teilweise seit Jahren bekannte Fehler, die oft nur bei anspruchsvollen Anwendungen (wie LiveConfig ;)) auffallen. Der Unterschied ist: ein bei SQLite gemeldeter und reproduzierbarer Fehler wird i.d.R. binnen 1-2 Tagen komplett beseitigt.
Codeservice auth { unix_listener auth-userdb { #group = mail mode = 0600 #user = mail }
Die spannende Frage ist, wer die Einträge "group" und "user" da auskommentiert hat. LiveConfig (in Form von "dovecot.lua") kann das nicht gewesen sein. Vielleicht können Sie anhand des Datei-Änderungs-Datums herausfinden, was genau zu diesem Zeit passiert ist (z.B. ein Update von Dovecot?)
Ab sofort steht v1.6.4-r2488 als Preview zur Verfügung. Wer bislang das Problem hatte, dass keine Domains beim Erstellen/Bearbeiten von Postfächern angezeigt wurden, möge bitte mal dieses Update installieren und uns ein kurzes Feedback geben. Die einzige Änderung gegenüber r2487 besteht in den SQLite-Optionen.
Viele Grüße
-Klaus Keppler
Ich tippe mal auf CentOS? (bitte immer die genaue Distribution mit angeben)
Was steht denn in /etc/dovecot/dovecot.conf im Abschnitt "service auth"? Sollte eigentlich so aussehen:
unix_listener auth-userdb {
group = mail
mode = 0600
user = mail
}LiveConfig fasst die Datei /var/run/dovecot/auth-userdb nicht an; auf die Schnelle finde ich hier auch kein anderes Script, dass da irgendwie herumfummelt.
Haben Sie SELinux aktiviert?
Viele Grüße
-Klaus Keppler
Das Problem ist leider wirklich äußerst kompliziert - ob man Wheezy oder Squeeze verwendet spielt dabei keine Rolle. Ich stehe mit dem Hauptentwickler in Kontakt, um dem näher auf die Spur zu kommen. Vereinfacht gesagt: mit SQLite ab Version 3.7.15 wurden einige Optimierungen am sogenannten Query Planner begonnen (ein zentraler Bestandteil eines Datenbanksystems). SQLite hat damit zwar spürbar an Performance gewonnen, aber es gibt ganz offenbar einige Fälle, in denen der neue Query Planner schlicht alle Ergebnisse wegoptimiert 
Dabei kommt es nicht nur auf die exakte SQL-Abfrage an (bei dem letzten von uns entdeckten Fehler wurden z.B. durch Verwendung der ORDER-Klausel plötzlich die Ergebnisse weggefiltert), sondern z.T. auch auf intern erzeugte Statistikdaten über die Index-Verteilung.
Deshalb können wir den Fehler hier selbst bislang auch nicht reproduzieren. In unserem eigenen Continuous Integration-System laufen beispielsweise auch automatische Tests zum Anlegen von Domains und Postfächern; dabei ist es bislang noch zu keinem Fehler gekommen.
Da wir aber auch nicht unsere Kunden als Testkaninchen für SQLite hernehmen möchten, haben wir ab sofort einige dieser Optimierungen ("STAT3") vorübergehend deaktiviert. Die Auswirkungen sollten nicht wirklich spürbar sein (wir selber können auch mit größeren Testdatenbanken bislang keinen Unterschied feststellen). Dennoch möchten wir das SQLite-Team in der Fehlersuche unterstützen - schließlich kommt SQLite ja auch in ziemlich vielen anderen Umgebungen zum Einsatz (Smartphones, Browser, usw.).
Eben läuft v1.6.4-r2488 durch die letzten Tests durch, sollte in ca. 30min fertig sein. Sobald wir dann von einem der "betroffenen" Kunden das "OK" bekommen, dass nun alles wieder funktioniert, wird das als offizielles Update bereitgestellt.
Viele Grüße
-Klaus Keppler