Beiträge von kk

  • PHP 5.6.40, 7.1.26, 7.2.14 und 7.3.1

    Zitat von dicker

    Ich habe es jetzt bei zwei Kunden Accounts getestet. Da hat es funktioniert.


    Stelle ich eine Domain, die unter *Mein Hosting* registriert ist auf 5.6.4 um, dann kommt immer error.


    Dann vergleichen Sie mal, wie die PHP-Ausführung konfiguriert ist (Vertragseinstellung) - FastCGI, suPHP oder FPM. Das wird beim "eigenen" Vertrag und bei den Kunden vermutlich unterschiedlich sein.
    Die Ausgabe von liveconfig --diag ist leider zu sehr gekürzt - die ganze Liste der PHP-Versionen fehlt da. Da würde nämlich stehen, welche PHP-Version wie verfügbar ist (FPM/FastCGI).

  • GitHub

    Zitat von weltmeister

    Momentan geht die Entwicklung für viele gewünschte Erweiterungen sehr schleppend voran... oder täuscht das?


    Die Release-Häufigkeit hat nichts mit der Entwicklungsgeschwindigkeit zu tun.
    Es tut sich im Moment *sehr* viel, nur können wir das noch nicht alles gleich freigeben. Bitte noch ein klein wenig Geduld. In v2.8 gibt es große Änderungen.

  • date.timezone nicht gesetzt in .../php56/php.ini

    Zitat von sTeaLth

    Ist die Option "date.timezone" in php56 noch kein Standard oder warum wird diese nicht gesetzt


    Soweit ich weiß ist diese Option standardmäßig in der php.ini auskommentiert. (PHP kann ja nicht wissen, in welchem Land es gerade eingesetzt wird)


    Die sauberste Lösung ist:

    • im LiveConfig als "admin" anmelden
    • zur php.ini-Verwaltung gehen
    • dort einen neuen Eintrag vom Typ "Zeichenkette" anlegen. Name="date.timezone", Wert="Europe/Berlin". Änderungen durch den Kunden ggf. erlauben.


    Damit landet diese Einstellung dann in allen mit LiveConfig genutzten PHP-Versionen.


    Viele Grüße


    -Klaus Keppler

  • DEBUG Problem

    Ihr CMS hat sich irgendeine Malware eingefangen.
    Von dieser URL wird Code nachgeladen, der dann auf dem Webserver ausgeführt wird (häufig irgendwas um Malware/Trojaner weiter zu verteilen).


    Lassen Sie am besten mal einen lokalen Malware-Scan laufen (z.B. Linux Malware Detect).


    Die Website an sich sollte schleunigst abgeschaltet werden, bevor diese bei Google etc. auf einer Blacklist landet.

  • LiveConfig v2.7.3

    Update: einer Diskussion auf HackerNews zufolge ist LiveConfig tatsächlich nicht betroffen.
    (gefährdet scheint nur Software zu sein, bei der beliebige SQL-Befehle ausgeführt werden können; wo das der Fall ist, hat man aber ohnehin ein anderes Problem: SQL Injections ;)

  • LiveConfig v2.7.3

    Hallo,


    ab sofort steht LiveConfig v2.7.3 (r5163) zum Download bereit.
    Die einzige Änderung gegenüber der vorherigen Version (2.7.2-r5133) ist, dass die enthaltene SQLite-Bibliothek von 3.25.3 auf 3.26.0 aktualisiert wurde.


    Vor wenigen Tagen haben Sicherheitsforscher der Firma "Tencent" eine Sicherheitslücke in SQLite entdeckt, welche in manchen Fällen die Ausführung beliebigen Codes erlauben soll.
    Nach allem, was wir bislang in Erfahrung bringen konnten, dürfte LiveConfig eigentlich ohnehin nicht davon betroffen sein, da LiveConfig SQL-Befehle ausschließlich als "Prepared Statements" ausführt, und auch keine "fremden" SQLite-Dateien geöffnet werden können. Da aber bislang keine weiteren Details zur Lücke bekannt sind, haben wir uns entschlossen, SQLite sicherheitshalber zu aktualisieren.


    Wenn uns weitere Informationen zur SQLite-Sicherheitslücke vorliegen, werden wir hier darüber berichten.


    Viele Grüße


    -Klaus Keppler

  • Verbot bestimmter Ziel-Domains bei Weiterleitungen

    Kurz zur Info: mit LiveConfig v2.8.0 gibt es einen LCDefaults-Key "mail.forwards.blacklist", bei dem man bestimmte Zieldomains für die Verwendung in E-Mail-Weiterleitungen sperren kann (kommagetrennte Liste). Also z.B. so was wie "gmx.de,web.de,t-online.de". :)
    Bestehende Weiterleitungen sind davon nicht betroffen, die Blacklist wird nur beim Anlegen oder Bearbeiten eines Postfachs geprüft.

  • Standard PHP-Version ändern

    Zitat von tfi

    Wir würden nun gerne den Standard überall auf 7.3 setzen ohne aber die bestehenden Verträge/Webseiten,
    die in der Auswahl Standard (und damit 5.6 usw.) gewählt haben, zu beeinflussen.


    Soll PHP 7.3 also nur für neue (Sub)Domains als "Standardversion" voreingestellt werden?
    Das ist nicht ganz einfach. "Standardversion" bedeutet, dass für die betroffene Domain keine bestimmte Version fest eingestellt ist. Man kann höchstens sagen, dass alle Verträge die aktuell die Standardversion (z.B. 5.6) nutzen, fix auf 5.6 eingestellt werden und anschließend z.B. 7.3 als neue Standardversion festsetzen. Damit sind aber die alten Verträge auf die bislang alte Standardversion "festgenagelt".


    Zitat

    Speichert sicht LC die PHP-Version für diese Verträge/Webseiten mit der passenden Version oder als "standard"
    und wenn wir nun "standard" umstellen, stellen wir auch die PHP-Versionen für die Webseiten um?


    Technisch betrachtet speichert LiveConfig bei den Domains, bei denen "Standard" ausgewählt ist, einfach keine Versionsnummer sondern wählt während die vHost-Konfiguration erzeugt wird die Version, die als PHP-Standardversion erkannt bzw. festgelegt wurde.



    Zitat

    Edit - Auch wenns nicht ganz zum Thema passt:
    Ist es möglich sich die Verträge auflisten zu lassen, die eine gewisse PHP-Version verwenden?
    Wir wollen uns einen Überblick verschaffen bei welchen Verträgen noch PHP 5.5/5.6 aktiv ist
    um diesen Kunden eine Infomail zukommen zu lassen.


    Code
    grep -l php56 /etc/apache2/sites-available/*.conf


    Viele Grüße


    -Klaus Keppler

  • E-Mail Versand mit .NET Client nicht möglich

    Zitat von pitgrap

    Ich habe nun verschiedene Clients aus dem Firmennetz getestet und Clients außerhalb. Alle aus dem Firmennetz erhalten eine Antwort ohne Starttls, alle anderen mit.


    Daher tippe ich aktuell auch auf die Firewall.


    Die wird es sicher sein. Der Mailserver unterscheidet nicht nach Herkunft der Verbindung - der bietet allen SSL an. In großen Netzen ist es üblich, dass kein verschlüsselter (= nicht scanbarer) Traffic nach außen geht. Einfach mal mit den lokalen (zuständigen) Admins sprechen, ob eine "unverschlüsselte" Verbindung (bis zur Firewall) erlaubt ist, bzw. was die empfehlen würden.

  • E-Mail Versand mit .NET Client nicht möglich

    Zitat von pitgrap

    ich habe das Problem, dass ein Programm (SAP) E-Mails mittels .NET verschickt.


    Das sind sogar zwei Probleme. ;)


    Scherz beiseite.

    Zitat

    EDIT: ich habe mich gerade per telnet mal mit dem Postfix verbunden und nach dem EHLO antwortet dieser nur


    Code
    250-Requested mail action okay, completed
250-SIZE 20000000
250-ETRN
250-8BITMIME
250 OK


    Ich hätte erwartet, dass dort auch sowas wie "250-STARTTLS" zurückkommt. Ich denke, dass dies auch der .NET Client erwartet und deswegen die Fehlermeldung zurück gibt.


    Ja, der Server bietet offensichtlich kein SSL an.


    Ist denn im LiveConfig SSL für Postfix aktiviert und konfiguriert? Sie können den SSL-Zugriff auch mal via https://sslcheck.liveconfig.com testen.


    Da das Ganze offenbar unter Windows stattfindet, kann es auch sein, dass sich ein lokaler Virenscanner dazwischen klemmt. Die akzeptieren häufig keine verschlüsselte Verbindung auf lokaler Seite.


    Wenn der SSL-Check (s.o.) also auf den Ports 25 und 587 ein SSL-Zertifikat anzeigt, prüfen Sie mal ob ein lokaler Virenscanner (oder eine transparente Firewall o.ä.) läuft und evtl. die Verbindungen abgreift.

  • HostingDomainAdd Api erweitern

    Ist aktuell in Arbeit - sowohl über HostingDomainAdd() als auch über die GUI direkt beim Anlegen der Domains. Dabei wird die SSL-Komponente etwas umfangreicher umgebaut (um auch andere Anbieter automatisiert einbinden zu können), wird bis März 2019 fertig sein.

  • Standard PHP-Version ändern

    In der custom.lua die Variable "LC.web.PHPDEFAULT" auf die gewünschte PHP-Version setzen, z.B.:

    Code
    LC.web.PHPDEFAULT = "php71"


    Anschließend LiveConfig neu starten, dann eine IP-Gruppe, Hostingangebote oder Verträge bearbeiten um die vHost-Konfigurationen neu schreiben zu lassen.


    Viele Grüße


    -Klaus Keppler

  • PHP Phar

    Weil ich gerade sehe dass die Antwort hier noch fehlt: es gibt offenbar einen Bug im PHP Opcache, wenn man auf Phar-Archive zugreift und Opcache die Daten im Shared Memory cached.


    Der Fehler lässt sich umgehen, indem man die php.ini-Einstellung "opcache.file_cache_only" von "no" auf "yes" setzt. Damit wird der compilierte Bytecode im jeweiligen Cache-Verzeichnis als Datei abgelegt, und nicht mehr im Shared Memory. Im Zeitalter von SSDs hält sich der "Impact" dabei auch in Grenzen.


    Weitere Infos auch im GitHub-Ticket des Contao Managers: https://github.com/contao/cont…47#issuecomment-434752134


    Ab LiveConfig v2.7.1 ist die Einstellung "opcache.file_cache_only" in der php.ini-Verwaltung enthalten und kann durch Kunden von "no" (Standard-Einstellung von PHP) auf "yes" geändert werden.


    Viele Grüße


    -Klaus Keppler

  • LiveConfig 2.7.2

    Hallo,


    ab sofort steht LiveConfig v2.7.2 (r5133) zum Download bereit.


    Mit diesem Update werden einige kleinere Fehler behoben sowie die enthaltene OpenSSL-Bibliothek auf v1.1.1a aktualisiert. Alle Änderungen finden sich wie immer im Changelog.


    Viele Grüße


    -Klaus Keppler