GUI auf Server - Einwände?

tackleberry

Banned
Registriert
Okt. 2007
Beiträge
1.437
Servus

Ich werde wohl meinen Threadripper Pro auf Linux umstellen. Primär fungiert das Ding als Server. Ich habe auch diverse Custom Scripte (Python etc.) drauf laufen, die noch einige Bugs haben. Daher habe ich oft auf Windows tagelang SSH Fenster offen. Früher hat man ja keine GUI auf Servern installiert weil das Leistung frisst. Nun hat der Rechner aber einiges an Leistungsfähigkeit und 5% Verlust könnte ich locker verkraften. Welche Einwände gabe es auf einem High End Server eine GUI zu betreiben? Zugriffe würde űber BMC Chip oder irgendwelche Remote Lösungen laufen.
 
Zuletzt bearbeitet:
Ausser Leistungs- und Ram-Überlegungen könnten ggf. noch die potentiell größere Angriffsfläche ne Rolle spielen. Würde aber dazu neigen, dass es heutzutage kein Problem ist, ne DE mit drauf zu packen, selbst Gnome ist inzwischen ja wieder etwas sparsamer geworden, von KDE, LXQT, XFCE ganz zu schweigen.
 
  • Gefällt mir
Reaktionen: GTrash81
Jede unnötig installierte Software ist ein potenzielles Einfallstor. Wenn das allerdings nur ein Homeserver ist, der nicht ans Netz angebunden ist, gibts keine Einwände solange dein standard runlevel ohne GUI ist und du sie nur lädst wenn du sie brauchst.
 
tackleberry schrieb:
Daher habe ich oft auf Windows tagelang SSH Fenster offen.
OT: Screen oder tmux helfen da ungemein.
 
  • Gefällt mir
Reaktionen: Termy, Evil E-Lex, snaxilian und 5 andere
Hi,

ich habe bei mir einige Linux "Server" auf einer kleinen PROXMOX Installation am laufen.

Da habe ich bei einigen https://webmin.com/ am laufen.
Ist natürlich keine echte GUI, aber vielleicht reicht dir das schon.

Ansonsten: Die paar Prozent für nen Desktop wird den Threadripper im Privatbereich wohl nicht interessieren.
 
Das klingt nach XY-Problem.
Sieht so aus als möchtest du eine GUI auf dem Server haben, damit dir der Screen und damit das Skript nicht gekillt wird, wenn du deine Arbeitsmaschine ausmachst.
Dafür gibt es Screens.
 
  • Gefällt mir
Reaktionen: tackleberry
Gegenfrage:
Was willst Du mit der GUI machen was du nicht über remote Sessions und Tools wie screen/tmux lösen kannst?

Ganz allgemein:
GUI heißt mehr Pakete die potentielle Sicherheitslücken haben können. Beim Server achte ich sehr strikt auf "was nicht da ist kann auch nicht kaputt gehen oder kaputt gemacht werden".
 
xammu schrieb:
OT: Screen oder tmux helfen da ungemein.
Danke. Gucke ich mir mal an. Bisher habe ich Superputty benutzt.
 
Screen oder tmux musst du auf dem Server starten. Superputty kannst du am Client weiterhin verwenden.

Ich mache das immer so:
Erst per SSH am Server einloggen und dort dann "tmux" ausführen bzw. wenn bereits eine Sitzung läuft, diese mit "tmux a" übernehmen. "tmux ls" zeigt dir an, ob Sitzungen aktiv sind.

Mit <Ctrl+a> <d> kannst du eine Session verlassen und im Hintergrund weiterlaufen lassen. Dann kannst du die SSH-Verbindung zum Server beenden.

Edit: Ups, standardmäßig ist die Tastenkombination <Ctrl+b> <d>. Ich stelle das immer auf <Ctrl+a> um, weil ich mir sonst die Finger breche. 🥴
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: snaxilian
Ein Server ist darauf aufgelegt mit anderen Clients zu kommunizieren und übers Netz erreichbar zu sein. Ein Desktop ist für so ein Anwendungszenario nicht ausgelegt. Das stellt ein erhebliches Sicherheitsrisiko dar, besonders wenn der Desktop auf dem Xserver läuft der den gensamten Desktop ins Netz streamen kann. Und dafür ausgeleht ist über das Netzwerk steuerbar zu sein. Es ist glaube ich schon 10 Jahre her aber ich hab mal den gesamten Gnome2 Desktop über das Heimnetz via Xorg auf meinem Laptop gestreamt und konnte alles ausführen, als würde ich einen Windows Rechner per Teamview ansteuern.
 
Normalerweise will man auch gar keine GUI auf dem Server. Was nicht bedeutet, dass man auf (lokale) GUI Programme zur komfortablen Konfiguration und Verwaltung (von Dateien) verzichten muss. Ich persönlich verwende gerne WinSCP (via SSH/SFTP) und Notepad++ für Dateioperationen. WinSCP ist Windows (Wine) und derzeit (Wine 6.12) leider fehlerhaft. Edit: WinSCP unter Windows ist davon natürlich nicht betroffen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Linuxfreakgraz
@Uridium
Als Ex-Windows-User war ich auch geneigt, die dort lieb gewonnenen Tools unter Linux weiter verwenden zu wollen. Aber mittlerweile mache ich das nicht mehr. Es lohnt sich, die Alternativen zumindest mal anzusehen. Statt WinSCP kannst du z.B. sshfs mit einem Dateimanager deiner Wahl verwenden. Das ist meiner Meinung nach viel flexibler. Auch wird die Konfiguration in ~/.ssh/config verwendet, so dass man es sich schön gemütlich einrichten kann.
 
ja, zb als nautilus oder dolphin bookmarks ablegen, dann sind die dateien fast wie lokal...
 
Ich würde gerne auf ein natives Linux Pendant setzen, es kommt für mich aber nichts an WinSCP heran.
 
Ein weiteres Problem ist auch, dass man höchstwahrscheinlich häufiger updaten muss, was auch einen Reboot mit sich bringen. Bei einem Server möchte ich das in der Regel nicht, der soll laufen und nur im Ausnahmefall neu gestartet werden.

Und wie die Vorredner auch schon geschrieben haben, wäre ein Desktop unnötig. Wenn man dann auf der Kiste ist, muss man eh wieder ins Terminal um seine Serveranwendungen zu konfigurieren.
 
Linuxfreakgraz schrieb:
besonders wenn der Desktop auf dem Xserver läuft der den gensamten Desktop ins Netz streamen kann.
Hier herrscht leider oft ein Verständnisproblem. Ein X Server streamt überhaupt nichts ins Netz. Er lauscht und spricht in der Regel ein physikalisches oder emuliertes Display an. Wenn du auf deinem Laptop/Client/Whatever die GUI Applikationen über das X11 Protokoll "streamen" (falscher Begriff, ich übernehme ihn jetzt aber mal von dir) möchtest, muss der Xserver eben auf deinem Client laufen und nicht auf dem Server.
 
Nach einer kleinen Edition der xorg.conf kann man den gesamten Desktop auf einem andern PC übertragen und ihn von dort aus steuern. Das ist ein Feature das Xserver noch aus einer Zeit haben als man in Unternehmen eine Workstation stehen hatte auf den die Anwendungen liefen und man mit Clients nur darauf zugegriffen hat.

Edit: zumindest damals heute gibt es ja bei vielen Distros die xorg.conf nicht mehr. Das war damals ein Experiment. Und war auch sehr Träge. Bei heutigen Desktops mit noch mehr 3D Spielerein müsste das noch träger sein.
 
Zuletzt bearbeitet:
Was du meinst ist xdmcp. Ändert aber dennoch nichts daran, dass der X Server auf dem "Client" sprich auf dem Gerät, welches die GUI Applikation anzeigt, laufen muss. Wenn ich z.B. einen ffox oder Chrome remote auf einer VM laufen habe muss da weder ein X Server laufen noch installiert sein. Ich brauche lediglich lokal einen laufenden. ssh -X (X11 forwarding) host 'firefox' und das war's dann.
 
Dem widerspreche ich nicht, damals lief auf beiden damaligen Geräten xorg. Was ich aufzeigen wollte ist das es dabei keine Sicherheitsvorkehrungen gibt. Wenn die Entsprechenden Ports nach draußen offen sind kann das sehr leicht mißbraucht werden.
 
Zuletzt bearbeitet:
Zurück
Oben