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 ;) .

    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.

    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

    Code
    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.

    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.

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


    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.

    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.

    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.

    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 ;)

    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.