In Terminal, X Session starten, Anwendungen öffnen

[theSplit]

Hallo,

ich hätte eine Frage wie man folgendes unter Linux generell realisieren könnte:
a) Ich würde gerne, ideal wäre Debian automatisch in das Terminal booten und einen vordefinierten User einloggen
b) dann eine X Session starten
c) zwei Anwendungen ohne den Desktop starten, beide laufen permanent, das heißt ich kann sie nicht sequentiell - sondern muß sie parallel laufen lassen

Ich bin mir sicher das hat etwas mit .xinitrc zu tun, aber in etwa etwas wie "startx & startclient & startserver". So in etwa.
Aber ich bin mir da etwas unsicher.

Auch weiß ich nicht wie ich den Autlogin eines User realisiere.

Das Zielsystem ist ein Linux - Flavour unbekannt, aber erste Schritte kann ich hier mit einem Debian nachvollziehen.

Als installierte Software - wäre kein Loginmanager oder ähnliches, sondern nur Xserver(-org) und x11utils (ich glaube das war das Paket für "startx" ?

Über Vorschläge wäre ich sehr dankbar!

 

[thom53281]

Unter Debian (und vielen anderen Distributionen) sollte man das über die rc.local lösen können. Dort packst Du hinein:

su - [I]Benutzername[/I] -c "xinit" &

Beachte da bitte, dass Du mit [KW]dpkg-reconfigure x11-common[/KW] den X-Server so einstellen musst, dass dieser von jedem Benutzer gestartet werden kann. Zudem sollte Xinit auch installiert sein.

In die .xinitrc kommen dann die Anwendungen, die Du starten möchtest. Beachte da aber bitte, dass die X-Session beendet wird, sobald das Skript beendet ist. Heißt, die letzte aufgerufene Anwendung (i. d. R. wäre das der Fenstermanager) darf nicht beendet werden. Die weiteren Anwendungen rufst Du mit "&" am Ende davor auf, damit das Skript weiterläuft.

Allgemein würde ich aber trotzdem empfehlen, zumindest einen rudimentären Fenstermanager wie z. B. dwm oder i3 zu starten.

 

[theSplit]

Hi, das klingt ja schon sehr gut. Also beide Anwendungen laufen in Schleifen.

Wenn ich nicht irre, werden die Befehle ja sequentiell aufgerufen bzw. verarbeitet, aber der Aufruf der Folgeanwendungen die nach dem "xinit" Aufruf mit "&" kommen laufen weiter, korrekt?

Löst die "rc.local" dann auch einen Autologin, mittels "su benutzername" aus oder käme der "Trigger" vor einem Login in das System, damit zum Beispiel nicht bereits ein User mit Rechten ausgeführt wird?

 

[nik]

Kannst das ganze mit Systemd lösen. wird z.b. hier beschrieben: https://blog.sleeplessbeastie.eu/2016/07/25/how-to-automatically-login-user-at-the-console/

Den Rest kannst du dir ja mit nem Skript oder über die .bashrc direkt basteln.

 

[theSplit]

@nik:

Danke für den Tip, muß ich mir mal zu Gemüte führen. So im Nachgedanken wäre es vielleicht sogar "sicherer", wenn es so sein sollte:
Die Befehlskette über einen bestimmten User ausgeführt wird - aber kein automatischer Login in das System vorgenommen wird, falls das überhaupt so umsetzbar wäre.

Quasi das nach einem Beenden der Anwendungen, allerhöchstens ein Login im TTY1 kommt, wie das auch normal der Fall wäre.

 

[nik]

@theSplit: wozu dann überhaupt ein Login? Kannst das ganze doch über cron laufen lassen oder baust eine Unit für systemd.

 

[thom53281]

Wenn ich nicht irre, werden die Befehle ja sequentiell aufgerufen bzw. verarbeitet, aber der Aufruf der Folgeanwendungen die nach dem "xinit" Aufruf mit "&" kommen laufen weiter, korrekt?

Ja, die Folgeanwendungen danach laufen weiter.

Löst die "rc.local" dann auch einen Autologin, mittels "su benutzername" aus oder käme der "Trigger" vor einem Login in das System, damit zum Beispiel nicht bereits ein User mit Rechten ausgeführt wird?

Es wird kein Login in das System ausgeführt. Es ist mehr oder weniger so, als würdest Du Dich als root am System in einem Terminal anmelden und mit [KW]su benutzername[/KW] zu einem anderen User wechseln und einen Befehl ausführen. Der "Trigger" kommt ungefähr zeitgleich mit dem TTY1 (je nachdem, wie schnell das Ding bootet). Sobald der X-Server beendet wird, landet man beim TTY1 und könnte sich anmelden.

 

[theSplit]

@nik: Naja, ich war jetzt davon ausgegangen das ein Login irgendwie notwendig ist - wenn man das ganze mittels rc.local so lösen kann und ich nur Veränderungen an einer Datei und ein paar Installationen vornehmen muß, und keine all zu "komplexen" Mechaniken, wäre mir das schon lieber.

Die Steps zur Konfiguration sollten zu dem auf fast jedem System funktionieren, gehe ich stark von aus. Von daher vielleicht "schöner" je einfacher es ist.

Aber gut, ich kenne jetzt weder Vor- und Nachteile was cron oder systemd angeht, außer das es zu dem komplexer zu sein scheint.

Also das was Thom aktuell vorschlägt, ist eigentlich auch genau das was ich (erstmal) brauche

 

[nik]

@theSplit: ist nur ein Vorschlag, weil du meintest, dass nicht bekannt ist, welche Distribution verwendet wird. rc.local findet man afaik nur auf Debian-basierenden Distributionen. Die Units könntest du auf allen Distributionen verwenden, die Systemd nutzen.
Und mir ist keine Distribution bekannt, die nicht cron laufen hat.

 

[theSplit]

Also aktuell ist das Zielsystem nicht bekannt, spätestens im Laufe der kommenden Woche werde ich wohl genaueres Wissen und mir hoffentlich ohne Probleme eine virtuelle Maschine anlegen können, um erste Tests vollziehen zu können.
Ich hoffe natürlich inständig das es nicht irgendwas utopisches ist.

Kann aber gut sein, wenn "rc.local" wirklich "nur" eine Debian bzw. Debian-Familienspezifische Lösung ist(?), dass ich nochmal Nachfrage bezüglich systemd bzw. Cron; aber erstmal wissen was dort läuft.

Ich werde aber ohnehin nicht darum herumkommen Bibliotheken nachzuinstallieren die ich für die Anwendungen benötige, so viel steht eigentlich schon fest. Wenn ich allerdings richtig Pech habe, ist es ein Custom-Linux, das wäre der GAU...

 

[musv]

Du hast da ein paar Unklarheiten in Deinen Ausführungen.

Wenn die Anwendungen reine Konsolenanwendungen sind, dann brauchst du keinen X-Server und auch kein startx. Um Anwendungen beim Systemstart zu starten, machst du das entweder über die o.g. rc.local (alt) oder systemd mit gesetztem User. Aber dazu musst du erst mal rausfinden, wie neu oder alt das Debian ist. Erst seit Debian 8 wird da Systemd benutzt.

Bei X-Anwendungen ist das etwas problematischer. Da wäre "eigentlich" am sinnvollsten für jedes Programm einen nested X-Server zu starten. Damit kannst du dann problemlos auf den jeweiligen X-Server mit der Anwendung darin per X-Forwarding zugreifen:

Xnest starten:

Xnest -ac :1.0 -geometry 640x400

Anwendung starten:

env DISPLAY=:1.0 $anwendung

Zugriff dann entweder über einen VNC-Server oder per XDMCP

 

[theSplit]

@musv: Ich weiß nicht ob es Debian ist, ich weiß das ich eine GUI Anwendung habe und eine Konsolenanwendung. Zumindest ein Fenster muß sich öffnen lassen.

Wie gesagt ist nur eine der beiden Anwendungen auf eine GUI angewiesen, aber ich glaube ein XServer / XSession ist das minimum. Es ist schon grafisch.

Ob ich einen Windowmanager brauche, weiß ich nicht, aber es sollte auch in einer X-Sitzung (wenn alle Treiber installiert sind) funktionieren. Denke ich. Hoffe ich.

Und dann noch die Frage, dass soll in den Autostart.

 

[thom53281]

Aber dazu musst du erst mal rausfinden, wie neu oder alt das Debian ist. Erst seit Debian 8 wird da Systemd benutzt.

Wobei auch unter Jessie die rc.local immer noch unterstützt wird.

 

[darksider3]

Wobei auch unter Jessie die rc.local immer noch unterstützt wird.

Wa r dass nicht systemd-sysvinit?

 

[Metal_Warrior]

Jupp, die konservative Entwicklungspolitik von Debian folgt dem Credo, dass ein Dienst, der einmal auf dem System gelaufen ist, auch bei großen Updates über mehrere Hauptversionen immer noch lauffähig zu sein hat, sofern es nicht überragende Gründe gibt, dieses nicht mehr zu tun (etwa weil eine Konfig-Option eklatante Sicherheitslücken bot oder ein neues Programmfeature eine Anpassung der Config in diesem Punkt nötig machte - wie etwa die sicherheitskritische Ausführbarkeit von Dateien über Samba, die kein Executable-Bit gesetzt hatten). Insofern funktionieren alte Sysinit-Skripte in aller Vollständigkeit, wie auch RC etc. Durch die Parallelisierung einiger Grundfunktionen kann es aber mitunter trotzdem zu Problemen kommen, aber das war auch beim Umstieg auf Systemd klar.

 

[darksider3]

@Metal_Warrior: OpenSSH hat da sowas. Weil Networking zu spät gestartet wird, kommt OpenSSH zu früh. Failed dann, weil die Networking-Abhängigkeit noch nicht erfüllt war.

BTW finde ich konservativ hier gut. Der Aufwand, alle Packete systemd-Kompatibel zu machen wäre einfach zu groß bei über 15 Tausend Packete, allein aus Stable.
Noch besser hätte ich es gefunden, kein systemd zu haben.

 

[Metal_Warrior]

@darksider3: Bei OpenSSH hatte ich jetzt keine Probleme, mir hatte es die Firewall zerlegt, weil mehrere Netzwerkinterfaces zeitgleich gestartet natürlich auch mehrere Firewallscripte gleichzeitig starten, die dann durcheinander fuhrwerken. Naja, musste ich das halt umschreiben.

Debian ohne systemd gibt es: Debuan. Ist halt die Frage, ob SysinitV eine so glorreiche Zukunft vor sich hat...

 

[darksider3]

@darksider3: Bei OpenSSH hatte ich jetzt keine Probleme, mir hatte es die Firewall zerlegt, weil mehrere Netzwerkinterfaces zeitgleich gestartet natürlich auch mehrere Firewallscripte gleichzeitig starten, die dann durcheinander fuhrwerken. Naja, musste ich das halt umschreiben.

Debian ohne systemd gibt es: Debuan. Ist halt die Frage, ob SysinitV eine so glorreiche Zukunft vor sich hat...

Mein Problem bei Devuan ist das selbe wie bei anderen kleinen Distros: Die aufmerksamkeit. Ich habe die Debian-ML-Diskussion dazu verfolgt...
Das Ding bei Systemd ist: Es ist ein Monolith. Das passt mir gar nicht. Auf Debian kann ich BTW auch ohne systemd(wie gehabt, sysvinit) arbeiten. Aber ich finde es schade, dass systemd so adoptiert wird. Mir fehlt die Konkurrenz.

Sicher, SysVinit hat Jahrzehnte seinen Dienst getan; Ist aber mittlerweile natürlich einfach veraltet. ABER es mit der einzigen Alternative zu ersetzen(und damit meine ich nicht Debian; Damit meine ich einfach 90% der Distros: Ubuntu, Fedora, RHEL...), ist mir einfach zuviel.
Ich will die Wahl haben. Das hat Debian bei mir immer ausgemacht. Nicht "der einzig Wahre weg". Du weißt was ich mein?


Back2Topic:
Der Login ist einfach nur ein Programm das von root beim Boot gestartet wird. rlogin/login ruft dann einfach einen Benutzerwechsel, droppt alle alten Privilegien und übernimmt die Rechte. Deshalb ist es auch immer so fatal gewesen, wenn login ne Lücke hatte.
Um einen Benutzer direkt über die TTY anzumelden musst Du beim X-Server den Default-Manager droppen, und bei dem jeweiligen User am besten eine xinitrc anlegen. Durch die startest Du dann einfach die Dienste und den DE. So hatte ich das damals gemacht. Aber da scheinen die anderen das fast genau so gemacht zu haben

 

[theSplit]

Mal die naive Frage in den Raum gestellt, "xinitrc" sollte ja praktisch überall funktionieren wo X installiert ist, oder? Im Gegensatz zu "rc.local" ?

Wie gesagt weiß ich nicht was dort läuft, "ein Linux"... hm ja.

Im übrigen gibt es glaube ich auch im weiteren das Problem, ich fange keine Keyboard eingaben ab, das wäre möglich, ist aber nicht implementiert - ohne Window Manager würde ja zum Beispiel Alt + F4 so nicht funktionieren, oder?
Derartiges würde ja erst vom Window Manager eingeführt werden?

Heißt also, wenn ich das als Autostart anlege, in einer normalen X Sitzung ohne WM, würde ich das Gerät ja so ziemlich verriegeln, da die Anwendung einfach nicht beendet werden kann?
Strg + C würde hier vermutlich auch nicht helfen, da es ja nicht aus einer Konsole ausgeführt wird...

Also käme ich gar nicht darum herum ein Fallback zum normalen Beenden der GUI Anwendung einzubauen?!

Oder wäre es alternativ noch möglich mit Strg + Alt + F1 in TTY1 zu wechseln, sich einzuloggen und dann die Arbeit zu verrichten? Theoretisch läuft die X Session ja auf Strg + Alt + F7?
Ich will das nur nochmal abstecken, nicht dass das in die Hose geht....

 

[musv]

Du willst eigentlich sowas hier, wobei ich das selbst nie getestet hab.