Posts by [netcup] Lars

    Hallo p4scal ,



    die erwähnten Upgrades finden im Zeitraum April bis Juni statt. Kunden, die dadurch besonders betroffen sind (da PHP-Versionen älter als 5.6 deaktiviert werden), wurden bereits darüber informiert.


    Alle weiteren Kunden informieren wir dann, sobald der genaue Termin für das Upgrade feststeht. Wie aber bereits geschrieben, findet hier noch kein Upgrade auf Obsidian statt, bis dies geschieht, wird es noch ein wenig dauern.

    Hallo jni ,


    danke für deine offenen Worte und auch danke an alle Foren-Teilnehmer, die hier geholfen haben.


    In der Tat ist es so, dass wir hier von der verwendeten Hostingpanel-Software abhängig sind, die dieses Feature seitens des Herstellers nicht anbietet. Wie jni schon richtig angemerkt hat, gibt es die Möglichkeit, das Feature beim Hersteller zu "voten", so dass es dort ggf. priorisiert wird.


    Es tut uns Leid, dass wir dieses Feature nicht anbieten und deinen Anforderungen somit in diesem Punkt nicht gerecht wurden. Du kannst das Hosting, falls du dies wünscht, über unser CCP bequem mit unserer Zufriedenheitsgarantie zurückgeben und erhältst dann alle angefallenen Kosten zurückerstattet. Alle nötigen Informationen dafür findest du hier in unserem Wiki:

    https://www.netcup-wiki.de/wik…iedenheitsgarantie_nutzen

    Hallo killerbees19 ,


    ich habe dir gerade bereits auf dein Ticket geantwortet.


    Um es auch noch einmal im Forum für alle festzuhalten:


    disable_functions wurde von uns für alle Domains im Webhosting geleert, um vielfältige Probleme mit Webanwendungen zu vermeiden.


    Nach erneuter Prüfung und Rücksprache bei uns im Team ist es möglich, dass wir den Wert für disable_functions im Webhosting auf Anfrage bei unserem Support anpassen. Dazu dem Support bitte die betroffenen (Sub-)Domains und den gewünschten Wert nennen. Sollte es hier eine anders lautende Rückmeldung geben, bitte auf diesen Beitrag im Forum verweisen. Vielen Dank.

    Guten Abend zusammen,



    danke für eure Unterstützung.


    Bei den zwei Meldungen ganz oben (im Bezug auf das session_dir) handelt es sich um eine Notice und eine Warning. Die erste Meldung deutet lediglich darauf hin, dass der Garbage Cleaner von PHP die Session Files nicht löschen konnte. Das ist korrekt so, da wir die Löschung automatisiert vornehmen. Dieses Feature sollte eigentlich in den PHP-Settings unsererseits deaktiviert sein. Ich werde prüfen, warum das nicht der Fall ist und es ggf. korrigieren. Diese Meldung ist aber definitiv nicht ursächlich und erzeugt auch keinerlei Probleme bei der Nutzung von PHP-Sessions. Zahlreiche Kunden auf dem gleichen Server nutzen PHP-Sessions erfolgreich. Der session_path ist korrekt so, dieser wird erst in der Zukunft (bei einem Upgrade des Betriebssystems) verändert.


    Die zweite Meldung dürfte eher im Programmcode der verwendeten Software zu verorten sein, evtl. durch die vorangegangene Meldung. Aber auch diese stellt nicht das eigentliche Problem dar.


    Der eigentliche Fehler lautet: "Identifier DB not initialized yet"


    Dieser Fehler deutet laut einer Internetrecherche z.B. auf einen Fehler bei der Datenbankverbindung hin, auf ein zu niedriges Memory Limit, eine zu niedrige Max Execution Time, usw.


    Hier empfiehlt sich auch ein Blick in das error log, nachdem die entsprechende Option ("log_errors") in den PHP-Einstellungen der Domain aktiviert wurde. Dort finden sich evtl. weitere nützliche Hinweise, die bei der Fehlersuche helfen können.


    Ich habe mit dem betroffenen Kunden Kontakt per E-Mail aufgenommen, damit wir uns den Fehler gemeinsam nochmal ansehen können. Eventuell gibt es aber ja hier auch Shopware-Anwender, die ein ähnliches Problem hatten und weiterhelfen können.

    Hallo marpri ,



    danke für deinen Hinweis.


    Die von dir benannten Situationen treffen viele Mailanbieter und jeder Provider muss sich individuell entscheiden, wie er damit umgeht. Mir persönlich sind auch andere Mailprovider bekannt, die damit wie wir umgehen.


    Grundsätzlich ist es so, dass das SMTP-Protokoll ganz bewusst keine Kontrollen des Absenders vorsieht, ähnlich wie es möglich ist, eine beliebige Absenderadresse auf einen Brief zu schreiben. Wir sehen an vielen verschiedenen Stellen, wo das nötig ist und genutzt wird, z.B. bei Mailinglisten, Benachrichtigungen, Weiterleitungen, usw.


    Gerne möchte ich einmal auf deine einzelnen Punkte eingehen:


    Zu 1.) Es ist korrekt, dass das prinzipiell möglich ist. Der Empfänger ist dafür verantwortlich, mittels den zur Verfügung stehenden Techniken zu überprüfen, ob ein bestimmter Absender autorisiert ist, von einem Mailserver zu versenden. So würde im konkreten Beispiel, wie auch von dir erwähnt, der SPF-, DKIM- und DMARC-Check fehlschlagen. Das wird aber vom empfangenden Provider für das absendende System nicht negativ ausgelegt, eben da das SMTP-Protokoll eine solche Möglichkeit des Versendens von abweichenden Mailadressen explizit vorsieht. Es erhöht also nicht das Risiko auf Blacklists o.ä. zu landen. Auch den Blacklist-Betreibern ist bekannt, dass diese Schwierigkeiten im SMTP-Protokoll vorhanden sind, weswegen es ja überhaupt erst Techniken wie SPF / DKIM und DMARC gibt.


    Zu 2.) DKIM weist leider konzeptionelle Schwächen auf: Somit ist DKIM in erster Linie erhöhend für die Reputation des Mailservers, aber nicht der Authentizität der Absenderdomain, auch wenn es dafür ursprünglich vorgesehen war. Außerdem ist für den Endanwender in den meisten Fällen nicht sichtbar, ob eine Mail DKIM signiert wurde, oder nicht. So erhöht eine DKIM-Signatur zwar die Zustellbarkeit, Mails ohne DKIM werden aber dennoch (wenn keine anderen schwerwiegenden Fehler vorliegen) in der Regel zugestellt. Es muss den Empfängern also ohnehin vermittelt werden, dass der Absender einer E-Mail grundsätzlich nicht zweifelsfrei als korrekt angesehen werden sollte. Empfänger sollten immer die enthaltenen Links bei einer Nachricht auf Korrektheit prüfen. Bei einer Antwort würde außerdem ohnehin an die "FROM"-Adresse geantwortet werden.


    Zu 3.) Es ist richtig, dass der Absender bei uns teilweise zur Authentifizierung von Anfragen verwendet wird. Allerdings antworten wir ja auch stets an die Absenderadresse. Somit gehen persönliche Daten in keinem Fall an den Fälscher des Absenders. Wir würden in dem Fall ja an die korrekte E-Mail-Adresse des Kunden antworten. Bei kritischen Aktionen, wie z.B. Kündigungen, lassen wir uns diese immer zuvor über eine erneute Antwort an den Absender bestätigen. Dadurch ist ausgeschlossen, dass z.B. Löschungen von Daten durch einen gefälschten Absender initiiert werden.


    Zu guter Letzt schreiben wir die wahre Absenderdomain in die Message-ID und bei unseren Webhostingtarifen auch in einen weiteren Header, so dass auch für uns (z.B. bei späteren Abusemeldungen zu einer Nachricht) eindeutig erkennbar ist, von wem die E-Mail versendet wurde.


    Ich hoffe, dass das weiterhilft.

    Hallo Volker S , danke für deine Fragen.


    Die eingeschränkte PHP 5.6-Version lässt sich im Vorfeld nicht testen. Aus unserer Erfahrung ist diese aber für nahezu alle Kunden hinreichend.


    Du kannst die PHP-Version je (Sub-)Domain in den "Hosting-Einstellungen" oder den "PHP-Einstellungen" im Hosting-Panel anpassen. Dafür musst du nicht mit .htaccess-Dateien arbeiten. Für jede eigene (Sub-)Domain kannst du dort eine eigene PHP-Version setzen.

    Ansonsten werde ich eure Mails nur los wenn ich die Weiterleitungen zurück auf Hosting stelle, PHP Version ändere und wieder die Weiterleitung aktivieren.

    Es ist in dem Fall nun allerdings nicht zwangsläufig eine Aktion nötig. Wir werden noch eine weitere Mail versenden, in der wir für jeden Host den genauen Update-Zeitpunkt ankündigen. Diese wird aber an alle Kunden gehen. Insofern brauchst du nichts ändern – das passiert dann im Zweifel beim Upgrade einfach automatisch. Ich kann aber natürlich verstehen, dass das missverständlich sein kann, daher werden wir das sicherlich in der Zukunft verbessern.

    Aha, danke. Ergo heißt das, für mich als reinen email Nutzer ändert sich mit der PHP Umstellung gar nichts, und ich kann nach der Umstellung unverändert auf meine mail accounts zugreifen. Für zukünftigen Website-Aufbau müsste ich auf Software zurückgreifen, die auf neuere PHP Versionen zugeschnitten ist. Soweit korrekt?

    Richtig.


    Macht es Sinn, dennoch im CCP in den Domäneeinstellungen bereits auf neuere PHP Versionen umzustellen wie in der netcup Anleitung vorgeschlagen, oder ist das für mich irrelevant?

    Das ist nicht zwangsläufig nötig, die Umstellung erfolgt (falls eine Version älter als 5.6 genutzt wird), dann mit dem Upgrade automatisch durch uns.

    Danke für den Hinweis. Ich werde das für das nächste Mal prüfen. Es gibt sicherlich auch Kunden, die PHP nur temporär deaktivieren und die sich daher trotzdem über den Hinweis freuen. Daher ist das immer eine Abwägungssache.

    Was beinhalten die Updates des Betriebssystems und von Plesk?

    Durch das Update des Betriebssystems werden in der Chroot einige neuere Versionen von Tools bereitstehen. Plesk wird innerhalb des "Onyx"-Branches von 17.5 auf 17.8 aktualisiert. Hier sind z.B. Verbesserungen am "Wordpress Toolkit", sowie in der Performance und der Stabilität festzustellen.

    Also welches Betriebssystem wird in welcher Version eingesetzt werden

    Dazu erteilen wir bei unseren shared Webhostingtarifen keine Auskunft, dafür bitte ich um Verständnis. Es wird ein Upgrade auf die nächste neuere Version vorgenommen. Dadurch profitieren unsere Kunden, wie bereits erwähnt, auch von neueren Versionen.

    und wird im Rahmen des Plesk-Updates die disable_functions Problematik behoben werden?

    Diese ist bereits für alle Kunden behoben. Die benötigten Funktionen sind nicht mehr in disable_functions enthalten.

    Wie sieht es mit den Reseller-Tarifen aus?

    Wird es da auch Einschränkungen bei php 5.6 geben? Wenn ja, welche?

    Dort ist die Version mit den Einschränkungen schon (seit Beginn) aktiv. Die Einschränkungen werden in den FAQ oben genauer erklärt. Sollten bisher deine Skripte problemlos funktionieren, wird sich dort nichts ändern. Die Reseller-Webhostings benötigen aktuell auch kein Upgrade. Die Kunden darauf sind also nicht betroffen.

    ===================================

    ENGLISH VERSION BELOW

    ===================================


    Liebe Kundinnen und Kunden,



    im Rahmen eines wichtigen Updates von Plesk und des Betriebssystems der Webhosting-Systeme kommt es zu Änderungen, welche unsere Kund/innen der aktuellen Tarife des Plesk Onyx Cloud Webhostings betreffen, die PHP 5.* Versionen verwenden.


    Im Zeitraum von April bis Juni 2020 werden wir

    • PHP Versionen älter als 5.6 entfernen und
    • die PHP-Version 5.6 in einer Variante mit kleineren Funktionseinschränkungen weiter bereitstellen


    Die betroffenen Kund/innen werden in einem Newsletter darüber detailliert informiert. Nur Kunden, welche eine der betroffenen Versionen verwenden, werden aktuell benachrichtigt. Der Newsletter wird an diese sukzessive versendet. Wir bitten um ein wenig Geduld. Mit diesem Forenthema möchten wir darüber hinaus die Möglichkeit zur gegenseitigen Information und Hilfe zum Thema geben.


    Beachtet bitte auch die häufig gestellten Fragen aus dem Newsletter:




    ===================================

    Click for English version:

    ===================================

    Guten Morgen Maximilian Rupp ,



    danke für deine Frage.


    Derzeit ist die Planung zum Upgrade von Plesk auf Obsidian im Webhosting als auch auf den managed Servern noch in den Kinderschuhen, denn wir sind aktuell mit einem anderen Upgrade-Projekt beschäftigt, das zuerst abgeschlossen werden soll. Dazu werden wir in der näheren Zukunft Ankündigungen an unsere Webhosting- und managed Server-Kunden versenden. Diese Upgrades beziehen sich auf die Plesk-Version und auf das verwendete Betriebssystem. Auch hier wird die Plesk-Version allerdings vorerst noch weiter bei Onyx bleiben.


    Das hat den Hintergrund, dass das verwendete Hosting-Panel ein integraler Bestandteil unserer Produkte ist. Jegliche größere Updates werden von uns äußerst sorgfältig auf ewtaige Schwierigkeiten und Inkompatibiltäten geprüft. Diese können vor allem bei Major-Upgrades, also größeren Versionssprüngen (wie z.B. von Onyx auf Obsidian) auftreten. Es ist für uns sehr wichtig, dass bei dem verwendeten Hosting-Panel keine Fehler auftreten, da dies von unseren Kunden zurecht erwartet wird. Wir betreiben daher bei Plesk eine etwas konservativere Versionspolitik: Stabilität geht hier in jedem Fall vor. Wichtig ist: Auch Onyx wird selbstverständlich noch vom Hersteller mit Updates versorgt (https://www.plesk.com/lifecycle-policy/). Wir stellen natürlich sicher, dass wir in unserer Webhosting-Cloud, als auch auf unseren managed Servern, nur Versionen verwenden, die auch vom Hersteller unterstützt werden.


    Das Upgrade auf Obsidian wird natürlich ein Schritt sein, den wir noch zeitnah planen werden. Aktuell legen wir unseren Fokus auf die Aktualisierung des Betriebssystems der Webhosting-Systeme und der managed Server. Danach werden wir prüfen, wie wir weiter mit dem Upgrade von Onyx auf Obsidian verfahren.