Inetd für ds26 >= 14.4

[McNetic]

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

 

[olistudent]

Angesichts des knappen Speichers auf der Box ist sowas natürlich hoch interessant.
Ich würde als erstes mal den inted der busybox versuchen. Auch wenn der wohl nur eine Konfigurationsdatei hat. Da müssen wir uns dann überlegen wie wir das machen.
TCP Wrappers ist auch das was man für einen NFS-Server braucht?

MfG Oliver

 

[McNetic]

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

 

[derheimi]

Ich dachte, die 'TCP Wrapper' sind dafür da, den jeweiligen Service für bestimmte IP-Adressen im Netz einzuschränken (siehe http://www.linuxfibel.de/wrapper.htm
). Braucht man i.d.R. eigentlich nicht, zumindest nicht, wenn der Platz knapp ist

Das, was man für NFS braucht, ist der portmap-Daemon.

 

[McNetic]

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.

 

[McNetic]

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.

 

[kriegaex]

Grundsatz-Aussage, die ja Oliver auch schon in ähnlicher Form gemacht hat: Wenn es uns eine sauberere Struktur und/oder Ressourcen-Ersparnis bringt und mit allen relevanten Diensten gut funktioniert, macht es Sinn, es in den DS-Mod zu integrieren.

Zur Build-Struktur allgemein: Schau mal ins DS-Mod-Wiki, dort gibt es Artikel über die wichtigsten Make-Targets (z.B. busybox-menuconfig) sowie einen etwas detaillierteren Überblick über die gesamte Build-Struktur. Somit kannst Du die Busybox testweise so konfigurieren, daß inetd aktiv ist. Bei Dropbear kannst Du ggf. den Configure-Aufruf in make/dropbear/dropbear.mk entsprechend anpassen, sofern das die richtige Stelle für Dropbear ist (nicht nachgeschaut).

Die Konfiguration des inetd on the fly zu editieren, kriegen wir hin, wenn es soweit ist. Da hilft Dir auch jemand. Schau erst mal, wie weit Du kommst mit manuellem Testen sämtlicher Dienste, um die grundsätzliche Machbarkeit und Stabilität zu verifizieren.

 

[olistudent]

Die busybox-Optionen werden mit "make busybox-menuconfig" geändert. Danach "make busybox-clean" und "make busybox-precompiled".
Die inetd.conf müsst dann in /etc als Link eingefügt werden, der nach /mod/... zeigt.
Die Config könnte man per sed ändern.
Natürlich wäre diese inetd-Sache ein grundlegende Änderung des dsmod.

MfG Oliver

edit: Zu langsam ;-)

 

[McNetic]

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

 

[olistudent]

Das hört sich schonmal richtig gut an. Was spricht denn dagegen den inetd per Default zu aktivieren, also als Startoption Automatisch.
Patches mache ich mit "diff -burN ...". Die kannst du ja in ein tar.bz2 packen und hier anhängen. Dann bau ich das ein.

MfG Oliver

 

[McNetic]

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 ;-).

 

[McNetic]

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]

Der dsmod-Entwickler (Oliver) hat überhaupt keine Ahnung vom inted -> kein Input.
Aber ich werd mir das mal anschauen und mich dann im Lauf der nächsten Woche mal melden.

MfG Oliver

 

[derheimi]

Ich bin zwar kein dsmod-Entwickler, würde aber gerne auch meine Senf dazugeben (falls es jemand interessiert):

[*]Inetd immer bauen. Alle Pakete so weit möglich fest damit einbauen.
[*]Inetd als Option im DS-Mod anbieten. Wenn Inetd integriert ist, alle Pakete mit Starttyp automatisch darüber laufen lassen.

Das fände ich beides nicht so toll. Bei den Paketen, die ich nutze, kann ich mich z.B. nicht so sehr für den inetd erwärmen, Begründung siehe unten.

[*]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 Variante würde ich auch am liebsten sehen - da hat jeder dann die größte Freiheit zu wählen, wie er es haben möchte. Aber jetzt zur Begründung warum ich (für mein persönliches Setup) den inetd nicht wirklich nehmen würde. Ich geh mal meine Pakete durch:

• dnsmasq - der muss sowieso immer laufen, den zu wrappen, macht also keinen Sinn
• dropbear - hier würde es sinn machen, weil man ja eigentlich nicht immer auf die Box zugreifen will; auf der anderen Seite habe ich das Teil lieber permanent gestartet, damit ergibt sich eine (potentielle) Fehlerquelle weniger. Denn wenn ich auf die Box muss und dann klappts grad nicht, weil SSh nicht hochkommt (grad zu wenig Speicher oder sowas z.B.), dann wäre das unschön.
• telnet - dito, wobei man noch überlegen könnte eines von beiden durch inetd zu jagen und den anderen Daemon permanent laufen zu lassen. Ja, ich glaube, dass wäre meine Wunschkonfig.: Telnet via inetd, ssh standalone
• snmpd - hm, keine Ahnung, ob der inetd unterstützt, aber da der auch alle 5min von mrtg abgegriffen wird, wäre mir das auch zu viel Overhead
• openvpn - geht glaube ich nicht
• bird - geht nicht
• AVM-WebIf - würde ich auch liebe Standalone lassen, allein deshalb, damit der "nicht-so-erfahrene" dsmod-Benutzer notfalls wieder zurückflashen kann (das recover von AVM geht ja nicht mit allen Boxen, oder?)
• DSMOD-WebIf - hier wäre inetd sinnvoll, weil ich die EInstellungen nur selten ändere
• WOL-WebIf - dito, braucht man eher selten

Bei den letzten beiden, müsste man halt schauen, ob es die große Speicherersparnis bringt.
Zu den hier noch angesprochenen Paketen (b)ftpd und samba würde ich meinen, dass da auch jeder sein "Nutzungsverhalten" checken muss. Gerade bei samba könnte ich mir vorstellen, dass es schon sehr langsam wird.

Ok, das waren meine 2cents

 

[kriegaex]

Wo wir schon beim Meinungsaustausch sind: Ich würde es als sinnvoll erachten, alles, was nur irgend geht, optional auf inetd laufen lassen zu können, denn wenn die Box eines nicht hat, dann genügend RAM für viele Pakete. Optional bedeutet aber tatsächlich auch tendenziell Lösung #3, denn daß jemand eine Ausnahme haben will, kann ich verstehen. Ich persönlich würde dabei vermutlich rigoroser vorgehen und sämtliche Web-Ifs (AVM, DS, WoL) auf den inetd legen, dazu auch Dropbear. Das Argument, er könne evtl. nicht starten, wenn der Speicher zu voll wäre, würde ich nicht gelten lassen, denn der inetd hilft ja gerade beim Speichersparen.

Ich selbst bin ebenso neu in der Materie wie Oliver, aber wenn man sich ein wenig einliest, stößt man als Alternative zu inetd und tcpwrapper (als Sicherheitskrücke) schnell auf den längst etablierten xinetd, der die Zugangskontrolle integriert hat. Wie wäre es, wenn wir versuchen würden, xinetd zum Laufen zu bringen mit unseren Diensten? Siehe http://www.linuxfibel.de/inetd.htm.

Welche der beiden inetd-Varianten auch immer es sein würde, eines wäre elementar: absolute Zuverlässigkeit und Stabilität, damit wir uns nicht selbst den Teppich unter den Füßen weg ziehen. Ein Single Point of Failure für mehrere Dienste ist der unvermeidliche Nachteil des großen Vorteils inetd.

 

[McNetic]

@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

 

[kriegaex]

Da habe ich wohl nicht weit genug zurück geblättert wegen xinetd, Entschuldigung. Wie ist das eigentlich technisch? Muß ein Daemon den inetd wirklich explizit unterstützen? Kann man nicht einfach ein Start-/Stop-Skript verwenden, um ihn hoch- und herunterzufahren? Darf z.B. websrv nicht Port 80 belegen, weil inetd dort hört? Aber andere Webserver laufen doch auch auf 80. Oder tunnelt inetd sämtliche Verbindungen nur durch zum eigentlichen Dienst, der auf einem ganz anderen Port hört - eine Art Portmapping? Du siehst, ich kenne das Thema wirklich nicht.

 

[McNetic]

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.

 

[RalfFriedl]

Muß ein Daemon den inetd wirklich explizit unterstützen? Kann man nicht einfach ein Start-/Stop-Skript verwenden, um ihn hoch- und herunterzufahren? Darf z.B. websrv nicht Port 80 belegen, weil inetd dort hört? Aber andere Webserver laufen doch auch auf 80. Oder tunnelt inetd sämtliche Verbindungen nur durch zum eigentlichen Dienst, der auf einem ganz anderen Port hört - eine Art Portmapping? Du siehst, ich kenne das Thema wirklich nicht.

Der inetd liest seine Konfiguration und macht dann einen bind() Systemaufruf für jeden Port der Konfiguration. Wenn eine Verbindung auf diesen Port kommt, nimmt er mit accept() die Verbindung an und startet das dazugehörige Programm. Dieses Programm bekommt die bestehende Netzwerkverbindung auf stdin, stdout und stderr, also auf den Descriptoren 0, 1 und 2. Die ganze weitere Netzwerkkommunikation läuft dann direkt ab.
Mit Portmapping hat das nichts zu tun, die Verbindung wird auch nicht weitergereicht

Damit kann prinzipiell jedes Programm netzwerkfähig gemacht werden. Man kann darüber zum Beispiel /bin/sh starten und hat damit einen ähnliche Funktion wie telnetd (ohne pty, also ohne Kommandozeileneditor, kein vi usw.).
Das aufgerufene Programm muß sich also nicht um die Netzwerkverbindung kümmern, es darf aber auch nicht selbst auf eine Netzwerkverbindung warten, sondern muß die bestehende Verbindung übernehmen.
Wenn inetd schon in der busybox ist, ist das wahrscheinlich die platzsparendste Variante. Ich habe ihn mal aktiviert, es mach knapp 15 kB aus.
Wenn man wie bin xinetd zur Konfiguration eine Datei pro Dienst verwenden will, kann man das leicht mit einem Shell Script machen:

cat /etc/inetd.d/* > /etc/inetd.conf

 

[kriegaex]

Okay, verstanden. Gut erklärt. Wenn die Dateideskriptoren durchgereicht werden, ist es im Grunde so ähnlich wie im Verhältnis von Webserver und CGI.

Daran, daß inetd zur Busybox gehört, hatte ich nicht gedacht. Dann nehmen wir den auch.