Beiträge von kk

    Noch mal: welche Version KONKRET?
    Oder anders gefragt: welche PHP-Version genau möchten Sie auf welchen Stand bringen?


    Sie haben ein ganz anderes Problem, das sieht man in der Fehlermeldung vom ZendGuardLoader. Das hier ist aber der falsche Ort für kostenlose Serveradministration.

    Ich schätze den Bot-Traffic auf "normalen" Websites auf eher 80%.
    Die meisten Anfragen kommen dabei nicht einmal vom GoogleBot etc., sondern von "SEO"-Crawlern und Spam-Bots. Wir verbieten inzwischen per robots.txt einige Bots und überlegen, mittelfristig direkt in LiveConfig per Button entsprechende Filter zu aktivieren.

    Hello,


    LiveConfig v2.5.1 is now available for download.
    This update contains mainly improvements and bugfixes - the full list of changes can be found in the changelog.


    Among other things, the two-factor-authentication has been improved. It's now also possible to log in only with the "normal" password. If OTP or U2F is enabled, a corresponding token or confirmation is requested afterwards in a separate dialog. This way, password managers can be used with LiveConfig.


    Best regards


    -Klaus Keppler

    Hallo,


    ab sofort steht LiveConfig v2.5.1 zum Download bereit.
    Dieses Update beinhaltet hauptsächlich Verbesserungen und Fehlerbereinigungen - die Liste aller Änderungen steht wie immer im Changelog.


    Unter anderem wurde die Zwei-Faktor-Anmeldung verbessert - man kann sich nun auch erst mal nur mit dem "normalen" Passwort anmelden. Sollte OTP oder U2F aktiviert sein, wird anschließend nach einem entsprechenden Code bzw. Bestätigung gefragt. Damit ist die Anmeldung nun auch bequem(er) mit Passwortmanagern nutzbar.


    Viele Grüße


    -Klaus Keppler

    Das mit der Omnipräsenz und Allwissenheit klappt leider nicht so wie erhofft. ;)


    Wir sind an dem Thema dran, Infos voraussichtlich bis morgen Mittag/Nachmittag (da planen wir ein Update).
    Vorab: es kommt u.a. auf die Distribution an, und ob PHP-CLI installiert ist. Unter CentOS 7 war/ist die PHP-Version (5.4 :-O) zu alt für phpMyAdmin.

    Hello,


    the LiveConfig repository is from now on also available via HTTPS (and HTTP/2):
    https://repo.liveconfig.com/


    Please note that under Debian/Ubuntu the package "apt-transport-https" is required to work with https repository URLs.
    Because the repository contents are anyway signed with a GPG key, there's no important security advantage by using HTTPS.


    Best regards


    -Klaus Keppler

    Hallo,


    das LiveConfig-Repository ist ab sofort auch unter HTTPS (und mit HTTP/2) erreichbar:
    https://repo.liveconfig.com/


    Beachten Sie bitte, dass unter Debian/Ubuntu erst noch das Paket "apt-transport-https" installiert werden muss, bevor Repository-URLs mit https funktionieren.
    Da die Repository-Inhalte ohnehin mit einem GPG-Schlüssel signiert sind, ergibt sich allerdings kein nennenswerter Sicherheitsvorteil durch HTTPS.


    Viele Grüße


    -Klaus Keppler

    Uns ist da kein Problem bekannt. Stehen in der Spalte "Benutzer" wirklich mehrere Benutzer drin?
    Ansonsten schicken Sie uns bitte einen Screenshot der Anzeige unter "Passwort-geschützte Verzeichnisse", sowie den entsprechenden Abschnitt aus /etc/apache2/sites-available/<Vertrag>.conf an support@liveconfig.com.


    In der LiveConfig-Demo (anmelden als mustermann/mustermann) habe ich zum Vergleich mal einen entsprechenden Passwortschutz mit zwei Benutzern angelegt.

    Ich verstehe nicht, was dieser Beitrag mit dem ursprünglichen, über 1,5 Jahre alten Thread zu tun hat.


    Offenbar hatten Sie während des Upgrades eine Fehlermeldung. Wenn Sie uns noch mitteilen, welche LiveConfig-Version Sie vor dem Update am Laufen hatten, und ob Sie MySQL oder SQLite nutzen, können wir uns das gerne mal anschauen.

    Nach Aktivierung von http/2 in Nginx explodiert die Last auf dem Server. Requests werden gefühlt endlos erneut abgesetzt:


    Problem ist lokalisiert und ein Workaround fertig.
    Die Ursache ist (unserer Ansicht nach) ein Fehler in NGINX. Konkret tritt dieses Verhalten dann auf, wenn NGINX mit HTTP/2 als Reverse-Proxy genutzt wird. Wenn der ursprüngliche (HTTP/1.1-)Server eine Antwort sendet, dann enthält diese i.d.R. den Header "Connection: keep-alive".
    Mit HTTP/2 ist dieser Header verboten - allerdings leitet NGINX diesen ungefiltert an die HTTP/2-Verbindung durch. Einige Clients wie u.a. Apple Webkit (Safari) oder auch cURL brechen dann die Verbindung ab.
    Die Lösung (ab v2.5.1-r4755) besteht vorerst darin, dass LiveConfig bei NGINX-Reverse-Proxy-vHosts HTTP/2 nicht aktiviert.


    NGINX bringt von Haus aus leider keine Möglichkeit mit, HTTP-Header aus einer Proxy-Antwort herauszufiltern. Lediglich ein 3rd-Party-Modul namens ngx_headers_more kann das. Jetzt gibt es eine gute und eine schlechte Nachricht...
    Die gute Nachricht: in Debian 9 ist dieses Modul über das Paket libnginx-mod-http-headers-more-filter relativ einfach nachinstallierbar.
    Die schlechte Nachricht: NGINX unterstützt keine Form von "IfModule" in der Konfiguration. LiveConfig muss also die vHost-Konfigurationen zwingend neu erstellen, wenn dieses Modul verfügbar (oder auch nicht mehr verfügbar) ist.


    Viele Grüße


    -Klaus Keppler

    Nach Aktivierung von http/2 in Nginx explodiert die Last auf dem Server. Requests werden gefühlt endlos erneut abgesetzt:


    Haben Sie HTTP/2 auf einer exklusiven IP-Gruppe mit NGINX aktiviert und gleichzeitig keine "gemeinsame" IP-Gruppe mit SSL im NGINX aktiv?
    Wenn ja, dann ist das Problem bereits gelöst (LiveConfig v2.5.1-r4752), die Pakete stehen in Kürze bereit.


    Falls das Problem in einer anderen Konstellation aufgetreten ist, schicken Sie uns bitte mal die /etc/nginx/sites-available/default an support@liveconfig.com


    Viele Grüße


    -Klaus Keppler

    Das haben wir kürzlich schon behoben, im nächsten Update (v2.5.1) klappt FIDO-U2F auch mit Firefox Nighty.
    (Es gibt eine aktualisierte Version der U2F-API, die zwar aufwärtskompatibel, nicht aber abwärtskompatibel ist - wir haben LiveConfig auf die neue API umgestellt, damit klappt es dann überall)

    Und betrachte ich mir das neue Zertifikat, dann schwant mir Übles. Ablauf kurz nach Ende der Sommerferien in Bayern? Wenn das nicht mal in der Erholung untergeht :)


    Ich kann zur Beruhigung versichern, dass keiner der Mitarbeiter schulpflichtig ist und sich zu diesem Zeitpunkt in Schulferien befinden wird. Vom Azubi vielleicht abgesehen, aber der hat ohnehin keine Berechtigung um die Zertifikate zu verwalten.
    Spaß beiseite: das sogenannte "Personenrisiko" ist intern genau dokumentiert - Schlüsselrollen sind entsprechend verteilt.
    Wie schon angekündigt werden wir beim nächsten Key-Rollover den neuen Schlüssel früher ausrollen. Konkret ist geplant, den Schlüssel mit einer Gültigkeit von 3,5 Jahren zu erstellen und 6 Monate vor dem Ablaufdatum auszurollen. Einen sauberen Weg dafür haben wir ja inzwischen gefunden.


    Die restliche Diskussion beenden wir bitte an dieser Stelle.