Beiträge von tab

    Habe nichts davon gehört in letzter Zeit. Vielleicht lohnen die sich nicht. Verbraten eine IPv4 und ein IPv6 /64 und einen Teil eines x86 Cores/Threads, allerdings einen kleineren Teil davon als ein VPS x86 pro vCore. Ich könnte mir vorstellen besonders die IPv4 tut weh. Vielleicht bastelt man ja an einer reinen IPv6 Version, wäre ich an netcups Stelle, würde ich das machen und vielleicht gleich noch auf ARM-Basis. Dann sollte sich das eher rechnen.

    Wenn die Mail zu einem netcup Webhosting gehört (inklusiv oder zusätzlich) dann sollte Mail - auch von der Nextcloud - im Idealfall über den zuständigen SMTP-Server verschickt werden. Dass hier von Mail-App nach DKIM gefragt wird, deutet für mich aber nicht darauf hin, dass die Einstellungen so sind. Oder falls doch, dass die Mail-App Daten abfragt, die sie gar nicht benötigt.

    • Projekte entschlacken.
    • Einfacher machen, Ziel klarer definieren.
    • Netcup überzeugen Nested KVM auf dedicated CPU‘s zu aktivieren.
    • Glücklich sein

    Also ich will auch wieder - wie jedes Jahr - die Bestände an Webhostings, Server und Domains auf das Notwendige reduzieren. Gelingen wird es wie immer nicht, aber immerhin habe ich schon an Silvester einen Anfang gemacht und ein Webhosting gekündigt (bei einem Mitbewerber), das um 20% teurer werden sollte wegen Anpassung an die Marktentwicklung. Ich finde das Webhosting zwar nicht schlecht, aber die Bedienung wurde nach jahrelanger Entwicklung kürzlich so verschlimmbessert, dass manches derzeit gar nicht mehr vernünftig nutzbar ist.

    Die Website die da läuft kommt auch prima mit meinem Webhosting 4000 klar, das kostet nicht mal ein Drittel von dem, was das andere Webhosting ab Februar kosten sollte. Eine 1:1 Kopie der Website läuft darauf seit heute bereits, aber halt noch unter der falschen Domain. Und das Webhosting 4000 hat sonst eh nichts zu tun. Gefühlt läuft die Kopie eher schneller als die Originalsite. So flott hatte ich das WH 4000 gar nicht in Erinnerung, muss ich morgen direkt mal ein paar Vergleichsmessungen machen.

    Soviel also zum Thema Marktanpassung. Außerdem hatte ich nach den Pleiten und Pannen der letzten zwei Jahre eh schon über eine Kündigung nachgedacht. Das tolle neue Kundenpanel :rolleyes: und die Preiserhöhung waren nur die letzten Tropfen, die das Fass endgültig zum Überlaufen gebracht haben.

    Geht mir gar nicht so sehr um das Veröffentlichen der Daten, mich stört der Scan an sich, der Missbrauch von Ressoucen. Nein, meine so gescannten Server haben genug Ressourcen, aber das können die vorher nicht wissen. Hinterher vielleicht, aber dann hätte der Server ein ernsthaftes Sicherheitsproblem. Die zu blocken ist nie endender Aufwand, die wechseln die IPs öfter mal und sind in unterschiedlichen Subnetzen unterwegs. Also alles was über irgendwelche Blocklisten oder fail2ban rausgeht pure Arbeitsbeschaffungsmaßnahme.

    Ich bin da diesmal nur draufgestossen, weil ich derzeit noch meine Resolver Logs schreiben lasse und diese überwache. Da steht dann 20x die selbe IP, für die der PTR vom selben Server abgefragt wurde innerhalb kurzer Zeit.

    Beim entsprechenden Server finde ich dann in den Logs, dass sich die IP 20 Mal hintereinander mit dem smtpd verbunden hat und sich dann ohne Aktion wieder verabschiedet. Teils mit irgendwelchen Fehlern in der TLS-Library oder mit fehlerhaften Anfragen.

    Ein andermal finde ich irgendeine IP im Log des Backup-Resolvers, der nur gefragt wird, wenn der erste nicht rechtzeitig eine Antwort liefert oder eben SERVFAIL. Da weiss ich dann gleich, mit der IP muss was komisch sein, sonst hätte der die Anfrage nicht bekommen. Da sie von Censys ist, kann man davon ausgehen, dass das Reverse DNS nicht versehentlich fehlschlägt. Also absichtlich präpariert, eventuell um herauszufinden, welche Resolver der Server benutzt. Die entsprechenden IPs der Resolver bekommen sie ja schön der Reihe nach geliefert, weil alle SERVFAIL liefern bei der Abfrage des PTR. Die IPs ist auch auf diversen DNS-Blocklisten gelistet. Bringt aber leider herzlich wenig in dem Fall.

    Jetzt könnte man sagen, gut dass es Shodan, Censys & Co gibt. Aber immer, wenn ich sowas finde ist es garantiert einer dieser Scanner, nie irgendein unbekannter Hacker. Jeden Tag mehrmals die selben "Tests". Der Ressourcenverbauch hält sich freilich auch in Grenzen, die Abfrage wird ja vom Resolver nur einmal wirklich rekursiv gemacht, die restlichen 19 Antworten kommen aus dem Cache. Und auch bei der einen rekursiven Abfrage wird ja der entsprechende Thread nicht blockiert, per UDP jedenfalls nicht.

    Dass nicht alle Mails ankommen kann unterschiedliche Ursachen haben. Haben die betroffenen User auch mal in ihren Spamordner geschaut? Gerade Microsoft stellt Mails von neuen Absenderadressen meist bestenfalls als Spam zu. Aber das sollten Benutzer von MS-Adressen ja eigentlich wissen. Die entsprechenden Mails als "kein Spam" zu markieren oder in den Posteingang zu verschieben sollte das für die nächste Zeit beheben. Wenn du per SMTP versendest, musst du das auch nicht zwingend über eine Absenderadresse aus deinem Webhosting machen.

    1. Anzahl der versendeten Mails. Wenn dein Forum sehr viele Mails verschickt, kannst du damit das Limit des netcup Webhostings überschreiten. Für ein sehr großes Forum mit vielen Usern und Benachrichtigungen reicht es eventuell nicht. Ich bin mir nicht sicher, wo genau das Limit derzeit liegt. 100 pro Stunde? Dazu gibt es noch ein tägliches Limit.
    2. Traditionell war die Zustellbarkeit von Mails aus dem netcup Webhosting nicht besonders gut. Es soll sich aber gebessert haben in letzter Zeit. Wie gut "besser" freilich ist, weiss ich nicht. 100% ist sowieso eher unrealistisch. Das erreicht wohl kaum ein Provider im Shared Webhosting. Es wird immer mal wieder passieren, dass z.B. (und vor allem) Microsoft deine Mails ablehnt. Welche KI nach welchen Kriterien entscheidet, welche IP Subnetze man gerade als Absender ablehnt (MS interne Blockliste), weiss nur Microsoft. Und auch das nur vielleicht.
    3. Technische Gründe. Passt deine DKIM-Signatur, SPF und DMARC jetzt? Würde ich mal überprüfen mit einem geeigneten Tool. Normalerweise sollte DKIM und SPF bei netcup passen, DMARC wird wohl nicht automatisch gesetzt, könnte nicht schaden das zu tun. Mit den dreien korrekt eingestellt wird es nur noch sehr wenige Mailhoster geben, die deine Mails wegen technischer Gründe ablehnen. Ich habe bei einem anderen Webhoster eine Mailadresse, die nur in Ausnahmefällen mal Zustellbarkeitsprobleme hatte (eigentlich nur einmal, bei wem wohl?). Und da war nur SPF gesetzt, kein DKIM und kein DMARC. Die haben DKIM erst vor kurzem nachgerüstet, als dies Web.de und GMX vor einigen Monaten (völlig unerwartet :D, jedenfalls für den Webhoster) zwingend voraussetzten.

    Ja, der Parameter bewirkt ja keine dauerhafte Erhöhung, nur für den einen Aufruf. Wenn du das (-d memory_limit=1024M) also in deinen Aufruf des Nextcloud-Cronjobs (cron.php) einbaust, dann wird der Cronjob mit höherem memory_limit laufen. Die PHP-Info im Control Panel gilt nur für den Webprozess, aber nicht für die Kommandozeile, das sind zwei Paar Stiefel.

    Im Webprozess hast du tatsächlich das hohe Limit von 1024 MB voreingestellt, außer du setzt es selbst niedriger. Bis vor einigen Jahren war das auch in der Kommandozeile per Default so, aber es wurde irgendwann geändert auf 128 MB. Braucht man mehr, muss man jetzt halt den Parameter mitgeben. Auch beim Aufruf von occ wird man zur Erhöhung des Limits aufgefordert. Ich glaube der will 512M haben, also wird das wohl auch für den Cronjob reichen.

    Wenn es der Cronjob ist, dann würde ich mal nachprüfen welches memory_limit in der Konsole (also für das PHP-CLI) eingestellt ist. Mir war so, als sei das seit einiger (längerer) Zeit per Default auf 128M eingestellt. Im Zweifelsfall mal beim Cronjob das gewünschte memory_limit mit angeben.

    Edit, gerade in einem 4000er getestet

    Code
    bash-5.1$ php -i | grep memory_limit
    memory_limit => 128M => 128M
    bash-5.1$ php -d memory_limit=1024M -i | grep memory_limit
    memory_limit => 1024M => 1024M

    Die mobile Outlook-App (also auch auf iOS) sendet deine Zugangsdaten ohnehin an Microsoft und ruft die Emails auf deren Cloud-Geschichte ab. Das heißt, dass es da eine technische Limitierung geben könnte, die das Verhalten erklärt.

    Abgesehen davon, dass es bei dir mit dem komplizierteren Passwort nicht geklappt hat, ist es also ohnehin fraglich, ob der Einsatz dieser App sinnvoll ist. Ich persönlich würde meine Zugangsdaten nicht gerne auf Microsoft-Servern hinterlegt wissen.

    Ich muss meine Zugangsdaten auch nicht auf Microsoft-Servern hinterlegen, aber genauso wenig auf irgendwelchen Apple oder Google-Servern. So weit die Theorie ...

    Könnte eventuell eine Störung sein, in einem anderen Thread wurde auch zeitweise das selbe Verhalten beobachtet, dass PHP-Dateien heruntergeladen werden statt ausgeführt. Das ist dann aber wahrscheinlich (hoffentlich) auf wenige oder nur einen Webserver begrenzt.

    Edit: Das wäre dann ein Fall für den Support. In dringenden Fällen sicher auch für den Notfallsupport.

    Also ich glaubenicht, dass es damit zu tun hat. Ich habe bei mir keinen vendor-Ordner. Außer bei Websites mit Symfony/Composer. Der vendor-Ordner wird dann auch bei der Installation der Software angelegt und nicht von netcup. Deshalb kann netcup bzw Plesk ihn auch nicht wieder herstellen. Im vendor-Ordner sind schlicht alle Pakete drin, die zu der jeweiligen Software gehören. Einen Einfluss darau, ob PHP-Dateien ausgeführt oder runtergeladen werden sollte das nicht haben. Wenn sie runtergeladen werden, dann fehlt irgendein Handler, also wenn z.B. PHP deaktiviert ist. Dass es in der Subdomain funktioniert heißt erst einmal nichts, weil die Einstellungen (Hosting, PHP, ...) für jede Domain oder Subdomain separat gemacht werden, also unterschiedlich sein können.

    Der Haken vor "PHP-Unterstützung (PHP Version ..." in dePHP-Einstellungen für die Domain, ganz vorne in der Zeile, wo die PHP-Version ausgewählt wird ist auch gesetzt? Den kann man ja durchaus mal versehentlich - oder absichtlich - wegklicken, zumal bei euch offenbar nicht alle Domains PHP-Skripte verwenden. Per Default sollte er gesetzt sein.

    Dann gehe ich davon aus, dass der Account normalerweise morgen, derzeit vielleicht auch übermorgen ;) , durch die Zahlung verifiziert ist und das Webhosting dann auch bereitgestellt wird. Ist zwar immer noch Urlaubszeit, aber das sollte ja gerade noch möglich sein. Falls nicht, gibt es ja morgen wieder normalen Telefonsupport. Ich muss das Webhosting nicht zwingend loswerden, die nächste Abrechnung dafü vom 24.12. ist sowieso in meiner nächsten Sammelrechnung Ende nächster Woche enthalten.