rc.ftpd einführen

olistudent · 23 Nov 2009

@Hermann
Kannst du bitte noch eine Zeile einfügen, dass auf den ftpuser gecheckt wird. Ist mir gerade beim lesen von http://trac.freetz.org/ticket/61 (am Ende) aufgefallen.

Und dann wäre noch wichtig zu wissen, ob der AVM ftpd mit einem Passwort in der shadow umgehen kann. Ich meine, dass ich das mal geprüft habe und es nicht so war. Wir könnten den ftpd auch selbst aus den Sourcen bauen, wenn man das beim Bauen aktivieren könnte.

Dann könnte man das Ticket eventuell zu machen...

MfG Oliver

hermann72pb · 20 Apr 2010

Ich hole das hier wieder aus der Vergessenheit...
Mir sind vor kurzem zwei unschöne Dinge bezüglich unseren FTP-Server aufgefallen:
1. AVM hat bei der 72XX-Boxreihe das Starten von deren ftpd über inetd eingeführt. Das wird zwar in meinem rc.ftpd schon jetzt teilweise abgefangen, jedoch nicht beim Status. Da man den Status in dem Fall nicht so einfach testen kann, muss man schon auf netstat zurückgreifen. Dazu jedoch etwas später.
2. Ich hatte zum ersten Mal gleichzeitig AVM-ftpd und vsftpd auf mehreren Boxen gehabt. ftpd wird ja von AVM (bzw. an den von mir gepatchten Stellen) beim Starten der Box aufgerufen. Somit ist der Port 21 erstmal belegt (egal, ob mit ftpd oder mit inetd). Startet man jetzt aber rc.vsftpd, so wird brav gemeldet:

Code:

Starting ftp server...done.

obwoh das eigentlich nicht stimmen kann:

Code:

/var/mod/root # /etc/init.d/rc.vsftpd status
stopped

Also, in rc.vsftpd wird weder gecheckt, ob der Port bereits belegt ist noch wird der Rückgabewert nach dem Start vom Binary überprüft und richtig zurückgegeben. Wir müssen hier eine Überprüfung entweder auf die Portbelegung oder auf die korrekte Rückgabe einführen, damit nicht immer "done" gemeldet wird, obwohl es nicht stimmen kann. Das Gleiche gilt auch für rc.ftpd. Auch dies bedarf der Nachbesserung.
Anbei sind einige Gedanken meinerseits, wie man mit netstat die Portbelegung testen und verarbeiten könnte:

Code:

ftpport=21
pidname="$(netstat -lnpt | grep -E ":$ftpport " | sed -e 's/.*LISTEN[ ]*//;s/\// /')"
mypid=$(echo "$pidname" | sed -e "s/ .*//")
myname=$(echo "$pidname" | sed -e "s/.* //")

Ich poste es hier, um von euch ggf. weitere Anregungen zu erhalten und um zu erfahren, ob ich in die Richtung weiter werkeln sollte.
Desweiteren wären noch folgende Ideen meinerseits von Interesse:
1. Im FREETZ-WebIF auf der Seite mit den Diensten einen Eintrag neben dem telnet und co. auch für AVM-ftpd zu spendieren. Natürlich nur dann anzeigbar, wenn mein rc.ftpd im Image ist. Denn sonst kann man es weder steuern noch vernünftig darstellen. Sobald ich den Status mit intetd implementiert habe, ist rc.ftpd eigentlich vollständig WebIF-tauglich.
2. Dem rc.ftpd optional so eine Art Masterfunktion verleihen, damit man per rc.ftpd auch bftpd oder vsftpd starten/stoppen konnte. Also, so eine Art Umleitung auf den tatsächlich verwendeten FTP-Server.
3. Eine optionale kill-Funktion basierend auf meinem code-Beispiel von oben. Erkennt man, dass der Port belegt ist, kann man den blockierenden Dienst per PID vorher killen, bevor man was anderes startet. Somit könnte man z.B. neben rc.ftpd in rc.vsftpd auch so eine Funktion einbauen (optional), die den AVM-ftpd vor dem Start von vsftpd killt, wenn sie die gleichen Ports belegen.
4. Die bereits angesprochene Problematik mit dem ftpuser. Allerdings blicke ich da nicht ganz durch, wann und wo genau es benötigt wird und ob überhaupt noch.

MfG

MfG

RalfFriedl · 20 Apr 2010

Ich fände es besser, den Exit-Status des FTP_Servers auszuwerten. Oder kommt da nichts brauchbares?

Silent-Tears · 20 Apr 2010

Und einfach mal dazu: In der Labor NAS auf jeden Fall kann der ftpd anscheinend nicht mit der Option -U" umgehen.

hermann72pb · 21 Apr 2010

@Ralf: Ich hatte es mir nicht angeschaut, wie der Server bei vsftp und bei bftp gestartet wird. Wenn er mit & ins Nirvana geschickt wird, dann hast du da wenig Chancen den Exitstatus abzufangen. Oder siehst du da Möglichkeiten? Aber man muss zunächst die rc-Skripte genauer studieren.
@Lars: Heißt das, dass rc.ftpd da nicht mehr vernünftig starten kann? Da sollen wir wohl Oliver dazu motivieren an der Eigenkompilation von ftpd noch bisschen weiter zu werkeln. Vielleicht kriegen wir es doch selbst gebacken?

MfG

olistudent · 21 Apr 2010

RalfFriedl schrieb:
Ich fände es besser, den Exit-Status des FTP_Servers auszuwerten. Oder kommt da nichts brauchbares?

Code:

close(7)                                = 0
stat64(0x4217e8, 0x7f9067e0)            = 0
getuid()                                = 0
getuid()                                = 0
fork(Process 2108 attached
)                                  = 2108
[pid  2107] exit(0)                     = ?
open("/dev/null", O_RDWR|O_LARGEFILE)   = 7
dup2(7, 0)                              = 0
dup2(7, 1)                              = 1
dup2(7, 2)                              = 2
close(7)                                = 0
setsid()                                = 2108
getpid()                                = 2108
getpgrp()                               = 2108
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
...
bind(7, {sa_family=AF_INET, sin_port=htons(21), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
fcntl64(0, F_GETFL)                     = 0x2002 (flags O_RDWR|O_LARGEFILE)
fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(0, "500 OOPS: ", 10)              = 10
write(0, "could not bind listening IPv4 so"..., 36) = 36
write(0, "\r\n", 2)                     = 2
exit(1)                                 = ?
Process 2108 detached

MfG Oliver

hermann72pb · 21 Apr 2010

naja, wenigstens Exitstatus "1", wie dein strace verrät, Oliver. Vermutlich landet da zusätzlich auch eine passende Fehlermeldung in Textform auf der Fehlerausgabe 2.

MfG

cuma · 21 Apr 2010

Spricht was gegen "pidof"?

RalfFriedl · 21 Apr 2010

Der Exitstatus "1" kommt aber nicht beim Aufrufer an, weil vorher schon ein fork() war.

hermann72pb · 21 Apr 2010

eben:

Code:

/etc/init.d # vsftpd
/etc/init.d # echo $?
0
/etc/init.d # ./rc.vsftpd status
stopped

Allgemein zu netstat-Methode. Sie würde auch bombensicher gehen, wenn man inetd benutzt. pidof funktioniert dagegen nur, wenn ein Prozess auch tatsächlich im Hintergrund lauscht. Im Falle von inetd lauscht jedoch kein Prozess im Hintergrund, sondern nur inetd.

MfG

cuma · 21 Apr 2010

Ah, stimmt

hermann72pb · 24 Apr 2010

Erste Gehversuche / Modifikation von modlibrc

Wie ich bereits oben angekündigt hatte, werkele ich momentan am rc.ftpd. Mit Hilfe von Oliver (danke für den Tipp mit /dev/null!) ist es mir gelungen rc.ftpd auch auf FREETZ-WebIF neben telnetd und Co. temporär bei mir on-the-fly (mount -o bind sei dank) zum Laufen zu bringen. Ich habe bereits mehrere Sonderfälle abgefangen, die früher gar nicht behandelt waren. Momentan teste ich sowohl auf einer 7170, wo AVM-ftpd nativ läuft, als auch auf einer 7270 mit AVM-eigenartigem inetd.
Soweit, sogut und ich werde demnächst bestimmt eine neue Version von rc.ftpd und Patches für vsftpd und bftpd posten. Als Vorgeschmack will ich aber schon heute hier ein Nebenprodukt zur Schau und Diskussion stellen, was bei mir im Zuge der Modernisierung von rc.ftpd entstanden ist. Die Rede ist von einer neuen Funktion, die ich gerne in modlibrc integrieren würde. Die Funktion erlaubt die Portbelegung von einem vorgegebenen Daemon zu checken und kann sogar den "Beleger" stoppen oder killen, wenn es natürlich ausdrücklich gewünscht ist. Verwendung wäre nicht nur ftp-Dienste, sondern auch z.B. http-Server, ssh-Server usw. Daher sollte es in modlibrc. Ich bitte die Idee und Code an sich zu beurteilen und euer Feedback dazu zu geben.

Code:

# modlib_check_port
#   check whether a port is busy and by which daemon. return status
#	$1: port number
#	$2: daemon name
#	$3: command: check, stop, kill
#	$4: socket: t: TCP u: UDP w: RAW
#   returns: 0 free; 1 oneself; 2 inetd; 3 other daemon 
modlib_check_port()
{
	[ -z "$1" ] && local netport=21 || local netport="$1"
	[ -z "$2" ] && local daemonname="daemon" || local daemonname="$2"
	[ -z "$3" ] && local docommand="check" || local docommand="$3"
	[ -z "$4" ] && local sockettype="t" || local sockettype="$4"
	local pidname="$(netstat -lnp"$sockettype" | grep -E ":$netport " | sed -e 's/.*LISTEN[ ]*//;s/\// /')"
	local avminetdconf="/tmp/inetd.conf"
	local freetzinetdconf="/tmp/flash/inetd.conf"
	if [ -z "$pidname" ]
	then
		return 0 # port is free
	else
		local mypid=$(echo "$pidname" | sed -e "s/ .*//")
		local myname=$(echo "$pidname" | sed -e "s/.* //")
		if [ "$myname" == "inetd" ]
		then
			local inetddaemon=""
			[ -e "$avminetdconf" ] && inetddaemon="$(cat $avminetdconf | grep ^$netport | sed -e 's/.*\///g')"
			if [ -z "$inetddaemon" ]
			then
				[ -e "$freetzinetdconf" ] && inetddaemon="$(cat $freetzinetdconf | grep ^$netport | sed -e 's/.*\///g')"
			fi
			[ -z "$inetddaemon" ] && inetddaemon="inetd"
		fi
		case $docommand in
			stop)
				[ "$myname" != "inetd" ] && inetddaemon="$myname"
				if [ "$inetddaemon" == "inetd" ]
				then
					echo "$inetddaemon"
					return 4	
				fi
				if [ -x "/etc/init.d/rc.$inetddaemon" ]
				then
					/etc/init.d/rc.${inetddaemon} stop
					local status=$?
					if [ "$status" -eq 0 ]
					then
						return 0
					else
						echo "$inetddaemon"
						return 4	
					fi
				fi
			;;
			kill)
				if [ "$myname" == "inetd" ]
				then
					echo "$myname"
					return 5	
				fi
				local cnt=9 
				while [ $cnt -ge 0 ] && kill -0 $mypid 2>/dev/null
				do 
					kill $mypid 2>/dev/null 
					sleep 1 
					let cnt=cnt-1 
				done 
				if kill -0 $mypid 2>/dev/null
				then 
					kill -9 $mypid 2>/dev/null 
					sleep 1
				fi 
				if kill -0 $mypid 2>/dev/null
				then
					echo "$myname"
					return 5
				else
					return 0
				fi
			;;
			*)
				if [ "$myname" == "$daemonname" ]
				then
					echo "$myname"
					return 1 # port is already used by this DAEMON
				fi
				if [ "$myname" == "inetd" ]
				then
					echo "$inetddaemon"
					return 2 # port is already used by inetd
				else
					echo "$myname"
					return 3 # port is already used by other DAEMON
				fi
			;;
		esac
	fi
}

MfG

RalfFriedl · 24 Apr 2010

Mir ist zunächst folgendes aufgefallen:

Die Beschreibung der Funktion ist nicht korrekt/vollständig: Es gibt return 4 und 5, außerdem echo Anweisungen.

Die Vorbelegung von Parametern bringt nichts. Port 21 ist nur sinnvoll für FTP, aber dann paßt der Name "daemon" nicht dazu. "check" und "TCP" ist vielleicht häufiger, aber ich würde es vorziehen, die Parameter explizit zu übergeben. Von der Reihenfolge würde ich erst das Kommando übergeben, dann Socket Typ und Port, die ja zusammen gehören.

Ansonsten bist Du anscheinend ein Fan von sed und Sub-Shells.
Erwartest Du Leerzeichen im Namen des Programms? Ich denke, das kann man ausschließen. Also ist es einfacher, das letzte Wort in der Zeile zu suchen. Das hat auch den Vorteil, daß es wirklich mit den Port-Type UDP und RAW funktioniert, bei denen kein LISTEN angezeigt wird.
Warum Du da "grep -E" verwendest, ist mir nicht klar. Oder hätte es "grep -F" sein sollen? Außerdem haben wir schon sed, da brauchen wir nicht noch grep.

Code:

local pidname="$(netstat -lnp"$sockettype" | sed -nre "s/^.*:$netport .* ([^ ]+) *\$/\\1/p"
local mypid=${pidname#*/}
local myname=${pidname%/*}

Ein Server könnte an mehrere Interfaces jeweils mit dem gleichen Port gebunden sein. Das wird weder von Deiner Version noch von meiner oben abgedeckt.

In der inetd.conf könnte der Port als Name eingetragen sein, dann würde er nicht gefunden. Tatsächlich werden aber anscheinend immer nur die Nummern verwendet.
Außerdem könnte es sein, daß die Funktion aufgrund einer Änderung der Konfiguration aufgerufen wird, oder einfach nachdem die Konfiguration geändert wurde, und deswegen in der inetd.conf der Dienst gar nicht mehr aktiv ist. Da wir ja die Pid haben, können wir diese mit /var/run/inetd.pid vergleichen für den Freetz inetd. Vielleicht hat der von AVM auch eine Pid Datei, wenn nicht, kann man wohl davon ausgehen, daß es nicht noch einen dritten inetd geben wird.

Im Fall, daß das Programm über inetd gestartet wird, Nimmst Du alles nach dem letzten '/' als Programm Name. Bei meiner inetd.conf auf dem PC kommt da in keinem Fall der Name des Servers heraus, aber vermutlich funktioniert es in den von Dir getesteten Fällen auf der Box.

Im Fall, daß der Dienst über inetd läuft, wird trotzdem die rc-Aktion stop ausgeführt. Ist beabsichtigt, daß diese die inetd.conf ändert? Wenn nicht, kann man sich den Aufruf gleich sparen. Zumal im Moment jeder Fehler beim Stop als "inetd" interpretiert wird, was nicht zwangsläufig so sein muß.

Außerdem haben wir schon Funktionen zum Stoppen von Diensten, deren Pid bekannt ist. Die könnte man hier aufrufen, statt das hier nochmal zu machen.

hermann72pb · 24 Apr 2010

Danke für ausführliche Kommentare und Vorschläge!

RalfFriedl schrieb:
Die Beschreibung der Funktion ist nicht korrekt/vollständig: Es gibt return 4 und 5, außerdem echo Anweisungen.

Ich hatte diesen case-Teil mit kill und stop nachträglich geschrieben, deswegen vorne nicht kommentiert.

RalfFriedl schrieb:
Die Vorbelegung von Parametern bringt nichts. Port 21 ist nur sinnvoll für FTP, aber dann paßt der Name "daemon" nicht dazu. "check" und "TCP" ist vielleicht häufiger, aber ich würde es vorziehen, die Parameter explizit zu übergeben. Von der Reihenfolge würde ich erst das Kommando übergeben, dann Socket Typ und Port, die ja zusammen gehören.

doch, doch. Ich will es nicht immer mit allen vier Parameter aufrufen. Daher auch die Reihenfolge, die vielleicht nicht ganz logisch ist, aber wegen Werte, die man weglassen können. Die stehen dann bei mir hinten. TCP wird wohl in den meisten Fällen benutzt, deswegen kann man es meist vorbelegen und so lassen. Über 21 kann man sich streiten. Ich wollte aber auf Nummer sicher gehen und auch Fälle abfangen, wenn die Funktion gar ohne Parameter aufgerufen wird. Daher kommen auch "" um alle Eingangsvariablen herum, weil ich möglichst viel abfangen will, was da kommen könnte.

RalfFriedl schrieb:
Ansonsten bist Du anscheinend ein Fan von sed und Sub-Shells.
Erwartest Du Leerzeichen im Namen des Programms? Ich denke, das kann man ausschließen. Also ist es einfacher, das letzte Wort in der Zeile zu suchen. Das hat auch den Vorteil, daß es wirklich mit den Port-Type UDP und RAW funktioniert, bei denen kein LISTEN angezeigt wird.

ok, danke für den Hinweis mit UDP und RAW! Ich versuche es dann nach deinem Vorschlag zu implementieren.

RalfFriedl schrieb:
Warum Du da "grep -E" verwendest, ist mir nicht klar. Oder hätte es "grep -F" sein sollen? Außerdem haben wir schon sed, da brauchen wir nicht noch grep.

hast du Recht, in dem fall muss man nicht unbedingt -E nehmen. -E nimmt man, wenn man z.B. verodern will oder was ähnliches. Ich programmiere nicht jeden tag damit und vergesse manchmal, wofür -E gut und nötig ist usw. grep + sed ist auch meine Art sed zu nutzen. Ich übergebe damit dem sed die Vorauswahl und lasse sed nicht über komplette Ausgabe suchen, sondern nur in den vom grep vorgefundenen Zeilen. Ob es in diesem konkreten Fall Sinn macht, weiß ich nicht. Bei größeren Datenmengen manchmal schon.

RalfFriedl schrieb:
Ein Server könnte an mehrere Interfaces jeweils mit dem gleichen Port gebunden sein. Das wird weder von Deiner Version noch von meiner oben abgedeckt.
In der inetd.conf könnte der Port als Name eingetragen sein, dann würde er nicht gefunden. Tatsächlich werden aber anscheinend immer nur die Nummern verwendet.

Das scheint mir wirklich ein Sonderfall zu sein. Lass uns es mal erstmal so mit numerischen Ports stehen, bis sich jemand beschwert.

RalfFriedl schrieb:
Außerdem könnte es sein, daß die Funktion aufgrund einer Änderung der Konfiguration aufgerufen wird, oder einfach nachdem die Konfiguration geändert wurde, und deswegen in der inetd.conf der Dienst gar nicht mehr aktiv ist. Da wir ja die Pid haben, können wir diese mit /var/run/inetd.pid vergleichen für den Freetz inetd. Vielleicht hat der von AVM auch eine Pid Datei, wenn nicht, kann man wohl davon ausgehen, daß es nicht noch einen dritten inetd geben wird.

Da bin ich momentan dran, das Beste aus AVM-Inetd und FREETZ-Inetd zusammenzuführen. AVM nutzt inetd.conf recht dynamsich. Das wirst du in meinem rc.ftpd finden, was ich von AVM-hotplug-Skripten übernommen hatte. Das geht etwas an FREETZ-inetd-Konzept vorbei. Ich werde wahrscheinlich dazu ein neues Thread eröffnen. Dann lass uns dort inetd-Implementierung diskutieren.

RalfFriedl schrieb:
Im Fall, daß das Programm über inetd gestartet wird, Nimmst Du alles nach dem letzten '/' als Programm Name. Bei meiner inetd.conf auf dem PC kommt da in keinem Fall der Name des Servers heraus, aber vermutlich funktioniert es in den von Dir getesteten Fällen auf der Box.

Kannst du bitte deine inetd.conf von einem PC-Linux posten? Was stehen da für Einträge, dass sie nicht gefunden werden? Die Methode wird nicht immer funktionieren. Das ist mir schon klar. Nur dann, wenn binary exakt mit dem rc-Skript im Namen übereinstimmt.

RalfFriedl schrieb:
Im Fall, daß der Dienst über inetd läuft, wird trotzdem die rc-Aktion stop ausgeführt. Ist beabsichtigt, daß diese die inetd.conf ändert? Wenn nicht, kann man sich den Aufruf gleich sparen. Zumal im Moment jeder Fehler beim Stop als "inetd" interpretiert wird, was nicht zwangsläufig so sein muß.

AVM macht es eben so, dass beim stoppen von ftpd über inetd der Eintrag aus inetd.conf mittels einer Binary von AVM ausgetragen wird. Die Idee an sich ist nicht schlecht und ich werde es deswegen prüfen, ob es generell auf FREETZ-inetd anzuwenden wäre. Aber lass uns dies wie oben vorgeschlagen in einem separaten Thread zu inetd diskutieren.

RalfFriedl schrieb:
Außerdem haben wir schon Funktionen zum Stoppen von Diensten, deren Pid bekannt ist. Die könnte man hier aufrufen, statt das hier nochmal zu machen.

Ja, das wäre alternativ zu überlegen, anstatt "unsicher" rc.binaryname aufzurufen. Die Funktionen liegen ja sowieso in modlibrc, von daher wäre so eine Art Queraufrufen möglich. Das Problem sind nur AVM-Dienste, die sich unter Umständen nicht an der FREETZ-Konformalität mit pid-Dateien halten. Aber genau das war meine Motivation, um rc.ftpd einzuführen: ftpd nach FREETZ-üblichen Standards mit pid und Co. zu starten.

MfG

RalfFriedl · 24 Apr 2010

Beispiel von der Box:

Code:

# cat /tmp/inetd.conf
22       stream  tcp     nowait  root    /usr/sbin/dropbear      dropbear -i
23       stream  tcp     nowait  root    /usr/sbin/telnetd       telnetd -i -l /sbin/ar7login
81       stream  tcp     nowait  root    /usr/bin/webcfg webcfg -i
# sed -e 's/.*\///g' /tmp/inetd.conf
dropbear      dropbear -i
ar7login
webcfg webcfg -i

Auch hier kommt nie der Name des Programms heraus. In manchen Fällen ist das erste Wort der Name des Programms, aber bei telnet zum Beispiel ist das nicht der Fall.

hermann72pb · 24 Apr 2010

So sieht es mit "AVM-inetd" bei mir aus:

Code:

/var/mod/root # cat /tmp/inetd.conf
21    stream  tcp     nowait  root    /bin/sh sh /bin/inetdftp

Zugegeben, es ist etwas an den Haaren vorbei gezogen da was rauszufischen...
Sag mal, woher kommt es, dass bei dir inetd.conf unter /tmp liegt? Das ist doch nicht die Standardeinstellung von FREETZ-inetd? Dort liegen die Configs nämlich wo anders.

MfG

RalfFriedl · 24 Apr 2010

Die echte inetd.conf liegt nicht in tmp, aber ich habe in tmp ein Kopie ohne die Kommentare erstellt, damit es übersichtlicher ist.

Im Beispiel von AVM würde man normalerweise direkt die Datei /bin/inetdftp aufrufen. Warum sollte man die Tatsache, daß /bin/inetdftp ein Shell-Skript ist und nicht Perl oder C in der Konfiguration berücksichtigen, wenn es nicht notwendig ist?
Es hat natürlich den Vorteil, daß die Abfrage von Dir mit diesem Format funktioniert.

Bist Du sicher, daß Du Dich da überhaupt mit inet-gestarteten Diensten herumschlagen willst?

Ich vermute übrigens, daß /bin/inetdftp der Grund ist, warum AVM überhaupt auf ientd für FTP umgestiegen ist. In der Datei wird /etc/webdav_control aufgerufen, um webdav beim Zugriff auf FTP (oder Samba) zu starten. Anscheinend ist auch geplant, nach dem Schließen der letzten Verbindung webdav auch zu beenden, aber in der mir vorliegenden Version passiert das nicht.

hermann72pb · 24 Apr 2010

So tief bin ich noch nicht eingestiegen, dass ich mir angeschaut hätte, was AVM mit inetdftp tut. Danke für die Aufklärung! Dennoch war unsere Intension mit diesem rc.ftpd möglichst nah an der AVM-Umsetzung zu bleiben. Man könnte sich natürlich generell überlegen, ob man sich mit vom inetd-gestarteten Diensten rumschlägt oder nicht, aber dazu mache ich wie versprochen ein eigenes Thread, sobald ich da selbst durchgestiegen bin. In dem Falle von AVM-ftpd versuche ich aber daran zu bleiben, die Zeile mit inetdftp in die Config einzutragen bzw. auszutragen, wenn rc.ftpd gestartet/gestoppt wird. So wie AVM es auch tut.
Bei der Filterung mit grep/sed hast du mich überzeugt, dass ich da ziemlich falsch lag. Ich versuche mir da was besseres zu überlegen und ggf. inetd-behaftete Fälle vielleicht sogar ganz auszuschließen.
Warum ich das überhaupt gemacht hatte: Wenn ich mich damit abgefunden hätte, auf Anfrage "wer belegt Port 21", eine Antwort zu bekommen "inetd", wäre es unzureichend. Denn wenn es "ftpd über inetd" ist, ist es schon was anderes, als "vsftpd über inetd". Daher brauche ich die Unterscheidung, wer hinter dem inetd steckt. In rc.ftpd mache ich daraufbasierend Fallunterscheidungen, die dafür wichtig sind, um eine Aussage zu treffen, ob der Port 21 denn letztendlich von ftpd (von sich selbst) oder von vsftpd (fremd) belegt ist und dementsprechend zu agieren.

Edit: Zur Problematik aus #35 habe ich eine Lösung:

Code:

/var/mod/root # cat /tmp/test.conf
22       stream  tcp     nowait  root    /usr/sbin/dropbear      dropbear -i
23       stream  tcp     nowait  root    /usr/sbin/telnetd       telnetd -i -l /sbin/ar7login
81       stream  tcp     nowait  root    /usr/bin/webcfg webcfg -i
/var/mod/root # cat /tmp/test.conf | sed -e 's/[^ ]*[ ]*[^ ]* [ ]*[^ ]* [ ]*[^ ]* [ ]*[^ ]* [ ]*\([^ ]*\).*/\1/;s/.*\///g'
dropbear
telnetd
webcfg
/var/mod/root # cat /tmp/test.conf | grep 23 | sed -e 's/[^ ]*[ ]*[^ ]* [ ]*[^ ]* [ ]*[^ ]* [ ]*[^ ]* [ ]*\([^ ]*\).*/\1/;s/.*\///g'
telnetd

Ich bin kein Fan von awk (weil es auf der Box ziemlich langsam läuft), deswegen diese grausame sed-Sequenz, die nach der sechsten Spalte sucht und sie ausweret.
In meinem Fall mit rc.ftpd wird es aber keine Lösung sein. Denn dank AVM kriege ich da "sh" als Dienst. Übrigens auch nicht immer, wie meine Studie der AVM-Skripte zum Starten von inetd zeigt. Ich muss da echt was einfallen lassen.

MfG

balou1974 · 23 Mai 2010

Hi,

beim aktuellen Trunk 4921 läuft auf meiner neuen 7270 v3 der ftpd von AVm nicht mehr. Ich habe schon alles probiert /mbr vom USB-Stick gelöscht neue Partitionen angelegt, neu formatiert.... Interessanterweise ist der der ftpd im freetz-Web-If immer inaktiv(inetd) wobei ich ihn im Fritz!-Web-If auf ein gesetzt habe ... Samba funktioniert wunderbar aber ftp-Zugriff, keine Chance - selbst wenn ich manuell starte per Button im freetz habe ich keinen Zugriff ... Kann es sein, dass es mit FREETZMOUNT und rc.ftpd noch irgendwelche Probleme gibt? Leider finde ich auch keine Log-Files die ein Aussage über den Fehler erlauben würden.
Vielleicht weiss ja jemand Rat, bitte NICHT nimm doch bftpd oder vsftpd

Gruss Balou

olistudent · 23 Mai 2010

Die inetd.conf wäre interessant. Weiterhin könntest du mal mit netstat schauen, ob was auf Port 21 läuft.

MfG Oliver

rc.ftpd einführen

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Aktives Mitglied

IPPF-Urgestein

IPPF-Promi

Aktives Mitglied

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Mitglied

IPPF-Urgestein

Statistik des Forums