[NUR ZUR INFO !] rc.custom und inetd

[sf3978]

@sf3978: Die Lösung von er13 ist keine Lösung, das ist nur Workarround. ...

YES, Sir!!! Ich wollte dieses Wort nicht schreiben, deshalb habe ich mich für "Lösung" entschieden. Der Rest war und ist mir auch klar. Danke für die Mitteilung.

 

[RalfFriedl]

Hast du den Link von mir mal angeklickt? Mein Windows 7 und Ubuntu 10irgendwas verhalten sich bei der autorun.sh/autorun.inf genau gleich.

Den Link habe ich angeklickt, es kommt eine Unmenge von Treffern.
Ich verwende weder Windows 7 noch Ubuntu, von daher verhalten sich beide für mich exakt gleich, nicht nur was autorun betrifft.

 

[cuma]

Und das Problem mit inetd ist dann auch nicht gelöst.

Mit dem Würkaround wird es aber auch nicht gelöst, da die rc.custom nach dem inetd gestartet wird. Im Gegenteil handelst du dir damit nur noch mehr Probleme ein, da durch diesen Link der "status" bestimmt wird. Zum Glück wird der beim "start" (momentan) noch nicht geprüft. Hast du übrigens bemerkt dass der Link durch rc.external wieder gelöscht wird? Dein Programm wird auch nicht starten wenn der Stick erst nachträglich eingesteckt wird.
Außerdem kann dadurch die Partition nicht richtig ausgehängt werden (zB beim reboot) und du kannst dir Dateisystemfehler einhandeln.

Das Ganze trifft übrigens nicht zu, wenn du den riesigen Aufwand auf dich nimmst den Aufruf von rc.custom nach flash/mod/rc.external zu verfrachten und dort im unload das Ganze auch beendest

Ich versteh echt nicht weshalb zuerst alle so geil darauf waren den Pfad zu external im Webinterface festzulegen, und jetzt so einen Käse drumherum zusammenfrickeln

 

[er13]

Ich versteh echt nicht weshalb zuerst alle so geil darauf waren den Pfad zu external im Webinterface festzulegen, und jetzt so einen Käse drumherum zusammenfrickeln

Sei bitte so nett und bleib ruhig, es frickelt keiner hier was zusammen. Ich habe geschrieben, "temporäre Abhilfe", was soviel bedeutet, dass es ein Workaround ist, mit dem man leben könnte bis das Problem richtig gelöst wird. Wir brauchen auch gar nicht zu diskutieren, ob "Symlink selber anlegen" oder "Aufruf von rc.custom nach flash/mod/rc.external verfrachten" besser ist. Es sei denn das letzte ist das, was Du für die richtige Lösung hälst. Mir wäre es allerdings lieber, dass es weiterhin möglich wäre, externalisierte Programme aus rc.custom zu starten. Wäre da die Auslagerung vom rc.custom-Aufruf von rc.mod nach /etc/init.d/rc.external die richtige Lösung? Bin mir nicht ganz sicher. Deine (@all Eure) Ideen?

p.s. wir suchen einfach mal nach der Lösung des Problems und versuchen es zu vermeiden, uns gegenseitig zu beleidigen, OK ;-)

 

[cuma]

Du nimmst es persönlich, wenn ich "etwas" als Käse bezeichne?
Es gibt einfach keine 100% Lösung dass man aus rc.custom Dinge von USB starten kann, da es nicht sichergestellt ist, dass alles schon erkannt wurde bzw eingesteckt ist. 2 Alternativen sind oben schon beschrieben und die Nachteile wenn man es nicht nutzt nur weil irgendein anderes Betriebssystem eine Datei ähnlichen Namens nutzt auch. Wenn man die .modstarted 1 Zeile höher anlegt gibt es die Wahrscheinlichkeit dass es funktioniert. Bei den Alternativen immer.

Was man noch machen könnte:
* alles von Hand starten > umständlich
* etwas ganz neues einbauen > überflüssig

 

[sf3978]

Mit dem Würkaround wird es aber auch nicht gelöst, da die rc.custom nach dem inetd gestartet wird.
...

OK. Was wäre deiner Ansicht nach, die richtige Lösung um externalisierte Programme, nur über inetd zu starten? Muss ich den Aufruf dieser Programme auch in "flash/mod/rc.external" eintragen?

 

[cuma]

Der sauberste Weg wäre wenn man ein passenden rc-Skript für das Package hat und passende external.services Datei im svn (oder man trägt das Package selbst im Webif bei "Diese selbst definierten Dienste behandeln" ein).
Als Folge wird das Package (ob inetd oder standalone interessiert nicht!) beim mount geladen und beim unmount beendet.

 

[sf3978]

... (oder man trägt das Package selbst im Webif bei "Diese selbst definierten Dienste behandeln" ein).
Als Folge wird das Package (ob inetd oder standalone interessiert nicht!) beim mount geladen und beim unmount beendet.

Das heißt zusätzlich zur aktivierten Einstellung "x Folgende externalisierte Freetz-Dienste behandeln: vtun ngircd umurmur vsftpd sshd privoxy ", muss z. B. bei mir, "vtun ngircd" unter "Diese selbst definierten Dienste behandeln:" eingetragen werden?

 

[cuma]

Da beide schon bei "Folgende externalisierte Freetz-Dienste behandeln" stehen reicht es davor dir Checkbox zu aktivieren. Wenn du aber nicht alle der "vtun ngircd umurmur vsftpd sshd privoxy" so starten möchtest mach die Checkbox aus und trag in die Textbox nur die 2 ein

 

[sf3978]

... reicht es davor dir Checkbox zu aktivieren.

Die Checkbox war schon immer aktiviert. D. h. diese Einträge ermöglichen nicht, externalisierte Programme über rc.custom zu starten. Oder verstehe ich das falsch bzw. darf/soll nur dann der Link "ln -s /var/media/ftp/uStor01/external /mod/external" benutzt werden, wenn die Checkbox aktiviert ist? Wenn ja, dann habe ich das von Anfang an, richtig gemacht.

 

[cuma]

Ich bin nicht so ganz sicher ob ich versteh was du meinst. Der Link wird automatisch anleget und die rc-Skripte auch automatisch geladen. Was steht denn in der external.log? Was genau ist das Problem?

 

[sf3978]

... Der Link wird automatisch anleget und die rc-Skripte auch automatisch geladen. ...

D. h. das Aktivieren der Checkbox macht nur dann Sinn, wenn für die externalisierten Programme die über rc.custom gestartet werden sollen, auch rc-Skripte vorhanden sind?

Ich habe deinen Beitrag:

Der sauberste Weg wäre wenn man ein passenden rc-Skript für das Package hat und passende external.services Datei im svn ([COLOR="Red"]oder man trägt das Package selbst im Webif bei "Diese selbst definierten Dienste behandeln" ein[/COLOR]).
Als Folge wird das Package (ob inetd oder standalone interessiert nicht!) beim mount geladen und beim unmount beendet.

dann nicht richtig verstanden.
Auch wenn das Package im Web-IF eingetragen ist, aber ein rc-Skript nicht vorhanden ist, dann wird das Package beim mount nicht geladen und beim unmount nicht beendet.

 

[cuma]

Du wolltest ja den saubersten Weg wisse, das ist ein rc-Skript.
Ohne rc-Skript geht es nicht so. Dann trägt man den Aufruf am besten in die tmp/flash/mod/rc.custom ein, dann klappt das unmounten über das Webinterface auch, sowie das Starten wenn der Strick eingesteckt wird (also nicht gleich beim Booten).
Zum komfortablen editieren: http://trac.freetz.org/changeset/6161

 

[sf3978]

...Dann trägt man den Aufruf am besten in die tmp/flash/mod/rc.custom ein, ...

D. h. das rc-Skript muss in die rc.custom eingetragen werden? OK, das muss ich mir noch genauer anschauen. Danke.

 

[cuma]

Jetzt bin ich verwirrt. Dachte es gibt kein rc-Skript? Dann kann man das auch nicht eintragen sondern den Aufruf selbst, also mit allen Parametern.
Vielleicht sollten wir das besser an einem konkreten Beispiel machen?

 

[sf3978]

Sorry, dann habe ich dich schon wieder falsch verstanden. Ja, wir werden das an einem Beispiel versuchen.

 

[cuma]

Ich zeige einfach mal wie ich das benutze:

Meine /tmp/flash/mod/rc.external sieht so aus

#!/bin/sh

tar cf /stick/sic/vns_BACKUP/vns_$(date +"%Y-%m-%d_%T"|sed 's/:/-/g').tar /stick/var/vns

case $1 in
        load)
                vcap.sh start
                twonky.sh
                ;;
        unload)
                [ -n "`pidof     vcap.sh`" ] && vcap.sh stop
                [ -n "`pidof twonkymedia`" ] && killall twonkymedia
                [ -n "`pidof      httpry`" ] && killall httpry
                [ -n "`pidof     tcpdump`" ] && killall tcpdump
                ;;
esac

eventadd 1 "Running custom rc.external done."

So werden 2 Programme gestartet wenn der Stick da ist und beim Unmounten/Neustart werden noch ein paar andere beendet, falls ich sie vergessen hab.

Da ich eine 16MB Box hab und alles gerade noch so ins Image passt, habe ich keine Pakete ausgelagert, aber trotzdem external aktiviert damit die Optionen im Webif sind. Dort ist somit die Checkbox von "Folgende externalisierte Freetz-Dienste behandeln" egal.

Bei "Diese selbst definierten Dienste behandeln" habe ich aber "tor rrdstats vnstat bip xmail lighttpd davfs2 subversion" eingetragen, da all diese Daten vom USB-Stick brauchen und ohne diesen nicht funktionieren können bzw das (saubere) unmounten verhindern würden. Von diesen laufen auch ein paar im inet-Modus

 

[sf3978]

Jetzt funktioniert es. Die rc.custom wird für externalisierte Programme (hier vtun) nicht mehr benötigt.
Inhalt der "rc.external":

#!/bin/sh
case $1 in
        load)
                sh /var/tmp/flash/mod/rc.vtun start
                ;;
        unload)
                sh /var/tmp/flash/mod/rc.vtun stop
                ;;
esac

eventadd 1 "Running custom rc.external done."

EDIT:

Hinweis: Namen der [COLOR="Red"]/etc/init.d/rc.DAEMON[/COLOR] Dateien ohne das führende rc. und mit Leerzeichen getrennt angeben. Dies kann dazu genutzt werden um nicht externalisierte Dienste die ein USB-Gerät zum Speichern der Daten benötigen (wie RRDstats, Tor, bip, Xmail oder vnstat-cgi) zu starten und stoppen.

Das rc-Skript muss nicht im Verzeichnis "/etc/init.d" sein.

EDIT 2:
Meldung in der "/var/log/external.log", wenn die "rc.external" noch jungfräulich ist:

/etc/init.d/rc.external: /tmp/flash/mod/rc.external: [COLOR="Red"]line 3: syntax error[/COLOR]: unexpected word (expecting "in")

 

[cuma]

Die Fehlermeldung sollte jetzt weg sein, wenn die Datei aber schon angelegt wurde hilft der Patch allerdings nicht...

Wieso nicht "/etc/init.d" ?
http://trac.freetz.org/browser/trunk/make/mod/files/root/etc/init.d/rc.external#L51

[ -x /etc/init.d/rc.$pkg ] && /etc/init.d/rc.$pkg $1 2>&1 | tee -a $LOG_FILE

 

[sf3978]

...
Wieso nicht "/etc/init.d" ?
...

OK, jetzt habe ich die rc-Skripte im Verzeichnis "/etc/init.d". Auszug aus der "/var/log/external.log":

Starting external (/var/media/ftp/uStor01/external):
Waiting for mod-startup: ....... done.
Usage: /etc/init.d/rc.vtun [start|stop]
Usage: /etc/init.d/rc.fbcauth [start|stop]
Usage: /etc/init.d/rc.iparchiv [start|status]
privoxy is disabled.
umurmur is disabled.
vsftpd is updating inetd ... active.
Usage: /etc/init.d/rc.iparchiv [start|status]

Jetzt sind aber folgende Anwendungen immer aktiv:

...
[COLOR="Red"]1337 root      1548 S N  /bin/sh /etc/init.d/rc.external start /var/media/ftp/uStor01[/COLOR]
...
[COLOR="Red"]2225 root      1512 S N  tee -a /var/log/external.log[/COLOR]
...

Ist das richtig so?