AVM-inetd und FREETZ-inetd zusammenführen

[hermann72pb]

Wie bereits rc.ftpd-Thread angekündigt, starte ich hier eine Diskussion zum Thema inetd.
Wie einigen bereits bekannt, hat AVM in ihren neueren Firmwares bei einigen Boxen auf inetd gesetzt. Hier hat RalfFriedl eine sehr glaubhaft scheinende Vermutung aufgestellt, warum AVM plötzlich auf die Idee gekommen war inetd zu nutzen. Aber das interessiert uns hier nur sekundär. Die Tatsache ist -wie es bei AVM fast immer der Fall ist-: Sie haben es etwas anders realisiert, als normal üblich ist, und als wir es bei unserer FREETZ-inetd-Lösung bereits hatten.
Wesentliche Unterschiede:
1. AVM-inetd wird mit einer config-datei gestartet, die direkt unter /tmp liegt. Es existiert keine dauerhaft gespeicherte Version dieser Datei, sie wird immer dynamisch generiert. Bei unserem FREETZ-inetd liegt die gleichnamige config-Datei etwas tiefer: /tmp/flash/inetd.conf. Diese Datei wird logischerweise mit modsave im Flash abgelegt und ist eher statisch zu betrachten, als AVM-eigene.
2. AVM nutzt ein Shell-Skript namens /bin/inetdctl, um einzelne Dienste per inetd zu starten. Was in dem Skript genau vor sich geht, habe ich bis jetzt noch nicht analysiert. Fakt ist jedoch, dass die besagte config-Datei damit bearbeitet wird: Beim Starten wird eine Zeile dort angelegt, beim Stoppen wird die Zeile entfernt. Vermutlich wird nebenbei auch inetd neu gestartet. Dies betrifft bis jetzt nur Dienste, die AVM über inetd laufen lassen will.
3. Wenn AVM-ftpd gestartet/gestoppt wird, wird /bin/inetdctl mit "enable" bzw. "disable" ausgeführt.

Die Frage ist: Wollen wir beides miteinander verheiraten und wenn ja, dann wie? Es sind mehrere Varianten möglich und ich bitte eure Äußerung dazu, wie man es am besten machen sollte.

1. Man könnte die Datei /tmp/inetd.conf löschen und sie stattdessen mit der FREETZ-Datei verlinken. Somit hätte man eine eindeutige Datei. Nachteil wäre jedoch, dass AVM da immer mit ihrem /bin/inetdctl dazwischen funken würde.
2. Beide config-Dateien laufen lassen, jedoch bei jedem Start der Box und bei allen Änderungen die FREETZ-Datei in die AVM-Datei reinmergen. inetd würde dann mit der AVM-Datei unter temp laufen. Die FREETZ-config-Datei wäre dann eine reine Kopie für Editierungszwecke. Diese Lösung würde ich favorisieren. Denn hier könnte /bin/inetdctl schreiben wie wild, es würde unsere Konfiguration unter FREETZ nicht betreffen. Hätte aber den Nachteil, dass man die dynamischen AVM-Einträge nicht sehen würde.
3. AVM-Skripte durchsehen und gründlich überarbeiten. Ähnlich, wie ich es mit hotplug-Skripten und FREETZMOUNT gemacht hatte. Erfordert viel Aufwand.
4. Komplett auf AVM-Methode umsteigen und auch beim FREETZ-inetd beim jeden Start/Stop von Diensten mit inetd die Zeile in/aus der inetd-Config eintragen/austragen.

Oder gibt es noch weitere Vorschläge?

MfG

 

[Silent-Tears]

Vielleicht sollten wir uns in die inetdctl einklinken? Ist immerhin auch nur ein Script. Btw hab ich die in der Standard-7270-FW nicht, dort gibt es /bin/inetdftp unde /bin/inetdsamba, und beide sorgne für vernünftiges Einbinden vom AVM-Webdav.

 

[hermann72pb]

So in die Richtung überlege ich gerade auch. Allerdings gefällt mir die Art und Weise, wie AVM es tut nicht ganz. Ich bin der Meinung, dass man die Inhalte von /bin/inetdftp eigentlich unter rc.ftpd und /bin/inetdsamba unter rc.samba unterbringen könnte. inetdctl kann man ebenfalls zwischen den beiden rc-Skripten verteilen und Gemeinsamkeiten unter modlibrc verpacken.

Ich würde dafür in den rc.-Skripten eine Sektion mit dem Aufruf "inetd" neben start, stop usw. vorschlagen. Somit könnte man in der inetd.conf dann auf "/etc/init.d/rc.script inetd" verweisen. Dort würde dann in etwa das stehen, was in /bin/inetdftp von AVM bereits steht. Den Inhalt von /bin/inetdctl verteilt sich dann zwischen start- und stop-Sektionen. Ich versuche dazu einen Beispiel zu entwickeln und im rc.ftpd-Thread zu präsentieren.

MfG

 

[RalfFriedl]

Die Datei /bin/inetdftp wird von inetd aufgerufen, wenn eine FTP-Verbindung hergestellt wird. Sie dient nicht dazu, die inetd.conf zu bearbeiten.

Ich würde in rc.xxx einbauen, daß beim Starttyp inetd bei den Aktionen start und stop die Konfiguration entsprechend geändert wird und dann inetd diese neu einliest, aber nicht daß umgekehrt inetd die rc.xxx Datei aufruft.

 

[hermann72pb]

Ich habe es bereits so ähnlich mit rc.ftpd implementiert und es scheint zu funktionieren. Zunächst habe ich in modlibrc eine neue Funktion eingeführt, die so aussieht:

modlib_inetd_control()
{
	local configfile="/var/tmp/inetd.conf"
	local tmpfile="/var/tmp/inetd.conf.tmp"
	[ "$CONFIG_IPV6" = "y" ] && local tcp_v46='tcp6' || local tcp_v46='tcp'

	case "$2" in
	ftpd )
		grep -v /rc.ftpd $configfile > $tmpfile
		[ "$1" = "enable" ] && echo "21    stream  $tcp_v46     nowait  root    /etc/init.d/rc.ftpd   rc.ftpd inetd" >> $tmpfile
    ;;

	*)
		return 127
	esac

	mv $tmpfile $configfile
	killall -HUP inetd
	return $?
}

Ist mehr oder weniger von AVM-eigenem /bin/inetdctl abgeschaut, mit dem inetdctl erstmal kompatibel aber doch ein bisschen angepasst (ich habe hier extra, die SAMBA-Sektion weg gelassen, die gibt es bei mir auch noch und sie ist bis jetzt noch unangetastet). Man kann die einzelne Dienste entweder händisch so pflegen, dass für jeden Dienst da so ein case-Eintrag steht (wie AVM es tut), oder versuchen es auf einen gemeinsamen Nenner zu bringen, wenn man davon ausgeht, dass alle Dienste über rc.dienstname gestartet werden und eine Aufruf-Option Namens "inetd" besitzen, wenn sie denn über inetd gestartet werden wollen.

Soweit so gut. Nun kommt die inetd-Sektion von meinem rc.ftpd. Sie ist dann von dem AVM-eigenem /bin/inetdftp abgeschaut und sieht so aus:

inetd()
{
	[ "$CONFIG_WEBDAV" = "y" ] && [ -x $WEBDAVCONTROL ] && $WEBDAVCONTROL start > /dev/null 2>&1 &
	run_binary inetd
	status=$?
	[ "$CONFIG_WEBDAV" = "y" ] && [ -x $WEBDAVCONTROL ] && $WEBDAVCONTROL stop_last > /dev/null 2>&1 &
	return $status
}

run_binary ist eine Funktion bei meinem rc.ftpd, die alle notwendigen Parameter zum Starten von Binary aufsammelt. Diese Funktion kann mit dem Parameter "daemon" aufgerufen werden und startet dann ftpd wie gewohnt als Daemon ohne inetd. Wenn man run_binary mit einem anderen Parameter aufruft (so wie hier mit inetd), dann wird ftpd ohne "-D" und ohne andere Daemon-spezifische Parameter gestartet. Somit agiert

/etc/init.d/rc.ftpd inetd

als Ersatz für /bin/inetdftp und ist so eine Art Parser/Wrapper für den inetd-Modus. Bei den AVM-spezifischen Sachen, wo noch WebDAV usw. mitgestartet/mitgestoppt werden wollen, ist es damit gedient. Für den Rest würde die Funktion inetd() dann nur eine Zeile beinhalten.
Weiterhin habe ich irgendwo in der start-Sektion von rc.ftpd dann eine Zeile stehen:

modlib_inetd_control enable $DAEMON

die abhängig davon aufgerufen wird, ob inetd-Modus für diesen konkreten Dienst gewünscht ist oder nicht (für AVM-FTPD werde ich noch entsprechende FREETZ-Variablen dafür einführen, denn momentan wird Existenz von /bin/inetdctl als Kriterium für inetd gecheckt).
Und dann entsprechende Eintragung in der stop-Sektion:

modlib_inetd_control disable $DAEMON

Wie gesagt, diese AVM-artige Syntax mit "enable" "disable" als Schnittstelle fliegt bei mir höchstwahrscheinlich raus, oder wird wenigstens erweitert. Neben dem Daemon-Namen würde ich da auch gerne wenigstens Port und Sockettype übertragen, damit man es universell gestalten kann und die Sachen nicht zu hard coden.

Wie ist eure Meinung zu einer solchen Vorgehensweise? Mit dem ftpd funktioniert es bei mir ja und wenn nichts gegen spricht, würde ich vsftpd und bftpd da vielleicht nachziehen und in einem gemeinsamen Pack als patch anbieten, sobald es fertig ist. Bis dahin sind alle Meinungen und Ratschläge eurerseits willkommen.

MfG

 

[RalfFriedl]

Man kann die einzelne Dienste entweder händisch so pflegen, dass für jeden Dienst da so ein case-Eintrag steht (wie AVM es tut)

Das gefällt mir nicht, auch wenn AVM es so tut. Es bedeutet, daß man an einer Datei Änderungen machen muß für jeden Dienst, der neu dazu kommt, und daß Informationen darüber, wie der Dienst gestartet wird, außerhalb der Dateien ist, die zum Dienst gehören.

Es gibt einige Programme, die ihre Konfiguration aus mehreren Dateien lesen können. Das wäre der eleganteste Weg. Ansonsten würde ich ein Verzeichnis anlegen mit Dateien in der Art /var/mod/inetd.d/inetd.ftp, in dem alle Dateien gesammelt werden. Diese kann man dann mit cat zusammenfassen, ohne daß das Steuerprogramm etwas von der Existenz oder der Konfiguration dieser Dienste wissen muß.

Nun kommt die inetd-Sektion von meinem rc.ftpd.

Wie bereits geschrieben, würde ich in rc.ftp nur die Steuerung unterbringen, aber nicht den Aufruf für jede Verbindung, die zum FTP aufgebaut wird.

 

[hermann72pb]

Die Funktion modlib_inetd_control in modlibrc habe ich etwas aufgeräumt. Nun sieht es etwas universeller aus:

# modlib_inetd_control
# enable / disable inetd watching for defined service
# $1: action. e.g. enable or disable
# $2: daemonname. e.g. ftpd
# $3: portnumber. e.g. 21
# $4: [optional] socket. e.g. tcp
modlib_inetd_control()
{
	local configfile="/var/tmp/inetd.conf"
	local tmpfile="/var/tmp/inetd.conf.tmp"
	[ -z "$1" -o  -z "$2" -o -z "$3" ] && return 127
	[ -z "$4" ] && local sockettype="tcp" || local sockettype="$4"
	[ "$CONFIG_IPV6" = "y" ] && [ "$sockettype" == "tcp" ] local sockettype='tcp6'
	grep -v /rc.$2 $configfile > $tmpfile
	[ "$1" = "enable" ] && echo "$3    stream  $sockettype     nowait  root    /etc/init.d/rc.$2   rc.$2 inetd" >> $tmpfile
	mv $tmpfile $configfile
	killall -HUP inetd
	return $?
}

ist bereits erprobt und funktioniert.
Das einführen von "inetd"-Option in den rc.Skripten würde ich doch schon gerne bevorzugen. Im Falle von ftpd habe ich damit schon 2 Dinge erschlagen:
a) Auf /bin/inetdctl kann verzichtet werden (vorausgesetzt samba-Sektion wird ähnlich nachgepflegt)
b) Auf /bin/inetdftp kann ebenfalls verzichtet werden, weil es in die inetd-Sektion von rc.ftpd eingepflegt ist

Somit befinden sich alle Daemon- / Binary-spezifische-Sachen in dem rc.script. Und zwar auch die Aufrufsektion für inetd-Modus. Alles in einer Datei und nicht irgendwo auf der Box zerstreut. Die rc.dateien pflegen wir sowieso selbst FREETZ-spezifisch, sodass ich da keine Kompatibilitätsprobleme sehe.
@Ralf: Wo würdest du denn dann sonst diese /bin/inetdftp-Skripte unterbringen? Und vor allem, wie kann man es alternativ mit dem Eintragen/Austragen beim Start/Stop lösen, ohne dass man inetd neu starten muss?

MfG

 

[RalfFriedl]

Normalerweise startet man vom inetd direkt das dazugehörige Programm. Der Umweg über das Skript ist nur wegen der webdav-Aufrufe. Für alle Dienste außer FTP und SAMBA ist das nicht nötig. Ich persönlich würde es vorziehen, eine konfigurierte webdav Verbindung grundsätzlich aufzubauen, so wie auch jeder andere Mount immer ausgeführt wird und nicht erst dann, wenn man darauf zugreift.
Die Konfiguration des inetd muß sowieso immer geändert werden, wenn man einen Dienst über inetd aktiviert oder deaktiviert.

 

[hermann72pb]

Die Konfiguration des inetd muß sowieso immer geändert werden, wenn man einen Dienst über inetd aktiviert oder deaktiviert.

Das ist die jetzige Realisierung. Ich hatte jedoch oben eine dynamische Änderung der Konfiguration vorgeschlagen, wie AVM es tut. Und diese Dynamik heißt nicht nur, dass man was zusätzliches starten/stoppen kann, sondern dass man z.B. Port 21 mit einem "stop"-Knopf von ftpd vom ftpd "befreien" kann.
Wenn man eine dynamische Änderung der Konfiguration zulässt, dann sollen eben die rc.scripte der Dienste befugt werden die Konfiguration zu ändern. Meiner Meinung nach wäre es eine deutliche Verbesserung gegenüber dem aktuellen Stand. Denn jetzt sieht es so aus, dass wenn man die Dienste per inetd aktiviert hat, dann kann man sie per Knöpfe im WebIF und per "rc.daemon stop" nicht mehr "stoppen", sondern man muss immer in die inetd.conf rein und dort was abändern oder eben in den Einstellungen zum Dienst den Starttyp ändern.
So wie ich es "dynamisch" vorschlage wäre es möglich per start/stop die Dienste auch in/aus der inet.conf ein/auszutragen.

Ist diese Dynamik gar nicht gewünscht, oder wie ist die Stimmung allgemein in die Richtung?

MfG

 

[RalfFriedl]

Technisch gesehen muß die Konfiguration des inetd geändert werden, um einen Dienst ab oder aus zu schalten, und der inetd muß darüber informiert werden (ob SIGHUP oder Neustart).
Das heißt aber nicht, daß man deswegen die Konfigurationsdatei von Hand ändern muß.
Der Vorschlag, den ich oben angedeutet hatte, war so gedacht:
Ein Skript zur Steuerung des inetd sammelt alle Dateien in einem Verzeichnis ein und erstellt daraus die Konfiguration. (Ein inetd, der das selbst tut, wäre noch eleganter.) Ein anderes Skript, rc.xxx, schaut nach, ob der Dienst xxx für inetd konfiguriert ist. Wenn ja, wird beim Aufruf von "start" eine Datei xxx.inetd erstellt und das vorher genannt inetd Skript aufgerufen. Beim Aufruf mit "stop" wird die Datei xxx.inetd gelöscht und auch wieder das inetd Skript aufgerufen. Das Ergebnis ist, daß "start" und "stop" genau die Funktion haben, die man auch ohne inetd erwarten würde. Beim Aufruf mit "status" könnte man prüfen, ob die Datei xxx.inetd existiert und das als Status anzeigen.

Da diese Datei xxx.inetd vom zugehörigen rc-Skript erstellt wird, hat dieses volle Kontrolle über den Inhalt, während das inetd-Skript nur die Dateien einsammelt und mit den einzelnen Diensten gar nichts zu tun hat. Man könnte den konkreten Aufruf beim Verbindungsaufbau über das rc-Skript leiten, aber ich würde es vorziehen, dafür eine andere Datei zu verwenden und das rc-Skript auf die Steuerung der Dienste zu beschränken.

 

[hermann72pb]

D.h. wir führen unter rc.inetd eine Funktion ein, die du als inetd-Skript bezeichnest. Diese Funktion wird dann beim "rc.inetd start" und beim "rc.inetd reload" aufgerufen. Wir verzichten auf externes HUP-en von inetd, wie AVM es tut und wie ich es momentan übernoommen hatte, sondern rufen stattdessen immer "rc.inetd reload". Dabei packt rc.inetd einzelne xxx.inetd zu inetd.conf zusammen und löst einen HUP von inetd aus.

Mit deiner Abneigung eine inetd-Startoption einzuführen hast du mich überzeugt. Ich schlage hier ein Kompromiss vor. Ich werde die AVM-eigene /bin/inetdftp und /bin/inetdsamba komplett mit unseren eigenen ersetzen. Jede Art Patcherei dieser Dateien erfordert zu viel Wartungsaufwand und sollte daher unterlassen werden. Auf der anderen Seite kann ich mit den beiden Dateien in ihrer jetzigen Form wenig was anfangen, weil sie hard coded sind, keine Parameteränderung vorsehen usw.
Die Funktion von /bin/inetdctl wird dann vollständig von rc.inetd wie oben besprochen übernommen.
Wir müssen uns nur festlegen, wo wir die xxx.inetd-Dateien hinpacken. /mod/etc/inetd wäre mein Vorschlag.

Edit: Und noch was... Wenigstens rc.inetd wird dann zum Pflicht auf allen neuen Boxen gehören oder wenigstens zusammen mit rc.ftpd mitausgewählt. Sonst kann man darauf nicht aufsetzen.

MfG

 

[RalfFriedl]

Bei den Boxen, wo inetd sowieso schon mit drin ist, kann ruhig auch rc.inetd mit dazu. Wenn man noch die /bin/inetdctl einspart, verbraucht es noch nicht einmal zusätzlichen Platz.

Ich habe mir mal die /bin/inetdctl angeschaut, da wird einem ja fast schlecht davon. Zum einen sieht man, daß /bin/inetdftp nur aufgerufen wird, wenn webdav tatsächlich aktiv ist, sonst ftp direkt. Ich hätte statt bin/inetdftp und bin/inetdsamba lieber ein Skript webdav_wrapper erstellt:

#!/bin/sh
WEBDAVCONTROL=/etc/webdav_control
test -x $WEBDAVCONTROL && $WEBDAVCONTROL start 1> /dev/null 2> /dev/null &
"$@"
test -x $WEBDAVCONTROL && $WEBDAVCONTROL stop_last 1> /dev/null 2> /dev/null &

Damit hat man schon mal die Funktion der beiden Skripte abgedeckt und braucht nichts mehr zu tun, wenn noch ein Dienst dazu kommt, der auch webdav benötigt.
Und /bin/inetdctl kann man auch vereinfachen:

#!/bin/sh

INETD_CONFIG=/var/tmp/inetd.conf
INETD_CONFIG_TMP=/var/tmp/inetd.conf.tmp

use()
{
  echo "use: inetdctl enable|disable servicename"
  exit 127
}

if [ "$CONFIG_WEBDAV" = "y" ] ; then
    WEBDAV_WRAPPER=/sbin/webdav_wrapper
else
    WEBDAV_WRAPPER=
fi
if [ "$CONFIG_IPV6" = "y" ] ; then
    TCP=tcp6
else
    TCP=tcp
fi


case "$2" in
    ftpd )
        grep -v /sbin/ftpd $INETD_CONFIG >$INETD_CONFIG_TMP
        if [ "$1" = "enable" ]  ; then
            # enable ftpd
            PRODUCT_NAME_WITHOUT_SPACES=`echo $CONFIG_PRODUKT_NAME |tr -d " "`
            echo "21 stream $TCP nowait root $WEBDAV_WRAPPER /sbin/ftpd /sbin/ftpd -q -t 120 -h $PRODUCT_NAME_WITHOUT_SPACES" >>$INETD_CONFIG_TMP
        fi
        ;;

    smbd )
        grep -v /sbin/smbd $INETD_CONFIG >$INETD_CONFIG_TMP
        if [ "$1" = "enable" ]  ; then
            # enable smbd
            echo "139 stream $TCP nowait root $WEBDAV_WRAPPER /sbin/smbd /sbin/smbd" >>$INETD_CONFIG_TMP
            echo "445 stream $TCP nowait root $WEBDAV_WRAPPER /sbin/smbd /sbin/smbd" >>$INETD_CONFIG_TMP
        fi
        ;;

    * )
        echo servicename unknown
        use
        ;;
esac

mv $INETD_CONFIG_TMP $INETD_CONFIG
killall -HUP inetd

Mit den angedachten Änderungen würde man einfach die Zeilen für die inetd.conf in einer Datei ablegen und dann die inet-Konfiguration neu laden. Es hätte auch den Vorteil, daß nicht zwei inetd-Programme laufen müssen.

 

[hermann72pb]

Interessante Lösung. Ich würde allerdings eher auf /bin/inetdctl letztendlich komplett verzichten und die entsprechenden Code-Teile direkt in die beiden rc.scripte vom FTPD und SAMBA übernehmen.
Da du dich so gut mit inetd auskennst, kannst du bitte die Syntax von inetd.conf näher erklären. Du sagtest zwar schon am Rande, dass da mehrere Dateien aufgerufen werden können, ich werde dennoch daraus nicht besonders schlau. Wie erkennt inetd, dass du zunächst den Wrapper aufrufst und dann ftpd? Die letzte Spalte in der Config ist der Aufruf samt Parameter, aber warum muss davor noch /sbin/ftpd ohne Parameter stehen?

MfG

 

[RalfFriedl]

Eine Datei /bin/inetdctl werden wir vermutlich brauchen, weil ich davon ausgehe, daß diese von den AVM Programmen aufgerufen wird, vermutlich vom ctlmgr. Deswegen muß sie natürlich nicht viel mit der jetzigen Form zu tun haben.

Ich gehe mal davon aus, daß Du eine man-Page von inetd.conf finden kannst.
Deine Frage bezog sich speziell auf den Kommando-Teil. Hier ist es so, daß zunächst angegeben wird, welches Progrmam aufgerufen werden soll, und dann werden alle Parameter für dieses Programm angegeben, inklusive dem Parameter 0, der üblicherweise den Programmnamen enthält. Das ist der Grund, warum der Programm-Name zweimal erwähnt ist. Das erste mal ist es die auszuführende Datei, beim zweiten Mal ist es der Name, der dem Programm übergeben wird. Wenn man von der Shell aus ein Programm aufruft, ist der aufgerufene Name und der Dateiname gleich. Wenn man aber allgemein ein Programm aufruft, müssen diese Angaben nicht übereinstimmen.
Der inetd erkennt gar nicht, ob ein Wrapper oder was auch immer aufgerufen wird, der inetd hat nur einige Strings, die festlegen, was er aufrufen soll.

Im obigen Beispiel gibt es zwei Möglichkeiten:
1. Wrapper verwendet: wrapper ftp ftp x y
Es wird der wrapper aufgerufen, wobei $0 auf ftp gesetzt wird (das erste von den beiden ftp). Da wrapper $0 nicht auswertet, spielt das keine Rolle. Der wrapper ruft dann "$@" auf, also "ftp x y"
2. Wrapper nicht verwendet: ftp ftp x y
Hier wird ftp aufgerufen, mit $0 == ftp. Das ist die Art, wie man normalerweise ein Programm vom inetd aufrufen würde.

 

[hermann72pb]

ok, der Parameter 0 war mein Klemmer. Jetzt hab ich deine Idee hoffentlich vollständig kapiert. Es wird jedoch schwierig mit der automatischen Erkennung von unter inetd agierenden Binary (ich hatte in rc.ftpd-Thread dazu was gepostet gehabt). Denn meine letzte Lösung liest nämlich die Spalte Nummer 6 mit dem Dateinamen. Und sie würde im Falle mit dem Wrapper den Wrappernamen beinhalten. Da muss man vielleicht eine Sonderbehandlung einführen.

MfG

 

[RalfFriedl]

Das Erkennen des Programms aus der Datei war sowieso nicht robust.

Wenn man die inetd.conf schon selbst erstellt, kann man bei der Gelegenheit auch die passenden Informationen unterbringen. Entweder irgendwo getrennt, oder als spezielle Kommentare vor der aktiven Zeile, z.B.:

#@INFO:21:ftp
21 stream ...

 

[hermann72pb]

nene, gerade mit Kommentaren kämpfe ich jetzt bei inetd. Ich hatte mir heute erst inetd ins Image mitgenommen und war erstaunt, was da alles bereits gemacht wurde. Leider nicht alles damit konform, was wir hier beschlossen haben. So wie es dort bereits realisiert ist, will ich zunächst aus Kompatibilitätsgründen so belassen, allerdings passt die dort angewandte Methode wenig an das dynamische Eintragen/Austragen, wie ich es gerne haben will. Ich habe damit angefangen die config-Datei von jeglichen Kommentaren zu befreien und unter /mod/etc/inetd.conf abzulegen. Auf diese Datei zeigt momentan auch die Verlinkung aus dem /etc/inetd.conf. Beim Laden von rc.inetd erzeuge ich zusätzlich ein Symlink /tmp/inetd.conf => /mod/etc/inetd.conf, um AVM-Kompatibilität halbwegs zu erhalten. Leider wird beim Bauen vom Image mit inetd der Hauptparser von AVM /bin/inetdctl weggelöscht. Das muss ich erstmal beseitigen, bevor ich weiter mache.
Der Weg scheint sich aber allgemein deutlich steiniger zu gestalten, als ursprünglich angenommen. Und je weiter ich grabe, desto mehr kommt es mit diesem inetd ans Licht. Obwohl die ursprüngliche Idee von mir war eigentlich "nur" rc.ftpd zu "reparieren". Blöd war nur, dass ich von der AVM-Lösung her gegangen bin und nähere mich erst jetzt der FREETZ-Implementierung von inetd.

MfG

 

[hermann72pb]

Dynamisches inetd

Basierend auf der obigen Diskussion habe ich nun einige Änderungen am inetd vorgenommen, um es "dynamischer" und gleichzeitig mehr kompatibler zu AVM-Implementierung zu machen.
Als Testobjekt hatte ich meine rc.ftpd genommen und sie an neue Bedürfnisse angepasst. Basierend an rc.ftpd kann man die anderen rc-Skripte ähnlich umgestalten, wenn man es denn will. Ansonsten ist natürlich die Kompatibilität zur alten inet-Manier auch noch geblieben.
Patch liegt bei. Beim patchen läuft leider das Umändern vom Symlink zur inetd.conf schief. Ich habe die Config-Datei verlegt, darum muss die Verlinkung auch geändert werden. Zur Not bitte händisch nachhelfen.

Ich bitte die Neuerungen durchzuschauen, zu testen und möglichst bald in den Trunk einchecken.

Nebenbei hatte ich -wie anderswo hier bereits versprochen- Basis-Pakete von den AVM-Diensten befreit und sie in eine Extra-Sektion zusammengefasst (s. Bild).
Auf den restlichen Bildern ist zu sehen, wie meine Funktion zum Check der Portbelegung ihre Dienste tut. Zunächst bekommt man eine Information darüber, warum z.B. ftpd nicht gestartet werden kann. Zum Anderen wird beim reload von inet.d doppelte/mehrfache Portbelegung gecheckt und verhindert. Letzteres ist vor allem für die Übergangsphase von der alten inetd-Realisierung zu dieser neuen (dynamischer) gedacht. Denn die alten inetd-Starter checken die Portbelegung gar nicht und melden sogar einen falschen Status nach dem misslungenen Starten zurück. Da wir jetzt die Portbelegung vor dem Start des Dienstes checken könnten, könnte man sowas eigentlich im Vorfeld verhindern (s. rc.ftpd).

Edit: Ticket dazu habe ich ebenfalls erstellt.

Viel Spass!

MfG

 

[hermann72pb]

Bevor es hier komplett runtergeht, bitte ich diesen Patch einzuchecken. Durch die 0 Downloads sehe ich, dass Interesse an dem Patch momentan gar nicht existiert. Dennoch bitte ich die Notwendigkeit der Maßnahme nicht zu unterschätzen: Damit machen wir die ersten Schritte, um AVM-Inetd mit dem FREETZ-Inetd zu verheiraten und die Boxen, wo AVM den inet-Daemon als defacto voraussetzt sauber zu unterstützen.
Ich gestehe in dem Patch noch einige andere Änderungen zu haben: AVM-Dienste-Sektion und Anpassung von rc.ftpd. Die Aufspaltung der Dienste wurde allerdings anderswo hier in IPPF positiv begrüßt, Änderungen in rc.ftpd waren notwendig, damit es mit dem neuen rc.inetd sauber läuft.
Ich persönlich habe meine Änderungen an einer 7170 (ohne inetd) und einer 7270v2 (mit inetd von AVM und FREETZ) erfolgreich getestet.

Ich habe etwas Angst, dass nach 2-3 Wochen so viele Änderungen im Trunk erfolgen, dass mein Patch gar nicht mehr passen wird.

Danke!

MfG

 

[hermann72pb]

Nachdem Oliver es in den Trunk (4850) eingepflegt hat (Danke!), würde ich mich über die Rückmeldungen freuen.
1. Es gab vereinzelt Meldungen, dass AVM-SAMBA mit FREETZ nicht laufen sollte. Ich hatte mit diesem Patch nicht gesondert auf AVM-SAMBA geachtet und es nicht explizit getestet. Der Unterschied zu vorher besteht darin, dass nun inetd als Paket zwangsläufig bei den Boxen mit inetd (>=72XX) gewählt wird. Gibt es jemand, der AVM-SAMBA erfolgreich/erfolglos verwendet?
2. Gibt es jemand, der AVM-FTP nutzt? Welche Erfahrungen habt ihr damit?
3. Gibt es sonst Probleme, die auf die Änderungen aus meinem inetd-Patch zurückgeführt werden könnten?

MfG