Beiträge von kk

    Auch 2019 wird LiveConfig wieder als Aussteller auf der weltgrößten Hosting-Messe - dem CloudFest - vertreten sein.


    Ab sofort können Sie sich für das CloudFest registrieren - mit unserem Anmelde-Code sparen Sie sich dabei die Kosten für das "Standard-Ticket" (399 € zzgl. MwSt).


    NEU in 2019: wir planen in diesem Jahr im Rahmen des CloudFests separate Veranstaltungen speziell für LiveConfig-Kunden (-Anwender/-Interessenten) durchzuführen:

    • LiveConfig-Schulung (Installation und Verwendung von LiveConfig)
    • LiveConfig-Anwendertreffen ("Best Practices", Roadmap, Diskussion mit den Entwicklern)


    Als Dauer ist jeweils ca. 1 Std. geplant, die exakten Termine stehen noch nicht fest (voraussichtlich aber am Mittwoch 27.03., da sind erfahrungsgemäß die meisten Besucher da).
    Weitere Informationen hierzu folgen dann im Februar.


    Viele Grüße


    -Klaus Keppler

    Die Preview wurde eben auf v2.7.0-r5091 aktualisiert.
    Neben einigen Bugfixes gibt es damit noch folgende neue Features/Verbesserungen:

    • Unterstützung von TLS 1.3 in der LiveConfig-Benutzeroberfläche
    • DNS-Whitelists können nun "gefiltert" werden.
      Konkretes Beispiel: dnswl.org erlaubt nur eine bestimmte Anzahl an DNS-Anfragen pro DNS-Resolver pro Tag. Überschreitet man diese, wird jede weitere Anfrage mit 127.0.0.255 beantwortet, womit alle angefragten Adressen beantwortet und somit oftmals ungefiltert durchgelassen werden.
      Künftig kann man die Whitelist z.B. in folgender Form einbinden:
      list.dnswl.org=127.0.[0..255].[1..3]
    • weitere Verbesserungen in der FPM-Konfiguration


    Wir haben bereits mit dem Rollout auf den ersten produktiven Servern begonnen, wenn alles passt erfolgt das "offizielle" Release dann in 1-2 Tagen.
    Die FPM-Konfiguration wurde manuell ausführlich durchgetestet, aus unserer Sicht sollte alles stabil laufen. Falls eine PHP-Version eingestellt ist, für die kein FPM-Binary verfügbar ist (z.B. PHP 5.3), dann wird im Browser eine entsprechende Fehlermeldung angezeigt (statt dem PHP-Source ;-). Wir empfehlen also, FPM nur dann zu aktivieren, wenn nur halbwegs zeitgemäße PHP-Versionen zum Einsatz kommen.


    Einige SSL-Meldungen im Log sind letztendlich nur Warnmeldungen, wir werden diese künftig besser herausfiltern. Der Verbindungsabbruch zwischen LiveConfig Client und -Server wird noch untersucht (die Verbindung wird ja aber automatisch wieder aufgebaut - tritt interessanterweise auch nur in einzelnen Szenarien auf).


    Viele Grüße


    -Klaus Keppler

    Wir empfehlen grundsätzlich eine Migration nur innerhalb der selben Distributionsversion durchzuführen.
    Also erst den Server von Debian 7 auf Debian 8 und anschließend von 8 auf 9 aktualisieren (ein erfahrener Admin sollte das in <30min schaffen).
    Das Problem ist, dass die internen Konfigurationsdateien einiger Dienste eventuell Upgrades benötigen, die eben nur während einer Aktualisierung ausgeführt werden. Wenn Sie nun auf ein Debian 9 eine alte Datei von einem Debian 7 kopieren, kann es sein, dass diese dann nicht verarbeitet werden kann.


    Dist-Upgrades sind bei Debian/Ubuntu auch immer relativ schmerzfrei - Migrationen machen da erheblich mehr Arbeit...

    Hallo,


    ab sofort steht PHP 7.3.0 (Release Candidate 3) als fertiges Paket für Debian/Ubuntu in unseren Repositories!
    Das Paket nennt sich "php-7.3-opt" (analog zu allen anderen PHP-Paketen).
    Verlinkung in unserem Wiki erfolgt erst in einigen Tagen (die Struktur der Seite soll demnächst noch geändert werden).


    Viele Grüße


    -Klaus Keppler

    Der Fehler wurde gefunden. Die Datei /sbin/start-stop-daemon ist 0 Bytes groß (da ist vermutlich während der Installation irgendwas schief gelaufen). Das führte zu dem merkwürdigen Verhalten, dass man proftpd zwar direkt starten konnte, nicht aber über das Init-Script... (der start-stop-daemon hat einfach nichts gemacht, wurde aber "fehlerfrei" ausgeführt...)

    Das zu Grunde liegende Problem ist wohl, dass die Änderungen laut ChangeLog auf dem System vorgenommen werden, aber eine Aktualisierung der "liveconfig.conf" unterbleibt.


    In die Richtung könnte es gehen. Das Upgrade-Script modifiziert mittels "sed"-Befehl die /etc/apache2/conf-enabled/liveconfig.conf. Wird aber ein zu großer Upgrade-Schritt gemacht (konkret also: von einer Apache-Installation, bei der die liveconfig.conf erst von /etc/apache2/conf.d/liveconfig.conf nach /etc/apache2/conf-enabled/ verschoben wird), dann kann das bei falscher Reihenfolge dazu führen, dass LiveConfig zuerst die Datei patchen will, die vom Apache-Upgrade aber erst danach verschoben wird...

    Leider fehlt die Information, was genau auf den Servern aktualisiert wurde, und von welcher alten auf welche neue Version.


    Zitat

    In den aktualisierten Systemen steht die Zeile:
    CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" LiveConfig


    Bei der Neukonfiguration steht jedoch:
    CustomLog "||/usr/lib/liveconfig/lclogsplit -i -w" LiveConfig


    Die "neue" Zeile (wo also nur die Parameter "-i -w" verwendet werden) ist die aktuellere - diese gilt ab LiveConfig v2.6.0 (siehe Changelog, unter dem Abschnitt für v2.6 der Hinweis "Aktionen während eines Upgrades von älteren LiveConfig-Installationen")


    Zitat

    Neuerdings scheint die Datei "liveconfig.conf" falsch gesetzt zu werden. Bei einer Neuinstallation liegt diese direkt in dem Ordner "/etc/apache2/conf-enabled".


    Das wird mit einem der nächsten Updates korrigiert; rein praktisch macht das keinen Unterschied - die Symlink-Lösung ist halt ordentlicher.

    Unsere PHP-Pakete sind "vanilla" - am Sourcecode wird nichts gepatched.
    Lediglich für den Build-/Paketierungsprozess müssen wir in einigen Fällen kleinere Anpassungen vornehmen (z.B. damit die ganzen Extensions nicht auch noch als statische Bibliotheken (.a) mit eingepackt werden).


    Die Hauptarbeit auf unserer Seite liegt also in der Automatisierung des Packagings - spezielle Source-Pakete gibt es daher nicht.


    Viele Grüße


    -Klaus Keppler

    Kann man ja auch machen.
    Wichtig ist, beim Anlegen der Subdomain für einen reinen TXT-Record im Tab "Webspace" das Häkchen bei der Checkbox "Webspace aktivieren" zu entfernen.


    Also:

    1. Button "neue Subdomain" anklicken
    2. im Tab "Webspace" die Checkbox "Webspace aktivieren" deaktivieren
    3. im Tab "eigene DNS-Einträge" einen DNS-Eintrag vom Typ "TXT" hinzufügen
    4. dort die gewünschten Daten eingeben (TTL, Wert) und auf "speichern" klicken.

    Kommt ganz darauf an, was für eine Subdomain (bzw. genauer: was für ein DNS-Resource-Record) angelegt werden soll.
    In A/AAAA-Records sind keine Unterstriche erlaubt. CNAME, SRV oder TXT-Records mit Unterstrichen sind in LiveConfig aber möglich.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 5.6.38, 7.0.32, 7.1.22 und 7.2.10 aktualisiert.
    Tatsächlich gab es einige dieser Versionen schon vor ein paar Tagen, wir haben mit einem erneuten Update aber noch einen Fehler in der opcache.ini behoben - da wurde versehentlich opcache.validate_permissions noch nicht gesetzt - siehe Hinweise zu FPM in diesem Thread.
    Außerdem gab es in den Ubuntu-Paketen oft noch eine Fehlermeldung beim Laden einer Extension (da konnte die PCRE-Bibliothek nicht geladen werden) - das ist nun auch behoben.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    aufgrund eines Umzugs in neue Räume (innerhalb des Gebäudes) sind wir heute nur sehr eingeschränkt erreichbar. Wir gehen davon aus, dass die Technik bis ca. 15:00 umgezogen und wieder einsatzbereit ist.
    Ich bitte also noch um ein klein wenig Geduld für aktuelle Tickets.
    Anschrift und Telefonnummern bleiben unverändert.


    Viele Grüße


    -Klaus Keppler

    Welche Ubuntu-Version genau verwenden Sie? Ubuntu 16 bringt PHP 7.0.30 mit, Ubuntu 18 PHP 7.2.7.
    Zudem hat liveconfig-meta keine Abhängigkeit von PHP 7.1...


    Zum Opcache-Fehler: ist das Paket "libpcre3" installiert?


    Welche Fehlermeldung exakt meldet APT?

    Dort ergibt PHP-FPM aber IMHO - selbst mit "ondemand" - wenig Sinn.


    ACK. Shared Hosting ist mit FastCGI und den vielen "exotischen" Ansprüchen wesentlich entspannter (der eine Kunde braucht IonCube, der andere ZendGuard, der dritte sonstwas - und die sind bisweilen zueinander inkompatibel...).
    FPM macht insbesondere bei Projekt-Servern Sinn, da FPM einfach eleganter skaliert als FastCGI. Schneller ist es nicht (auch wenn das immer wieder hartnäckig behauptet wird).
    Mass Shared Hosting mit NGINX macht auch keinen Sinn (die Performance, die ein NGINX bietet, kann ein Shared Webspace gar nicht vernünftig nutzen, und man benötigt irre viel "Tuning", um handelsübliche CMS zum Laufen zu bringen...). Aber ich glaube ich schweife ab...

    Die Alternative dazu ist, für jeden Benutzer einen komplett eigenen PHP-FPM-Prozess (und nicht nur einen eigenen Pool) zu erstellen.


    Das hatten wir uns natürlich auch schon überlegt :D
    Mit systemd und "socket activation" bekommt man das sogar halbwegs sauber hin, ohne dass hunderte idle-Pools die Prozessliste zumüllen. Aber leider eben nur mit systemd. Und übersichtlicher wird das ganze dann auch nicht. Die Idee behalten wir mal im Hinterkopf, bei "normalem" Mass-Shared-Hosting schießt das eher über's Ziel hinaus.

    Und noch ein kurzer Nachtrag: FPM bietet gegenüber Apache mod_fcgid kaum nennenswerte Vorteile, lediglich die Skalierbarkeit lässt sich etwas besser konfigurieren. Die Kommunikation zwischen den Prozessen (Apache <-> PHP) ist bei beiden Verfahren sogar identisch.
    Lediglich mit NGINX macht FPM aufgrund des eigenen Prozessmanagers das Leben erheblich einfacher.


    Wer sich etwas tiefer mit Control Panels, Shared Hosting und FPM beschäftigt wird feststellen, dass FPM und insbesondere Caching (nicht nur Opcache, sondern auch APC) hierbei ein ernstzunehmendes Problem darstellen. Es gibt Control Panels, denen das völlig Schnuppe ist - LiveConfig zählt nicht dazu. ;)