Guten Morgen! Früher konnte man sich als User auf der Console anmelden und X11 mit xinit oder startx starten. Man brauchte keinen Display Manager. Das funktioniert bei Debian seit einigen Jahren nicht mehr so einfach. Als Notlösung benutze ich ein eigenes xinit. Gibt es eigentlich noch eine "offizielle" Methode? Das ist für einen Rechner ohne Monitor gedacht. Normalerweise braucht der keine grafische Oberfläche, aber jeder billige Switch oder Router kann nur per Browser mit JavaScript konfiguriert werden :(
Bauform B. schrieb: > Das ist für einen Rechner ohne Monitor gedacht. Dann mach' die im Repo enthaltene MaschineX drauf, damit kann man dann… Bauform B. schrieb: > per Browser mit JavaScript konfiguriert
Bauform B. schrieb: > Früher konnte man sich als User auf der Console anmelden und X11 mit > xinit oder startx starten. ... > Gibt es eigentlich noch eine "offizielle" Methode? Bei Verwendung eines seat managers (logind auf Systemd systemen, elogind auf nicht-systemd Systemen, und/oder seatd (kann zusammen oder statt *logind genutzt werden. Für seatd braucht Xorg aber womöglich einen patch)), sollte das eigentlich weiterhin funktionieren. Bauform B. schrieb: > Das ist für einen Rechner ohne Monitor gedacht. Also headless. Das sollte eigentlich auch ohne Seat Manager gehen, der ist nur zuständig dafür Zugriff auf Sachen wie die die drm card node / KMS master zu vergeben, womit man die Bildschirmauflösung usw. kontrollieren kann. (und das gibt es noch nicht) Der User sollte aber zugriff auf /dev/dri/renderD* haben, für Sachen die die GPU nutzen wollen, aber kein KMS brauchen. Xorg bräuchte dafür aber einen headless Treiber, oder einen, der als solches verwendet werden kann. Mit dem modesetting Treiber geht das momentan nicht, wobei, es ist nicht allzu schwer, den Treiber etwas zu patchen, und daraus einen Headless Treiber zu machen. Der Treiber erstellt nämlich einen grossen BO, für den Screen, auf den gezeichnet wird, und die Outputs geben dann einen teil davon auf den Monitoren aus, vereinfacht ausgedrückt (Normalerweise ein KMS dumb BO von einer card node, müsste man einfach durch einen GEM BO ersetzen). Das mit den Outputs ist teil von KMS und müsste man einfach entfernen, der Rest geht alles auch mit einer render node. (Ich musste mich mal damit auseinander setzen, als ich ein Gerät hatte, mit einer render + card node (GPU), ohne Outputs / KMS unterstützung, und eine card node für ein Panel mit einem Output, die keine GPU Sachen konnte. Da wurde dann aber in Mesa ein hack dafür eingebaut, nennt sich KMSRO, das importiert die KMS dumb buffer im Hintergrund einfach bei einer render node usw., dann ist es, als ob man mit der KMS only node gpu rendering zeug machen könnte). Irgendwie scheint aber nie jemand Lust zu haben, Xorg zu patchen. Mittlerweile gibt es noch VKMS, damit kann man virtuelle drm card nodes mit virtuellen Outputs erzeugen. Ich weiss zwar nicht, ob das schon zusammen mit mesa KMSRO geht / ob man da die glamour GPU acceleration von Xorg kriegt. Ist zwar alles etwas witzlos, wenn man das Bild eh nirgends sehen kann. Da machen dann VNC Server usw. mehr sinn. Lies eventuell man https://wiki.archlinux.org/title/Headless durch. > Normalerweise braucht > der keine grafische Oberfläche, aber jeder billige Switch oder Router > kann nur per Browser mit JavaScript konfiguriert werden :( Ernsthaft, dafür brauchst du das? Das tönt als wolltest du per jump host auf nen Router zugreifen. Mach einfach SSH und Port Forwarding, und öffne die Seite lokal auf deinem Rechner im Browser, so wie jeder andere normale Mench auch. Was auch ginge wäre X11 forwarding per ssh (ssh -X oder ssh -Y), da brauchst du auch kein startx usw. höchstens der Agent sollte installiert sein. Da drüber müsste auch z.B. Xephyr gehen, wenn du nen ganzen Desktop starten willst. Der Vollständigkeit halber noch, bei wayland gibt es waypipe fürs forwarding. Aber keine Ahnung, wie genau das geht.
Bauform B. schrieb: > Guten Morgen! > > Früher konnte man sich als User auf der Console anmelden und X11 mit > xinit oder startx starten. Man brauchte keinen Display Manager. Das > funktioniert bei Debian seit einigen Jahren nicht mehr so einfach. Als > Notlösung benutze ich ein eigenes xinit. Gibt es eigentlich noch eine > "offizielle" Methode? > > Das ist für einen Rechner ohne Monitor gedacht. Normalerweise braucht > der keine grafische Oberfläche, aber jeder billige Switch oder Router > kann nur per Browser mit JavaScript konfiguriert werden :( Lass Dich mal nicht beirren. Natürlich geht das auch mit Debian. Ich betreibe selber ein paar "Kiosk"-Systeme auf Debian 13 (Trixie) in Minimalkonfiguration und mit autologin, startx und ohne desktop environment. Du musst halt mit einer Debian Minimalkonfiguration anfangen und dann nur die benötigten Pakete dazu installieren. Ist am Anfang ein bisschen Rumprobiererei, aber das funktioniert.
Wenn man nur den nackten X-Server haben will, braucht man nur das Executable des X-Servers starten. Eine passende Configdatei sollte der dann an der passenden Stelle allerdings vorfinden. In welchem Installationspaket der steckt, sollte man auch recht einfach herausfinden.
Es bleibt rätselhaft. Natürlich ist mein Wunsch mal wieder exotisch, ein Server braucht kein X, bei einem normalen Desktop-PC fällt ein fetter Display Manager nicht weiter auf und für Kiosk-ähnliche Fälle ist nodm perfekt. Wenn Debian diese xinit-Methode mangels Bedarf nicht mehr unterstützt, ist das ok. Aber warum gibt es xinit dann noch? Anscheinend hat man "X ohne root-Rechte" aufgegeben. Mit nodm läuft der auch als root und ein Start als User scheitert an "xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted)". Dagegen müsste der x-server seine root-Rechte freiwillig aufgeben und dafür braucht man einen neuen System-User oder ein User müsste konfiguriert werden. Das sieht doch ziemlich eindeutig aus? Muss ich kein schlechtes Gewissen haben, wenn der bei mir als root läuft?
Bauform B. schrieb: > ... Muss ich kein schlechtes Gewissen > haben, wenn der bei mir als root läuft? Du könntest ihn ja wegsperren, dann hätte man nüx von Exploits. Und ggfs. mit Firewall etc. noch nachhelfen. Flankierend wäre dann noch ein statischer Build mit "All Inn".
:
Bearbeitet durch User
Hallo, hier werden zwei Möglichkeiten beschrieben (selber nicht getestet): https://linuxcloudservers.com/installing-x11-ubuntu/ Scenario 3: Setting Up X11 Forwarding for Remote Access 1. Install OpenSSH and X11 2. Enable X11 Forwarding in SSH Config Scenario 4: Headless Ubuntu with Remote Desktop (Xrdp Setup) 1. Install X11 and XRDP 2. Install a Lightweight Desktop 3. Enable XRDP to Start on Boot
* Debian OHNE Desktop Zeug (bare bones) installieren. Dabei root und gleich auch einen Benutzer einrichten Als root: * apt-get install aptitude (wenn man ähnlich bequem ist wie ich es bin) * aptitude install xorg * abmelden oder Konsole wechseln Als Benutzer: * Anmelden, dann startx Das war's
Bauform B. schrieb: > Es bleibt rätselhaft. Ja. Was hast du deinem armen Debian angetan? "startx" existiert weiterhin, und ist Teil vom "xinit"-dpkg. Wenn du xinit benutzt, aber kein startx mehr hast, ist bei deinem Debian irgendwas stark schief gelaufen. Bauform B. schrieb: > Anscheinend hat man "X ohne root-Rechte" aufgegeben. Komisch. Funktioniert unter Debian ganz problemlos. Gerade getestet, Debian13: Konsolen-Anmeldung als normaler User, "startx", fertig. Kein SUID-Flag auf startx oder Xorg. Xorg Prozess läuft als der User. Also irgendwas hast du dir kaputt-konfiguriert. Edit: Versuch's mal mit "sudo dpkg-reconfigure xserver-xorg-legacy", und schau ob das bei dir (warum auch immer) auf "Nur Superuser" steht.
:
Bearbeitet durch User
Bauform B. schrieb: > Das ist für einen Rechner ohne Monitor gedacht. Normalerweise braucht > der keine grafische Oberfläche, aber jeder billige Switch oder Router > kann nur per Browser mit JavaScript konfiguriert werden :( Dazu siehe z.B. How to run a GUI application over SSH with X11 forwarding https://www.simplified.guide/ssh/run-gui-application X11 forwarding hatte Daniel A. weiter oben auch schon empfohlen.
Alexander S. schrieb: > Bauform B. schrieb: >> Das ist für einen Rechner ohne Monitor gedacht. Normalerweise braucht >> der keine grafische Oberfläche, aber jeder billige Switch oder Router >> kann nur per Browser mit JavaScript konfiguriert werden :( > > Dazu siehe z.B. > > How to run a GUI application over SSH with X11 forwarding > https://www.simplified.guide/ssh/run-gui-application > > X11 forwarding hatte Daniel A. weiter oben auch schon empfohlen. Um X zu forwarden braucht es einen laufenden X-Server. Und, wie Daniel auch schrieb, braucht X einen Bildschirm oder sonst ein Device, wo es reinmalen kann. In einem Headless-Setup lässt sich also kein X starten. Alternative: Bau einen dauerhaften SSH-Tunnel zwischen deiner Headless-Maschine und der Maschine, wo Firefox drauf läuft, auf. Konfiguriere Firefox um einen Proxy zu nutzen. Du kannst nun auf Webseiten zugreifen die nur von deinem internen LAN aus zu erreichen sind, z.B. deine Router-GUI. Ich bin zu faul ins Detail zu gehen, aber die KI hat das freundlicherweise mal schön aufbereitet. Ich habe das viele Jahre so gemacht um von unterwegs auf mein Heimnetz zuzugreifen (jetzt nutze ich einfach VPN).
:
Bearbeitet durch User
Εrnst B. schrieb: > Was hast du deinem armen Debian angetan? > "startx" existiert weiterhin, und ist Teil vom "xinit"-dpkg. > Wenn du xinit benutzt, aber kein startx mehr hast, ist bei deinem Debian > irgendwas stark schief gelaufen. Umgekehrt; ich habe beide, aber ich fragte mich wozu, wenn es beide nicht schaffen, den x-server mit genug Rechten zu starten. Ich habe nichts gegen die beiden, wenn die normalerweise funktionieren. > dpkg-reconfigure xserver-xorg-legacy Da steht der Default drin (Console Users Only), aber Anybody geht auch nicht. Norbert schrieb: > * Debian OHNE Desktop Zeug (bare bones) installieren. > Dabei root und gleich auch einen Benutzer einrichten > > Als root: > * apt-get install aptitude (wenn man ähnlich bequem ist wie ich es bin) > * aptitude install xorg > * abmelden oder Konsole wechseln > > Als Benutzer: > * Anmelden, dann startx Ganz genau so hab' ich schon immer gemacht, inklusive aptitude ;) Dachte ich. In Wirklichkeit war es statt xorg immer nur xserver-xorg. Das werden wir gleich sehen...
... wir sehen: x-server läuft als User! Witzigerweise kennt der jetzt Tastatur und Maus beim Namen, aber findet keinen Treiber und xinit geht nicht, nur startx. Egal, das sind normale Fehler, andere Baustelle. Das letzte(?) große Rätsel ist gelöst, vielen herzlichen Dank!
Bauform B. schrieb: > wenn es beide > nicht schaffen, den x-server mit genug Rechten zu starten. Welche Rechte fehlen denn? User sollte in der "video" Gruppe sein, um Bilder ausgeben zu können, und in der "input" Gruppe, um Eingabegeräte verwenden zu können. (Wenn du die Rechte von Hand vergeben willst, und das nicht seatd, systemd-logind, udev etc überlässt) Die Warnmeldung wegen "I/O ports 0000-03ff" kommt von der Auto-Detection des VESA-Treibers, den du ziemlich sicher nicht brauchst. Wenn dich die Meldung stört, wegkonfigurieren, oder xserver-xorg-video-vesa deinstallieren. Le X. schrieb: > Um X zu forwarden braucht es einen laufenden X-Server. Aber nur auf der Maschine, die nachher das Programm anzeigen soll. Auf der, wo das Programm läuft, muss kein X11-Server laufen.
Εrnst B. schrieb: > Die Warnmeldung wegen "I/O ports 0000-03ff" kommt von der Auto-Detection > des VESA-Treibers, den du ziemlich sicher nicht brauchst. Wenn dich die > Meldung stört, wegkonfigurieren, oder xserver-xorg-video-vesa > deinstallieren. Danke, das gefällt mir. Mit so einer Taktik hat das Unheil ja begonnen. Da wäre es nur konsequent, so weiter zu machen ;) Aber ich wollte doch langsam mal brav werden...
Bauform B. schrieb: > xinit geht nicht, nur startx. Wenn startx geht, dann geht auch xinit. Das isses nämlich was von startx in letzter Konsequenz aufgerufen wird. Nätürlich mit den richtig gesetzten Parametern.
1 | $ less $( which startx ) |
Norbert schrieb: > Wenn startx geht, dann geht auch xinit. Sollte man meinen. Aber lass gut sein, dies ist mal der ganz seltene Fall, wo sich tatsächlich eine Neuinstallation lohnt. Schuld an diesem Rätsel ist nämlich eine Installation, die auf eine 2GB CompactFlash passen sollte. Dabei kann man Pakete wie xorg-docs usw. natürlich nicht gebrauchen. Jetzt fehlt bestimmt noch ein unscheinbares Paket, genau wie bei nur x-server-xorg statt xorg. Am Ende brauchte die CF-Installation sogar nur 1.3GB und dadurch wurde "minimal" zur Gewohnheit, es gab ja nie echte Probleme. Jetzt, bei einer Trixie-Neuinstallation, ist es wieder aufgefallen und da bin ich neugierig geworden.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.

