Beiträge von kk

- 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:
  Folgende Zeilen eintragen:
  
  
  Code

  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:
  

  Code

  application/x-httpd-suphp54="php:/usr/local/php54/bin/php-cgi"

  
  

• FastCGI:
  Folgende Zeilen eintragen:
  
  
  Code

  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.:
  

  Code

  #!/usr/bin/sh
  umask 0022
  PHPRC=/var/www/webxxx/conf/php54/
  export PHPRC
  exec /usr/local/php54/bin/php-cgi

  
  

Danach 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.

Zitat von solidius

Code

service 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

Zitat von Stefan

auch beim Bearbeiten einer E-Mail-Adresse ist das Drop-Down-Feld leer. In der Log sind keine Auffälligkeiten zu erkennen.

Hmm, das ist nicht gut
Ich werde Ihnen gleich ein Update-Package bauen, bei dem einige SQLite-Optimierungen deaktiviert sind, die vermutlich für das Problem verantwortlich sind. Welche Distribution setzen Sie genau ein?
Außerdem würde ich den Fehler gerne näher analysieren (ich stehe in Kontakt mit Richard Hipp von SQLite). Könnten Sie uns dazu bitte die LiveConfig-Datenbank von einem der betroffenen Server an support@liveconfig.com senden? Alle nicht benötigten Tabellen können Sie vorab löschen (dazu also einfach eine Kopie von /usr/lib/liveconfig/liveconfig.db anlegen, die mit dem Programm "sqlite3" öffnen, und die in diesem Beitrag beschriebenen DROP TABLE-Befehle ausführen). Wir geben die Daten selbstverständlich nicht weiter und löschen alles nach Abschluss der Analyse.

Zitat von Stefan

In der Eingabemaske beim Anlegen einer E-Mail-Adresse erhalte ich ein leeres Drop-Down-Feld bei der Auswahl der Domain.

Es gibt (mind.) einen Bug in der SQLite-Bibliothek, der zu diesem Problem führt(e). Wir hatten vom SQLite-Team eine entsprechend gepatchte Version erhalten und damit selbst auch den Fehler nicht mehr reproduzieren können, daher wundert mich das.
Wenn Sie in LiveConfig (als admin) auf "Verwaltung" -> "LiveConfig" klicken, steht da auch überall in der Box "Status" was von "SQLite 3.8.0"?
Ist die Dropdown-Box auch beim Bearbeiten von E-Mail-Adressen leer?
Gibt es irgendwelche Fehlermeldungen in /var/log/liveconfig/liveconfig.log?

Viele Grüße

-Klaus Keppler

Das LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig 1.6.4 bekanntgeben zu dürfen.
Während v1.6.4-r2480 seit Freitag Abend im Repository bereit stand, gab es eben noch mal ein kleines Update (r2487), welches insbes. einen Konfigurationsfehler bei der neuen PASV-Konfiguration mit vsftpd beseitigt.

Die wichtigsten Neuerungen in v1.6.4 sind:

• LiveConfig speichert alle eigenen Passwörter ab sofort mit dem PBKDF2-Verfahren. Dieses zählt derzeit zu den sichersten Möglichkeiten, Passwort-Hashes zu speichern: während MD5-Hashes (auch gesalzen) mit modernen GPUs binnen weniger Minuten bis Stunden geknackt werden können, erfordert PBKDF2 einen erheblichen Speicher- und Rechenaufwand, der (derzeit) mit Hardware nicht umgangen werden kann
• In der Standard- und Business-Version kann nun ganz einfach per Mausklick die SSL-Konfiguration für Web- und Mailserver so angepasst werden, dass diese den Anforderungen des PCI-DSS genügen. Gleichzeitig wurde die SSL-Unterstützung von LiveConfig verbessert.
• LiveConfig unterstützt nun auch HSTS (HTTP Strict Transport Security)
• Änderung in der Konfigurationsdatei (liveconfig.conf): um Verbindungen auf allen IPs anzunehmen, muss nun "*" statt "[::]" verwendet werden (LiveConfig passt das automatisch beim Upgrade an - wenn der Paketmanager nachfragt, kann man also problemlos seine bisherige Konfigurationsdatei weiter verwenden!)
• Konfiguration von PASV-Port-Bereichen für FTP-Server möglich
• neuer Bericht "Top10 Verträge" - zeigt die Webspaces mit den meisten Zugriffen innerhalb der letzten 24 Stunden (weitere Berichte kommen mit dem nächsten Update)

Eine vollständige Übersicht aller Änderungen finden Sie im Changelog.

Zitat von dfritz

Toll wäre es, wenn in einer zukünftigen Version auch der Mailtraffic berücksichtigt werden könnte.

Das dazugehörige Tool wurde in den letzten Wochen fertig programmiert, wir planen das mit in v1.7.0 einzubinden. Das Tool wertet in Echtzeit die Logs des Mailservers (Postfix) und des FTP-Servers (ProFTPd/vsftpd) aus. Nun brauchen wir "nur" noch die Schnittstelle um die Zahlen in LiveConfig zu übernehmen und den jeweiligen Kunden zuzuordnen.

Viele Grüße

-Klaus Keppler

Yes, another customer reported this bug yesterday - meanwhile it's already fixed (r2484), update will be available within the next hour.
Sorry for the inconveniences...

Best regards

-Klaus Keppler

Wir haben das cfximport.php-Script eben noch mal aktualisiert (r127) - nun gibt es eine Fehlermeldung, falls kein passender MySQL-Benutzer gefunden werden kann; der restliche Import wird aber fortgesetzt (dann eben ohne die Datenbank zu importieren).

Die noch immer nicht beantwortete Frage ist ja, ob die Datenbank "usr_web120_1" tatsächlich nicht mehr in MySQL existiert (Confixx glaubt ja noch, dass es diese Datenbank gäbe)

Naja, das ist Ansichtssache - in unseren Augen ist das sehr auffällig
LiveConfig hat ein Problem damit, wenn kein Datenbank-Passwort bei der SOAP-Funktion HostingDatabaseAdd() übermittelt wird. Genau das ist aber beim Import von z.B. web120 der Fall (daher die Meldung "kein MySQL-Passwort gefunden!"). Dass LC dabei abstürzt ist sehr unschön und wird gleich gefixed, ist aber nicht das eigentliche Problem.

So wie es aussieht, wurde zwar durch Confixx die Datenbank "usr_web120_1" mit dem Benutzer "web120" angelegt, in der MySQL-Datenbank selbst ist diese aber nicht mehr vorhanden (zumindest findet das Migrationsscript in der Tabelle "mysql.user" keinen Benutzer namens "web120"). Wenn diese Datenbank also tatsächlich nicht mehr existiert, löschen Sie diese bitte auch im Confixx.

... und was steht im LiveConfig-Log (/var/log/liveconfig/liveconfig.log)?

Die o.g. Passwort-Meldung erscheint nur, wenn für den Kunden selbst in Confixx kein DB-Passwort gefunden werden konnte. Der Fehlermeldung nach zu urteilen scheint das genau das Problem zu sein.
Welche Confixx-Version nutzen Sie denn?