Posts by Paul

Schau mal im Server/KVM Bereich hier im Forum rein. Da gab es in letzter Zeit recht viele Diskussionen zu diesem Thema. Zusammengefasst bieten sich folgende Möglichkeiten an. Welche man davon jetzt bevorzugt, ist wirklich individuell verschieden. Am ehesten macht mal das, womit man die meiste Erfahrung hat:

• Snapshot erstellen und einspielen
• dd im Rettungssystemm
• rsync
• Backup / Restore

Aus vertraglicher Sicht musst du den alten Server regulär kündigen und einen neuen Server buchen. Da wirst bzw. möchtest du aber definitiv eine zeitlang beide Server unter Vertrag haben und bezahlen müssen. Das hat aus operativer Sicht aber definitiv Vorteile. Eine Migration (vor allem, wenn sie erst nach einigen Jahren stattfindet) ist meist immer etwas, wofür man sich Zeit nehmen sollte. Es gibt immer die ein oder andere kleinere Konfiguration, die man vielleicht vergessen, nicht genug dokumentiert oder einfach an sich geändert hat, weil man zusätzlich auch noch die Version aktualisiert. Da ist es immer besser, man hat den alten Server weiterhin online und kann in Ruhe vergleichen. Den Luxus, dass man auf beide Systeme gleichzeitig drauf an kann um zu vergleichen, sollte man daher nicht außer Acht lassen. Hat alles wie gewünscht geklappt, kann man den Server auch hier in der Tauschbörse noch anbieten. Ist das allerdings kein Aktionsserver, dürfte es schwer werden, hier einen Abnehmer zu finden. Du willst ja auch nicht ohne Grund wechseln .

Quote from gem

Vielen Dank, das bestätigt meine eigenen Recherchen.

Mir ging es auch weniger um Fedora als Distro sondern darum, dass RDP jetzt in Gnome quasi integriert ist und ich das eigentlich sehr bequem finde.

Außerdem scheint über die Zukunft von xrdp bei Wayland noch vieles offen zu sein.

Ich denke, ich kehre dann erstmal wieder auf xrdp mit xfce zurück, dass liegt mir persönlich mehr und läuft seit Monaten extrem stabil.

Das ist wohl keine schlechte Idee . xrdp mit xfce läuft vor allem dann besser, wenn es sich um einen Server (VPS, RS) ohne richtige GPU handelt. Die Gnome Shell läuft halt wirklich nur mit einer richtigen GPU flüssig. Ich hatte das in der Vergangenheit schon ein paar Mal mit VMs getestet und das war nie so wirklich toll. Daher würde gnome-rdp auch eher nur im Homlab nutzen. Vermutlich ist auch eher nur dafür gedacht und hat deswegen nur wenig Optionen, die man im Homelab ja auch nicht wirklich benötigt.

Quote from gem

Das ist mein erster ernsthafter Kontakt mit Fedora und Gnome... und Wayland...

Der RDP Port ist offenbar von /usr/libexec/gnome-remote-desktop-daemon geöffnet worden, aber ich konnte noch nicht herausfinden, wie man den umfassend konfigurieren kann... über die GUI kann man nur den Port selbst ändern, aber nicht IP oder NIC.

xrdp ist demgegenüber nahezu trivial zu konfigurieren...

Wenn du den RDP Dienst umfassend konfigurieren willst, ist wohl die gnome-rdp Methode nicht das richtige Tool. Das ist wirklich sehr minimalistisch und lässt nur wenige Einstellungen zu. Ähnlich wie gnome-boxes oder andere Gnome Tools.

gnome-rdp bietet im Grunde nur folgendes an

org.gnome.desktop.remote-desktop.rdp enable false
org.gnome.desktop.remote-desktop.rdp negotiate-port true
org.gnome.desktop.remote-desktop.rdp port uint16 3389
org.gnome.desktop.remote-desktop.rdp screen-share-mode 'mirror-primary'
org.gnome.desktop.remote-desktop.rdp tls-cert ''
org.gnome.desktop.remote-desktop.rdp tls-key ''
org.gnome.desktop.remote-desktop.rdp view-only true

Das war es dann auch schon. Will man mehr, muss man wohl auf eines der anderen RDP Tools ausweichen. Aber auch die kann man ja problemlos in Fedora nachinstallieren.

Quote from notfound404

Betrifft das eigentlich auch das Servercontrolpanel? Habe einen Server storniert und der ist zumindest gerade immer noch als "deaktiviert" dort aufgelistet. Auch an den Support wenden oder wird der nach einer Zeit rausgelöschjt?

So eine Serverleiche habe ich bei mir auch im SCP. Dieser würde vor über einem Jahr gekündigt und gelöscht, angezeigt wird er mir aber immer noch im SCP, auch wenn natürlich dort nichts mehr ist und ein Klick darauf nur eine Fehlermeldung wirft. Aber zumindest dürfte das die Frage klären, ob da automatisiert bereinigt wird - nein . Also normalerweise verschwinden die Server schon aus dem SCP. Aber es gibt wohl den ein oder anderen Bug, der das wohl manchmal verhindert. Ich wollte diesbezüglich auch schon die ganze Zeit mal ein Ticket aufmachen, aber da der Support in letzter Zeit eh schon so ausgelastet war, habe ich das erst einmal gelassen. Es stört mich jetzt auch nicht, ob da jetzt ein Server mehr angezeigt wird oder nicht. Aber "irgendwann" werde ich das sicher auch noch machen.

Quote from citecite

Hat jemand von Euch Zugriff auf ein System mit einem Intel N150-Prozessor und könnte den Output von cryptsetup benchmark posten?

Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             39 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      4
  On-line CPU(s) list:       0-3
Vendor ID:                   GenuineIntel
  Model name:                Intel(R) N150
    CPU family:              6
    Model:                   190
    Thread(s) per core:      1
    Core(s) per socket:      4
    Socket(s):               1
    Stepping:                0
    CPU(s) scaling MHz:      28%
    CPU max MHz:             3600,0000
    CPU min MHz:             700,0000
    BogoMIPS:                1612,80
    Flags:                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rd
                             tscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monit
                             or ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand l
                             ahf_lm abm 3dnowprefetch cpuid_fault epb cat_l2 cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase ts
                             c_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_det
                             ect user_shstk avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req vnmi umip pku ospke waitpkg gfni vaes vpclm
                             ulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities
Virtualization features:     
  Virtualization:            VT-x
Caches (sum of all):         
  L1d:                       128 KiB (4 instances)
  L1i:                       256 KiB (4 instances)
  L2:                        2 MiB (1 instance)
  L3:                        6 MiB (1 instance)
NUMA:                        
  NUMA node(s):              1
  NUMA node0 CPU(s):         0-3
Vulnerabilities:             
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Reg file data sampling:    Mitigation; Clear Register File
  Retbleed:                  Not affected
  Spec rstack overflow:      Not affected
  Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:                Mitigation; Enhanced / Automatic IBRS; IBPB conditional; PBRSB-eIBRS Not affected; BHI BHI_DIS_S
  Srbds:                     Not affected
  Tsx async abort:           Not affected

> cryptsetup benchmark
# Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen.
PBKDF2-sha1      2257429 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha256    4346429 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha512    1365333 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-ripemd160  764268 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-whirlpool  704688 Iterationen pro Sekunde für 256-Bit-Schlüssel
argon2i       4 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden)
argon2id      4 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden)
#   Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung
        aes-cbc        128b      1252,5 MiB/s      3173,7 MiB/s
    serpent-cbc        128b        86,7 MiB/s       350,9 MiB/s
    twofish-cbc        128b       214,9 MiB/s       471,2 MiB/s
        aes-cbc        256b       970,7 MiB/s      2651,0 MiB/s
    serpent-cbc        256b        89,8 MiB/s       347,9 MiB/s
    twofish-cbc        256b       222,6 MiB/s       466,5 MiB/s
        aes-xts        256b      3156,7 MiB/s      3149,4 MiB/s
    serpent-xts        256b       283,6 MiB/s       287,7 MiB/s
    twofish-xts        256b       345,7 MiB/s       363,2 MiB/s
        aes-xts        512b      2838,2 MiB/s      2833,5 MiB/s
    serpent-xts        512b       288,8 MiB/s       289,3 MiB/s
    twofish-xts        512b       352,0 MiB/s       365,6 MiB/s

Quote from ASS

Ist Openmediavault noch immer das Mittel der Wahl für ein Selbstbau NAS?

Was wäre Alternative? Was spricht dafür? Was dagegen?

Wenn es nicht für dich selbst ist, warum dann überhaupt einen Selbstbau? In einem solchen Fall würde ich eher was Fertiges von Synology oder Asustor nehmen. Es kommt dann ja auch immer etwas auf den Anwendungszweck an. Einfach so pauschal wird es da nie die beste Empfehlung für alles geben. Jede Lösung hat ja ihre Stärken und Schwächen.

Privat nutze ich aktuell Archlinux. Ich habe hier aber auch noch 2 weitere Clients mit Fedora (Einmal Fedora Kinoite mit KDE und eine normale Fedora Workstation Variante). Meine berufliche Workstation läuft mit Fedora und das jetzt seit vielen Jahren. Bin damit auch super zufrieden. Man merkt hier schon die Herkunft aus dem RHEL Lager und dass die RHEL Entwickler selbst sehr viel Fedora einsetzen. Zudem werden auch die Pakete immer sehr aktuell gehalten. Das ist ein Punkt, der ist mir bei einem Desktop Client sehr wichtig. So sehr die ganzen LTS Distros auf dem Server interessant sind (Ubuntu LTS, RHEL, ...), auf einem Desktop macht das nach einiger Zeit keinen Spaß mehr, weil eben auch die Pakete nicht mehr aktualisiert werden. Hat man ein RHEL, Alma oder Rocky als Desktop, dann hat man meist nach 2-3 Jahren so alte Python, Golang Pakete, so dass man sich hier schon mal ein Update wünscht. Ich würde daher auf dem Desktop Client nicht die gleiche Strategie wählen wie für einen Server, auch wenn man sehr schnell dazu neigen würde.

Aber am Ende kann man mit jeder Distro glücklich werden. Die lassen sich objektiv immer nur sehr schwer bewerten, weil es am Ende eine rein subjektive Wahrnehmung ist. Ich würde daher empfehlen, sich einfach mal auf die Reise zu machen und alle möglichen Optionen mal zu testen. Jede Distro einfach mal über einige Zeit nutzen und dann wechseln. Da merkt man dann schon recht schnell, welche einem liegt oder auch nicht.

Was man eher selten hört, aber definitiv anschauenswert ist, wäre auch OpenSUSE Tumbleweed. Das ist eine Rolling Release Distro wie Archlinux, aber etwas einfacher in der Wartung und in der Installation. So toll Archlinux auch ist, ist es gerade zu Beginn eine ziemliche Bastelei. Die Zeit und Lust dazu muss man haben - und auch eine gewisse Frusttoleranz .

Gaming sollte eigentlich mit allen gängigen Distros möglich sein. Anleitungen für Steam & Co. findet man überall. Die Tools sind ja am Ende die gleichen. Wenn der Schwerpunkt aber wirklich Gaming ist, sollte man sich definitiv mal Nobara Linux (https://nobaraproject.org/) anschauen. Das ist im Grunde ein Fedora, das speziell für's Gaming optimiert ist und auch die entsprechenden GPU Treiber (Nvidia) mitbringt. Das ist bei einem normalen Fedora nämlich sonst etwas mühsam, da es ausschließlich Open Source Tools und Treiber beinhaltet und alles andere aus 3rd Party quellen (z.B. RPMFusion) benötigt.

Ich kann für einen Serverumzug auch die Backup/Restore Methode empfehlen. So kann man nämlich auch mal testen, ob denn die eigene Backup Methode tatsächlich funktioniert und man die Backups erfolgreich wiederherstellen kann. Diesen netten Nebeneffekt sollte man nicht unterschätzen. Denn eine tatsächliche Verifikation des Backups macht man sowieso viel zu selten. Da bietet sich so eine Gelegenheit ja gerade zu an, da man den alten Server ja parallel laufen hat und somit die Daten vergleichen kann.

Man sollte eigentlich immer einen lokalen Notfall User haben, dessen Passwort man über irgendeine Art VNC Konsole eingeben kann. Das sollte dann definitiv kein Passwort mit 120 Zeichen sein. Man kann für diesen User auch problemlos den Remote Login (z.B. über die sshd_config) sperren, so dass dieser sich wirklich nur lokal anmelden kann. Aber einen User zu haben, mit dem man sich zur Not immer nochmal einloggen kann, ist immer ein guter Plan B. Es kann immer mal passieren, dass die Netzwerkverbindung Probleme macht und man sich lokal anmelden muss. Ein 120 Zeichen Passwort ist halt einfach Bullshit. Das muss man an dieser Stelle auch mal klar und deutlich sagen.

Quote from nikilase

Ja geil, dann bleib ich mal auf der Hut nach Aktionen.
Die 512GB wären schon geil gewesen.

Hier im Forum werden die auch immer wieder mal in der Tauschbörse angeboten. Da kannst auch gerne mal eine eigene Suche starten. Vielleicht hat ja noch jemand einen übrig: https://forum.netcup.de/inform…via-inhaberwechsel/suche/

Quote from Homwer

Höchstens den Stromverbrauch.

alternativ kann ich dir ein N100 mini PC empfehlen. Die bekommst du für 130€ inkl. RAM und NVMe und die verbrauchen 5w.

Kann ich ebenfalls empfehlen. Ich habe hier auch einige N150 (Nachfolger von N100) Mini PCs. Als Homeserver sind die wirklich super. Günstig, brauen wenig Strom, liefern aber trotzdem genug Leistung (hier sind es k3s Nodes). Die sind deutlich effizienter als uralte Intel CPUs. Wenn man von den alten Intel Systemen sowieso noch welche rumstehen hat, kann man die ruhig weiter nutzen. Aber neu bzw. gebraucht würde ich die mittlerweile wirklich nicht mehr kaufen.

Quote from TBT

Sorry, wenn ich den Thread kapere. Wie ist der Verwendungszweck eines solchen Alpine Servers? Ist das ein Barebone OS für nur eine Anwendung mit möglichst wenig Overhead? Oder die kleinstmögliche Dockerumgebung? Ich verwende bisher nur Alpine in Docker (FROM), aber auf nen Server hab ichs jetzt noch nicht installiert.

Letztendlich ist Alpine ja auch nur eine Linux Distribution unter vielen, wenn man mal von der musl libc und openrc absieht. Ich nutze Alpine vor allem als Kubernetes Node. Davon habe ich einige. Hier zahlt sich durchaus aus, dass Alpine so klein und schlank ist. Man kann das daher viel schneller deployen als ein Full Bloat OS wie Debian oder Fedora und auch die Updates/Reboots gehen im Vergleich super schnell. Es ist aber im Gegensatz zu anderen speziellen K8s OS (z.B. Talos) immer noch eine richtige Linux Distribution mit einem richtigen Paketmanager, damit man hier auch dem Node entsprechende Zusatzdienste installieren kann (z.B. Monitoring Agents).

Ich habe aber auch Mailserver mit Alpine. Das funktioniert ebenfalls wunderbar. Vor allem, da Alpine ein recht umfangreiches Repository bietet. Da findet man einige Pakete, die man in Debian, RHEL oder Fedora vergeblich sucht oder auf 3rd Party Quellen angewiesen ist.

Aber das ist wie so oft eine subjektive Einschätzung. Ich würde niemanden überreden wollen, dass er sich das anschaut oder sogar einsetzen soll. Denn man muss mit den Sonderheiten auch klar kommen. Wenn man sich über die Jahre an systemd gewöhnt hat, dann ist ein Umstieg auf openrc wirklich nicht einfach. Im Container merkt man das nicht, da man dort ja keinen Service Daemon hat. Ich kenne openrc noch aus meinen früheren Gentoo Jahren. Daher war es für mich dann doch einfacher. Es ist halt vor allem für die interessant, die wirklich das KISS Prinzip auf dem OS (ausprobieren) wollen.

If you are planning to run more than one server with Alpine, I can also recommend the following (this is what I do): https://github.com/alpinelinux/alpine-make-vm-image

With the script you can simply create a ready-to-use qcow2 image and then upload it in scp and use it again and again. This way you only have to do the installation once. This is a bit annoying with an ISO if you have to do it more than once. The script also works perfectly with btrfs.

Die TTL ist doch nicht anderes als eine Art UVP des Nameservers. Da kann man sich als Resolver daran halten. Muss man aber nicht. Auch Clients können das ganz unterschiedlich handhaben. Daher würde ich die Wörter "minimum" bzw. "maximum" komplett streichen. Einfach nur TTL. Fertig.

Das wäre doch ein wunderbarer Abschluss für diesen Thread!

Oder noch besser: Macht aus den FE Produkten eine "Forums Edition"

Quote from aRaphael

Hmmm... Was ist wohl "FE" ?

Vermutlich ein "Flash Egg"

Quote from aRaphael

Doch, das Ding hat schon Updates.

Allerdings wohl keine Kernelupdates, weil es nie rebooted wurde.

Aber du hast recht. Ist wohl besser ich trenne mich von dem Teil...

Dann hast du auch wieder mehr Zeit, dich um die jungen, hübschen Server zu kümmern

Quote from Valkyrie

Aber da sind auch paar Linux Server dabei bei denen seit Jahren keine Updates eingespielt worden

aRaphael ?

Quote from aRaphael

pasted-from-clipboard.png

Moderators Wäre es möglich, dass ihr das Netcup intern mal klären lasst bzw. in die entsprechende Abteilung weitergeben könntet bevor das hier noch weiter eskaliert? Es bringt ja nichts, wenn sich hier Kunden gegenseitig Vorwürfe machen, wenn es tatsächlich ein technisches Problem gibt, was aktuell definitiv den Anschein hat. Wenn das Netcup Standard Image und sogar das Rettungssystem keine Netzwerkverbindungen zulassen, ist das wohl definitiv ein Fall für die Netcup Techniker.