Posts by [netcup] Lars S.

    Guten Abend slackito ,


    danke für deine Frage.


    Die SSD-Storagekapazität wurde bei unserer neuen Root-Server Generation 9 auf bis zu 2 TB erhöht. SAS-Festplatten entfallen dadurch und werden nicht mehr angeboten.


    Durch den angebotenen SSD-Speicher profitieren unsere Kunden von der bestmöglichen Performance.

    Hallo zusammen,



    es sollte nun wieder alles funktionieren. So wie wir es beobachten, war der Fehler lediglich, dass die Fehlermeldung erschienen ist. Die Einträge wurden trotzdem aktualisiert / gespeichert. Jetzt sollte auch die falsche Fehlermeldung nicht mehr erscheinen.

    Für alle Ubuntu-Nutzer: Ubuntu 20.04 Server steht nun als Image und DVD zur Verfügung (die "Live"-Variante des Installers als DVD folgt im Laufe des Tages).


    Viel Spaß und Erfolg damit!

    Guten Abend,


    da hier ja einige nachgefragt hatten: Der VPS 200 ist nun endgültig ausverkauft. Alle verfügbaren Ressourcen im Rahmen der Oster-Aktion wurden für diesen aufgebraucht.


    Ich hoffe, ihr findet trotzdem etwas anderes passendes und wünsche euch noch schöne Ostertage.

    Ich hab den Osterhasen endlich gefunden - die Eier sind versteckt, die Suche kann losgehen. Er bittet um Entschuldigung für die Verzögerung.


    Viel Spaß und gute Nacht


    Euer Lars von netcup

    Hallo an alle. Der Osterhase hat leider ein wenig Verspätung. Er ist aber ein nachtaktives Kerlchen, ich glaube, er wird das zeitnah richten.


    Bitte habt noch ein wenig Geduld, ich bin mir sicher, die Eier werden schon bald versteckt sein. Ich halte euch auf dem Laufenden.


    Euer Lars.

    [netcup] Lars S. Bekommt man eigentlich eine Mitteilung wenn der Server umgestellt wurde?


    Die Umstellung müsste ja schon laut Mitteilung seit Anfang April laufen.

    Hey, danke für die Frage :)


    Da die Wartung mit kurzzeitigen Ausfällen in Verbindung stehen kann, wird diese zuvor selbstverständlich angekündigt. Nach durchgeführter Wartung erfolgt nicht nochmal eine spezielle Mitteilung, generell wird diese aber auch nach dem benannten Zeitpunkt abgeschlossen sein.

    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.