dhcp, ntp, vnc, httpd und udev?

[cosmac]

Servus!

irgendwie gehört diese Frage eher in die Abteilung Einstiegsfragen, andererseits geht es um eine ziemlich ungewöhnliche Installation. Daran wurde 12 Jahre lang bis auf Updates kaum etwas geändert. Vor 1½ Jahren wollte ich das mit Devuan neu aufbauen, aber dann war wieder etwas ganz anderes interessant. Jetzt wollte ich weitermachen, aber apt update funktioniert nicht. Der Fehler macht mich so nachdenklich, dass ich wieder bei Null anfangen möchte.

Der Ist-Stand:
Ein lüfterloser PC mit 15"- oder 17"-Touchscreen, Debian, openbox, epdfview, pcmanfm und einem festen Benutzerprogramm. Der PC wird normalerweise nie runter gefahren sondern einfach ausgeschaltet. Also ist alles read-only gemountet. Trotzdem muss der Benutzer eine neue config-Datei schreiben können und Daten auf einen USB-Stick kopieren können.

Das Netzwerk kann vom Benutzer konfiguriert werden: DHCP/feste IP/kein Netzwerk und NTP: per DHCP/Hostname/IP/kein NTP. Dafür gibt es ein suid-Programm, das im Prinzip nur "ifconfig eth0" macht. Das funktioniert nicht mehr, weil eth0 gelegentlich neue Namen bekommt. Oft gibt es keinen DNS-Server im Netzwerk, ein httpd, ein sshd und x11vnc müssen aber trotzdem laufen.

Die Systemzeit kommt zunächst per serieller Schnittstelle, die RTC wird nur benutzt, falls das nicht funktioniert. Im Betrieb wird optional rdate -n und adjtimex(2) benutzt. Das heißt, dass niemand sonst die hwclock oder die Kernel-Uhr anfassen darf.

Die seriellen Schnittstellen, echte und per USB-Konverter, müssen mit User-Rechten funktionieren. Dafür ist Hot-Plug nicht nötig, auch nicht für USB-Sticks, das kann der Kernel alleine. Allerdings wäre es nett, wenn es für X11-Tastatur und -Maus funktionieren würde. Das macht bisher ein udevd aus dubioser Quelle, die es nicht mehr gibt. Eine Alternative funktioniert ganz ohne udev, erfordert aber einen Neustart des x-servers. Das kann devuan wahrscheinlich viel besser, deren udev-Ersatz ist das entscheidende Argument.

Als Benutzer gibt es nur root, einen für die Anwendung und einen für den httpd. Login funktioniert nur auf den Text-Konsolen, es gibt keinen Display-Manager. Damit entfällt jegliche session/seat/user/whatever-Verwaltung.

Beim Booten wird ein Spezialprogramm gestartet (statt /etc/init/rcS), das dann X11, vnc usw. startet. Dieses Prinzip scheint mir nach wie vor zweckmäßig zu sein, weil damit möglichst wenig von der Distribution abhängt (die Kernel-Schnittstellen ändern sich ja doch eher selten). Das ganze würde wohl auch mit den Tools von busybox und init=busybox funktionieren.

Wie ich es mir wünsche:
Der Benutzer soll keinen Unterschied merken, aber innen drin soll es übersichtlicher werden, also eine normale Debian-Installation mit wenigen, verständlichen Anpassungen. Bisher war ich der Meinung, dass das nicht möglich ist. Oder sehr aufwendig wird und dadurch auch wieder unübersichtlich.

Aber wo fängt unübersichtlich an? Ist Debian oder Devuan für diese Sonderwünsche übersichtlicher? Oder ein angepasstes Debian (seit Bullseye werden ja alternative Init-Systeme offiziell unterstützt)?

[Tintom]

Beim Lesen habe ich den Eindruck bekommen, dass dein Konzept dieses Systems vielleicht an einem Debian von vor zwölf Jahren noch Stand der Technik war, aber bei einem modernen Debian kontraproduktiv wirkt.

Einige Beispiele:

Beim Booten wird ein Spezialprogramm gestartet (statt /etc/init/rcS), das dann X11, vnc usw. startet. Dieses Prinzip scheint mir nach wie vor zweckmäßig zu sein, weil damit möglichst wenig von der Distribution abhängt (die Kernel-Schnittstellen ändern sich ja doch eher selten).

Mit systemd erreichst du die gleiche Unabhängigkeit und zudem startet es die Software auch automatisch.

[...]es gibt keinen Display-Manager. Damit entfällt jegliche session/seat/user/whatever-Verwaltung.

Die Verwaltung funktioniert mittlerweile automatisch, da muss im Regelfall nichts mehr per Hand justiert werden.

Allerdings wäre es nett, wenn es für X11-Tastatur und -Maus funktionieren würde. Das macht bisher ein udevd aus dubioser Quelle, die es nicht mehr gibt.

Wozu man hierfür einen separaten udevd aus „dubiosen Quellen“ benötigt verstehe ich nicht.

Das funktioniert nicht mehr, weil eth0 gelegentlich neue Namen bekommt.

Das lässt sich auch relativ einfach beheben, es gibt verschiedene Möglichkeiten. Ganz klassisch würde ich es mit einer udev-Regel lösen.

Aber wo fängt unübersichtlich an? Ist Debian oder Devuan für diese Sonderwünsche übersichtlicher?

Was bedeutet für dich übersichtlich? Mit beiden kann man das gewünschte erreichen.

Oder ein angepasstes Debian (seit Bullseye werden ja alternative Init-Systeme offiziell unterstützt)?

Die werden schon seit einigen Versionen unterstützt, das Paket init ist schon lange ein Metapaket.

[cosmac]

Beim Lesen habe ich den Eindruck bekommen, dass dein Konzept dieses Systems vielleicht an einem Debian von vor zwölf Jahren noch Stand der Technik war, aber bei einem modernen Debian kontraproduktiv wirkt.

In der Tat, aber das soll ja jetzt besser werden.

Allerdings wäre es nett, wenn es für X11-Tastatur und -Maus funktionieren würde. Das macht bisher ein udevd aus dubioser Quelle, die es nicht mehr gibt.

Wozu man hierfür einen separaten udevd aus „dubiosen Quellen“ benötigt verstehe ich nicht.

Das funktioniert nicht mehr, weil eth0 gelegentlich neue Namen bekommt.

Das lässt sich auch relativ einfach beheben, es gibt verschiedene Möglichkeiten. Ganz klassisch würde ich es mit einer udev-Regel lösen.

Irgendein dubioser Ersatz war einfacher und zuverlässiger als diese Regeln. Die haben nie lange funktioniert, und das ist leider bis heute so: 1003835
udev: XEN domU:
Guest RX stalled, unreachable due to nw device naming change
"The predictable naming logic for network interfaces has been extended
to generate stable names from Xen netfront device information."

Ja, gut, XEN betrifft mich nicht, aber wer weiß, was nächstes Mal "extended" wird.

das Paket Debianinit ist schon lange ein Metapaket.

stimmt, ich benutze es auch. Allerdings sagt
https://wiki.debian.org/Init
Support for init systems other than systemd
is significantly improved in Bullseye.

[fischig]

Ganz klassisch würde ich es mit einer udev-Regel lösen.

Als „klassisch“ würde ich das nicht bezeichnen.
udev und systemd meide ich immer noch - wenn irgend ich kann.

[Tintom]

Irgendein dubioser Ersatz war einfacher und zuverlässiger als diese Regeln. Die haben nie lange funktioniert, und das ist leider bis heute so: 1003835

Das ist interessant, ich habe nämlich genau die entgegengesetzte Erfahrung gemacht. Die Regel für die Bezeichnung des WLAN-Adapters schleppe ich etwa seit wheezy (10 Jahre) auf diesem System mit. Funktioniert bis heute zuverlässig. Die Einführung der „unpredictable Interfacenames“ hatte keine Auswirkungen. Läuft einfach - typisch Debian.

Ganz klassisch würde ich es mit einer udev-Regel lösen.

Als „klassisch“ würde ich das nicht bezeichnen.

Für Puristen gibt es natürlich noch mknod

[fischig]

Für Puristen gibt es natürlich noch mknod

Eingehängtes devtmpfs tut's auch auf 'nem Heimrechner (seit ca. 2004).

edit: vergessene quote-tags eingefügt.

[cosmac]

Für Puristen gibt es natürlich noch mknod

Nur dass mknod nicht für Netzwerk-Interfaces funktioniert; da hat jemand vor 45 Jahren einen schweren Fehler gemacht.

Eingehängtes devtmpfs tut's auch auf 'nem Heimrechner (seit ca. 2004).

devtmpfs ist Schuld, dass ich Kernel selbst baue. Damals wollte ich das unbedingt sofort haben, und dann ist das Basteln zur Gewohnheit geworden. devtmpfs macht auch chgrp und chmod. Das funktioniert im Kernel natürlich viel problemloser als mit udev. Weil ja vieles über die Gruppe geregelt wird, könnte ein Distributionskernel diesen Teil von udev perfekt ersetzen. Auf einem Single User System oder auf meiner Spezialinstallation geht auch noch mehr. Wie gesagt, ich brauche udev nur, damit Hot-Plug für X11 funktioniert.

Ganz klassisch würde ich es mit einer udev-Regel lösen.

Ganz klassisch überlässt man das dem Kernel. Der weiß doch am besten, welche Devices aktuell zur Verfügung stehen. Auf wie vielen Rechnern sind denn die "natürlichen" Namen nicht eindeutig? 0.01% oder doch 1 von 1000? Und dort kann man ja udev benutzen, obwohl es doch eher eine Aufgabe für einen Network Manager wäre.

[fischig]

Für Puristen gibt es natürlich noch mknod

War mal wieder zu schludrig: Der Satz stammt von Tintom und ich habe in meinem Beitrag vergessen, ihn in qoute-tags zu setzen.
Hol' ich jetzt nach.

[Six]

Welchen Einsatzzweck verfolgst du denn mit der Kiste? Also, was soll sie tun und wozu?

Wenn man das wüsste, könnte man dir vielleicht eine Richtung weisen. Ich glaube nämlich, das "wie" kannst du schon

[cosmac]

Welchen Einsatzzweck verfolgst du denn mit der Kiste? Also, was soll sie tun und wozu?
Wenn man das wüsste, könnte man dir vielleicht eine Richtung weisen. Ich glaube nämlich, das "wie" kannst du schon

Das ist im Prinzip ein schlaues Grafikterminal. Ein paar Schaltschränke voller Hardware liefern Daten und dieser PC bringt die menschenlesbar auf den Monitor. Mensch kann sich Daten auf einen USB-Stick kopieren und kann von da neue Parameter für die Hardware laden. Optional kann man das Teil auch per http oder vnc bedienen. Für mich gäbe es noch einen sshd, aber oft gibt es garkein Netzwerk und wenn, kommt man von außen nur mit endlosem Papierkrieg dran.

Der "Desktop" beschränkt sich auf openbox. Normal sieht man nur das Fenster des Anwendungsprogramms und das als Vollbild. Von da aus kann man den Dateimanager starten und Handbuch-PDFs lesen. Updates werden auch von dem Programm verwaltet. Die kommen als foo.tgz mit einzelnen Dateien, man kann damit aber auch ein komplett neues System aufspielen.

Das ist alles ganz wunderbar für den Benutzer, aber innen drin wird die Debian-Installation auf ziemlich ungewöhnliche Art und Weise benutzt. Zum Beispiel ist /boot leer, es gibt keine initrd und /etc/init.d/rcS ist ein eigenes Programm, also fast ein eigenes Init-System. Das war die einfachste Möglichkeit, /etc/init.d/hwclock.sh los zu werden.

Jetzt träumte ich, dass man ein Original Default Debian installiert, dazu ein paar Pakete wie openbox und Freunde, und dann nur noch ein Paket mit der eigentlichen Anwendung. Leider habe ich überhaupt keinen Plan, was dann alles nicht mehr möglich ist. Gerade fällt mir ein, dass mein Programm für die Updates volle root-Rechte braucht. Was passiert, wenn es in einer cgroup eingesperrt ist?

Ein teuflischer Plan: alles ist original, mein foo.deb sieht auch ganz normal aus, aber es ergänzt die kernel cmdline in grub: 'init=/bin/foo'. Ab dem nächsten Neustart sieht die Installation noch völlig normal aus, aber alles hört auf mein Kommand Das ist nicht so krass wie es sich anhört. Es geht schließlich um eine feste, genau definierte Anwendung.

Nett, aber nicht einmal das funktioniert zuverlässig. Ich weiß ja nicht, was in der initrd gemacht wird. Und brauche trotzdem einen alternativen udevd oder muss auf Tastatur-Hot-Plug verzichten.

Es ist wohl aussichtslos. Vielen Dank für die Aufmerksamkeit und entschuldigen Sie bitte die Störung.