Nutzen Sie Apache oder NGINX?
Bei Apache müsste dann eigentlich in der betroffenen vHost-Konfiguration (/etc/apache2/sites-enabled/<Vertrag>.conf) eine "ErrorLog"-Anweisung zu finden sein.
Falls nicht: gibt es Meldungen in /var/log/liveconfig/liveconfig.log?
Beiträge von kk
-
-
Standardmäßig wird kein error.log angelegt*, hierfür muss man zuerst das Fehlerprotokoll aktivieren. Nach dem Apache-Reload (max. 60 Sekunden später) sollte - falls noch nicht vorhanden - eine leere error.log existieren. Mit dem Log-Viewer kann man die dann auch im Browser anschauen.
*) Grund: unsaubere PHP-Anwendungen geben Unmengen an Warnungen und Hinweisen aus, welche ein error.log schnell mal seeehr groß werden lassen. Zudem braucht Apache für jedes einzelne error.log einen eigenen Filedeskriptor. Deren Anzahl ist begrenzt und muss sonst ggf. mit "ulimit" getuned werden. Daher wird das Log (derzeit) auch automatisch nach 24 Stunden wieder deaktiviert.
-
LiveConfig 1.8.1-r3397
OpenSuse- aktuell ist LiveConfig v1.8.2-3494 (wobei das dieses Problem konkret nicht beheben wird)
- welche OpenSUSE-Version nutzen Sie?Ggf. ändern Sie die Socket-Angabe in der clamav-milter.conf.
-
Keine Angst: modifiedShop ist ein Thema bei uns. Eventuell wird diese App tatsächlich "rausgeschmissen", weil die Pflege nicht gerade "trivial" ist... Weitere Infos folgen aber noch.
-
Ich rede auch von MySQL-Benutzernamen und nicht von Datenbanknamen. Die Quelle ist auch in meinem Posting verlinkt.
Da in LiveConfig Benutzername=Datenbankname sind, gilt das Limit somit implizit auch für Datenbanknamen (es brächte ja nichts, die Präfixe nur bei Datenbanknamen zu erzwingen, nicht aber bei Benutzernamen).Wer mit dem Namen "web12345db1" nichts anfangen kann, sollte das Kommentarfeld in LiveConfig nutzen. Da kann man dann so Sachen eintragen wie "Online-Shop" oder "Joomla für Fischzuchtverein". Ich verstehe nicht, warum man diese Infos zwingend im Datenbanknamen bräuchte...
-
Ich habe das schon oft und an vielen Stellen erklärt: in MySQL können Benutzernamen nunmal nur max. 16 Zeichen lang sein. Das ist so in MySQL hartcodiert und lässt sich nicht ändern.
Punkt.
-
Vor etwa einer Stunde wurde eine neue Version von OpenSSL veröffentlich, welche einige als "hoch" eingestufte Fehler beseitigt. Auf den ersten Blick handelt es sich da vor allem um potenzielle DoS-Angriffsmöglichkeiten.
Ab sofort steht mit LiveConfig v1.8.2-r3494 eine neue Version bereit, welche ein aktualisiertes OpenSSL (v1.0.1m) enthält.
In Kürze erscheinen zudem die Updates für die openssl-Pakete der verschiedenen Distributionen (für Debian Wheezy ist das bereits verfügbar) - wir empfehlen, diese zeitnah einzuspielen und die betroffenen Dienste neu zu starten (je nachdem: apache, nginx, proftpd, vsftpd, dovecot, postfix, ...).
Viele Grüße
-Klaus Keppler
-
Hallo,
ein Teil des LiveConfig-Teams (cr & kk) wird dieses Jahr auch wieder auf den WorldHostingDays in Rust dabei sein.
Am Mittwoch und Donnerstag (25./26. März) sind wir den ganzen Tag vor Ort - wer einen Termin mit uns vereinbaren möchte schreibt bitte kurz an support@liveconfig.com (am besten gleich mit 1-2 Terminvorschlägen). "Spontane" Treffen sind natürlich auch möglich. Als Treffpunkt hat sich die "Internet Lounge" bislang ganz gut bewährt.
Viele Grüße
-Klaus Keppler
-
Derzeit geht das nur über globale Einstellungen (z.B. /etc/apache2/mods-enabled/fcgid.conf).
Eine Konfiguration von FCGI/FPM pro Angebot/Vertrag ist aber geplant: https://www.liveconfig.com/dev/issues/164 -
-
Steht nun auf der Tagesordnung: https://www.liveconfig.com/dev/issues/162
-
Die Domain liegt aber auf einem anderen Server, so dass er die Domain wieder gelöscht hat (ohne vorher den Mail-Account zu löschen).
Das sollte eigentlich
gar nicht möglich sein. Wenn man eine Domain löschen möchte, mit der noch Postfächer eingerichtet sind, gibt's eine Fehlermeldung.
Löscht man allerdings einen kompletten Vertrag, bei dem noch Domains mit Postfächern existieren, dann werden die alle mit gelöscht. In einigen Tests eben wurde die Domain dabei aber auch aus der virtual_domains entfernt.Können Sie herausfinden, wo/wie der Kunde die betroffene Domain ursprünglich angelegt und wie genau gelöscht hatte?
(hat der Kunde die Domain als "externe Domain" hinzugefügt oder ist er Reseller und hat die Domain direkt einem eigenen Vertrag zugeordnet? Wo/wie hat er die gelöscht?)
Ich würde das beschriebene Verhalten nämlich auch als Bug bezeichnen.
-
Ich wäre dafür, das man die Datenbanknamen nicht selber vergeben darf, bzw. es ein generelles Präfix gibt.
Einstellungen -> Wiederverkäufer -> Präfix für Datenbankzugänge. Dort "%c" als Platzhalter für den Vertragsnamen verwenden (z.B. "%cdb" erlaubt nur Datenbanknamen in der Form "web1db[...]")
-
LiveConfig zeigt immer den Namen an, der als "Common Name" (CN) im Zertifikat hinterlegt ist.
Könnten Sie uns den Domainnamen, wo dieses Zertifikat verwendet wird, mal an support@liveconfig.com schicken? Ich würde gerne mal einen Blick auf das (öffentliche) Zertifikat werfen.Viele Grüße
-Klaus Keppler
-
Mit der PHP-Version 5.6 von Keppler/LiveConfig mag ownCloud nicht, es beschwert sich unter anderem, dass angeblich das zip-Modul fehle...
Stimmt, die Datei /opt/php-5.6/etc/conf.d/zip.ini fehlt.
Wird im nächsten Update mit installiert. Bis dahin: einfach diese Datei anlegen, mit folgendem Inhalt: -
Was die Zeichencodierung oder HTML-Ausgabe betrifft gab es seit längerer Zeit keine Änderungen an diesen Bereichen. LiveConfig selbst führt auch keinerlei Konvertierung der Ein- oder Ausgabe durch - auch der Zeichensatz für alle HTML-Seiten ist fest auf UTF-8 eingestellt.
Interessant wäre, wo genau "falsche" Umlaute auftauchen: ob nur in Inhalten die von der Datenbank kommen, oder auch in "sonstigen" Elementen (Navigation etc.). Schicken Sie uns bitte wenn möglich mal einen Screenshot an support@liveconfig.com, wenn das Problem wieder auftritt.
Welche Datenbank genau setzen Sie im Backend ein? (ich tippe mal auf MySQL oder eine Variante davon). Gibt es Auffälligkeiten bei MySQL, wenn Umlautprobleme auftauchen?Viele Grüße
-Klaus Keppler
-
Ab sofort steht das o.g. Update (als v1.8.2-r3493) für den produktiven Einsatz bereit.
Viele Grüße
-Klaus Keppler
-
Die Preview wurde eben noch mal aktualisiert (r1.8.2-r3493), da in r3489 noch zwei Fehler aufgetaucht sind (mehrfache zend_extension-Einträge wurden nicht in die php.ini geschrieben, sowie bei mehreren IP-Adressen für externe DNS-Server gab es einen Parser-Fehler).
Derzeit wird die Dokumentation aktualisiert und erweitert (es gibt separate KB-Artikel für DNSSEC, externe DNS-Server, PHP-Extensions etc.).
-
Hallo,
künftig werden wir alle Issues (Fehler und Feature-Requests) ausschließlich in Redmine tracken. Die bislang bei uns in zwei anderen Systemen (Jira und noch ein proprietäres Tool) erfassten Tickets werden wir im Laufe der nächsten zwei Tage "umziehen". Der Entwicklungsprozess soll so etwas transparenter gemacht werden.
(die Issues werden derzeit alle mit dem User "admin" im Redmine verwaltet, da diese über eine API aus unseren internen Projektplanungs-Tools kommen)
Die Redmine-Installation wird in den nächsten Stunden zeitweise nicht erreichbar sein (zwecks Aktualisierung).Zudem soll es für LiveConfig Premium-Partner und einzelne "Power-User" die Möglichkeit geben, einen eigenen Account für Redmine zu erhalten, um Fehler und Feature-Requests direkt erfassen zu können. Wer Interesse daran hat, schreibt bitte eine kurze Mail an support@liveconfig.com.
Viele Grüße
-Klaus Keppler
-
Ab sofort ist LiveConfig v1.8.2-r3489 als Preview verfügbar, ab heute Abend dann produktiv.
Es gibt einen ganzen Schwung Fehlerbeseitigungen und Verbesserungen, unter anderem:- "admin"-Benutzer kann nun umbenannt werden
- Kontaktdaten von LiveConfig-Benutzern können nun geändert werden
- Unterstützung der Konfiguration von PHP-Erweiterungen (Extensions) in php.ini-Verwaltung
- bei Wiederverkäufer-Einstellungen wurde falsches "Standard"-Logo angezeigt
- Fehler beim Bearbeiten eines php.ini Ausdruck-Wertes innerhalb von Verträgen behoben
- Anzeige des Webserver- und Datenbankserver-Namens in Webspace-Übersicht
- Spamfilter: Schwellwert für Warnung kann nun auf selben Wert wie für Ablehnung gesetzt werden (somit werden keine Mails als "Spam-verdächtig" markiert)
- mehrfache gleichzeitige Anmeldung mit dem selben Login ist nun nicht mehr erlaubt ("Admin-Verbindungen" sind davon nicht betroffen)
- jeder OTP-Code kann nun für nur eine Anmeldung verwendet werden (verhindert Session-Hijacking)
Viele Grüße
-Klaus Keppler