Beiträge von kk

    Ab sofort steht ein weiteres kleines Update in den Repositories bereit: v1.8.2-r3508.


    Dieses macht im Grunde nur eine einzige Änderung: während des Update-Vorgangs wird in den globalen Standard-Kontext von Apache (quasi vor dem Default-vHost) explizit ein "DocumentRoot /usr/share/liveconfig/html/" eingefügt und Apache danach "reloaded". Das erhöht die Sicherheit bei falsch konfigurierten vHosts bzw. Zugriffen auf den Default-vHost.
    Hintergrund ist, dass verschiedene Distributionen unterschiedliche Standard-Docroots in Apache einkompiliert haben. Die Sicherheit wird erhöht, wenn wir das DocumentRoot vom Standard-vHost (was ja quasi immer das Fallback ist) auf einen definierten und "sicheren" Wert setzen.


    Wir empfehlen, das Update zeitnah durchzuführen. An der sonstigen Konfiguration wird nichts geändert, mit "Nebenwirkungen" ist also nicht zu rechnen.


    Viele Grüße & ein schönes Wochenende


    -Klaus Keppler

    Derzeit muss hierfür in der Tabelle LCDEFAULTS noch der Wert "login.u2f.enabled" auf "1" gesetzt und LiveConfig danach neu gestartet werden. Wir werden U2F "offiziell" freigeben wenn das Handbuch aktualisiert ist und auch das Löschen von U2F-Devices fertig ist.


    FIDO U2F setzt natürlich voraus, dass Sie ein entsprechendes Device haben (wir haben das bislang mit den U2F-fähigen Yubikeys sowie dem günstigen Modell von Plug-Up getestet). Außerdem unterstützt derzeit nur Chrome dieses Verfahren. In den nächsten Monaten sollen aber Firefox und sogar der IE nachziehen.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ein Whitelisting gibt es bislang noch nicht (ist aber eine gute Idee...).
    Löschen Sie einfach die Inhalte der Tabellen IPBLOCK und IPLOG, dann sollten Sie wieder hineinkommen (oder alternativ 15min warten).


    Viele Grüße


    -Klaus Keppler

    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?

    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.

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

    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

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