Mit x86 ist die CPU-Architektur gemeint, als Unterscheidung zu ARM.
Alle netcup-Produkte sind 64bit, immer schon.
ThomasChr Hier z.B. in der Navigation oder auch im SCP…
Mit x86 ist die CPU-Architektur gemeint, als Unterscheidung zu ARM.
Alle netcup-Produkte sind 64bit, immer schon.
ThomasChr Hier z.B. in der Navigation oder auch im SCP…
Und man sieht Antworten auf Posts von fremden Instanzen womöglich nicht bzw. stark verspätet. Dieses Problem ist bei größeren Instanzen oftmals nicht so stark ausgeprägt, weil die automatisch mehr "mitbekommen".
Docker ist von Mastodon nicht dokumentiert und wird nur von der Community zusammengehalten (mehr oder weniger). Wenn du da Probleme hast, bist du komplett auf dich allein gestellt. Absolut nicht zu empfehlen, hatte das auch schon durch ist eine Katastrophe.
Danke für den Hinweis! Dann nehme ich alles zurück und behaupte das Gegenteil.
Dann war meine Abneigung ggü. Docker vielleicht doch nicht so schlecht bei Mastodon.
cadeyrn Ich habe hier übrigens ein paar öffentliche Notizen für Debian. Das ist aber noch am Stand von Mastodon 4.1, ich muss irgendwann upgraden…
Grundsätzlich wäre eine eigene Instanz natürlich auch interessant, allerdings fürchte ich, dass der Aufwand das übersteigt, was ich zeitlich aufbringen kann. Aber aus Interesse, macht das jemand, vielleicht sogar auf einem Netcup-Server? Wie groß ist da euer Aufwand in der Wartung (Updates etc.)?
Ich betreibe seit 2022 eine eigene Instanz, hauptsächlich für mich selbst. Ursprünglich auf einem VPS 200 G10s, aber der hatte auf lange Sicht einfach zu wenig RAM und Speicherplatz. Seit alles auf einem VPS Karneval 2020 läuft, ist das wesentlich entspannter und macht keinen Stress mehr.
Der Wartungsaufwand hält sich absolut in Grenzen. Da ich bei Mastodon aber nicht auf Docker setze und möglichst ohne zu viele Fremdquellen auskommen möchte, braucht es bei Major/Minor Upgrades von Mastodon teilweise mehr Planung, was die Abhängigkeiten angeht. Meistens habe ich das gleich mit einem Debian Dist-Upgrade verbunden. Wenn man hingegen Docker nutzt, muss man sich darüber wahrscheinlich keine Gedanken machen.
Wenn Du kein zusätzliches IPv6-Subnetz hast (das direkt geroutet wird), brauchst Du wahrscheinlich einen NDP-Proxy. Siehe ip -6 neigh add proxy …, bzw. falls es viele Adressen sind z.B. ndppd.
Die Live-Migrations-Einträge im SCP sind übrigens wieder weg
Und auch die Einträge vor der Serverübernahme sind wieder unsichtbar. Meine Vermutung war wohl richtig, dass das nur ein Bug mit der Filterung war.
/cc m_ueberall
Nur wegen des Traffics oder war hier die Besonderheit?
Besonders wegen des 1,5 TB großen Speichermediums.
War damals zwar keine SSD, aber die braucht man nicht immer.
Zum Glück habe ich zwei von den 1000er Modellen in der Plus-Variante.
Vom VPS Ibiza bzw. VPS 2000 G8 Plus landen auch nicht viele Systeme in der Tauschbörse.
Irgendwie bereue ich es gerade ein wenig, dass ich den damals wieder hergegeben habe.
How will they return my money?
Afaik only via bank transfer (SEPA)
Wenn der Verdacht besteht, dass das System kompromittiert ist, und der Angreifer womöglich bereits Rootrechte besitzt (die genannten Dateien kann man als normaler User nicht erstellen/bearbeiten), würde ich anders vorgehen:
Danach kann man die Inhalte des Speichermediums immer noch in einer abgeschotteten Umgebung analysieren. Oder man startet den betroffenen Server im Rettungssystem und sieht sich dort alles an. Aber auch im Rettungssystem gilt: Keinesfalls in das Speichernedium chroot'en oder irgendwelche Binaries davon ausführen! Die könnten alle verseucht sein…
Aber was soll die Migration von n437a nach n437a? Im Kreis migriert?
Hübsch auch eine Migration nirgendwohin:
Ich glaube die Details beim Abschluss sind ein Blödsinn, da stehen immer die gleichen Systeme, auch bei mir. Beim Start der Migration sieht man die korrekten Werte.
Gerade bei Abschaltung eines alten Servers gesehen: Mittlerweile werden dort auch Live-Migrationen protokolliert (war mir bislang entgangen); gefällt mir!
Ich kann mir fast nicht vorstellen, dass so viele Details wirklich beabsichtigt waren.
Denn auch das macht mich stutzig: Bei von anderen Kunden übernommenen Produkten wurde das Protokoll zuletzt erst ab dem Zeitpunkt angezeigt, seit man den Server im eigenen Account hatte. Nun ist plötzlich wieder alles sichtbar. Das wirkt eher, als ob da eine interne Filterung kaputt ist. Aber immerhin weiß ich nun, wo 80% meiner VMs laufen und dass keine auf dem gleichen Hostsystem liegt.
Das Format der Hostsysteme ist bei mir übrigens überall nXXXX, wobei XXXX ein hexadezimaler Wert ist. Nur nicht bei einem Wiener VPS, der läuft auf xaas-kvmNNNNNN. Kann das jemand mit einem System in AT/NL/US bestätigen?
Ich bin mir aber auch ziemlich sicher, Netcup ist sich dessen bewusst, wieso sollte Wien sonst auch günstiger sein.
Vielleicht weil alle Kosten, die mit dem Betrieb eines RZ verbunden sind, dort womöglich günstiger sind? Außerdem befindet sich der Wiener Standort im Besitz von Anexia (DATASIX Rechenzentrumsbetriebs GmbH), bei den anderen weltweiten Standorten wird Anexia wahrscheinlich größtenteils in fremden RZ eingemietet sein.
Wir?
Ok, nur ihr!!!!!111elf
Und lässt sich am Beitragszähler eines Users ableiten, wie sehr dieser eine Mitschuld trägt?
Wenn dann nur an der Anzahl der Posts in den letzten paar Jahren. Wer da wohl führt? Vielleicht Bud?
(SCNR Bud!)
Ich hätte interesse und überlege ernsthaft ob es sich lohnt einen Bot zu bauen der auf jeden Kommentar im Längsten Thema antwortet um bis morgen 20:00 Uhr noch Beiträge zu sammeln
Wir haben schon Claudia vergrault, willst Du Lars/Christina/Bianca/Esther auch noch verlieren?
Bitte nicht!
Kann man bei "DNSSEC Status" den Haken setzen, oder eher nicht?
Aktuell würde ich ganz klar NEIN sagen, wenn Du Probleme vermeiden möchtest.
Die Bugs sind meiner Erfahrung nach noch nicht behoben. Eine Test-Domain hat's vor wenigen Wochen wieder erwischt...
Wenn Du DNSSEC wirklich brauchst, nimm externe Nameserver. Zum Beispiel die von deSEC e.V.
Ist das ein Server mit zugebuchtem bzw. zubuchbarem Local-Block-Storage?
Ich habe es mit zwei relativ alten Systemen getestet, bei denen es gar kein LBS gibt: VPS 1000 G8 Plus und ein RS X-Mas 2016.
Bei ZFS funktioniert ein normales fstrim nicht.
zpool trim default sollte helfen
Danach ein wenig abwarten, bis es fertig ist. Siehe Ausgabe von: zpool status -t default
Schon mal probiert, ob die Subnetze der genannten Firmen von Deinem Server aus erreichbar sind?
Meine erste Anlaufstelle wären da A/AAAA/MX Records und dann einfach ping/traceroute anwerfen. Falls Du noch Received-Header aus früheren E-Mails hast, wäre das natürlich auch einen Test wert.
Vielleicht sieht man so schon irgendwelche offensichtlichen Routingprobleme o.ä.
Klappt aber nicht mit einem Webhosting, oder?
Doch, das klappt mit nahezu jedem SSH-Zugang.
Und zur Not gibt es auch noch curlftpfs für FTP(S), aber das ist wahrscheinlich deutlich ineffizienter.