Beiträge von kk

Zitat von Mercator1972

Kann es sein, daß seit dieser Preview-Version fie Werte für opcache.file_cache und opcache.lockfile_path neu in Liveconfig verwaltet werden?

Diese Werte sind scheinbar leer, sodaß zumindest hier der php-Prozess (auch bei fcgi) ausstieg.

LG

Thomas

Alles anzeigen

Ja, das ist uns bereits aufgefallen. Wenn LiveConfig von einer älteren Installation auf 2.7.0 aktualisiert wurde, dann landeten leider falsche Werte in der php.ini-Verwaltung. Für die beiden opcache-Einträge bitte jeweils "%HOME%/tmp" hinterlegen, dann klappt wieder alles.
Mit v2.7.0-r5092 ist das bereits korrigiert, landet in Kürze im Repo.

Sagen wir mal: der Admin braucht <30min - wenn die Hardware langsamer ist, geht das eben "on top".

Zitat von RB-Media-Group

ich habe eine Seite von FastCGI auf FPM umgestellt, nutze PHP 7.0.32 und habe ca. 250ms schnellere Reaktionszeiten laut Pingdom Test.

Wenn eine "Website" (PHP-Code) mal komplett gecached ist, gibt es technisch keinen Geschwindigkeitsunterschied zwischen FPM und FastCGI (die Kommunikation ist exakt die selbe, nur die Prozessverwaltung unterscheidet sich etwas).

APCu ist das eine - Opcache das andere... Bei FPM läuft das technisch so ab, dass ein PHP-Interpreter tatsächlich nur ein einziges Mal gestartet wird. Für alle Worker-Pools wird dieser dann geforked. Deshalb kann keine individuelle php.ini pro Pool verwendet werden, stattdessen muss man die gewünschten INI-Anweisungen via "php_admin_*"-Befehle in die Pool-Konfiguration schreiben (die werden quasi nach dem fork() nachträglich angewendet).
Für Shared-Hosting-Systeme bedeutet das: man kann nicht mehr einzelne Zend-Extensions nur für einzelne Webspaces laden, sondern diese müssen global registriert werden.

Bei FastCGI gibt es zwangsweise mindestens eine laufende PHP-Instanz pro Vertrag und pro PHP-Version. FPM ist hier flexibler und ermöglicht es, auch den "ersten" benötigten PHP-Interpreter nur bei Bedarf zu starten. Bei Shared-Hosting ermöglicht das somit (theoretisch) eine höhere Kundendichte pro Server, insbesondere wenn der Trend zu vielen verschiedenen PHP-Versionen gleichzeitig geht.

FPM ist also nicht pauschal "schneller" als FastCGI (die Kommunikation ist in beiden Fällen sogar exakt identisch), es kommt vielmehr auf den jeweiligen Anwendungsfall an.

Seitens LiveConfig gab es keine Änderungen was suPHP betrifft - wir haben aber vor, das künftig nicht mehr zu unterstützen. Wird schließlich von Debian seit Version 8 nicht mehr bereitgestellt...
Warum das bislang lief kann ich unmöglich sagen, wird reines Glück gewesen sein.

suPHP? Mit Debian 9? Das dürfte da eigentlich gar nicht mehr verfügbar sein...
Bitte testweise auf FastCGI umstellen.
Ich vermute, dass suPHP nicht funktioniert (würde mich auch wundern) und deshalb als Fallback mod_php verwendet wird.

Zitat von RB-Media-Group

im LiveConfig ist z.B. PHP 5.3.28 ausgewählt aber PHP 7.0 wird geladen.

Welche PHP-Ausführung ist in dem betroffenen Vertrag eingestellt? (mod_php, FastCGI, FPM)

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

Hello,

our PHP packages for Debian/Ubuntu have just been updated to version 7.1.23 and 7.2.11.

Best regards

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.1.23 und 7.2.11 aktualisiert.

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

Zitat von Marco

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.

service proftpd stop
service proftpd start

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