Posts by saremox

LMGTFY

pasted-from-clipboard.png

Quote from mainziman

od. auch nicht; ein ARM-Core ist was anderes als ein x86-Core

https://www.elektronikpraxis.d…32cd605f35d17648310a6ca7/

(Hauptunterschied: RISC vs. CISC)

Es gibt durchaus workloads die mit der ARM64 Befehlssatz, bei ähnliche Core/Thread Anzahl durchaus mithalten oder sogar schneller sind als x86 cores. Die Generelle aussage, dass ARM/RISC grundsätzlich langsamer ist als x86/CISC ist meiner Meinung nach nicht mehr genau genug.

Hier einmal kurz ein Geekbench von paar x86/arm kisten die ich hier so herumstehen habe. Natürlich waren alle Kisten nicht nackt und da lief Monitoring und paar andere Dienste drauf. Würde also sagen das die nicht ganz genau sind und bei den VPS ist es ja auch immer die Frage wie laut die Nachbarn sind.

Also zumindest laut Geekbench 6 kann ein arm64 core gar nicht mal so schlecht mit einen RS G9.5 core mithalten. Wichtig ist natürlich das man trotz aller tollen Benchmarks immer vorher schaut ob der spezifische Workload auf der Architektur läuft oder überhaupt eine ARM64 binary gibt.

Zumindest für die Neoverse N1 hat z.B. meines Wissens Amazon auch einige patches für PHP submitted damit es performanter läuft. (Die Graviton nutzen in einer Generation auch die Neoverse N1 cores meines Wissens).

Also fände kleine ARM64 kisten mit 2 vcores durchaus interessant als Gateway server für Haproxy und SSL termination. Sind zumindest deutlich fixer als die VPS nano die ich gerade dafür verwende.

Quote from H6G

Im SCP? => Support

Edit:
Stimmt denn der Serverstandort mit dem VLAN Standort überein?

Jop im SCP und Standort ist bei allem NUE. Hab sogar für Debug zwecke ein free vlan NUE hinterher bestellt. Auch mit den frischen VLAN sind alle 3 nicht startbar. Mal gucken evtl. bemühe ich am Tag den Notfall support falls ich noch keine Antwort auf mein E-Mail Ticket bekomme. Würde schon sehr gerne das Wochenende zum aufsetzen benutzen. Wollte aber niemand jetzt um die Uhrzeit wach klingeln.

Quote from Paul

Das halte ich daher in der Praxis für keine gute Idee.

Effektiv wird das aber z.B. bei AWS ELB gemacht. Wenn dort eine eine von den 3 Endpunkten für maintenance rausgenommen wird, kommt eine neue IP dazu. Deswegen soll man da mit einen CNAME arbeiten statt die A Records vom LB zu setzen. Aber wahrscheinlich sperrt man dann alle mit den faulty DNS resolvern aus.

Nachteil an der Failover IP ist halt auch, dass man kein DNS Load Balancen zwischen seinen Servern dann hat. Außer man bucht sich direkt 2-3 Failover IPs auf denen man dann auflöst und dann im Failover fail ein Server 2 IP zugeordnet hat.

Bei mir gings auch flott

Nur leider gehen bei allen 3 das VLAN nicht. Sobald ich ein VLAN NIC hinzufüge bekomme ich den Generischen Fehler dass etwas nicht geht

Wenn ichs VLAN wieder entferne geht's sofort wieder. Evtl möchte mir Netcup auch nur sagen das ich schlafen soll anstatt server einzurichten

Quote from User_unknow

Wenn man einen Standort bei der Bestellung bucht, sollt der auch korrekt sein. Schliesslich wird manchmal standortbedingt ein Aufpreis verlangt.

GeoIP Dienste Standort != Realer Standort. Je nachdem wann der Dienst auf den du Zugreifen willst zuletzt seine GeoIP Datenbank aktualisiert hat kann es auch wochen Dauern bis die den Korrekten Standort haben. Das kann Netcup hier nur bedingt beeinflussen (insbesondere, wann die Diensteanbieter ihre Kopie Aktualisieren).

Quote from Janko

ungünstig konfigurierte Spam-Prüfung.

Die Erklärung, warum es mit Off-the-shelf MTA und Anti Spam Lösung zu 5-6 Sekunden kommen kann wurde bereits mindestens einmal gegeben: Backscatter. Dadurch das die E-Mail beim MTA erst nach der Spamprüfung in die Queue eingefügt wird, verhindert man bei einer Positiv Meldung (E-Mail ist Spam) das versenden einer Mailer-Daemon E-Mail an den Absender. Es ist auch der bevorzugte Weg, dass bereits beim Enqueue sehr viele Checks passieren, gerade wenn man die Postfächer auch für den Versand per PHP/JS etc. pp. nutzt. Dadurch kann die Anwendung nämlich auf den Misserfolg reagieren.

Ich musste schon einmal mit einen MTA arbeiten, der genau das nicht gemacht hat. Der hat fröhlich alles angenommen, nur um dann schöne Mailer-Daemon Nachrichten zu verschicken, dass wegen irgendwas die E-Mail nicht versendet wird. Schön blöd das für die Laravel Anwendung dann die E-Mail als "Erfolgreich Versand" markiert waren und es deshalb kein Retry dann gab ...

Lösung für dein konkretes Problem mit Thunderbird:

Es ist btw, in Thunderbird durchaus möglich das "Versenden" in den Background zu packen:

pasted-from-clipboard.png

Das ist default auf false, dass es noch known issues geben soll: https://wiki.mozilla.org/Thund…estPlans/SendInBackground.

Quote from Ecki

Mein ARM VPS 2000 wurde nicht verschoben aber die Disk IO Werte sind auch nicht besser

Hab gemerkt, dass der echt langsam geworden ist.

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda4):

---------------------------------

Block Size | 4k (IOPS) | 64k (IOPS)

------ | --- ---- | ---- ----

Read | 8.03 MB/s (2.0k) | 37.14 MB/s (580)

Write | 8.07 MB/s (2.0k) | 38.24 MB/s (597)

Total | 16.11 MB/s (4.0k) | 75.39 MB/s (1.1k)

| |

Block Size | 512k (IOPS) | 1m (IOPS)

------ | --- ---- | ---- ----

Read | 54.56 MB/s (106) | 99.02 MB/s (96)

Write | 59.22 MB/s (115) | 110.48 MB/s (107)

Total | 113.78 MB/s (221) | 209.50 MB/s (203)

Display More

Wenn ich diese Werte mal bei dem Großen A in den Rechner einwerfe bekomme ich horrende Preise. Ja man sollte jetzt Netcup nicht mit dem Großen A vergleichen, da gibt es halt die gute Cloud Tax drauf. Aber ich finde das hilft sich mal eben kurz auch in seiner Erwartung zu erden:

Block Storage Cost: 97.48 USD
4,000 iops - 3000 GP3 iops free = 1,000.00 billable gp3 iops

Max (1000.00 iops, 0 minimum billable iops) = 1,000.00 total billable gp3 iops

1,000.00 iops x 1.00 instance months x 0.006 USD = 6.00 USD (EBS IOPS gp3 Cost)

Block Storage IOPS Cost: 6.00 USD
250 MBps - 125 GP3 MBps free = 125.00 billable MBps

Max (125.00 MBps, 0 minimum mbps) = 125.00 billable throughput (MBps)

125.00 MBps / 1024 MB per GB = 0.1221 billable throughput (GBps)

0.1221 GBps x 1.00 instance months x 48.7424 USD = 5.95 USD (EBS gp3 throughput Cost)
97.48 USD + 6.00 USD + 5.95 USD = 109.43 USD (Total EBS cost)

A Elastic Block Storage (EBS) total cost (monthly): 109.43 USD

Ja Klar ich habe beim Großen A dann diese Performance (4000 IOPS ; 250 MB/s) zugesichert. Aber Bei Netcup Zahlst du gerade für 1 TB block storage ca 12,60 € (regulärer Nürnberg Preis) und hast da dann auch direkt Network, CPU und memory einfach noch mit dabei. Beim Großen H bezahlst für 1 TB Block storage auch direkt 50+ € ohne CPU,Memory,Network.

Ich finde für den Preis den ich hier bei Netcup bezahle bekommen ich sehr gute Performance. Über meinen Job weiß ich das ich bei OnPremise, Azure und Amazon für die gleichen Specs ( RS4000 + 3x VPS 3000 ARM) wahrscheinlich im Bereich von 500-1000+ € / Monat wäre.

Ohne jetzt Netcup hier zu sehr in Schutz zu nehmen, frage ich mich ja schon ein wenig was "von Uns Kunden" hier überhaupt die Erwartungshaltung ist bei z.B einen VPS 1000 ARM G11 für 7,29 € (Nürnberg).

Wir können uns ja einmal den Spaß machen nachzurechnen was für eine IO Leistung man da so erwarten sollte:

Micron 7400 PRO - 1DWPD Read Intensive 7.68TB, 512B, 2.5" / U.3 / PCIe 4.0 x4 - € 1179,60

For the sake of argument als RAID 10 (4 Stück / 2 => 15360 GB Kapazität) -->

Dann machen wir die jetzt mal voll mit VPS 1000 ARM. Damit da noch Sicherheitspuffer ist würde ich mal tippen das Netcup hier die "verkaufte" Kapazität irgendwo zwischen 70-90% liegt --> 80% it is => 12288 GB

Da bekommst knapp 48 VPS 1000 ARM (288 vCPU, 384GB memory) drauf. Vom derzeit von mir beobachten Steal auf meinen VPS 3000 kann die CPU Überbuchung von Faktor 2-3 gut hinkommen. (Basis Ampere Altra 128 CORE CPU).

[EDIT]

Kurzer Napkin Math Einschub:

Gesamtkosten für 4x die NVME => 4.716 €
Aufgeteilt auf 48 VPS => 98,25 €

Wenn man hier jetzt "nur" die NVME kosten reinbekommen müsste würde der VPS1000 für mindestens 13,5 Monate bezahlt werden. Und dann ist CPU, Memory, Netzwerk, Strom etc. pp. noch nicht bezahlt. Ist also sowieso schon ein guter Kampfpreis

[/EDIT]

Jetzt teilen wir die IO mal, unter der Annahme das wir den NVME link "Perfekt" saturieren, fair unter allen 48 auf:

Klingt erst mal ganz ordentlich oder? Das ist aber Ideal Performance von den NVME's, und dann natürlich auch nicht gleichzeitig lesend und schreibend.

Jetzt muss ich ehrlich sagen, ich kann mir vorstellen, dass sich hier einige auch denken "Wenn ich für 8GB memory bezahle, nutze ich diesen auch für meine Anwendung". D.h. je mehr Kunden/Server auf dem Host system sind, welche hohe Major Page fault werte haben, desto mehr Disk Thrashing passiert auf dem Hosts , dadurch dass der Linux Kernel bei Memory Knappheit mit/ohne SWAP zuerst anfängt die CODE pages zu entladen. Wenn das Programm im Programmfluss wieder den Code braucht muss das erst wieder geladen werden. Wenn man sehr auf Kante fährt wird das natürlich sehr schlimm und kann schon einmal Richtung 50-100MB/s gehen. Je nachdem was man so auf sein System laufen hat. Wenn jetzt Kunden Swap haben ist das natürlich ähnlich.

Jetzt wird so ein ARM host wahrscheinlich nicht nur voll mit VPS 1000er sein, sondern Netcup wird hier wohl versuchen Große und Kleine VPS sinnvoll zu verteilen und es wird auch nicht jeder Guest zu jeder Zeit seine IO Performance nutzen.

Aber wie bereits schon erwähnt die oberen Werte sind Ideal Werte unter den perfekten Bedingungen (IO Queue auf dem NVME controller voll). Das hängt auch davon, ob Netcup hier noch ordentlich RAM Reserve hat um die "HOT" teile der VM Disk in memory zu cachen (Das Würde das Disk Thrashing deutlich reduzieren).

Wir können natürlich den ganzen Spaß nochmal mit 4TB nvmes machen und dann 8 Stück. Da würde die Read Performance im RAID10 natürlich besser aussehen. Aber der Faktor zwischen Read/Write kam jetzt einigermaßen gut hin mit den 8TB Geräten, zu den FIO tests die ich hier bisher immer gesehen habe.

Dass das wohl überwiegend von noisy Nachbarn kommt kann ich mir bei im Monitoring sehen. Als mal "wieder" ein ARM 3000 ausgefallen ist war die Disk IO auf einmal so gut:

pasted-from-clipboard.png

Danach ging die IO time von der Disk die ich für einen CEPH Cluster verwende nach einen Tag ca wieder hoch. (Sehr viel RAM Cache und aktuell nur Datengrab. Deswegen überraschen mich die hohen IO Time werte doch etwas. Peak Read/Write liegt bei 10MB/s )

Off-Topic:

Spannend ist auch das der Ausfall in meinen Monitoring länger dauerte als in der E-Mail von Netcup:

Ausfall Start: 3:08 UTC - Netcup: 04:58:30 UTC
Ausfall Ende: 5:17 UTC - Netcup: 05:31:53 UTC

Aber gut dafür ist es ein Ceph Cluster. Gemerkt habe ich den Ausfall nicht. War eine Ruhige Nacht ohne Klingeln

Und nochmal zur Vollständigkeit, Metriken von einen RS 4000 G9.5 und einen VPS 200 G10s. Bei beiden ist der Steal deutlich niedriger. Der VPS 200 G10s sammelt überwiegend von meinen anderen "nicht kubernetes" kisten ein und Macht ein paar HTTP checks. Auf der RS 4000 lief schon Game server, Video Streaming, Video Encode und anderes.

Daten sind von den letzten 6 Monaten:

RS 4000:

VPS 200

Aus meiner bisherigen Erfahrung hier bei Netcup würde ich mich den Vorredner anschließen:

Webhosting oder Sachen die nicht Latenz kritisch sind können gerne auf ein VPS (ARM64 / x86-amd64). Für Gaming oder Latenzkritische sachen (Voicechat/Videochat) würde ich lieber einen entsprechend dimensionierten RS nehmen. Wenn man sich einen RS holt und da dann mixed sachen drauf laufen lässt, kann man (wenn man Zeit und Lust hat) dann noch mit entsprechenden cgroups und prioritäten dafür sorgen das ein Voiceserver (mumble/teamspeak) immer als ersten CPU abbekommt, danach z.b. ein Game server und evtl begleit webserver oder anderes dann als letztes.

Habe 3x VPS 3000 ARM G11 als ein Kubernetes Cluster. Im Screenshot einmal der CPU Steal über die letzten 7 Tage. Da ich da überwiegend nur Burst Workload drin habe merkt man das nicht wirklich. Steal geht auch nicht stark hoch wenn ich da mal ein Video Transcode die CPU auf 50-80% laufen lässt.

Y-Achse ist Steal% der jeweiligen VPS VM

Quote from tuxproject.de

Hast du denn auch nur ein einziges Gegenargument für meine ausführliche Begründung, warum Docker bestenfalls überflüssig ist, aufzubieten oder möchtest du es beim virtuellen Ansabbern meiner Person bewenden lassen? Ich frage für die Einschätzung, wie ernst dich irgendjemand hier nehmen sollte.

Sorry ich habe mich nur versucht deinen bisherigen Umgangston gegenüber den anderen Teilnehmern anzunähern.

Quote from tuxproject.de

Übersetzt: "Es löst das 'Problem', dass Entwickler schlechter Software zu faul für Unittests und/oder CI sind."

Gerade in CI Umgebungen sind Container echt Gold wert, da Sie mir erlauben eine System Umgebung reproduzierbar immer wieder neu aufzubauen für meinen Integration Test. Auch kann ich hier dann sehr einfach meinen Unittests gegen x verschiedene RDMS (mariadb, postgresql, mysql etc. pp.) oder andere Dependencies testen. Also spätestens hier zeigt sich eine Starke von Containerisierung. Ja klar dass ganze bekomme ich auch hin indem ich über Ansible/Puppet jedes mal eine VM hochziehe oder ein VM Snapshot boote. Ist hier also auch eine gewisse Frage des, was ist einfacher aufzusetzen mit der jeweiligen CI System Umgebung. Habe ich ein Gitlab mit Gitlab-Ci sind container deutlich einfacher zu handhaben. Benutze ich eine Jenkins Farm die direkt in meine VMWare cluster, VMs für die cI test hochfahren kann, ist evtl das die bessere Wahl.

Quote from tuxproject.de

Übersetzt: "Es stellt eine unnötig komplizierte Infrastruktur bereit, die sich mit weit weniger RAM und Plattenplatz auch mit chroot und shared libraries abbilden ließe."

Siehe oben. Das Szenario ließe sich wahrscheinlich nicht einfach so mal eben 1:1 abbilden. Ja den Punkt kann ich dir geben die Abstraktion mit Docker sorgt durchaus für einen gewissen RAM overhead. Hier muss man abwägen ob die sonstigen Vorteile diesen Nachteil von mehr RAM und Platte weg machen. Hier ist aber die Frage, ob jeder immer die Lust hat die Anwendung in ein Chroot einzusperren. Evtl ist hier das Tooling besser geworden. Aber ich kann mich noch erinnern dass es sehr aufwändig war eine Anwendung im Chroot lauffähig zu bekommen (insbesondere wenn diese sich nicht selbst chrooten kann). Auch Chroot scheint hier nicht die versprochene Sicherheit zu bieten: https://blog.pentesteracademy.…a08df5c28?gi=0aa1fd1ff592

Ich empfinde es als deutlich weniger Aufwand z.b. ein Redis/Mariadb etc. pp. in einen Docker container ohne privilegien laufen zu lassen. In meiner Docker compose / Kubernetes Deployment sind das nur wenige zeilen konfiguration und der Container läuft nicht als root, hat ein Read-Only FS (außer das Directory mit den Daten). Dropt noch vor der Ausführung sämmtliche Capabilities und ich kann durch Network Policies (Kubernetes) ganz genau sagen welche Anwendung überhaupt auf Netzwerkebene zu meinen Redis/Mariadb/Postgres container kommt. Auch kann ich direkt Ausgehend es so blockieren das es nicht möglich ist vom Redis/Mariadb/Postgres überhaupt ins internet zu kommen. Damit habe ich eine sehr feine isolation möglichkeit. Sowas lässt sich bestimmt auf einen System lösen indem man statt tcp socket, unix sockets nimmt und dann über default Dateirechte oder sogar ACL das ganze einschränkt.

Aber spätestens wenn ich sowieso auf mehr als 1 System Skalieren möchte zwecks Ausfallsicherheit und/oder Lastverteilung bringt gerade die Containerisierung in Zusammenspiel mit Kubernetes oder Docker Swarm (bisher nicht getestet, also keine Ahnung wie gut das geht) doch gute Vorteile in der Handhabung der Komplexität. Ja hier verliere ich wieder Effizienz im Sinne von RAM, CPU und Platte. Ist also eine Frage wie viel mich das mehr kostet und wie viel mir meine Zeit wert ist.

Quote from tuxproject.de

Übersetzt: "Container ignorieren Sicherheitspatches des Betriebssystems, aber das macht ja nichts, weil man mit ihnen auf die viel besseren Sicherheitspatches von Drittanbietern angewiesen sein kann." (?)

Also die meisten Container die ich so im Einsatz habe basieren auf Ubuntu, Debian oder Alpine. Manche bestehen sogar einfach nur aus der glibc und einer statisch kompilierten Go Binary. Für die meisten Container kann ich mir sogar das Dockerfile holen und den Container mit einen docker build selber bauen. Natürlich muss man hier sein Patch Management anpassen. Ein einfaches Unattended Upgrade über Apt (Ubuntu / Debian) mit Auto restart um 4 Uhr morgens tut es da dann natürlich nicht mehr. Aber auch da gibt es Lösungen. Man kann hier mit clair die Container scannen lassen welche man im Einsatz hat und bei gefundenen Sicherheitslücken seine Incident Prozesse starten. Falls es ein Update bereits gibt spielt man das auch bei Docker container einfach ein. Falls es kein Update gibt muss man eine andere Mitigation wählen, hier hat man evtl bei Container mehr Werkzeuge zur Verfügung oder man hat wie bereits oben genannt bereits sehr viel hardening betrieben, dass eine Sicherheitslücke gar keine Relevanz hat für das eigene Container Geflecht/System.

Quote from tuxproject.de

Übersetzt: "Container wie Docker erfinden Solaris-Zonen, FreeBSD-Jails und/oder einfaches UNIX-chroot mitsamt loopback device noch mal neu, nur halt schlechter."

Weil Linux das letzte System war, das noch keine mindestens gleichwertige Lösung im Kernel hatte?

Wie gesagt ich bin hier wahrscheinlich nicht aktuell, aber das oben von mir genannte mit CAP DROP, Read-Only FS, Netzwerk Isolation kenne ich so von einen chroot nicht. Evtl können das die FreeBSD-Jails, habe ich aber selber noch nie verwendet. Aber hier Grundsätzlich zu sagen, Docker/Container wäre schlechter als ein einfacher UNIX-chroot ist tatsächlich falsch. Evtl gibt es da tools welche einfach und so convienent wie Docker/Container network namespace einrichten können für einen Prozess der im Chroot läuft. Ob das dann nicht aber eigl schon fast wieder ein Docker/Container mit extra manual steps ist?!

Wir haben jetzt aber auch das Ganze Argument ohne Apparmor / SELinux gemacht. Apparmor könnte ich sowohl auf meinen System verwenden um meine Prozesse nochmal mehr abzusichern, als auch im Container. (Kubernetes hat gerade erst den Support in die Beta graduated). Ich persönlich habe aber bisher noch nicht wirklich Apparmor profiles oder SELinux profiles geschrieben und könnte jetzt nicht mit zuversicht sagen, dass ich in ähnlicher Geschwindigkeit damit eine Software abhärten kann, als ich es aktuell mit meinen defaults Konfigurationen für Kubernetes und/oder docker compose ( docker compose probiere ich mich gerade in meiner Freizeit ) tun kann.

Ich gebe dir vollkommen Recht, dass wenn ich nur 1 Maschine habe, es sehr wahrscheinlich Signifikant weniger Resourcen braucht, als wenn ich den selben Software Stack mit Docker Container aufbaue. Aber der richtige Vorteil von Container kommt meines Erachtens dann zum Vorschein wenn ich n Maschinen habe auf denen ich aufgrund von Lastverteilung und Ausfallsicherheit die Anwendung verteilen möchte, und diese mit Network Namespaces und Cgroups isoliere und dafür sorge, dass diese andere Prozesse, bei Fehlfunktion oder überlast, nicht mit runter reißen können (CPU limits, memory Limits in den cgroups).

Ich kann aber auch Leute verstehen, die einfach nur den Docker container vom nächsten fancy Tool über docker compose deployen wollen und der Traefik terminiert dann das TLS und leitet dann mithilfe der Label am Container automatisch den HTTP traffic zu der neuen fancy node.js/python/ruby Anwendung. Es ist Convienent wenn man neue Software schnell mal ausprobieren möchte oder nur mal für 1-2 Wochen hostet für ein Event oder sonst was und danach wieder ausmacht.

Quote from tuxproject.de

Sobald Docker für die auf meinen Servern laufenden Betriebssysteme zur Verfügung steht, haben wir da vielleicht eine andere Diskussionsgrundlage. Tut es halt nicht. Also die Kurzfassung ist: Immich will nicht, dass Menschen, die sich etwas besser mit Servern auskennen, es nutzen. Wird vermerkt.

We get it: Du bist der allerbeste. BSDs sind das wahre Betriebssystem. Alle anderen die GNU/Linux (Debian, Ubuntu, Gentoo etc. pp) nutzen haben keine Ahnung/Skill Server zu betreiben. Convience Argumente für Docker Akzeptierst du nicht, sondern machst dich darüber lustig. Jeder Software Entwickler der nicht eine riesige Matrix an Betriebssystemen mit jeden Commit über UnitTest und CI testet ist ein schlechter Developer. Aber am wichtigsten ist es natürlich das die Software für dein BSD funktioniert, wenn nicht dann ist es ein schlechter Developer. Bloß keine anderen Herangehensweisen zulassen, ohne diese nicht im selben Atemzug nieder zu machen. Good Job.

Moin Flaschensammler,

erst einmal Geiles Hobby was du dir gesucht hast. Egal was andere jetzt dazu sagen lass dir das nicht kaputt machen. Wichtig ist hier aber zu verstehen woher die Ratschläge, mit einer lokalen VM erst einmal Basics zu lernen bevor man einen VPS/Root Server mietet, kommen:

Debian und Ubuntu haben zum Beispiel die Unangenehme Eigenart bei der Installation von Diensten (PHP, Apache, Cups etc. pp.) diese direkt über Systemd (Das Herzstück deines Linux Betriebssystem was andere Service für dich automatisch startet und diese teilweise sogar überwacht und automatisch neu startet falls diese abstürzen/crashen) zu aktivieren, sodass diese automatisch direkt gestartet werden in ihrer Standard Konfiguration.

Ich Bringe hier Cups als Beispiel an, da genau bei dieser Software erst vor kurzer Zeit eine Lücke gefunden wurde, die es mit sehr wenig Aufwand möglich machte den Computer ( Auf dem Cups läuft ) dinge tun zu lassen, die der "Besitzer" von eben jenen nicht selber wollte. Die Bewertung ob es in der freien Wildbahn einen erfolgreichen Einbruch über diese Lücke gab erspare ich mir hier. Aber Fakt ist das ein Sicherheitsforscher feststellen musste das im Bereich 100.000 Computer einfach offen im Internet diesen Dienst hatten. D.h. dort hat keine Firewall oder andere Sicherheitsmaßnahme den Zugriff von Außen blockiert. Und das ist ein Problem!

Also niemand (ich hoffe) möchte dir dein neues geiles Hobby hier schlecht reden, verbieten oder dir absprechen es auszuüben. Aber bitte nehme dir die Ratschläge die in den teils harsch formulierten Beiträgen hier dennoch zu Herzen. Du solltest dir wirklich erst einmal anschauen wie die Firewall deines neuen Linux Servers funktioniert und wie du diese z.b. von deinen Privaten Rechner aus testen kannst.

Ich bin immer ein Freund davon, bevor ich eine Abstraktion (UFW) nutze mindestens einmal mich einzulesen wie das darunter liegende Funktioniert (nftables / iptables):

• https://www.englert.one/iptables-tutorial
• https://wiki.ubuntuusers.de/iptables/

Damit solltest du zumindest erst einmal gelesen haben was eigentlich die Grundlage deiner Firewall bei deinen Linux Server ist. Jetzt kannst du dir einmal UFW genauer ansehen. Dies vereinfacht es für dich deutlich. Da du dich nicht mehr darum kümmern musst in welche Reihenfolge du die nftables/iptables rules definierst und wie diese direkt beim Start deines Linux Server angewendet werden:

• https://wiki.ubuntuusers.de/ufw/
• https://www.digitalocean.com/c…th-ufw-on-ubuntu-20-04-de

Hier einmal die wichtigen Basics:

• Grundsätzlich solltest du als Standard/Default Regel sämtlichen eingehenden Traffic blockieren
• sudo ufw default deny incoming
• Jetzt erlaubst du SSH
• sudo ufw allow ssh
• Schau dir einmal mit sudo ufw status an was jetzt alles an Regeln angelegt ist. Wichtig ist hier nur das du PORT 22/SSH erlaubst. Ansonsten sperrst du dich selber aus
• Jetzt kannst du UFW einschalten: sudo ufw enable
• UFW wird jetzt im Hintergrund Iptables/nftables für dich konfigurieren. Du kannst dir das Ergebnis von UFW anschauen indem du sudo iptables-save eingibts. Dann bekommst du ein Gefühl dafür wieviel Arbeit dir UFW abnimmt.

Jetzt ist es geschafft dein Server lehnt alles außer SSH ab und wie geht es weiter? Dein Problem ist jetzt, dass Angreifer evtl versuchen dein SSH zu knacken. Du müsstest bereits erste Versuche in deinen Log finden können: tail -n 200 /var/log/auth.log. Falls nicht schätze dich glücklich. Die ersten Angriffe werden aber kommen. D.h. jetzt geht es darum deinen Zugang über SSH abzusichern. Hier gibt es viele Strategien die wichtigste aber zu allererst: Nutze keine Passwort Authentifizierung:

• Wenn du putty unter windows nutzt: https://www.lancom-systems.de/…ubkeyauth_generation.html
• Weitere ergebnisse für dich zur ansicht mit teilweise guten Anleitungen wie man das ganze aufsetzt: https://www.google.com/search?…q=putty+ssh+key+erstellen

Ein weiterer Faktor der deine SSH Sicherheit erhöhen kann ist fail2ban einzurichten:

• Allgemeines zur software: https://wiki.ubuntuusers.de/fail2ban/
• Eine Anleitung für Ubuntu mit UFW: https://www.howtoforge.de/anle…l2ban-unter-ubuntu-22-04/

Das für dich wichtige ist, den SSH jail zu aktivieren. Das sorgt dafür, dass Angreifer die sich x Mal falsch einloggen erst einmal direkt gesperrt werden.

Wenn du das ganze jetzt gemacht hast: Herzlichen Glückwunsch! Du hast deinen VPS erst einmal grob abgesichert, sodass nur SSH rein darf und wer zu häufig sich am SSH schloss versucht wird geblockt. Aber hier hört der Spaß natürlich nicht auf. Du kannst dir Elaboriertere Sicherheitsmethoden ansehen oder sogar (wenn du eine FritzBox hast) über ein Wireguard VPN den SSH zugriff zu deinen Server von außerhalb ganz sperren und nur über dein VPN zum server erreichbar machen.

Wichtig ist hier aber, es gibt NIE eine 100% Sicherheit. Du kannst leider immer das Ziel sein, wo eine neue Sicherheitslücke in der Software OpenSSH selber ausgenutzt wird, um alle deine Sicherheitsmaßnahmen zu umgehen. Aber ob ein Angreifer eine solch teure Lücke wirklich an deinen VPS nutzt mag ich mal zu bezweifeln, da gibt es lukrativere Ziele im Internet.

Wie gehts jetzt weiter? Nachdem du jetzt deinen Administrativen Zugang zu deinen VPS abgesichert hast, beginnt der noch viel Spannendere und spaßige Teil. Das Einrichten von Diensten für dich oder bekannte. Sei es für Spaßige sachen (GameServer, VoiceServer), produktive (Eigene Nextcloud mit Office anyone?!) oder andere tolle Dienste. Wichtig ist aber hier bei allem: Lies dich immer ein wenig ein bevor zu eine neue Technologie verwendest. Apache Webserver? --> Google was du beachten musst wenn du den sicher betreiben willst. Mach dich schlau wie Dateirechte funktionieren in Linux ( https://wiki.selfhtml.org/wiki/Linux/Dateirechte ). Wenn du einen neuen Dienst ausprobieren willst: Schalte am bestenn immer erst einmal nur deine Eigene IP in deiner firewall frei. Ein Beispiel an einen HTTP/HTTPS server wie Apache/nginx:

• Gehe auf https://myip.wtf/ und schreib deine IP auf
• Welche Ports braucht dein Dienst? (80 und 443)
• Welches Protokoll (TCP)
• sudo ufw allow from 1.2.3.4 to any port 80
• sudo ufw allow from 1.2.3.4 to any port 443

Jetzt kannst nur du darauf zugreifen und weiter testen und/oder z.b. einen Webinstaller von Nextcloud oder Wordpress oder whatever nutzen. Ohne das jemand darüber Stolpert und es direkt ausnutzen kann.

Wenn du diese paar Sicherheitsmaßnahmen befolgst senkst du dein Risiko bereits enorm. Sicherer geht es immer. Was aber gerne viele missachten ist, dass zu deinen Sicherheitskonzept auch immer die Frage sein sollte: Wer möchte mich angreifen? Wie viele Ressourcen möchte mein Angreifer aufwenden um rein zu kommen. Wenn du dir diese Fragen stellst bist und dir das einmal angucken möchtest. Schau dir einfach die BSI sachen dazu an: https://www.bsi.bund.de/DE/The…tionssicherheit_node.html

Vorsicht aber das sind sehr dicke Schinken und gehen meist auch nur Oberflächlich mit Buzzwords ran ohne konkrete Technische Lössungen für dein Debian vorzuschlagen.

Quote from Win98SE4ever

Sehr schön geschrieben.

Für Einsteiger wäre noch ergänzenswert dass die ARM-Architektur voll ausgereift ist und stabil läuft.

Daran hat Android mit ARM-basierten Smartphones/Tablets in Milliardenstückzahl und viele Millionen Singleboard-Computer wie z.B. der Raspberry Pi auch einen Anteil als Technologietreiber.

ARM selbst wirbt mit 200 Mrd. ausgelieferten ARM-Chips (Stand 2021).

Aktuell sind es grob 7 Mrd. Chips pro Quartal.

Display More

Danke :). Hatte schon damals 2014/2015? Während meines Studiums kleine Vorträge zur ARM Architektur gehalten, weil ich die interessant fand. Da war das aber alles noch etwas holprig mit dem Software Support. Spätestens mit dem NEOVERSE N1 und den aktuellen Distros Ubuntu/Alpine/Debian merkt man den Unterschied ja wirklich nur noch bei sehr speziellen use cases und an der Performance von manchen Workloads.

Wenn man mit einen Neoverse V2 mal spielen möchte, kommt aber leider glaube ich aktuell nicht drum herum beim großen A für teuer Geld sich einzukaufen. Das ist es mir dann irgendwie auch nicht wert

Quote from xelth

Nur so ... zum Vergleich ... Bald geht ihr alle arbeiten zum Arbeitsamt

Okay mal eine ernst gemeinte Frage: Möchtest du hier nur Provozieren? Du selbst hast immer wieder mit komischen Anmerkungen vom eigentlichen Topic abgelenkt. Beschwerst dich dann, dass man deine Eingangsfrage nicht zu deiner Zufriedenheit beantwortet. Und jetzt tust du so, als wäre es unser Job, quasi unsere Berufung dir zu helfen. ><)))))*> Hier ein Fisch für dich.

Aber for the record einmal die Antwort auf die eingangs Frage, soll ja Menschen geben die evtl die gleiche Frage sich stellen:

Grundsätzlich ist ARM64 für die typischen Server/Hosting Anforderungen mittlerweile sehr Stabil und verwendbar. Wenn man jetzt keine x86 spezifische Software verwenden möchte/muss, lässt sich dein Debian auf ARM64 genauso administrieren wie ein Debian x86. Alle Software die du in den Offiziellen Debian Repos findest werden in der Regel auf ARM64 problemlos laufen. Falls du eher Docker und/oder einen andere Containerisierung Technologie verwenden möchtest, sind auch dort die typischen (Nginx, Postgresql, Node.js, Apache, Php) Basis Container Images in der ARM64 Variante vertreten.

Edit: Ich selber betreibe sogar aktuell ein Talos Kubernetes cluster mit 3 ARM64 VPS3000 Nodes und habe bisher noch keine Probleme feststellen können. Bisher ist mir zumindest in diesem Kontext noch keine Software untergekommen die nicht out of the box funktioniert. Das Contaier Ökosystem ist aber bei den häufig verwendeten Software Paketen aber auch schon länger auf Multi Architektur ausgelegt. (Meine da auch PowerPC, mips armv7 und andere außer x86 und ARM64 zu sehen.)

Man muss sich aber hier in Klaren sein, dass die ARM64 CPUs andere Performance Charakteristika haben. Es gibt kein wirkliches x86 oder ARM64 ist besser bei nodejs und postgresql. Es gibt Verwendungs-Szenarien sowohl bei Postgresql, als auch anderen Datenbanken/Anwendungen, wo die beiden Architekturen besser oder schlechter abschneiden. Das Heißt pauschal kann man hier keine Empfehlung geben, ob ARM64 oder x86 geeigneter ist.

Was man aber sagen kann ist, dass ARM64 bei so gut wie fast allen Hoster/Providern für denselben Arbeitsspeicherbedarf meist günstiger sind, da diese deutlich Energie effizienter sind. D.h. wenn du experimentieren willst und/oder es dir auf ein paar ms reaktionszeit/TTFB nicht ankommt du mit ARM64 genauso gut fährst wie mit einen x86 basierten System.

Bonus Points für ARM64 bei Netcup sind, dass diese deutlich kürzere Vertragslaufzeiten für den niedrigen Preis haben als vergleichbare (gleiche RAM Kapazität) VPS/RS. D.h. falls dir auffällt das du für deinen special case doch bestimmte Features der x86 Architektur brauchst kannst du einen ARM64 Server auch ohne die Serverbörse hier im Forum wieder schnell los werden.

Quote from xelth

Ich hatte ein RS und habe es nur zum Lernen benutzt... Ich habe nie auch nur annähernd die volle Leistung genutzt... Aber wenn du deine 100k Seite einen Monat lang nicht besuchst, dauert es bis zu 30 Sekunden, bis der Server antwortet... Also bei RS sind deine Kerne auch nicht immer bei dir...

Und die Festplatte ist wahrscheinlich noch gezippt.

Okay und du hattest entsprechend Metriken/Traces mit hilfe derer du es darauf einschränken konntest, dass deine VM für 30s kaum bis gar keine CPU-time bekommen hat bei einen RSxxxx? Das müsste ja dann über 30s ein Steal% jenseits von gut und böse gewesen sein.

Es kann nicht daran liegen, dass du falsche IPv6 Einstellungen genutzt hast oder allgemein deine Software Konfiguration der Ausschlaggebende Punkt war?

Und was soll die Anspielung mit Festplatte gezippt? Grundsätzlich gibt es Kompression bei Dateisystemen/Logical Volume manager. Wo du diese Behauptung jetzt her nimmst dass das hier Anwendung findet wüsste ich auch gerne. Bei meinen IO-Latenzen in den Metriken sehe ich zumindest, falls lz4 oder ähnliches für die VM-Disk zum Einsatz kommt, keine Auffäligkeiten.

Quote from xelth

Bis jetzt kann ich wirklich keinen Unterschied zum RootServer erkennen... Wäre es wirklich interessant zu wissen, für welche Extras die Besitzer von Rootservern ca. 30 % mehr bezahlen?

Der Unterschied wird relativ transparent auf der Netcup Webseite erläutert. Und sogar hier nochmal als eine Tabelle dargestellt: https://www.netcup.com/de/server/vergleich-root-server-vps

TL;DR: Rootserver haben exklusive/dedizierte CPU Kerne. D.h. kein CPU-STEAL. Bei VPS hast du zwar x vCPUs, diese werden aber Überbucht. D.h. bei einen Server mit z.b. 64 Cores, werden VMs mit 128 cores drauf laufen. Das bedeutet das im Worst Case du nur die Hälfte der CPU Leistung bekommst.

Falls du dauerhaft 100% Leistung brauchst und/oder realtime Anwendungen hast, brauchst du Rootserver mit dedizierten CPU cores.

Edit: Idee ist das bei VPS eher burst Anwendungen laufen und es im Mittel nicht zu hohem Steal kommt, da nicht alle VPS zur selben zeit die Leistung abrufen.

Quote from H6G

IPv4 und IPv6 sind zwei unterschiedliche Protokolle die zueinander inkompatibel sind. Das kannst du dir etwa wie ein Schienenfahrzeug und ein Auto vorstellen.

Das Auto kann auf der Schiene nicht fahren und der Zug hat Probleme auf der Autobahn. Beide fahren jedoch auf dem Erdboden (Layer 2, bspw. Ethernet) und beide transportieren Menschen und Waren (Layer 4, bspw. TCP und UDP), Komisches Beispiel, aber naja.

Im Endeffekt braucht jeder Teilnehmer im Tunnel und jeder Tunnelendpunkt eine IPv6 Adresse, vergleichbar mit dem 10.0.0.0/8 Netz. Dabei bieten sich bspw. fc00::/7 Blöcke an, es können aber auch öffentliche Präfixe benutzt werden.

Die Routingtabelle sieht dann entsprechend so aus:

fd00:68::2 via fd00:68::1 metric 1000 dev tun0

Display More

Das ist mir bewusst. Der Threadersteller hat aber hier geschrieben, dass in dem Tunnel / auf dem Tunnel Interface nur 10.0.0.0/8 Adressen liegen und darüber irgendwie auf die IPv6 Adressen auf dem docker0 interface / respektive die container interfaces routet. So zumindest bisher meine Interpretation des hier geschriebenen.

Der Threadersteller hat auch mehrfach jetzt geschrieben das es funktioniert in einen IPv4 only VPN tunnel IPv6 traffic zu routen. Deswegen die Frage wie das laut Threadersteller funktioniert. Mir ist zumindest keine Möglichkeit bekannt das ohne den von dir beschriebenen Weg zu bewerkstelligen.

Mich würde auch interessieren, wie man IPv6 Traffic über ein VPN interface (tun0, wg0 etc. pp.) routet wo im Tunnel selber nur Adressen aus dem 10.0.0.0/8 Netz verwendet werden. Insbesondere wie sieht hier die Routing table aus?

Wäre dann ja etwa sowas:

2a03:4000:bla1:bla1::0/64 via 10.0.0.1 metric 1000 dev tun0