Beiträge von kk

Zitat von bfal

Ich hoffe die 50 Server sind nur Testsysteme

Warum? Haben Sie irgendwelche Probleme mit den neuen PHP-Paketen festgestellt?

Die neuen PHP-Pakete sind ab sofort freigegeben:
https://www.liveconfig.com/de/…-31-7-1-20-7-2-8)?p=16306

Hallo,

ab sofort stehen neue Versionen unserer PHP-Pakete für Debian/Ubuntu zum Download bereit (PHP-Version 5.6.37, 7.0.31, 7.1.20 und 7.2.8).

Bei diesen Paketen gibt es einige grundlegende Neuerungen:

• die Pakete werden nun komplett als "ordentliche" PHP-Pakete gebaut, d.h. alle Konfigurationsdateien (u.a. /opt/php-X.X/etc/) werden als solche verwaltet.
  Während des Upgrades wird mittels Prüfsummen verglichen, ob die .ini-Dateien früherer Installationen unverändert sind und dann ggf. stillschweigend ersetzt, ansonsten wird während des Upgrades gefragt, ob eine neuere Version davon installiert werden soll.
• die PHP-Pakete enthalten viele weitere Extensions, und viele bisherige Extensions sind nun als separate Module (Shared Objects) ausgelagert - die können somit einzeln aktiviert/deaktiviert werden.
• PHP 5.6 steht nun auch für Ubuntu 16.04 und 18.04 bereit
• APCu und ImageMagick steht nun auch für alle 7.x-Versionen zur Verfügung
• alle Pakete ab PHP 5.6 registrieren sich nun selbständig am LiveConfig (via /etc/liveconfig/lua.d), ein Eintrag in die custom.lua ist somit nicht mehr notwendig. Für ältere Pakete (5.5, 5.4, 5.3, evtl 4.4) wird das voraussichtlich in den nächsten Wochen folgen.
• die neuen Pakete (PHP 5.6/7.0/7.1/7.2) installieren nun ein Init-Script und ggf. einen systemd-Service, mit dem künftig PHP-FPM-Instanzen automatisch gestartet werden können. Die nächste LiveConfig-Version (v2.7) wird nämlich FPM unterstützen. (Daher ist dieses PHP-Update für LiveConfig wichtig, da für FPM eine etwas komplexere Registrierung an LiveConfig erforderlich ist)

Im Wiki folgt in Kürze noch eine Beschreibung, wie man zusätzliche PHP-Versionen unter CentOS bequem hinzufügen kann.

Sollte es während des Updates Probleme geben, schicken Sie uns bitte alle Bildschirmmeldungen die während des "apt upgrade" aufgetreten sind.
Im Notfall hilft es, die jeweilige PHP-Version komplett vom Server zu entfernen ("apt purge php-X.X-opt") und neu zu installieren.
Wir haben die Upgrades auf allen unterstützten Distributionen manuell durchgetestet und keine Fehler oder Warnungen dabei erhalten.
AUSNAHME: wer vorher eine PHP-Version aus dem "debian-test"-Repository installiert hatte, muss i.d.R. nach dem Update die Datei /opt/php-X.X/etc/conf.d/xml.ini löschen.

Um zu testen, ob eine bestimmte PHP-Version korrekt ausgeführt werden kann (inkl. aller Module), einfach wie folgt aufrufen: /opt/php-X.X/bin/php -v

Viele Grüße

-Klaus Keppler

Zitat von Mercator1972

Das Paket aus stable php-7.0-opt-imagick_3.4.3-1+stretch1_amd64.deb steckt die imagick.so nach /opt/php-7.0/lib/imagick.so

Ich habe das sicherheitshalber eben mal geprüft und kann das nicht bestätigen.
Das Paket php-7.0-opt-imagick_3.4.3-1+stretch1_amd64.deb (MD5: c9f3406347d603983006d5d4274e92b0) installiert die imagick.so an den richtigen Ort:

/opt/php-7.0/lib/php/extensions/no-debug-non-zts-20151012/imagick.so
(MD5: 89a1531cc2d86cd620fd3950a80657bf)

Handelt es sich vielleicht noch um eine veraltete Datei aus einer früheren Installation/Version?

Zitat von RB-Media-Group

demnach ist es bekannt das ist mit den letzten Paketen Probleme gab/gibt?

War die Antwort nicht eindeutig?

Zitat

Sie verwenden höchstwahrscheinlich ein PHP-Paket aus unserem "debian-test"-Repository. Die sind noch nicht stabil, der o.g. Fehler ist bekannt.

Oder anders formuliert: in den Test-Repositories befinden sich unsere Test-Pakete - die wie also noch durchtesten bevor diese freigegeben werden. Daher kann es damit zu Problemen kommen.

Wir generieren unsere PHP-Pakete künftig komplett anders als bisher. Das bedeutet u.A., dass wir den Build-Prozess völlig umgestellt haben. Welchen Sinn und welche Vorteile das hat, erläutere ich dann sobald alles abgeschlossen ist in einem ausführlichen Beitrag.

Sie verwenden höchstwahrscheinlich ein PHP-Paket aus unserem "debian-test"-Repository. Die sind noch nicht stabil, der o.g. Fehler ist bekannt.
Verschieben Sie einfach die .so-Dateien:

cd /opt/php-7.0/lib/php/extensions/no-debug-non-zts-20151012/
mv *.so /opt/php-7.0/lib/extensions/no-debug-non-zts-20151012/

Das Extension-Verzeichnis hat sich von /opt/php-X.X/lib/php/extensions nach /opt/php-X.X/lib/extensions geändert - also nicht mehr unterhalb von "php/"; ausführliche Beschreibung der neuen Pakete und aller Änderungen folgt voraussichtlich im Laufe dieses Tages, wenn alle neuen PHP-Pakete fertig sind.

Zitat von Neumann

Finde ich nicht gut - Kunden wollen generell so wenig wie möglich mit der Technik zu tun haben. Das sagt die Erfahrung.

Kann ich voll und ganz unterschreiben.

Zitat

Gäbe es ansonsten bei "sendmail_from" einen Platzhalter der Mailadresse, die bei LC für den jeweiligen Kunden hinterlegt ist?

Genau das ist ja das Problem: es ist eben nicht unbedingt eine E-Mail-Adresse des LC-Kunden hinterlegt.

Was ich mir vorstellen könnte, dass wir einen Platzhalter einführen, der - falls vorhanden - durch die E-Mail-Adresse des Hauptkontaktes (oder Tech-C) ersetzt wird. Falls keiner vorhanden ist, bleibt das Feld leer. Wir müssten aber noch testen, wie sich PHP bei einem leeren sendmail_from in der php.ini verhält (ich vermute aber, dass das funktionieren müsste). Als Zwangs-Option beim sendmail_path (-f) würde das aber garantiert Probleme geben, wenn dort keine Adresse drin steht.

Zitat von suppenuser

Zum Einen: Wenn ich mir anschaue, wie oft hier eine Verlängerung eines LC-Zertifikats nicht klappt und nachgearbeitet werden muss, dann setze ich ehr auf stabiles, bewährtes und gebe ein paar Cent dafür aus.

Als wenn es da keine Probleme gäbe... (Verlängerung schlichtweg vergessen weil manuell notwendig, CA inzwischen als "unsicher" gebrandmarkt, usw...)

Zitat

wenn ich in meiner eigenen -relevanten- Umgebung noch nicht einmal 10 Euro (brutto) für ein Zertifikat ausgeben will.

Die Tatsache, dass man für ein SSL-Zertifikat Geld bezahlt, macht dieses per se doch nicht "besser".
Let's Encrypt bedeutet, dass der Prozess für eine Basisverschlüsselung *voll automatisiert* ist. Das wäre mir persönlich wichtiger als ein Zertifkat, bei dem ich jährlich an die Verlängerung denken muss oder von der ausstellenden CA diesbezüglich zugespammt werde.

Und wie unser gemeinsamer Freund eines (sehr empfehlenswerten) SSL-Anbieters sagt: "secure is not safe". Eine anständige Validierung (OV/EV) kostet natürlich Geld, aber vollautomatisierte DV-Zertifikate sind doch nur noch eine Gelddruckmaschine, die langsam zusammenbricht.

Die werden auch vereinfacht, aber nicht über Wildcard-Zertifikate (das wäre der falsche Ansatz).
Demnächst wird man beim Anlegen von (Sub-)Domains direkt SSL aktivieren können - also in einem einzigen Workflow.

Die Unterstützung von Wildcard-Zertifikaten ist geplant, allerdings muss hierfür die betroffene Domain durch LiveConfig im DNS verwaltet werden, oder man muss manuell einen (von LC bereitgestellten) TXT-Record in seiner Zone anlegen. In letzterem Fall (externe DNS, manueller TXT-Record) Verlängerungen problemlos klappen ist noch nicht klar.

Zitat

Der manuelle Aufwand bei 40 Subdomains ist enorm!

Warum nicht gleich für jede Subdomain ein "eigenes" SSL-Zertifikat verwenden? Ist im zweifelsfall ohnehin sicherer. Ob man das selbe Wildcard-Zertifikat für jede Domain auswählt oder gleich ein eigenes Zertifikat anlegt macht ja keinen Unterschied im Aufwand.

Pl*k benötigt zwangsweise von jedem Benutzer/Kunden eine E-Mail-Adresse (u.a. um dann so beliebte Mails wie "We would like to hear your opinion about Pl*k" zu schicken).

LiveConfig tut das eben nicht - in Bezug auf die DSGVO ist eine E-Mail-Adresse ein persönliches Datum, welches technisch nicht für die Erbringung der Dienstleistung (Webhosting) benötigt wird. Somit ist es prinzipiell schwer, eine Voreinstellung hierfür zu treffen.

Wer seinen Endkunden die php.ini-Einstellung sendmail_from ermöglichen möchte, kann das mit zwei Mausklicks tun: in der php.ini-Verwaltung einen neuen Eintrag "sendmail_from" anlegen, Wert dabei leer lassen, und die Änderbarbeit auf "durch Kunden" einstellen. Dann kann jeder Kunde in seinen php.ini-Einstellungen hierfür einen Wert eintragen.

Zitat

Warum ist das hier so umständlich?

Der große Unterschied zu Plesk ist, dass da der Webserver immer (ob man will oder nicht) durch das Control Panel mit verwaltet wird. Somit ist es auch keine Zauberei, die Autorisierung für das SSL-Zertifikat dort in die Apache/NGINX-Konfiguration zu bekommen.
Die Architektur von LiveConfig ist da grundlegend anders. Wenn auf einem Server kein Webserver betrieben/verwaltet wird, dann kann dort keine SSL-Autorisierung durchgeführt werden.

Ein Workaround ist ja bereits beschrieben (Reverse Proxy) - wir arbeiten aber an einer eleganteren Lösung.

Zitat

Nebenbei. Man darf von einem LC-Betreibr schon erwarten, das er ein echtes Zertifikat verwendet.

Das ist Quatsch. SSL-Zertifikate von Let's Encrypt sind genauso "echte" Zertifikate, der Validierungsvorgang ist sogar transparenter als bei manchen kommerziellen CAs.

Schwierig... eine "falsche" Domain gibt es an sich ja nicht, da die Postfachnamen im Confixx gar keinen Domainnamen angefügt hatten.

Nehmen wir an, in Confixx gab es die Domains "test1" und "test2", und das Postfach hieß "web1p1".
Dann waren effektiv zwei Weiterleitungen angelegt (info@test1 -> web1p1 sowie info@test2 -> web1p1)

Beim Import in LiveConfig wird mit dem Benutzernamen (web1p1) und der erstbesten Domain (z.B. test1) ein Postfach angelegt => web1p1@test1. Die beiden Weiterleitungen (info@test1 und info@test2) werden unverändert übernommen.

Existiert für ein Postfach nur eine einzige Weiterleitung (z.B. im Confixx nur die info@test1 auf web1p1), dann optimiert der cfximport das so, dass auch nur ein Postfach ohne Weiterleitung angelegt wird: web1p1@test1, mit dem Alias "info".

Es ist also nicht damit getan, die Postfächer einfach auf eine andere Domain umzustellen - in der Regel gibt es noch "kollidierende" Weiterleitungen, die erst gelöscht werden müssen.

Es besteht grundsätzlich schon die Möglichkeit, über einen Eingriff in die Datenbank einige Mailkonfigurationen auf einen Schlag zu ändern (z.B. das Quota) - das klären wir am liebsten aber im Einzelfall per Mail an support@liveconfig.com (wir möchten vermeiden, dass sich jemand ins Knie schießt...)
Ein Umbenennen mehrerer Postfächer könnte schwierig werden, wenn es kollidierende Weiterleitungen gibt. Ansonsten ist das evtl auch möglich, daher bitte kurze Mail an uns.

Viele Grüße

-Klaus Keppler

Zitat von nightshift

Ich habe genau selbiges mit der aktuellen Version probiert, aber ich lande egal was ich mache nachher wieder beim Hostname.url:8443 mit dem selbst signiertem Zertifikat.

Wann genau landen Sie auf der Seite mit dem selbstsignierten Zertifikat - direkt nach dem Aufruf der URL, oder erst nach dem Abschicken der LiveConfig-Anmeldedaten?

Zitat

Als Proxy Weiterleitung sind https://localhost:8443/* bei HTTP und HTTPS eingetragen

Das macht nicht viel Sinn. Bei HTTP tragen Sie bitte eine Weiterleitung auf https://acp.meinedomain1.de/* ein, und nur bei HTTPS die o.g. Proxy-Weiterleitung.

Ansonsten können Sie uns gerne mal den "echten" Domainnamen an support@liveconfig.com schicken, vielleicht fällt uns da was auf.

Viele Grüße

-Klaus Keppler

Ein LiveConfig-Neustart ist vorerst weiterhin notwendig, da LC die Paketerkennung nur beim Start ausführt.
Wir sind derzeit dabei, den Build der PHP-Pakete komplett auf Debian-Bordmittel umzustellen (dpkg-buildpackage). Mit Debian 7.2 sind wir fertig, 7.1 läuft in diesen Minuten, dann kommen noch die restlichen (7.0, 5.6, evtl ältere). Wenn alles erledigt ist, wird die o.g. Wiki-Seite komplett neu erstellt (wenn alles gut geht etwa Mitte nächster Wocher).

Hintergrund: die "neuen" Pakete erledigen nicht nur die Lua-Registrierung, sondern bringen auch alles mit was LiveConfig braucht, um PHP via FPM laufen zu lassen (z.B. entsprechende systemd-Unit-Files).
Weitere Details dann hoffentlich in Kürze...

Schicken Sie uns einfach eine kurze Mail an support@liveconfig.com mit der Info um welche Distribution es sich bei Ihrem Server handelt, dann schicken wir Ihnen die Ausgabe von "postconf" sowie die main.cf/master.cf eines Testsystems einfach zu.
Letztendlich hängt es aber immer davon ab, welche Einstellungen Sie im LiveConfig aktivieren...

Auswahllisten machen dann keinen Sinn mehr, wenn man mehr als 20 Domains auf dem Server angelegt hat.

Ich würde diesen Punkt gerne zurückstellen, der ganze Workflow der SSL-Bestellung (für DV-Zertifikate) wird derzeit überarbeitet und stark vereinfacht. Bitte aber noch ein klein wenig Geduld.

Hallo,

weil uns gerade eine Menge Server um die Ohren fliegen: derzeit sollte man kein Kernel-Update auf Debian Stretch installieren, wenn man Xen nutzt!
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903767

Mit den Kernel-Optionen "elevator=noop pti=off" kann man wieder booten.

Unser Secondary-DNS ist leider gerade deshalb down, wir arbeiten an einer Lösung. Die Domain "liveconfig.com" ist derzeit gestört.

Beim Bearbeiten von SSL-Zertifikaten einfach mal auf den Tab "Optionen" klicken.

Die LTS-Unterstützung von Debian 7 (Wheezy) ist zum 31.05.2018 ausgelaufen.

Die nächste LiveConfig-Version (v2.7) wird Debian 7 nicht mehr unterstützen.
Auch die zusätzlichen PHP-Pakete für Debian 7 werden wir nicht mehr weiter aktualisieren.

Hinweise zum Upgrade von Debian haben wir im Wiki zusammengestellt - das Upgrade von Debian 7 auf 8 läuft unserer Erfahrung nach recht problemlos. Wer sich bislang noch nicht mit systemd beschäftigt hat, wird daran aber nun nicht mehr vorbei kommen.

Im übrigen ist es wesentlich einfacher, ein System von Debian 7 auf 8 zu aktualisieren, als einen Serverumzug durchzuführen.

Viele Grüße

-Klaus Keppler