Hallo,
mit LiveConfig v1.7.4-r3101 steht nun ein "kleines" Update (als Preview) bereit, bei dem die Tabellendarstellungen überarbeitet wurden. Die Tabellen sind nun sortierbar und LiveConfig "merkt" sich die Sortierung, Anzeigeseite und ggf. Filterbegriffe. Vereinzelt fehlen noch CSS-Anpassungen (z.B. im Bereich "Berichte"), das wird spätestens bis Montag auch überarbeitet sein.
Viele Grüße
-Klaus Keppler
Nur bei Partner-Rechnungen gibt's das Kommentar-Feld. Und das kann derzeit auch nur bei der Bestellung einer Lizenz festgelegt werden.
Das "Problem" ist unsere strikte Trennung einiger Systeme: das Lizenzsystem ist "read-only", daher können derzeit z.B. keine Änderungen an bestehenden Lizenzkommentaren durch Partner vorgenommen werden. Eine Änderung am Lizenzservice ist schon seit längerer Zeit geplant, spätestens zum 01.01.2015 (zur Umstellung aufgrund neuer MwSt.-Richtlinien) ist das dann erledigt.
bfal: wenn Sie sich im Lizenzportal anmelden (https://www.liveconfig.com/license) sehen Sie ja alle einzelnen Lizenzen, deren Abrechnungszeitraum sowie die IP, von der aus diese zuletzt aktiviert wurde.
Wie bereits angekündigt enthält die nächste LiveConfig-Version (v1.8) eine neue HTML-Klasse. Die Ausgabe erfolgt damit nicht mehr in XHTML1.1, sondern in HTML5. Die Ressourcen-Datei wird zudem künftig austauschbar sein. So ist es möglich, völlig eigene CSS-Templates zu nutzen.
Wer einen ersten Blick darauf werfen möchte: http://www.liveconfig.com/downloads/template/main.html
Als Download: http://www.liveconfig.com/downloads/template.zip
Ich weise ausdrücklich darauf hin, dass es sich hier um einen DUMMY handelt - dieser besitzt keinerlei Funktionalität und kann bisweilen auch noch JavaScript-Fehler, einige interne Kommentare, "toten Code" etc. enthalten. Was dagegen (zu 95%) fest steht, ist das HTML-Gerüst. Wer also plant, ein eigenes Template zu entwickeln, kann mit dieser Vorlage schon mal herumspielen.
Derzeit wird noch an der Mobildarstellung gearbeitet, außerdem fehlen noch die Graphen und eine Menge interner LiveConfig-Klassen. Weitere Updates am Template werden in diesem Thread bekannt gegeben.
Und bevor nun die Diskussion los geht, dass es wichtigere Sachen gäbe als die Darstellung 
: einer der Hauptgründe für die überarbeitete HTML-Ausgabe ist die neue Tabellen-Klasse. Der Austausch der HTML-Erzeugung kostet uns nur wenige Stunden, die HTML-Templates wurden unabhängig vom LiveConfig-Kern (neu) entwickelt. Und spätestens mit der Funktion, mehrere Datensätze einer Tabelle gleichzeitig zu bearbeiten, wird es hoffentlich keine Kritiker mehr geben. :p
Viele Grüße
-Klaus Keppler
tolle Wurst, hier ne Anleitung einzustellen, wie man Erfolg haben könnte.
Eventuell haben Sie die Lücke oder den o.g. Befehl nicht verstanden. Der vom Nutzer "bash" genannte Befehl zeigt tatsächlich nur, ob die eigene bash-Version noch verwundbar ist. Richtigen Exploit-Code gibt es inklusive Backdoor und notwendigem HTTP-Request schlüsselfertig bei GitHub, selbst große IT-Newsmagazine verlinken sogar schon direkt darauf.
Und: man muss kein besonders großer Hacker sein, um diese Lücke erfoglreich ausnutzen zu können. Das ist ja das Schlimme daran...
[2014/09/27 21:57:56.647466] [19502|19502] Backtrace: (liveconfig/client, r3086)
[2014/09/27 21:57:56.647472] [19502|19502] [ 0] 0x
[2014/09/27 21:57:56.647478] [19502|19502] [ 1] 0x
[...]
Könnten Sie uns bitte genau diese Daten (vom Backtrace) ungekürzt zukommen lassen? (im Zweifelsfall an support@liveconfig.com - darin sind aber ohnehin keine Daten enthalten, sondern lediglich die Adressen der auf dem Stack befindlichen Funktionen)
Ja, derzeit werden Catchall-Adressen beim SpamAssassin (bzw. lcsam) nicht berücksichtigt. Die einfachste Lösung für uns wäre, wenn eine Abfrage an /etc/postfix/spamassassin nach einer konkreten Mailadresse erfolglos war (z.B. "mail@dom.com"), danach eine zweite Abfrage zu machen - in diesem Fall nach "@dom.com".
Der Haken daran ist aber: wenn z.B. ein Postfach "info@dom.com" eingerichtet und SpamAssassin dafür deaktiviert ist, dann steht diese Adresse auch nicht in /etc/postfix/spamassassin - der erste Lookup liefert also kein Ergebnis, während der zweite Lookup (@dom.com) dann die Einstellungen des Catchall-Postfachs zurückgibt.
Mit anderen Worten: die SpamAssassin-Einstellungen von Catchall-Postfächern würden somit gleichzeitig für alle normalen Postfächer gelten, bei denen SpamAssassin deaktiviert ist.
Die einzige saubere Lösung wäre, Postfächer mit deaktiviertem SpamAssassin auch explizit in die /etc/postfix/spamassassin mti aufzunehmen (und dort eben irgendwie als "no SpamAssassin" zu hinterlegen). Das würde die spamassassin-Benutzerliste aber auf einen Schlag ziemlich aufblasen. :-/
Wir tendieren nun eher dazu, bei Catchall-Adressen die SpamAssassin-Option komplett zu deaktivieren (schließlich funktioniert das aktuell ja ohnehin nicht). Wenn zudem etwa eine eingehende Spam-Attacke an zufällige Empfängeradressen läuft, würde das mit Catch-All auch eine gefährliche Serverlast mit sich bringen, wenn jede dieser Mails dann erst durch SpamAssassin durchgeschoben wird.
Viele Grüße
-Klaus Keppler
Wir werden auch zukünftig keine "offiziellen" PHP-Pakete bereitstellen - sonst könnten wir den ganzen lieben Tag mit nichts anderem verbringen, als PHP in allen verschiedensten Versionen auf allen verschiedensten Plattformen zu compilieren und würden zudem in lauter Supportanfragen wie diesen hier versinken.
Wir stellen die Debian-Pakete auf freiwilliger Basis bereit, weil wir diese ohnehin auch für unsere eigene Serverfarm benötigen.
PHP selbst zu compilieren macht zwar nicht viel Spaß, ist aber auch kein Ding der Unmöglichkeit. Die Build-Flags sind ja angegeben; sollten irgendwelche Abhängigkeiten fehlen, dann muss man eben in die Hände spucken und auf die Suche gehen. Die "fiesen" Stolperfallen (z.B. dass zip nicht einer externen libzip funktioniert, oder dass PHP's gd-Funktionen inkompatibel mit denen der libgd2 von Debian sind) lassen sich bei Verwendung des o.g. Build-Befehls implizit umschiffen.
Zitatund mit Liveconfig kommt ja sogar nur 5.3.10
LiveConfig installiert/liefert überhaupt kein PHP. Das kann höchstens bei der jeweiligen Distribution dabei gewesen sein. Im Zweifelsfall sollte dann mal die Distribution aktualisiert werden.
Viele Grüße
-Klaus Keppler
Was steht in /var/log/liveconfig/liveconfig.log?
Hallo Herr Keppler,
in Ihrer Anleitung KB#23 sind zwei kleine Fehler enthalten:
Danke für den Hinweis! War gestern ein langer Tag... Die Anleitung wurde entsprechend korrigiert.
Sie haben nichts verschrottet
Falls Sie die SSH-Session noch offen haben, geben Sie einfach "unset X" ein.
Oder melden Sie sich ab und wieder an.
Hallo,
vielleicht haben Sie bereits von der Sicherheitslücke in der Bourne Again Shell (kurz bash) gehört. Diese Lücke ist absolut kritisch. Wir haben in ersten Tests erfolgreich auch über PHP-Scripte, die via suPHP ausgeführt werden und die shell_exec-Funktion (bzw. Backticks) aufrufen, in eigene Testsysteme "einsteigen" können. Der eigentliche "Exploit" besteht quasi nur aus einem einzigen, spziell präparierten HTTP-Aufruf!
Im Gegensatz zu Heartbleed, welches ein mittel-/langfristiges Ausspähen verschlüsselter Daten ermöglichte, gibt es mit ShellShock einen sofortigen, unmittelbaren Serverzugriff! Potenziell verwundbare PHP-Scripte lassen sich mittels Suchmaschinen schnell finden.
Für PHP Wheezy wurde am 25.09. gegen 01:00 ein erstes Patch bereitgestellt; mit dem nun vorliegenden zweiten Patch (23:18) sollte die Lücke vollständig geschlossen sein. Für Debian Squeeze dürfte via LTS in Kürze auch ein weiteres Update erfolgen.
Für ältere Linux-Systeme gibt es nur zwei Möglichkeiten: manuell bash neu compilieren, oder mittels LD_PRELOAD-Trick einen Workaround installieren. Eine ausführliche Beschreibung haben wir in unserer Wissensdatenbank bereitgestellt: http://www.liveconfig.com/de/kb/23
Bitte nehmen Sie diese Sicherheitslücke sehr ernst! Aktualisieren Sie umgehend Ihre Server, oder installieren Sie das in KB#23 beschriebene Workaround. Nach Medienberichten existieren bereits die ersten automatisch verbreitenden Würmer.
Viele Grüße
-Klaus Keppler
Sie können die IPs des Kunden nur nicht als Admin bearbeiten. Wenn Sie eine Session als Kunde/Reseller starten, dann können Sie die IP-Einstellungen bearbeiten.
Wird trotzdem überarbeitet...
Eben wurde Version 1.7.4-r3086 mit folgenden Änderungen freigegeben:
Vielen Dank für die Rückmeldungen!
Bezüglich der Auswahl der PHP-Versionen für NGINX: das ist etwas komplizierter: da NGINX ja nicht selbst die notwendigen FastCGI-Instanzen starten kann, haben wir hierfür ein Helfer-Script (/etc/init.d/nginx-php-fcgi). Dieses liest aus den NGINX-vHost-Konfigurationen jeweils aus, was für PHP-Instanzen gestartet werden sollen. Dort unterstützen wir derzeit nur eine PHP-Instanz pro Vertrag in NGINX.
Wir erweitern aktuell dieses Starter-Script sowie die notwendigen Anweisungen in den NGINX-vHosts, in Kürze* sollten also auch verschiedene PHP-Interpreter mit NGINX möglich sein.
*) voraussichtlich bis Ende kommender Woche
Eben wurde Version 1.7.4-r3086 mit folgenden Änderungen freigegeben:
Vielen Dank für die Rückmeldungen!
Kurze Vorab-Info: DKIM wird ab der nächsten LC-Version (1.8.0) direkt unterstützt. Dabei bietet LC dann die Möglichkeit, Keys selbst zu erzeugen oder zu importieren, erstellt ggf. die dazugehörigen DNS-Records und konfiguriert OpenDKIM entsprechend.
Eine erste Vorab-Version dürfte in ca. 2 Wochen bereit stehen.
Hmm, Fehler gefunden: wenn in den LCDEFAULTS bei den ".enabled"-Feldern eine "1" gesetzt ist, dann wird diese Option auch aktiviert wenn die Checkbox nicht angehakt ist (ist ein unerwünschtes Verhalten unserer Formularklasse: wird eine Checkbox nicht gesetzt, wird diese natürlich auch nicht im HTTP-Request an den Server gesendet - uns hier fügt die neue LCDefaults-Funktion eben dann den Wert aus der Datenbank ein 
Merkwürdig, dass uns das nicht auch schon aufgefallen ist.
Ich empfehle daher, vorerst die .enabled-Werte in der LCDEFAULTS auf "0" stehen zu lassen. Die Fehlerbehebung ist recht einfach und dürfte morgen früh schnell erledigt sind.
Viele Grüße
-Klaus Keppler
Ach ja, zur nachträglichen Aktivierung (=Massen-Update aller Postfächer) ist auch schon eine Lösung in Arbeit - Details dazu dann auch bis Ende der Woche. Ein einfacher Eingriff in die DB genügt jedenfalls nicht, da die gewünschten Änderungen aktiv angetriggert werden müssen, damit der LC-Client-Prozess diese übernimmt.
Die Werte aus LCDEFAULTS werden nur beim Programmstart eingelesen - d.h. starten Sie LC bitte neu, dann sollten auch die neuen Werte gelten.
(Die Doku für LCDEFAULTS kommt noch bis Ende dieser Woche ins Handbuch ;))
Der Fehler wurde mit v1.7.4-r3082 beseitigt (wird in Kürze bereitgestellt).
Mir sind noch zwei Dinge aufgefallen: Wenn ich eine Weiterleitung erstelle und als Ziel http://www.domain.de/* eingebe, erfolgt die Weiterleitung auf z.B. http://www.domain.de//index.php (man beachte die zwei Schrägstriche).
Ist mit v1.7.4-r3080 erledigt.
ZitatUnd bei mir sind die Tooltips für die Weiterleitung und die PHP-Version beim Bearbeiten einer Domain auf Englisch.
Ist mit v1.7.4-r3081 erledigt.
