Inetd für ds26 >= 14.4

Update: Dieses Paket ist in DS-Mod ab 26-15 bereit integriert

Inetd-Patch für DS-Mod 0.2.9_26-14.4 und Zusammenfassung:

Die Implementierung und Konfiguration des Inetd im DS-Mod ist nun weitestgehend komplett. Grob gesagt funktioniert das Ganze jetzt so, dass der Inetd ausgewählt werden und ein zugehöriges Paket 'inetd' installiert werden kann. Dienste können dann eine Konfiguration bereitstellen, die es erlaubt, diese Dienste über inetd zu starten. Das Ganze ist komplett im DS-Mod-WebIf integriert.

Meine Lösung besteht jetzt aus drei Teilen:

1. Inetd-Patch für DS-Mod 0.2.9_26-14.4 v0.2

• Im menuconfig gibt es eine Option BusyBox-Optionen. Darunter kann man den inetd aktivieren. Wird diese Option ausgewählt, wird die BusyBox entsprechend mit inetd gebaut.
• Dropbear wird immer zusätzlich mit dem Inetd-Modus gebaut. Wie gesagt, er wird dadurch lediglich um 36 Bytes größer, das sollte jeder verschmerzen können.
• Der busybox-httpd in Version 1.4.1 hat eine fehlerhafte Behandlung von POST-Requests im inetd-Modus. Dies ist in 1.5.x behoben. Die entsprechenden Änderungen wurden per Patch auf den 1.4.1er httpd zurückportiert.
• Der busybox-inetd wurde dahingehend gepatcht, dass die 1024-Byte-Variable line (siehe Post http://www.ip-phone-forum.de/showpost.php?p=867589&postcount=22 von RalfFriedl) nur beim (Neu-)Einlesen der Config allokiert wird.
• Config und makefile für inetd-Paket eingebunden
• DS-Mod-WebIf: Seite 'Dienste' (daemons.cgi) zeigt nun ggfs. Status 'inetd' an.
• DS-Mod-WebIf: save.cgi angepasst, so das nötigenfalls die inetd.conf-Datei aktualisiert wird und der inetd entsprechend zum Neuladen selbiger veranlasst wird.
• Telnetd und DS-WebIf für Inetd vorbereitet. Hierzu ist jeweils
  • rc-Script angepasst
  • inetd-Script angelegt
  • Weboberfläche angepasst (Startart inetd)

2. Inetd-Paket 0.1

• /usr/bin/modinetd - Dieses Script kann die inetd.conf Datei für einzelne oder alle inetd-fähigen Dienste aktualisieren und bei Bedarf auch im Flash speichern (per modsave).
• /etc/init.d/rc.inetd - Starten und Stoppen des inetd-Dienstes. Hat auch eine Option reload, die den Dienst zum Neuladen der inetd.conf veranlasst
• Web-If-Seite zur Konfiguration des Inetd (Startart und zusätzliche Argumente)

3. Patch zum dropbear-0.49-dsmod-0.5-Paket
Dieser Patch verwandelt das Dropbear-Paket in eine Referenzimplementierung eines Inetd-Fähigen Dienstes für den DS-Mod. Die einzelnen nötigen und daher auch hier durchgeführten Anforderungen sind:

• Anpassung des rc-Scripts. Wenn die Startart des Dienstes (in diesem Falle die Konfigurationsvariable DROPBEAR_ENABLED), die bisher 'yes' oder 'no' (automatisch oder manuell) enthalten konnte, den Wert 'inetd' enthält, dann muss der von rc.package status zurückgelieferte String 'inetd' lauten. Hierfür muss die Config des Pakets natürlich auch für den Befehl 'status' eingebunden werden.
• Das rc-Script muss ggfs. auch so angepasst werden, dass zum Start des Dienstes notwendige Konfigurationsdateien oder sonstige Vorraussetzungen bereits im load() erzeugt werden. Alternativ kann man solche Anpassungen auch noch im inetd-Script (s. nächster Punkt) erledigen, wenn nicht anders möglich.
• Anlegen eines kleinen Scripts /etc/default.package/package.inetd. Diese Script benötigt keine shebang (#!/bin/sh)-Zeile, da es nur von modinetd aufgerufen wird. Es muss eine Reihe von Variablen setzen (siehe entsprechende Datei im Patch), aus welchen von modinetd die inetd.conf-Zeile für den Dienst erstellt wird.
• Anpassung des cgi-Scripts. Wenn das Inetd-Paket installiert ist, muss zusätzlich die Startart 'inetd' auswählbar sein.

Bei mir läuft die ganze Geschichte seit einigen Tagen stabil. Es gab auch keine wirklichen Probleme bei der Implementierung, man vergisst nur schnell die eine oder andere Stelle, wo eine Anpassung nötig ist.

Vorgehensweise zum Testen wäre die folgende:

1. Einigermaßer 'sauberer' dsmod_26-14.4 als Ausgangsbasis
2. Den Inetd-Patch auf selbigen anwenden.
3. Das bestehende Dropbear-Paket, sofern noch nicht in packages, manuell aus dem dl-Ordner nach dort entpacken
4. Den Dropbear-Patch entsprechend im Ordner packages/dropbear-0.49 anwenden
5. Das Inetd-Paket manuell nach packages entpacken
6. make menuconfig
   • BusyBox-Optionen, Inetd auswählen
   • Pakete->Testing->Inetd auswählen
7. Wenn noch nicht geschehen:
   • make precompiled
   Andrenfalls:
   • make dropbear-clean; make dropbear-precompiled (damit der Dropbear mit inetd-Modus gebaut wird)
   • make busybox-clean; make busybox-precompiled (damit die busybox mit inetd gebaut wird)
8. make
9. Installieren und mit spielen WebIf usw. sollte selbsterklärend sein.
10. Vorsicht. Wenn 'wichtige' Dienste über Inetd gestartet werden, sollte man Inetd natürlich auf 'Automatisch' stellen. Im Notfall kann der telnetd natürlich nach wie vor über das Telefon manuell gestartet werden.

ACHTUNG! Das Ganze ist noch absolut experimentell. Ich übernehme keinerlei Garantien.

Gruss, Nico

Edit: dsmod26-14.4-inetd-0.2.patch: save.cgi gefixed


Ursprünglicher Thread-Beginn:

Hallo,

ich bastel gerade daran, den rcapid selbst für die Fritzbox zu kompilieren. Da dieser ja einen Inetd vorraussetzt, musste ich an den natürlich auch ran, und dabei kam mir die Überlegung, dass es für den DS-Mod an sich vielleicht auch interessant sein könnte, einen Inetd zu integrieren, und (eventuell nur falls dieser ausgewählt wurde) verschiedene der Dienste über selbigen zu starten, was, wenn die Services nicht parallel genutzt werden, eventuell zu einem verringerten Speicherbedarf (RAM!) der Box führen könnte.
Ich habe jetzt nicht nachgeschaut, ob und welche der Dienste das unterstützen, aber interessant könnte es zumindest für telnetd, dropbear, evtl. den oder sogar die HTTP-Server, den FTP-Server, Samba, und OpenVPN sein, was die Pakete betrifft, die bisher im Mod enthalten sind. Da müsste man einfach mal prüfen, mit welchen Diensten das funktioniert und auch Sinn ergibt.
Weiterhin dürfte das auch intressant für diejenigen sein, die zusätzlich bspws. einen Apache oder andere Serverdienste einrichten möchten, insbesondere, wenn diese nur selten benutzt werden.

Die Frage, die sich dann als nächstes stellen würde, wäre, welcher der zahlreichen verfügbaren Inetds verwendet werden soll.

• Der BSD-Inetd hat den Vorteil, dass er klein ist (mips-Binary aus dem Debian-Source ca. 38 KB) - dafür hat er nur eine einzelne Konfigurationsdatei und auch sonst nicht sehr viele Features.

• Der XInetd hat sehr viele Features, unter anderem unterstützt er einzelne Konfigurationsdateien für jeden Service (Was sehr praktisch ist, wenn man unterschiedliche Pakete einfach einbinden möchte), aber leider wird das Binary 204 KB groß

• Zu beiden könnte man dann noch TCP Wrappers linken - die libwrap.so dürfte knapp 30 KB haben, das tcpd-Binary nur 4 oder so. Damit könnte man dann auch noch zusätzlich die hosts.allow und hosts.deny-Mechanismen benutzen.

Wenn da Interesse besteht (insbesonder auch von den Mod-Entwicklern und den Entwicklern der einzelnen Pakete), dann würde ich mich mal daran machen, entsprechende Patches für den DSMod zu erstellen.

Gruss, Nico

Ah, an die busybox hatte ich noch gar nicht gedacht. Das wär ja an sich die optimale Lösung. Ich denke auch, dass das mit den einzelnen Files gar nicht so wichtig ist, wie ich ursprünglich dachte, da ja seltenst im laufenden Betrieb Dienste hinzukommen oder entfernt werden (wie bei einem 'normalen' System, wenn man Pakete nachinstalliert). Ansonsten ist die Konfiguration ja pro Dienst mit einer Zeile erledigt, die kann man ja ganz einfach anhängen.

Was die TCP Wrapper betrifft: Ich denke, dass das das ist, was Du meinst, bin aber nicht 100%ig sicher. Auf der FBox verwend ich NFS nicht, und in meinen übrigen System sind die tcp wrapper sowieso installiert

Ja, richtig. Ich weiss nicht, ob nfs zwingend tcp wrapper benötigt, da die exports ja für bestimmte IP-Adressen eingeschränkt werden können.

So, ich hab mir jetzt mal grundlegend die Makefile- bzw. Config-Struktur angeschaut (hatte sowas bisher noch nicht gesehen, nur benutzt ). Da bisher die Busybox aus einem der vier statischen Config-Files gebaut wird (wenn ich das richtig verstanden habe), müsste man hier irgendwie basteln, damit man bei der Busybox zusätzlich den Inetd auswählen kann. Mir ist leider nicht ganz klar, wie sowas aussehen müsste. Ich denke aber, es könnte eventuell auch noch ganz interessant sein, um andere bisher deaktivierte oder nicht zwingend benötigte Features der busybox manuell an- und abwählen zu können.
Weiterhin müsste man (am besten abhängig davon, ob der inetd gebaut ist) beim Dropbear und evtl. auch weiteren Paketen die Indetd-Unterstützung aktivieren. Zumindest beim Dropbear hab ich gesehen, dass es nicht aktiv ist.

• Auf meiner Box hab ich mal testweise den telnetd und httpd über einen separat installierten (bsd-)inetd gestartet. Das scheint überhaupt kein Problem zu sein. Kann einloggen und DS-Mod-Webinterface funktioniert und geht auch nach meinem Empfinden normal schnell.

• Der normale ftpd hat leider offenbar keinen inetd-Modus an Bord. Wenn man bftpd installiert, ersetzt der dann den 'normalen'? Denn der hat Unterstützung für inetd. Hier ist allerdings noch das Problem, dass der ftpd normalerweise von hotplug gestartet wird. Man könnte aber ein kleines Wrapper-Script schreiben, was die entsprechenden Konditionen abfragt, und sonst eben die Verbindung sofort wieder schliesst.

• Dropbear kann mit inetd-Support gebaut werden, ist dies aber momentan (zumindest in meinem -13er Mod) nicht. Hierbei gäbe es auch noch was zu tun: das rc-Script von Dropbear erzeugt ja im Zweifel noch Keys. Aber das Script kann man ja weiterhin bestehen lassen, so dass es nur noch die Keys erzeugt, aber Dropbear nicht mehr startet.

Weiteres Problem, was prinzipiell fast alle Dienste betreffen würde: Wenn diese im Webinterface an- und abschaltbar sind, muss man sich hierfür etwas einfallen lassen. Entweder man wrappt hierfür alle vom inetd gestarteten Dienste in ein Script (was evtl. zu Lasten der Performance geht, vor allem bei Diensten wie dem HTTP, der ja immer neue Connections aufmachen muss), oder man müsste die inetd.conf on the fly per script editieren und dem inetd dann ein HUP schicken, damit er sie neu einliest. Letzteres wäre wohl die bessere Lösung, allerdings weiss ich nicht genau, wie das Editieren funktionieren könnte (ist die Datei beschreibbar, und wenn ja, wie).

Wie ihr seht, sind meine Kenntnisse, was die Interna der Box und des Mod betrifft, noch ein wenig beschränkt, d.h. alleine werde ich das Ganze nicht hinbekommen (auch weil ich nicht die Zeit habe, mich in alle entstehenden Probleme und Funktionen einzuarbeiten). Ideal wäre es, wenn einer der Mod-Entwickler mitarbeiten würde, vor allem bezüglich der Frage, auf welchem Weg bestimmte Probleme gelöst werden sollten. Und wichtig ist natürlich zuerst mal die Frage, ob sowas überhaupt offiziell in den Mod rein soll.

Danke erstmal für die Infos .

Was die busybox-Optionen betrifft: Manuell ist das schon klar, aber wenn man inetd optional anbieten möchte im DS-Mod, müsste man ja vom ds-make-menuconfig aus auch Optionen der Busybox ändern können, was momentan nicht geht, so weit ich das sehe.

Mittlerweile bin ich 2-3 Schritte weiter:

httpd
Wie sich herausgestellt hat, gab es mit dem httpd doch Probleme, und zwar beim übergeben von Post-Daten. Der httpd hat diese im Inetd-Modus nicht eingelesen. In der aktuellen Busybox aus dem Subversion-Repository ist das Problem behoben. Ich habe den Fix mal als Patch auf die 1.4.1 zurückportiert, und siehe da, dann funktioniert es wirklich.

dropbear
Den dropbear mit inetd-Unterstützung zu bauen erfordert das einstellen eines #defines in der dropbear/options.h. Interessanterweise ist das defaultmässig an, wird aber vom ds-mod ausgepatcht. Die dadurch erzielte Ersparnis im Filesystem liegt bei sage und schreibe 36 (in Worten sechsunddreissig) Bytes. Ich denke fast, das könnte man einfach per default drin lassen. Eher interessant wäre es, wenn man den inetd einbindet, den Daemon-Mode abzuschalten. Das brächte dann nämlich eine Ersparnis von immerhin 3020 Bytes gegenüber dem Dropbear mit Daemon-Mode. Allerdings ist dies wie gesagt nur über die options.h möglich, und um das vom ds-make-menuconfig aus zu steuern müsste man wohl noch ein #define drumrumpatchen, um es vom make aus anzusteuern.

ftpd
Der ftpd hatte mich etwas in die Irre geführt. Er hat natürlich wohl einen inetd-Modus. Das funktioniert auch im Prinzip, ich habs allerdings noch nicht hinbekommen, dass er vom inetd aus die Option für den Hostnamen akzeptiert (normalerweise wird er mit -h FRITZ!Box Fon WLAN 7170 gestartet. Auch Anführungszeichen bringen nix, vom inetd gibts dann immer nur die usage-Meldung). Darüber hinaus kann ich mich nicht anmelden (das betrifft aber auch den standalone-ftpd), welchen Benutzernamen/Passwort will der haben :noidea:?

Wenn wir sowieso ein Script erstellen, mittels dem man dynamisch Einträge in die inetd.conf einfügen und entfernen kann, dann ist es wohl auch kein Problem, die hotplug-Scripts für den ftpd so zu patchen, dass sie das machen, anstatt den ftpd direkt zu starten.

Zusammenfassung / Weiteres Vorgehen

• Ich bin jetzt so weit, dass der busybox-inetd zumindest telnetd, httpd, ftpd und dropbear bereitstellen kann. Weitere Dienste wie samba usw. überlasse ich erstmal den jeweiligen Paketverwaltern, da ich die selbst nicht verwende.
• Bei den Paketen (Diensten) könnte man als Starttyp bei aktiviertem Inetd zusätzlich zu 'Automatisch' und 'Manuell' auch noch die Option 'Inetd' anbieten. Davon abhängig könnte man die rc-Scripte so abändern, dass sie statt den daemon direkt zu bedienen den Eintrag in der inetd.conf ändern. Der Inetd muss nach so einer Änderung nicht neugestartet werden, sondern es reicht, ihm ein HUP zu senden, damit er die Datei neu einliest und entsprechend die Ports auf- und zumacht. Diese ganze Scripterei ist wohl der größte Aufwand bei der Sache.
• Wie schon angedeutet, denke ich, es wäre sinnvoll, den Inetd in der DS-Mod-Konfig optional anzubieten.

Was meint ihr, und was soll ich als nächstes machen? Und wo/wie möchtet ihr evtl. meine Patches haben?

Gruss, Nico

Tja, das ist eben die Frage, wie der Inetd in den DS-Mod integriert werden soll. Meiner Ansicht nach gibt es 3 Möglichkeiten:

1. Inetd immer bauen. Alle Pakete so weit möglich fest damit einbauen.
2. Inetd als Option im DS-Mod anbieten. Wenn Inetd integriert ist, alle Pakete mit Starttyp automatisch darüber laufen lassen.
3. Inetd als Option im DS-Mod anbieten. Falls Inetd integriert ist, kann man einzelne Pakete entweder über Inetd starten lassen oder weiterhin wie bisher als Standalone-Daemon. Letzteres kann ja auch Vorteile haben, wenn ein Dienst sehr häufig gebraucht wird oder sehr oft neue Verbindungen aufmacht, was der Performance nicht gerade zuträglich ist, wenn er dann jedesmal neu geladen werden muss (z.B. httpd oder auch samba - ich habe keine Ahnung, wie sich das Starten über inetd auf die Performance auswirkt)

Die letzte Möglichkeit ist halt am flexibelsten, daher favorisiere ich die. Aber ich bin ja nicht die entscheidende Instanz ;-).

So, ich habe nun einen Patch gebaut, der den Inetd grundlegend im DS-Mod verfügbar macht. Folgendes ändert sich dadurch:

• Dropbear wird immer zusätzlich mit dem Inetd-Modus gebaut. Wie gesagt, er wird dadurch lediglich um 36 Bytes größer, das sollte jeder verschmerzen können.
• Im menuconfig gibt es eine Option BusyBox-Optionen. Darunter kann man den inetd aktivieren. Wird diese Option ausgewählt, wird die BusyBox entsprechend mit inetd gebaut.

Mehr habe ich jetzt noch nicht gemacht, da ich an sich gehofft hatte, von den DS-Mod-Entwicklern noch ein wenig mehr Input bezüglich der weiteren Vorgehensweise zu bekommen (siehe meine beiden vorigen Posts).

Gruss, Nico

@olistudent: Ich hoffe, Du hast meine Äußerung(en) nicht als Drängelei aufgefasst. Wollte nur sagen, dass ich mit dem weiteren Vorgehen noch warte, bis sich die sinnvollste Vorgehensweise gefunden hat.

Zum Thema:

AVM-WebIf: Soweit ich das sehe, werden wir das nicht über den inetd zum laufen bringen. Es gibt keinen dokumentierten inetd-Modus, und auch keine undokumentierte Option -i, d.h. der websrv startet immer im Daemon-Modus und versucht sich an Port 80 zu binden. Er verweigert demnach auch den Dienst, wenn ich ihn über den inetd starten will. In meinen Augen ein Ärgernis, denn er tut sich von den laufenden Prozessen mit am meisten Speicher weg, was sicherlich auch daran liegt, dass er gleich 4 Prozesse forkt - wenn die lediglich dazu da sind, bei mehreren parallel ankommenden Requests schneller zu antworten (so wie dies üblicherweise bei einem http-daemon gemacht wird) für mich völlig unverständlich - wer soll denn alles gleichzeitig mit dem WebIf 'arbeiten'? Oder steckt da noch was anderes hinter?

Was die Zuverlässigkeit betrifft: Ich denke, dass inetd an sich schon sehr zuverlässig ist, egal, welche Lösung man jetzt verwenden möchte. Das Thema tcpwrapper sehe ich primär erstmal losgelöst von der Frage nach dem inetd: Bisher ist es so, dass jeder Dienst einfach seinen Port aufmacht. Das ändert sich durch den inetd ja erstmal nicht. Es führt nur dazu, dass es die zusätzliche Möglichkeit der Absicherung gibt.

Den xinetd hatte ich im ersten Post ja auch schon vorgeschlagen. Damit der den tcp-wrapper-Sicherheitsmechanismus intern unterstützt, muss allerdings auch für den die libwrap dazu gebaut werden, wenn ich es richtig sehe. Es ist kein Problem, den xinetd für die Box zu bauen - nur leider ist das Binary dann erstmal (wie im ersten Post erwähnt) gut 200 KB groß. Dazu käme dann nochmal eine libwrap (wenn man möchte), die wohl auch um die 30 KB groß würde (das hab ich noch nicht probiert). Der Busybox-Inetd vergrößert letztere aber nur um lächerliche 11 KB. Wenn der xinetd läuft, wird der also vermutlich auch um einiges mehr Speicher brauchen, als die busybox. Ich denke fast, das ist die Vorteile nicht wert. Auf der anderen Seite wäre es natürlich auch möglich, beide Varianten anzubieten. Ich glaube, der xinetd unterstützt neben seinem eigenen, 'Ein Config-File pro Dienst'-Mechanismus auch eine Standard-inetd.conf. Man könnte so das Handling der Konfiguration u.U. sogar verallgemeinern.

Gruss, Nico

Ja, ein Daemon muss das explizit unterstützen. Technisch funktioniert das so, dass der inetd sich an alle Ports hängt, die er konfiguriert hat. An jedem Port kann nur ein einzelner Dienst lauschen. Der inetd nimmt die Verbindung dann an und startet für jede eingehende Verbindung (!!, das ist u.U. halt ein Overhead bzw. ein Performanceproblem) jeweils neu den Dienst, der dort konfiguriert ist, und verbindet die Netzwerkverbindung mit dem Stdin/Stdout des Dienst-Prozesses. Der Dienst selbst läuft also erstmal gar nicht (und hier wäre die Speicherersparnis im 'Normalbetrieb', d.h. wenn nicht alle Dienste benutzt werden).

Daraus ergibt sich an sich, dass man eher selten benutzte Dienste über inetd starten sollte, und häufig benutzt bzw. performancekritische (wie z.b. bei einem reinen Webserver der httpd) direkt am Port lauschen und u.U. schon diverse Prozesse laufen lassen ('prefork'). Bei uns ist das Hauptkriterium in den meisten Fällen wohl selten benutzter Dienst und Speicherersparnis im Allgemeinen.

Im Prinzip gibt es dann theoretisch noch eine weitere Möglichkeit, Speicher zu sparen, und zwar im Dateisystem: Die Implementierung des Inetd-Modus ist simpler als die eines eigenen Daemons, woraus auch resultiert, dass ein Dienst ohne Daemon-Modus ein kleineres Binary hat. Wie schon angedeutet, brachte das Abschalten des Daemon-Modus im Dropbear bei mir ein um ca. 3 KB kleineres Binary. Ich weiss nicht, ob wir das auch nutzen wollen, denn ich hab keinen Überblick, wie 'eng' eine 4MB-Box wirklich wird, und ich weiss auch nicht, wo man das überhaupt sonst noch abschalten könnte als beim Dropbear.