Posts by bjo

Debian works? Hauptsache anders gemacht als Upstream es vorsieht.

Aber alternativ könnte man sich auch ein VXLAN bauen? Oder erzeugt das dann auch schon zuviel Latenz? Ich nutze VXLAN bisher nur zwischen wirklich unterschiedlichen RZ-Standorten.

vmk wrote:

@cljk: Du musst halt mal fstrim ausführen. Klitzekleines Problem bei proxmox: Das klappt für fast alles außer in den lxc-Containern.

fstrim läuft bei mir jede Woche, trotzdem rödelt die Speicheroptimierung nun seit einigen Minuten.

[netcup] Felix wrote:

Guten Morgen,

Langfristig schließen wir einen Wechsel auf AMD Epyc CPUs nicht aus. Diese werden intensiv von uns getestet. Wenn wir zu AMD schwenken, geschieht dieses mit einer neuen Root-Server Generation. Die vorangegangene Generation wird dann weiterhin bestellbar sein, so dass Sie als Kunden wählen können ob Sie eine CPU von Intel oder AMD nutzen möchten.

Da bin ich mal gespannt. Mein Arbeitgeber hat neulich mal Angebote für einen Kundenserver basierend auf den Epycs eingeholt und das sah vom Preis-Leistungsverhältnis sehr interessant aus.

Gibts Baikal nicht mehr? Das war doch afaik auf PHP basierend.

False wrote:

Ja bringt aber nichts, da die Ip des Servers ja gesperrt ist nicht die Domain.

Das dachte ich ja auch, mit der anderen Domain konnte ich aber Problemlos senden, IP/Hostname/PTR vom Server war gleich geblieben. Absendedomain wieder geändert und es gab og. Fehlermeldung.

Hast du noch eine andere Domain von der du versenden könntest?

Es wird noch kurioser: Verwende ich eine 10 Jahre org-Domain als Absende-Domain, geht die Mail durch. Mit einer zwei Tage alten .email-Domain nicht. Dann passt die Fehlermeldung ja kein Stück.

Aber hallo.

Da schickt man ihnen

und kriegt diesen *$%$ als Antwort:

Quote

I do not see anything offhand that would be preventing your mail from reaching our customers.

You may be able to find additional information on common delivery questions at the Outlook.com Postmaster Site found at https://mail.live.com/mail/postmaster.aspx I would like to highlight some key areas that I believe are appropriate to your company.

Oah, diese Flitzpiepen.

Quote

We have completed reviewing the IP(s) you submitted. The following table contains the results of our investigation.

More information needed

194.59.205.xx/32

We were unable to identify anything on our side that would prevent your mail from reaching Outlook.com customers.

Ja, wenn sie gleich das /22 blocken, dann finden sie die auch nicht.

Achja, das ewige Leid mit Microsoft und Konsorten. Auf der mailop-Mailingliste war nun auch ein Fall, wo jemand bei SDNS und dem ganze Geraffel angemeldet war und trotzdem seine Mails geblockt werden. Zugleich liest man dann von Fällen, wo Amazon's abuse-Adressen mit "user unknown" bouncen.

phisigma wrote:

Wie sieht es mit Yahoo und GMX aus? Dort hatte ich Probleme …

Mit Shared Webhosting oder eigenem Server?

Danke für deine Erläuterungen!

H6G wrote:

Es wird dem darunterliegendem Storage mitgeteilt, dass der Block anderweitig beschrieben werden kann.

Mitlerweile gibt es ja zwei Defragmentierungsbegriffe bei Netcup.

Also ist der Speicherplatz nicht "fest" allokiert wie beispielsweise wenn man einer VM ein LV zuweisen würde?

Worin unterscheiden sich die beiden Defragmentierungsbegriffe?

H6G :

Danke für den Link. Ich meine hier mal gelesen zu haben, dass durch die BLKDISCARD-Fähigkeit von virtio-scsi ein trim quasi eine "Defragmentierung" des darunterliegenden Storage durchführen würde - bzw das, was im SCP unter "Defragmentierung" verstanden wird. Ist dem so?

Mal über mdbox mit Komprimierung nachgedacht?

Das sind eigentlich nur 20 User oder so, aber von manchen Usern wurde die IRC-Bridges etc genutzt, was vermutlich den auch den Ressourcenbedarf erhöhte. Und ein Arbeitskollege erzählte, dass er mit seiner Synapse nur den @matrix@matrix.org-Raum joinen konnte, wenn er vorher seiner VM mehr RAM gab

Wir haben für unsere Freifunk Community eine Synapse laufen, als föderierte Instanz. Wenn dann User anfangen, gut frequentierte IRC-Channels über Gateways zu benutzen, kommt irgendwann ein Ressourcenproblem. tldr; Die Instanz braucht momentan ~10GB RAM und die psql DB hat 18GB.

Heise meldet neue Sicherheitslücken für Intel: https://www.heise.de/security/…en-betroffen-4039302.html

Besonders "hübsch":

Eine der Spectre-NG-Lücken hat nach Ansicht von c't jedoch ein wesentlich höheres Bedrohungspotenzial als die bekannten Spectre-Lücken – sie lässt sich über die Grenzen virtueller Maschinen hinweg für Angriffe ausnutzen. Angreifer könnten ihren Schadcode in einer virtuellen Maschine ausführen und von dort aus das Wirtssystem attackieren.

Hier lieb das Update ohne Probleme durch, VM läuft wieder und vom Durchsatz her ist auch alles schick. Bei uns in der Firma stehen gerade deswegen auch Updates dutzender VMs/VMHosts an, von daher mal eine große virtuelle Kanne Kaffee an das Netcup-Team für eure Mühen.