Ich vermute mal eher, dass die PHP-Instanzen gar nicht laufen.
Welche Ausgabe gibt "ps aux | grep php"?
Debian 9!? Was steht in /etc/debian_version?
Beiträge von kk
-
-
So wie es aussieht haben Sie einen Syntax-Fehler in der Konfigurationsdatei.
Führen Sie bitte mal "liveconfig -f" aus - was wird dabei ausgegeben? -
"Nix" gibt's nicht.

Warum können Sie nicht einfach mal mit copy&paste alle Ausgaben aus /var/log/liveconfig/liveconfig.log übermitteln?
(es reichen ja die letzten ~30 Zeilen - halt alles mit Datum/Uhrzeit vom letzten Startversuch)Ohne Log keine Hilfe.
-
Ohne die Info, was genau nicht geht, wird es leider sehr schwer irgendwie zu helfen.
Wenn Sie den SQLite-Dump erzeugt und gemäß der Anleitung in MySQL eingespielt haben, tragen Sie einfach in liveconfig.conf die Zugangsdaten zur MySQL-Datenbank ein und starten LiveConfig anschließend neu.
Wenn irgendwas nicht klappen sollte (z.B. falsche Zugangsdaten o.ä.), dann gibt es eine Fehlermeldung in /var/log/liveconfig/liveconfig.log.Viele Grüße
-Klaus Keppler
-
Der Anzeigefehler ist mit v1.6.1-r2011 beseitigt, die "Zoom"-Funktion steht noch auf der ToDo-Liste.
Viele Grüße
-Klaus Keppler
-
Sofern die Domains "ohne" SSL auf der selben IP-Adresse laufen, auf der auch (mindestens) ein SSL-Zertifikat aktiviert ist, lässt sich das rein technisch gar nicht vermeiden, dass man dieses Domains auch mit https:// aufruft. Das kann auch kein Confixx umgehen ;). Die Warnmeldung wird durch den Browser erzeugt (da er kein passendes SSL-Zertifikat präsentiert bekommt); letztendlich wird aber die Seite "Diese Domain ist nicht verfügbar" (oder so ähnlich) angezeigt, weil kein entsprechender VirtualHost konfiguriert ist.
Viele Grüße
-Klaus Keppler
-
Das hatte mit der neuen Version übrigens nichts zu tun, sondern nur mit dem (durch das Update ausgelöste) LiveConfig-Neustart. Die Liste der Apache-Module wird nämlich nur beim Start von LiveConfig (bzw. vom jeweiligen LiveConfig-Client) aktualisiert.
Viele Grüße
-Klaus Keppler
-
Dovecot hat eine integrierte Sieve-Unterstützung - es muss also kein zusätzliches Paket installiert werden, um den Autoresponder nutzen zu können.
Funktioniert der Autoresponder bei Ihnen nicht?Viele Grüße
-Klaus Keppler
-
Hallo,
hier lag leider ein Bug im OpenSUSE-spezifischen Konfigurationsabschnitt in der "postfix.lua" vor.
Workaround: öffnen Sie bitte /usr/lib/liveconfig/lua/postfix.lua und fügen in Zeile 180 noch "unix:" vor dem Socket-Pfadnamen ein:Codedata['clamav_milter_socket'] = "[U][COLOR=#b22222][B]unix:[/B][/COLOR][/U]/var/lib/clamav/clamav-milter-socket";Starten Sie LiveConfig anschließend neu.
Patch ist ab Version 1.6.1-r2110 enthalten.
Viele Grüße
-Klaus Keppler
-
Der Fehler wurde inzwischen lokalisiert und ist ab v1.6.1-r2109 beseitigt.
Offenbar gibt es einen Bug im aktuellen Linux-Kernel bzw. libc, die mit OpenSUSE 12.2 ausgeliefert werden, oder in der Dokumentation der Systemfunktion getgrnam_r.
Weitere Infos:
- Ticket: https://www.liveconfig.com/dev/issues/77
- http://tomlee.co/2012/10/probl…nd-getgrgid_r-getgrnam_r/Wir konnten das hier auch erst bei einem Test-Import von >200 Kunden aus Confixx auf OpenSUSE 12.2 reproduzieren - auf anderen Distributionen ist uns dieser Fehler bislang nicht begegnet.
Nun läuft jedenfalls alles, die neue Version läuft gerade durch's Build-System und wird heute Abend bereitgestellt.Viele Grüße
-Klaus Keppler
-
Kurz gesagt: ja, macht absolut Sinn, die fehlende Zeile ist ab mit r2108 erstellten Konfigurationen enthalten.
(bei RHEL/Centos war diese Zeile bereits mit drin)Viele Grüße
-Klaus Keppler
-
Ja, das ist ein guter Einwand. Das CRAM-MD5-Schema, in dem die über LiveConfig erfassten Passwörter gespeichert werden, kann auch für Plaintext-Authentifizierung verwendet werden - nur anders herum klappt das natürlich nicht.
Wird einem Mail-Client nun beim Login das CRAM-MD5-Verfahren angeboten, aber dessen Benutzerpasswort liegt nur im MD5-CRYPT-Schema vor, klappt das Login nicht.Ich habe eben in die dovecot.lua eine Änderung eingebaut, mit der Sie über die custom.lua künftig festlegen können, dass CRAM-MD5 nicht als Authentifizierungsverfahren erlaubt werden soll. LiveConfig wird die Passwörter dennoch im CRAM-MD5-Schema speichern (ist ja "abwärtskompatibel"), damit man vielleicht eines Tages - wenn alle MD5-Passwörter mal über LiveConfig aktualisiert wurden - auf CRAM-MD5 umstellen kann.
Für maximale Benutzersicherheit ist eine SSL/TLS-Verbindung ohnehin am wichtigsten, da sich alle MD5-Passwörter mit heutigem Stand der Technik in überschaubarer Zeit knacken lassen.

Die aktualisierte dovecot.lua ist morgen in r2108 enthalten. Bis dahin entfernen Sie einfach in der dovecot.conf das "cram-md5" aus der Zeile mit "mechanisms = plain login cram-md5" und starten Dovecot neu. LiveConfig wird diese Datei nicht überschreiben, so lange Sie in der Oberfläche bei Serververwaltung -> Mail -> Dovecot keine Änderungen vornehmen.
Viele Grüße
-Klaus Keppler
-
Die .httpd.conf kann/darf nur vom "root"-User erstellt/verwaltet werden.
Das ursprüngliche Ziel lässt sich ganz einfach mit simplen RewriteRules in einer .htaccess-Datei verwirklichen.
Apache ConfigurationRewriteRule ^webmail/(.*) /var/www/webxxx/htdocs/webmail/$1 [L] RewriteRule ^(.*) /var/www/webxxx/htdocs/cms$1Viele Grüße
-Klaus Keppler
-
Könnten Sie bitte einen der betroffenen Accounts mal löschen, dann LiveConfig neu starten und dann erneut importieren?
Wir werden morgen auch mal eine Confixx-Migration mit einem OpenSUSE 12.2-Zielsystem testen.
Viele Grüße
-Klaus Keppler
-
Merkwürdig... unter Debian ist mir diese Meldung bislang noch nie in die Finger gekommen.
Starten Sie bitte Dovecot mal neu (/etc/init.d/dovecot restart) und versuchen es dann noch einmal.
Sollte es immer noch die Meldung "too many open files" geben, würde mich die Ausgabe von "ulimit -n" (ausgeführt als root) sowie eine Prozessliste (ps -aux) interessieren - gerne auch per PM oder an support@liveconfig.comViele Grüße
-Klaus Keppler
-
Hmm, ist das nicht deutlich genug?
ZitatCan't open SSL parameter file ssl-parameters.dat: Too many open files
Offenbar gibt es zu viele gleichzeitige geöffnete Dateien durch die dovecot-Prozesse.
Was sagt denn "ps -u dovecot | wc -l"?
Welche Limits für gleichzeitige Verbindungen zu Dovecot haben Sie in LiveConfig eingestellt?Viele Grüße
-Klaus Keppler
-
Das lcdbdump-Tool wurde eben aktualisiert, so dass der Dump nun mit "SET NAMES 'utf8';" beginnt. Damit sollten beim Import nach MySQL auch keine Zeichensätze mehr durcheinander gewürfelt werden.
Viele Grüße
-Klaus Keppler
-
Nein, das Migrations-Script hat auf LiveConfig keinen Einfluß.
Ich habe eben auch noch mal den zuständigen Code in "web.lua" angesehen - es kann eigentlich gar nicht passieren, dass die Verzeichnisse alle root:root gehören, da diese direkt nach dem Anlegen dem jeweils richtigen User übereignet werden.
Haben Sie eventuell nach dem Anlegen des Accounts z.B. mit rsync noch Daten vom alten Server in diese neuen Verzeichnisse übernommen, so dass hierbei eventuell die Rechte geändert wurden?
ODER: haben Sie /srv/www eventuell von einem anderen Medium gemountet, dessen Filesystem keine Benutzer/Gruppen unterstützt? (zB. externe Platte mit FAT32 o.ä.)Ansonsten tragen Sie bitte (ab r2102) mal in /etc/liveconfig/liveconfig.conf die Option "log_level=debug" ein, starten LiveConfig neu und legen dann über die LiveConfig-Oberfläche einen neuen Vertrag an. Prüfen Sie dann, ob auch hier die Rechte alle falsch gesetzt sind, und was ggf. in der liveconfig.log steht.
Viele Grüße
-Klaus Keppler
-
Danke für den Hinweis.
Zur Version r2052 gab es keine Änderungen, welche die Berechtigungsvergabe betreffen, daher vermute ich ein anderes Problem.
Könnten Sie bitte noch einen Blick in /var/log/liveconfig/liveconfig.log werden, ob es nach dem Anlegen des Accounts web590 noch sonstige Fehlermeldungen gab? (ich vermute, dass nach dem Erstellen der Verzeichnisse ein Fehler aufgetreten ist).Die anderen Fehler könnten daher rühren, dass falsche bzw. zu restriktive Berechtigungen auf das o.g. Verzeichnis gesetzt sind.
Bei der Gelegenheit ist uns übrigens aufgefallen, dass CGI-Scripte mit SuExec unter OpenSUSE nicht funktionieren (siehe LC#74) - dieser Fehler ist mit r2102 beseitigt (Update kommt in Kürze ins Test-Repository).
Viele Grüße
-Klaus Keppler
-
Da scheint beim Import des Dumps in MySQL ein falscher Zeichensatz verwendet worden zu sein (der Dump wird mit UTF-8 erzeugt).
Es sollte genügen, im Dump noch ganz am Anfang die Zeile "SET NAMES UTF-8;" einzufügen. Wir werden das morgen ins Dump-Tool mit einbauen, so dass das automatisch passiert.