rc.ftpd einführen

Im Züge meiner Bemühungen einige mount-Sachen aus den AVMs hotplug-Skripte zu freetz zu transferieren ist mir aufgefallen, dass AVM in ihren Hotplug-Skripten sehr oft auf dem ftpd rumtanzt. Wobei da widerholte Codesequenzen an mehren Stellen und sehr oft auftauchen. Das Problem von AVM: Sie haben kein Startskript für ftpd. Dies erschwert unsere Arbeit enorm. Wird AVM-eigener ftpd ausgepatcht, so muss es an mehreren Stellen durch das einfügen von if-Schleifen rum herum um Tausende andere Schleifen geschehen.
Auf der anderen Seite haben wir bei FREETZ wenigstens zwei eigene ftp-Pakete. Sind denn diese Pakete halbwegs zu ftpd kompatibel? Kann man dann die Stellen in AVM-hotplug-Skripten durch den Aufruf von z.B. vsftpd ersetzen?
Um die Sache etwas strukturierter zu gestalten, würde ich vorschlagen einen /etc/init.d/rc.ftpd einzuführen. In diesem Skript paken wir eine Art wrapper, der dann beim Ausführen von "start", "stop", "restart" erstmal live checkt, welcher der drei ftp-daemons denn am Bord ist. Ist es AVMs-ftpd, so werden die beliebten AVM-Sequenzen a-la:
ausgeführt, ist es vsftpd, so wid das Kommando an rc.vsftpd übergeben.
Somit könnte ich diverse Sachen aus run_mount und storage dahin auslagern. Dies würde mir die Arbeit deutlich erleichtern.

Ähnlich könnte man eventuell auch rc.tam_mount einführen.

Spricht etwas dagegen?

MfG

Wozu ist es dann mit AVM-eigenem ftpd gut? Weiß das jemand überhaupt?
Ich bin bis jetzt kein großer Fan von ftp gewesen. Diese Geschichte interessiert mich hier nur, weil man damit den ganzen ftp-Kram zentral verwalten könnte und aus den hotplug-Skripten rausnehmen würde.

MfG

Ich versuche mal zu erklären, warum es mich so interessiert.
Ich habe mir als Ziel gesetzt "run_mount" und "storage" mit sed von einigen Sektionen/Unterprogrammen zu befreien, die ich dann in den eigenen Bibliotheken (es werden wahrscheinlich doch zwei werden) nachbaue. Somit könnte man komplett auf alle storage, automount und ftpd - Patches verzichten. Soweit, sogut. Ich könnte mich nach dieser Idee nur auf die Auslagerung von nicename(), do_mount() und do_umount() beschränken. Es gibt aber im "storage"-Skript ein Paar Stellen, wo AVM alle Register zieht, ftpd und smbd killt oder neu startet.
Am härtesten finde ich die "unplug)"-Sektion von "storage". Eigentlich ist diese Sektion dafür gedacht Partitionen vereinzeln zu unmounten. Und das tut es auch und wir nutzen es jetzt sogar in der mounted.cgi. Allerdings werden dort z.B. smbd und ftpd gekillt. smbd kommt nachher wieder, weil in do_umount() dann doch "/etc/samba_control reconfig" aufgerufen wird. Die Spuren vom Starten von ftpd konnte ich nicht finden.
Die Aufrufsektionen kommen für spindown-Sachen und für ftpd doppelt, wenn sogar nicht drei-/ vierfach vor und wenn du um jeden ftpd da immer eine if-Schleife rum-herum reinpatchen musst, damit es auch mit ftpd-Patch funktioniert, dann wird es sehr umständlich mit den patches. Und genau das will ich vermeiden, indem ich ftpd-aufrufende-Teile in eine rc.ftpd packe und dort an einer Stelle eine permanente Prüfung auf das Vorhandensein von ftpd einführe.

Ist denn eurer Meinung nach notwendig ftpd und samba immer neu zu starten, wenn eine Partition dazugemounted/ungemounted wird?

MfG

ok, gut zu wissen. Wahrscheinlich ist es sinnig, samba_control reconfig auch beim Unmount durchzuführen, wie AVM es momentan macht. Allerdings samba vorher killen finde ich für etwas übertrieben und werde wahrscheinlich rausschmeißen. Beim reconfig wird ja auch samba runtergefahren und nachher gestartet. Von daher dürfte es so alleine ausreichen.

Mit ftpd bin ich immer noch am überlegen. Es gibt eine lange Passage in do_mount() von run_mount, die sich mit ftpd beschäftigt. Diese Passage kommt auch unter storage in Sektion "reload) genau wörtlich so vor. Aus diesem Grund würde ich dazu neigen die Passage separat als rc.ftpd auslagern und etwas ummanteln, damit sowohl do_mount() als auch "reload)" darauf zugreifen könnten.

Warum an den Stellen ftpd gestartet werden muss ist für mich immer noch ein Rätsel. Aber sei es rum.

MfG

Das würde ich auch aus Sicherheitsgründen nicht machen. Erstens, wenn man ftp nach Draußen frei gibt, dann sowieso. Zweitens, nicht alle Familien-/Wohnung-/WG-mitglieder sollen unbedingt in die Tiefen der Box reinschauen können. Wenn du die Box administrieren willst, dann nimmst du SSH/SCP-Client dafür. Das ist der bessere Weg.

Zu dem ftpd von AVM. Das Ding meldet sich eigentlich gar nicht übel als GNU-ftpd (welcher denn genau?) und hat viele Optionen, die AVM garnicht nutzt:
Ich schau mal, ob ich so ein rc-Skript nach freetz-Vorlagen hinkriege.

Edit:
Ich hab's fertig:
Bitte einchecken (Ausführungsrechte nicht vergessen)! Ich brauche es nachher als Baustein für meine Veränderungen an den mounting-Skripten. Deswegen wäre es nett, wenn es in den trunk einfließen würde.

Zum Neustarten von ftpd, wenn sich etwas an den Mountpoints geändert hat. Es ist meiner Meinung nach nicht notwendig. Wenn die Verzeichniss (mountpoints) beim unmounten korrekt gelöscht werden, dann kriegt man es auch so mit. Genau das Gleiche gilt fürs mounten.

Man kann natürlich sagen, meine Arbeit war komplett für die Katz. Ich sehe es aber nicht so. Wenigstens haben wir einen vernünftigen Starter/Stopper für AVMs-ftpd.


MfG

@cando: Ich hatte auch keine Zweifel, dass du das bewusst so machst. Ich wollte lediglich auf die Problematik hinweisen, dass auch diejenigen es wissen, die nicht so mit der Thematik vertraut sind, wie du. Denn sonst grabt das jemand nach 2-3 Monaten hier raus und implementiert es bei sich ohne die Risiken zu kennen. Von solchen Beispielen haben wir hier genug. Es gab diesbezüglich schon vor Jahren auch eine heftige Diskussion hier mit kriegaex bzgl. seiner rudi-shell, die zwar ein mächtiges Tool ist, jedoch im Grunde genommen ein ernsthaftes Sicherheitsrisiko bildet, wenn man das WebIF nicht genügend gut absichert.
Aber zurück zum Thema.
@cuma: Sowohl ftpd als auch smbd werden an diversen Stellen von storage und run_mount knallhart mit killall abgeschossen. Mit dem Abschießen von ftpd hat sich meine Befürchtung bestätigt: Der bleibt nach jedem unplug einer Partition (nach unserer neuen Methode mit dir bekannten Knöpfen) reproduzierbar gekillt. Aus AVM-Sicht ist es gut so, weil sie die Partitionen nicht einzeln abschießen, sondern nur komplette Medien. Wird ein Medium wieder eingesteckt, so wird ftpd "irgendwie" irgendwo in Tiefen von "storage" wieder gestartet.
Dass smbd kein HUP besitzt ist auch nicht schlimm. Dann muss man eben stop-start machen, wenn man was ändert. Vermutlich wird es in "/etc/samba_control reconfig" auch so gemacht. Nur wozu muss man da smbd davor nochmal zusätzlich so gewaltsam killen? Sicher ist sicher, oder wie? Ich schaue es mir nochmal an.
Ich würde rc.ftpd als einen festen Bestandteil in die Box einbauen. Momentan ist es so robust aufgebaut, dass selbst, wenn ftpd gepatcht ist es zu keinen Fehlermeldungen kommt. Vorteil: Man kann auf dieses rum-herum und ewige patcherei (die übrigens sowieso vermutlich nicht komplett vollständig war!) verzichten, wenn man ftpd aus dem Image entfernt. Später kann man überlegen, ob man vom rc.ftpd eine Brücke zu den Startskripten anderer FTP-Server (bftpd, vsftpd) baut. In diesem Fall würden diese FTP-Server nach der von uns festgelegten Priorisierung dann als Backup "freigeschaltet". Würde bedeuten, dass z.B. "rc.ftpd start" dann zu "vsftpd start" wird. Ich hatte es aber bewusst jetzt noch nicht so realisiert, weil die Notwendigkeit und die Kompatibilität der Server dazu genau untersucht werden sollte.
Zu der Frage, ob man denn den ftpd-Server ständig stoppen und starten muss sage ich wiederum ein klares "nein" und werde es wahrscheinlich aus den beiden (storage und run_mount) Skripten entfernen. Eventuell sehe ich dort an einigen Stellen ein "rc.ftpd start" vor. Ich hatte es im Startskript bewusst so realisiert, dass es auch im "start"-Fall zunächst übrprüft wird, ob ftpd bereits läuft. Ist es der Fall, so wird einfach ein HUP dem ftpd gesendet. Die Sinnhaftigkeit von HUP in diesem Fall sei hingestellt, es schadet aber wenigstens nicht. HUP scheint ftpd zu überleben. Ob er das auch tut, weiß ich nicht. Wenigstens meldet kill Erfolg des HUPens.
Und ich bitte nochmal es einzuchecken. Zunächst ist dieses rc-Skript wirkungslos und dürfte mit sich keine Risiken bringen.

Übrigens, man könnte/sollte auf die Art und Weise auch das Starten der anderen AVM-Diensten realisieren. Ob AVM dann die Dienste trotzdem direkt startet, ist erstmal nicht so relevant. Wenn die Dienste so FREETZ-konform ausgeführt wären, könnte man unter "Dienste"-Seite eine extra-Sektion für AVM-Dienste spendieren. Mir schwebe da was vor, wie dsld, voipd, telefon, wlan, AVM-Webserver (nicht unsere httpd-Alternative, die sowieso nicht geht, sondern ctlmgr) usw.

MfG

7270v3 76-Firmware Originalskripte von AVM (vor dem patchen)
/etc/hotplug/storage: Zeile 233 (unplug-Sektion); Zeile 266 (remove-Sektion); Zeile 321 (stop-Sektion)

Nach der Zeile 233 kommt der Aufruf von "do_umount", wo dann "samba_control reconfig" aufgerufen wird.

Cuma, diese beiden sch*-hotplug-Skripte von AVM sind so verschachtelt und von so einem schlechten Programmierungsstill, dass du da am besten gar nicht anfangen sollst etwas zu verstehen. Ich hatte mir beide Skripte auf dem Papier augedruckt (mache ich relativ selten) und arbeite sie schon seit ein Paar Tagen mit einem roten Stift ab, um irgendwelche Dupplikate zu finden. ftpd-Aufruf war ein Beispiel dafür. Wenn man sowas macht, versucht man so nebenbei zu verstehen, was die Jungs von AVM damit sagen wollten. Und das sollte man wahrscheinlich doch von vorne an bleiben lassen.

MfG

Die Motivation war, die ganzen patches zu ersparen und alles möglichst so transparent und boxunabhängig zu machen, dass der Wartungsaufwand von storage / ftpd / autorun / autoend und evtl. noch weiteren Geschichten sich minimiert. Anstatt zu patchen würde ich mit sed aus "storage" und "run_mount" ganze Abschnitte ausschneiden und sie durch unsere ersetzen. Die Suche würde dann nach Funktionnamen /Sektionnamen laufen und nicht wie bei patch nach den Zeilen rumherum. Klar gibt es dabei Risiken, aber dafür sind wir ja auch da, sie auszutesten und auszuschalten.

MfG

Dazu hatte ich schon lange einen Vorschlag gehabt, einen Ordner namens "optional" oder ähnlich einzuführen. Dort könnte man solche Sachen reinpacken, die dann nur bei Bedarf eingefügt werden. Alternativ kann man natürlich wie immer eine negative Logik verwenden und erst die Datei reinkopieren und danach löschen, wenn die Box keinen USB-Host hat. Es wird mir aber langsam umständig. Mit box.info und freetz.info hätte ich auch lieber über "optional" gemacht, als nachträglich löschen.
Grundsätzlich es optional anzubieten, damit habe ich überhaupt kein Problem. Es ist von mir auch so gedacht, dass es als ein Teil vom modifizierten storage-Patch fungiert. Allerdings es immer rauszupatchen, wenn ftpd nicht da ist und die Prüfung über das vorhandensein deaktivieren: Da bin ich streng dagegen. Das ist nämlich gerade meine Motivation, warum ich das Ding erschaffen hatte: Ich will aus modifizierten hotplug und run_mount und wie die alle heißen über einen Aufruf von "/etc/init.d/ftpd start" den ftpd immer fehlerfrei "starten" können, selbst wenn er nicht vorhanden ist. Das würde die restliche umpatcherei unheimlich vereinfachen, sodass du nicht mehr in Tausenden Skripten darauf achten muss, ob ftpd denn ausgepatcht wurde oder nicht. Außerdem könnte man dann ftpd-Startskript erweitern und damit vsftpd und bftpd starten.
Zum Programmierungsschreibstill. Ich finde, dass
deutlich strukturierter und logischer aussieht, als
Denn in der vorgeschlagenen Schreibweise werden then und else ungleich behandelt. Ich schreibe übrigens genau so die C-Programme und hasse geschleifte Klammer in der Zeile, wo der Name der Struktur steht. Auch hier würde ich die beiden Klammer gleich behandeln.
Aber keine Sorge, cuma ist schon fleißig dabei meine gewöhnungsbedürftigen then-s mit der Kurzform in der mounted.cgi zu ersetzen. Von daher werden sie irgendwann mal aussterben, wie die Dinos.

MfG