Beiträge von kk

Das Problem ist, dass bei "klassischem" SSL erst der SSL-Handshake stattfindet, und dann der HTTP-Request erfolgt. Mit anderen Worten: pro SSL-Zertifikat braucht(e) man eine eigene IP-Adresse; man kann keinen "anderen" Content zuverlässig auf der selben IP hosten.
SNI verschafft da theoretisch Abhilfe - funktioniert allerdings nicht mit dem IE unter Windows XP u.ä. (was immerhin noch rund 10% der Internetnutzer betrifft).

Legen Sie die Datei /etc/apache2/conf.d/sni mit folgendem Inhalt an:

<IfModule mod_ssl.c>
SSLStrictSNIVHostCheck on
</IfModule>

Starten Sie Apache danach neu. Mit dieser Einstellung (SSLStrictSNIVHostCheck on) sollten dann nur noch "richtige" SNI-Zugriffe durchgestellt werden. Beachten Sie aber bitte, dass eben noch nicht alle Browser SNI beherrschen.

Viele Grüße

-Klaus Keppler

aptitude search php | grep opt

Oder noch einfacher: einen Blick in KB#22 werfen. Dann werden Sie feststellen, dass wir für Debian Squeeze gar kein optionales PHP 5.3 Paket bereitstellen (schließlich gibt es das da direkt von Debian).

Ab sofort steht ein kleines Update bereit (v1.7.4-r3112), welcher einen Fehler bzw. ein Problem mit den neuen Tabellen beseitigt.
(Wenn man z.B. einen Kunden mit 30 Domains geöffnet hat, in der Domainliste auf die Seite 2 blätterte und danach einen Kunden mit z.B. nur 5 Domains öffnete, dann wurden dort gar keine Domains mehr angezeigt (weil die Tabelle noch auf "Seite 2" stand).)

Viele Grüße

-Klaus Keppler

Zitat von Seppelchen

der Style und die Formatierung für die Cron-Jobs muss sicher noch anlag zu den anderen Tabellen angepasst werden. Das sieht so nicht ganz normal aus. Herr Keppler machen Sie es bitte noch ?

Danke für den Hinweis, wurde eben aktualisiert (r3110). Die Cron-Jobs sowie übrigens auch die Datenbanken waren auch noch nicht sortierbar.

Zitat

Also bei Weiterleitungen kann eine Sortierung schon Sinn machen wenn es nur ein Ziel gibt und man so alle Weiterleitungen zu dem Ziel finden will.

Wenn man alle Weiterleitungen zu einem Ziel finden will, dann braucht man das nur ins Suchfeld der Tabelle eingeben - so bekommt man alle Treffer, auch wenn ein Postfach zusätzlich noch an andere Ziele weitergeleitet wird.

Zitat

Nun, wenn das neue, fehlerfreie Release veröffentlicht wurde, wollte ich nachfragen, wann kommt das nächste Release?

Wenn's fertig ist.
Aktuell werden die Änderungen für's neue Templatesystem (HTML5/CSS) umgesetzt, eine erste Preview dürfte nächste Woche verfügbar sein. Insgesamt stehen derzeit aber keine "großen" Teilprojekte an, so dass wir voraussichtlich alle 4-6 Wochen jeweils neue Funktionen releasen werden.

Zitat

ist es gewünscht das die Suchen bzw. den Begriffe auch nach dem aus und wieder einloggen gespeichert sind?

Ja, das ist so beabsichtigt; falls das zu verwirrend ist können wir das ggf auch wieder rausnehmen.

Viele Grüße

-Klaus Keppler

Der "ar" von BSD und GNU unterscheidet sich leider etwas - der von GNU fügt (warum auch immer) intern noch einen Schrägstrich an den Dateinamen an. Dieser führt dann auch zu Problemen mit dpkg-sig.

Ab Version 1.8 werden wir die Debian-Pakete anders bauen (also nicht mehr mit ar), um künftig u.a. die Repo-Files automatisiert auf korrekte Signaturen prüfen zu können. In Kürze sollte sich dieses Problem also erledigt haben.

Viele Grüße

-Klaus Keppler

In unseren Debian-Repositories steht ab sofort PHP 5.6.1 zum Download bereit (siehe KB#22).

Viele Grüße

-Klaus Keppler

Eine Sortierung ist nur in den Spalten möglich, wo das auch einen Sinn macht. Da für Aliase/Weiterleitungen mehrere Einträge pro Postfach existieren können, ist eine alphabetische Tabellensortierung danach eher sinnlos. Diese Felder werden aber in der Filterung berücksichtigt.

Viele Grüße

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig v1.7.4-r3109 zum Download (als "Stable-Version") bereit. Die zwei wichtigsten Änderungen sind:

• überarbeitete Tabellen (sortierbar, Einstellungen werden gespeichert)
• Fehler im LCCP-Parser beseitigt, der in seltenen Fällen zum "Stillstand" des Client-Prozesses führen konnte*

Das Update steht auch in den Repositories bereit und kann wie immer reibungslos installiert werden.

Viele Grüße

-Klaus Keppler

*) zu diesem Fehler muss ich etwas ausholen
Einige Kunden berichteten davon, dass ab und zu LiveConfig keine Aktionen mehr ausführte (z.B. Anlegen von Datenbanken oder Löschen von Postfächern). Wir konnten dieses Verhalten hier bislang aber nicht reproduzieren.
Dank der Unterstützung einiger LiveConfig-Kunden (namentlich besonderen Dank an aziegler und mgoeben!) konnte der Fehler nun lokalisiert werden: er trat ausschließlich dann auf, wenn mehrere "große" LCCP-Nachrichten vom Server- an den Clientprozess gleichzeitig gesendet wurden und deren Header an einer ganz bestimmten Position im Lesepuffer auftauchte (es handelte sich um 15 Byte in einem 4096 Byte großen Lesepuffer).
Der Fehler ist nun endlich beseitigt und war auf diese eine recht spezielle Parser-Funktion beschränkt.

Hallo,

für Gentoo steht nun r3108 als Preview bereit. Ich hatte am Samstag offenbar nur einen Teil der Backtrace-Ausgabe überarbeitet (nur den Teil für den Server-Prozess, nicht aber den für den Client-Prozess :(). Ich bin optimistisch, dass uns ein Backtrace zur Wurzel des Übels führen dürfte; falls das nicht hilft würde ich gerne das SSH-Angebot in Anspruch nehmen (dazu würde ich mich aber noch mal separat melden).
Auf unserer Test-VM mit Gentoo haben wir bislang übrigens keinen SEGFAULT im Log feststellen können.

Viele Grüße

-Klaus Keppler

Exakt, das betraf nur die Preview-Version.

Danke für den Hinweis! Fehler wurde eben behoben (r3106), Preview-Update kommt im Laufe des Nachmittags.

Hallo,

das Gentoo-Paket wurde nochmal aktualisiert (r3103), unter Gentoo gibt es mit der APR (Apache Portable Runtime) Probleme bei der Ausgabe von Pointern (wie in diesem Fall im Backtrace). Könnten Sie bitte bei Gelegenheit das Update einspielen? Der Fehler wird damit leider noch nicht beseitigt sein, aber wir sollten damit dann eine brauchbare Meldung bekommen, was den Fehler auslöst.

Zudem: könnten Sie bitte in die /var/log/liveconfig/access.log schauen, was für Requests zu dem Zeitpunkt stattgefunden haben, als der o.g. Fehler aufgetreten ist? (also am 02.10.2014 gegen 19:54:22). Offenbar wurde der Fehler durch eine Nachricht vom Server zum Client hin ausgelöst, ich vermute also dass es da auch irgendeinen Zugriff gegeben haben müsste.

Besten Dank für Ihre Unterstützung!

-Klaus Keppler

Könnten Sie bitte die aktuelle Preview (v1.7.4-r3101) einspielen? Bei dieser sollten die Stacktraces wieder "sichtbar" sein (hier gab es leider einen Bug in der APR-Bibliothek, der die Formatierung von Adressen betraf). Sollte nach dem Neustart von LiveConfig und dem erneuten Löschen einer Mailadresse wieder ein Fehler auftauchen, schicken Sie bitte die entsprechenden Log-Ausgaben.

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

Zitat von Sven_67

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

Zitat von mgoeben

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

Zitat

und 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