Mit Version 1.9.0-r3619 enthält LiveConfig einen Workaround für den Bug im MySQL-Client.
LiveConfig (bzw. der darunterliegende Datenbank-Layer) initialisiert das mysql-Objekt dann für jeden Verbindungsversuch komplett neu.
Eventuell sind die hier vereinzelt genannten Sonderzeichen-Darstellungsfehler mit MySQL als Backend damit auch beseitigt (ich kann mir vorstellen, dass da beim Reconnect auch die UTF8-Einstellung verloren gegangen ist).
Was genau ist fehlerhaft?
Was liefert der Befehl "apache2ctl configtest"?
Weiß jemand, wie man LC von diesem Verhalten, den Socket an der falschen Stelle in /tmp statt an der passenden Stelle unter /var/run/mysqld/ zu suchen, abbringt?
LiveConfig ruft zur Verbindung zu MySQL die Funktion "mysql_real_connect()" in einer Schleife auf. Der MySQL-Client wiederum liest seine Einstellungen (u.a. socket) aus /etc/mysql/my.cnf, Abschnitt [client].
Wenn bei einem Reconnect der falsche Socket-Pfad verwendet wird, dann handelt es sich um einen Fehler im MySQL-Client, und nicht in LiveConfig.
[offtopic]Höchste Zeit also, Oracle mal mit dem Anwalt zu drohen.[/offtopic]
In LiveConfig können Sie den Socket auch explizit in der /etc/liveconfig/liveconfig.conf angeben. Fügen Sie dazu die Zeile "db_options = socket=/var/run/mysqld/mysql.sock" hinzu.
Wir werden dennoch gerne prüfen, ob es einen Workaround für diesen MySQL-Client-Fehler gibt.
Hallo,
hier mal 3 Links:
http://www.liveconfig.com/de/handbuch/server.sslcert.html
https://www.liveconfig.com/dow…/32bit/bash_ld_preload.so
https://www.liveconfig.com/dow…/64bit/bash_ld_preload.so
und weitere diverse Verlinkungen zu Beiträgen aus dem Forum.
Danke für den Hinweis. Die Handbuch-Dateien enden nun mit ".xhtml" statt bisher ".html" - ab sofort wird das weitergeleitet. Die beiden Downloads sind theoretisch obsolet (ShellShock sollte in jeder halbwegs aktuellen Distribution kein Thema mehr sein), werden aber gleich wieder online genommen.
Gefühlt wird ohne Nachfrage gar kein Support-Ticket beantwortet, ich hab letztens mal mit nem Anwalt gedroht und dann ging das Ganze einmal.
Jetzt habe ich schon wieder seit 6.6.:
Ja, seit dem 06.06. 23:40. Das ist Wochenende, kurz vor Mitternacht zu Sonntag.
Das von Ihnen beschriebene Anliegen ist nicht betriebskritisch (Ihre Infrastruktur funktioniert ja), daher lassen wir hier nicht sofort alles stehen und liegen und fahren am besten noch persönlich bei Ihnen vorbei.
Zu Drohungen mit Anwälten sage ich mal besser gar nichts...
ZitatDer Gipfel der Frechheit war in meinen Augen die Aussage, dass man bestimmte Sachen nicht braucht oder nicht so macht (konkret wegen meiner Nachfrage, wieso man nur 10 Emailadressen pro Postfach anlegen kann) (schon klar, mit Weiterleitungen gehen mehr)
Meinen Sie Alias-Namen? Dieses Limit ist inzwischen auch konfigurierbar. Wenn Sie es als "Gipfel der Frechheit" empfinden, dass wir das Produkt nicht (nur) nach Ihren Vorstellungen entwickeln, sollten Sie besser eine Individualentwicklung beauftragen. Mit einem kleinen sechsstelligen Betrag sind Sie da schon dabei.
Sie wissen genau, dass wir in dringenden Fällen jederzeit telefonisch zur Verfügung stehen und wir auch schon direkt auf Ihrem Server Support geleistet haben. Dass Sie dann hier im Forum (halbanonym) so herumpoltern enttäuscht mich dann schon etwas.
Mit freundlichen Grüßen
Klaus Keppler
Was mich persönlich noch mehr nervt sind das diverse Seiten dieser Webseite nicht mehr vorhanden sind. Auch wichtige Anleitungsseiten etc, und das schon seit etlichen Tagen.
Welche Seiten vermissen Sie denn konkret? Inzwischen sollte wieder alles online sein.
Ja, das ist in der Tat ein Problem (dass OpenSSL 1.0.2 benötigt wird was nicht bei Debian Jessie dabei ist).
Aaaaber: 
1.) in Kürze wird Apache 2.2.30 freigegeben, der u.a. dieses Thema adressiert. Aufgrund der großen Verbreitung kann man wahrscheinlich davon ausgehen, dass der relevante Patch in die Versionen von Debian 6 & 7 portiert wird.
2.) LiveConfig wird die eigenen DH-Parameter unter Debian 8 mit in die Zertifikatsdateien (.pem) schreiben. Somit werden die dann auch berücksichtigt, wenn eben der SSLOpenSSLConfCmd-Befehl nicht verfügbar ist.
Im kommenden Update der 1.9er-Preview ist das bereits enthalten (dauert nur noch ein paar Tage bis wir die online stellen können).
Das Problem mit Postfix und Error 503 bleibt weiterhin bestehen!
Ohne genauere Fehlerbeschreibung bleibt mir nur der Blick in die Kristallkugel.
Zum Postfix:
- was genau liefert "liveconfig --diag"? (ggf. nur den Abschnitt rund um Postfix/Dovecot posten)
- wurde LiveConfig komplett neu gestartet? (bitte "ps aux | grep liveconfig" ausführen, Prozess-Startzeitpunkt prüfen. Ggf LiveConfig beenden ("liveconfig -k stop"), anhand der Prozessliste das prüfen, dann LC neu starten).
- existiert die Datei /etc/postfix/liveconfig.status ?
Zum 503: wo genau wird dieser Fehler ausgegeben? Vom LiveConfig? Vom Apache? Was liefern die jeweiligen Log-Dateien bei so einem Fehler? (/var/log/liveconfig/liveconfig.log bzw /var/log/apache/error.log)
Da Sie Apache 2.4.10 nutzen, dürfte dieser wohl selbst compiliert sein - suPHP dann vermutlich auch.
Prüfen Sie bitte, ob die Datei /etc/apache2/mods-enabled/suphp.conf existiert. Die enthält nämlich den relevanten "SetHandler"-Befehl. Normalerweise sollte die Datei etwa so aussehen:
<IfModule mod_suphp.c> <FilesMatch "\.ph(p3?|tml)$">
SetHandler application/x-httpd-suphp
</FilesMatch>
suPHP_AddHandler application/x-httpd-suphp
<Directory />
suPHP_Engine on
</Directory>
# By default, disable suPHP for debian packaged web applications as files
# are owned by root and cannot be executed by suPHP because of min_uid.
<Directory /usr/share>
suPHP_Engine off
</Directory>
# # Use a specific php config file (a dir which contains a php.ini file)
# suPHP_ConfigPath /etc/php5/cgi/suphp/
# # Tells mod_suphp NOT to handle requests with the type <mime-type>.
# suPHP_RemoveHandler <mime-type>
</IfModule>Ein Downgrade von LiveConfig ist nicht möglich (außer, Sie haben die LiveConfig-Datenbank vor dem Update gesichert und spielen diese auch wieder zurück).
Wenn Postfix nach einem Update nicht angezeigt wird, dann wird während des Update-Vorgangs vermutlich auch Postfix aktualisiert worden sein und LiveConfig das nicht erkannt haben (weil zum Zeitpunkt des LiveConfig-Neustarts das Postfix-Paket nicht vollständig installiert war).
Ein Neustart von LiveConfig alleine hätte genügt.
Die Fehlermeldung klingt aber ohnehin danach, dass Sie auf Ihrem Server noch ganz andere Probleme haben.
LiveConfig ist als ganz normales Debian-Paket installiert, lässt sich also auch mit ganz normalen "Hausmitteln" entfernen. Die notwendigen Parameter sind in den man-Pages von "dpkg" und "aptitude" beschrieben. (--force etc.)
wget -O -f - https://www.liveconfig.com/liveconfig.key | apt-key add -
Das "-f" hat da nichts zu suchen bzw sitzt an der falschen Stelle (also weglassen, oder "-O - -f" nehmen)
ZitatFEHLER: Dem Zertifikat von »www.liveconfig.com« wird nicht vertraut.
FEHLER: Das Zertifikat von »»www.liveconfig.com«« wurde von einem unbekannten Austeller herausgegeben.
Das Paket "ca-certificates" fehlt. Ihr Server wird also gar keinen SSL-Zertifikaten vertrauen.
Prinzipiell sollte das reibungslos funktionieren; bitte posten Sie mal die Ausgabe von "liveconfig --diag" (der Apache-Abschnitt mit allen Modulen & PHP-Versionen genügt)
Übrigens: wenn der Kunde König ist, dann würde ich diesem als sein Dienstleister empfehlen FastCGI zu nutzen, weil das deutlich schneller & ressourcenschonender ist. suPHP hatte seine besten Zeiten als Arbeitsspeicher extrem knapp war und Shared Hosting Server seeeeeehr viele Webspaces gleichzeitig hosten sollten. Man kann mit suPHP auch keinen OpCode-Cache verwenden, etc...
Viele Grüße
-Klaus Keppler
Danke für den Hinweis. Diese Datei ist beim Website-Relaunch leider unter die Räder gekommen 
Steht nun wieder online - sorry für die Unannehmlichkeiten!
Viele Grüße
-Klaus Keppler
Äh, sorry, ich meinte nicht die suphp.log sondern die suexec.log (/var/log/apache2/suexec.log)
Tauchen Meldungen in /var/log/suphp/suphp.log auf?
Wenn nein: bitte auch das PHP-Errorlog aktivieren (in LC über Hosting -> Webspace -> php.ini-Einstellungen -> dort "log_errors" auf "on" stellen)
Das PHP-Log landet dann in ~/logs/priv/php_errors.log (kann auch über den Log-Viewer in LiveConfig angezeigt werden)
Guten Abend!
Nach einer Installation von LC auf Debian 8 erhalte ich bei der Installation der PHPMyAdmin-App den Fehler 500. Wo kann ich hier ansetzen?
Wenn ein Error 500 kommt, dann tritt der Fehler i.d.R. noch "vor" PHP auf.
Aktivieren Sie bitte im LiveConfig das Fehlerprotokoll (Hosting -> Webspace -> Fehlerprotkoll aktivieren). Nach ca. einer Minute rufen Sie dann die phpMyAdmin-URL erneut auf - es sollte dann einen Eintrag in der error.log geben (die können Sie sich ebenfalls über LiveConfig "live" anzeigen lassen)
Wenn es sich um einen allgemeinen Fehler handelt ("Premature end of script headers...") dann wäre wichtig, ob Sie PHP mit suPHP oder mit FastCGI ausführen.
In allen Fällen müssen natürlich die Pakete "php5-cgi" und "apache2-suexec" installiert sein, bei FastCGI zudem noch "libapache2-mod-fcgid". Wichtige Log-Dateien sind dann die /var/log/suphp/suphp.log und /var/log/apache2/error.log
Viele Grüße
-Klaus Keppler
Kurzes Update: der Issue Tracker (Redmine unter https://www.liveconfig.com/dev/) sowie das Übersetzungsportal "Pootle" (https://www.liveconfig.com/pootle/) laufen derzeit noch nicht - hier macht die Umstellung von lighttpd auf NGINX leider deutlich mehr Probleme als erwartet.
Wir werden das im Laufe der kommenden Woche angehen - bis dahin bitte um um Verständnis und etwas Geduld.
Die "normale" Website, das Forum, Lizenzportal und SOAP-API laufen aus unserer Sicht soweit reibungslos. Die neue Website wurde für mobile Darstellung verbessert, insgesamt aufgeräumt & entrümpelt und die meisten Inhalte nun auch auf Englisch bereitgestellt. Die Wissensdatenbank (Knowlede Base) wurde durch ein Wiki abgelöst (Verlinkung und KB-Redirects folgen noch). Außerdem fehlen noch Handbuch & Shop auf Englisch.
Viele Grüße
-Klaus Keppler
Hallo,
kurz zur Information: in den nächsten zwei Stunden stellen wir auf eine komplett neue Website um. Das Forum und der Issue Tracker laufen auf getrennten Systemen, da wird es daher eine Zeit lang zu Darstellungsfehlern kommen bis das CSS entsprechend aktualisiert und die Templates ausgetauscht sind.
Wenn die Umstellung abgeschlossen ist und keine Fehler mehr auftreten sollten, werde ich hier noch mal kurz Bescheid geben.
Viele Grüße
-Klaus Keppler
Hab heute morgen zu meiner letzten Idee noch eine .dpkg-old Datei gefunden, die anscheinend von LC irgendwann man überschrieben wurde.
Eine .dpkg-old wird dann erzeugt, wenn Sie z.B. das Apache-Paket aktualisieren und die von LiveConfig erzeugte Konfiguration mit der vom Debian-Paket überschreiben (also genau anders herum). Wenn es Änderungen an Konfigurationsdateien gibt, wird bei einem Update nachgefragt, ob Sie die bestehende Konfiguration beibehalten oder überschreiben wollen - Standard ist "beibehalten" - Sie haben dann vermutlich "überschreiben" gewählt (so wurde die bestehende (LiveConfig-)Konfiguration in die .dpkg-old weggesichert).
ZitatAllerdings,
/var/www/web01/htdocs/unterordner/kundenzugriff1 (protected2: User1, User2) (domain: kunde1.example.com)
/var/www/web01/htdocs/unterordner/kundenzugriff2 (protected3: User1, User3) (domain: kunde2.example.com)
funktioniert auch weiterhin nicht für User1.
Die von LC erstellten <Directory> Einträge aus meiner web01.conf:
Da ist etwas falsch - wenn User1 auch Zugriff auf "kundenzugriff1" bzw "kundenzugriff2" haben soll, dann muss der bei "Require user" auch mit drin stehen.
Prüfen Sie bitte noch mal in LiveConfig, ob Sie User1 wirklich zum jeweiligen Ordner hinzugefügt haben. Das sollte dann so aussehen:
forum.liveconfig.com/cms/attachment/13/
Hallo,
/var/www/web01/htdocs (domain: example.com)
/var/www/web01/htdocs/unterordner (protected1: User1)
/var/www/web01/htdocs/unterordner/kundenzugriff1 (protected2: User1, User2) (domain: kunde1.example.com)
/var/www/web01/htdocs/unterordner/kundenzugriff2 (protected3: User1, User3) (domain: kunde2.example.com)
Ich habe mal genau diese Struktur auf einem Debian 8 eingerichtet und kann keinerlei Probleme feststellen.
User1 kann beide Websites (kunde1.example.com, kunde2.example.com) öffnen, die anderen beiden User nur jeweils eine (User2 -> kunde1, User3 -> kunde3).
Vielleicht hatte Ihr Browser noch irgendwelche Zugangsdaten gespeichert, was zu Fehlern führte? Ggf mal Cache leeren bzw. mit einem Browser im Privat-Modus oder einem anderen Browser testen.
(wir testen sowas übrigens immer mit curl oder lynx auf der Konsole)
ZitatWas mir heute morgen noch aufgefallen ist:
In sites-available existiert eine Konfiguration "000-default", die offensichtlich von liveconfig zuletzt bearbeitet wurde, aber nicht aktiviert ist (ich gehe mal davon aus, dass liveconfig diese normalerweise aktivieren würde).
Das ist definitiv ein Fehler. Diese Datei sollte unter Debian 8 "000-default.conf" heißen und aktiviert sein.
Haben Sie den Rechner neu aufgesetzt oder von einer früheren Debian-Version aktualisiert?
Benennen Sie diese Datei bitte um (in 000-default.conf) und aktivieren Sie diese (a2enmod 000-default).
ZitatMöchte ich diese nun manuell aktivieren, stürzt Apache2 mit der Fehlermeldung ab, dass Port 443 nicht zugewiesen werden konnte.
Dann läuft auf Port 443 wohl noch irgendein anderer Dienst. Was liefert "netstat -tlpn | grep 443"?
Viele Grüße
-Klaus Keppler
