Warmduscher Interface/ Menüfür Automounter

[Tommy]

Der Automounter funktioniert ja mittlerweile prima. Es gibt nur den Nachteil das er nicht per GUI konfigurierbar ist. Das wiederum gliedert sich in zwei Schwerpunkte:

1. Konfiguration der auto.net über Menü (ähnlich Mountoptionen jetzt)
2. Auswählbarkeit der Mounts aus den diversen Einstellungen Menüs (Aufnahme, Bildbetrachter etc)

2. Ist eigentlich keine große Sache - das Problem ist halt nur, das die mounts in /var/autofs/ nur sichtbar sind, wenn auf sie zugegriffen wird (+timeout). Dh. bevor ein Filebrowser geöffnet wird müßte ein Zugriff auf alle mounts aus auto.net gemacht werden (ls > /dev/null) danach sind die mounts für tZugriff+timeout sichtbar und können ausgewählt werden. Alternativ könnte man das mit einem extra skript erschlagen. Das müßte aber immer vorher ausgeführt werden. Evtl gibts ja noch eine ganz andere Lösung. Ich behelfe mir momentan mit symlinks im /mnt/ - ist für mich ok aber zur laufzeit im squashfs nicht machbar.
Noch eine andere Lösung wäre, beim Auswählen der Verzeichnisse (Aufnahmeverzeichnis, Bildbetrachter etc.) nicht in den Filebrowser zu springen sondern lediglich eine Auswahl aus auto.net anzuzeigen. Der Filebrowser macht an der Stelle eh nicht großartig Sinn, da man eh nur auf mounts aufnehmen kann.

Was spricht eigentlich dagegen, den Automounter als Neutrino-Standard zu etablieren und die "althergebrachten" Mountoptionen damit zu ersetzen? Die mountoptionen würden dann halt nicht mehr in die neutrino conf geschrieben sondern in die /var/etc/auto.net (fstab format). Das setzt natürlich funktionalität nach 2. voraus.

[MajorK]

Der Automounter funktioniert ja mittlerweile prima.

100% ACK - ich nutze die "alten" Mounts auch nicht mehr.

(...) Ich behelfe mir momentan mit symlinks im /mnt/ - ist für mich ok aber zur laufzeit im squashfs nicht machbar.

Also ich brauchte das nur fuer die erstmalige Einrichtung. Bei mir sind die Startverzeichnisse fuer Aufnahme, Movieplayer etc. entsprechend gesetzt und wenn eine Aufnahme gestartet wird, wird auch gemountet.
Das sollte 90% aller Anforderungen abdecken.
Also wuerde es reichen, bei der Konfiguration(!) einen Button a'la "Mount all Directories from auto.net" zu haben. Anschliessend kann man die Standardeinstellungen fuer Audioplayer etc. vornehmen.

Zur Not koennte man ja auch ein "filebrowser.start" script vorschalten oder Du loest Dein Problem mit verschiedenen Aufnahmeverzeichnissen ueber ein "mounten" in "recording.start"

Was spricht eigentlich dagegen, den Automounter als Neutrino-Standard zu etablieren ... .

Was spricht gegen eine Co-Existenz?

Major K.
PS: Die auto.net ueber die GUI editieren zu koennen waere natuerlich wuenschenswert.

[mb405]

also ich brauch da kein zusätzliches gui, was die neutrino binary künstlich aufbläht. die auto.net erstelle ich 1x und übernehme die in jedes neue image. ist ne sache von paar sekunden. es geht schneller, als wenn ich jedesmal in der gui alles eingeben muss.
ist meine meinung dazu. aber deswegen ist es ja ein forum, um alle meinungen zu hören.

[hannebamb(el)]

<IRONIE>

man kann auch mit pzapit schalten und fernsehen, wozu überhaupt ein aufgeblasenes binary names Neutrino, was das Image nur fett macht

</IRONIE>

*SCNR*

[Tommy]

also ich brauch da kein zusätzliches gui, was die neutrino binary künstlich aufbläht. die auto.net erstelle ich 1x und übernehme die in jedes neue image. ist ne sache von paar sekunden. es geht schneller, als wenn ich jedesmal in der gui alles eingeben muss.
ist meine meinung dazu. aber deswegen ist es ja ein forum, um alle meinungen zu hören.

Wenn mans aus der Sicht sieht bräuchte man auch nicht die mountoptionen in der GUI da man's ja auch bequem in der neutrino.conf editieren kann. Die Frage ist nur, was die mountsettings in der neutrino.conf überhaupt zu suchen haben. Man könnte also eher von einer entschlackung reden, da ja auch irgendwo der code für das mounten (beim start) im neutrino versteckt ist. Auf einem "normalen Linux System" liegen diese settings in /etc/fstab oder (schlagt mich wenns falsch ist) in /etc/auto.master im Falle des Automounters. Eine Coexistens würde ich vermeiden da die settings s.o. in unterschiedlichen files gespeichert werden und Fehlfunktionen so nicht ausgeschlossen werden können.
Eine neue/extra GUI will ich auch nicht. Die bisherigen mountsettings können unverändert genutzt werden, nur das nicht mehr in neutrino.conf sondern auto.net gespeichert wird. Am look&feel von Neutrino wird sich dadurch nichts ändern, außer das es sicherer wird. Hat es jemals jemanden interessiert ob ein mount eingehängt war/ist wenn er es nicht benutzt hat? Mit dem Automounter wird sichergestellt, das bei bedarf die NW Recource deffinitiv zur Verfügung steht (wenn der dazugehörige Server ON ist) Der ganze Bratsch mit dem "mounten in recording.start", "mounten beim start von Neutrino", "mounten wenn die Frau nach hause kommt"..... kann somit entfallen.

Versteht mich bitte nicht falsch - ICH brauch die Settings auch nicht in der GUI da ich beim image bauen die auto.net reinkopiere nebst neutrino.conf und zur sicherheit noch symlinks nach von /var/autofs/film nach /mnt/film lege. Hier geht es darum den Automounter als Standard zu etablieren.

[mb405]

das mit dem entschlacken wurde schon zig mal beschrieben. ein paar haben da schon angefangen(experimental menu) was auszulagern. nur wird der bequemlichkeit halber immer wieder zeugs in die neutrino reingenommen.
weitere meinungen ?

[Nico 77]

Was genau wäre der Unterschied zwischen Automount und der derzeitigen Version in Neutrino?
Welche Vorteile bringt automount genau mit?

Ich habe meine Mountordner einmal per Menü eingegeben und wird auch bei jedem Start gemountet. Somit ist es quasi auch Automount.

Was gegen die neue Version spricht ist ganz klar das es ein Script ist und nicht über Gui, was sich speedmäßig wenn die Scripteuforie weitergeht sehr negativ auswirken wird.

Am besten zu sehen ist das in diesen ganzen Dummflashimages wo ein Script das andere jagt und mit dem schnellen komfort der Neutrino Gui nichts mehr zu merken ist.

recording.start
recording.stop
stanby.on
standby.off
usw...

Das wäre mein Gedankenansatz zu dem Thema Scripte.

[Tommy]

Ich habe meine Mountordner einmal per Menü eingegeben und wird auch bei jedem Start gemountet. Somit ist es quasi auch Automount.

was ist wenn der mount ausgehängt wird durch server downtime z.B. oder andere unwägbarkeiten?

Was gegen die neue Version spricht ist ganz klar das es ein Script ist und nicht über Gui, was sich speedmäßig wenn die Scripteuforie weitergeht sehr negativ auswirken wird.

wie bitte? Es gibt ausgenommen dem Startscript zum starten des AM keine weiteren scripte. Es gibt eine auto.net die aussieht wie eine fstab in jedem anderen Linux system. Nur tuxbox hat sowas nicht und stattdessen eine proparitäre Lösung mit den settings in der neutrino.conf. Ist vermutl. damals wie so oft quick&dirty eingebaut worden und dann neutrino Standard geworden. (vermutl. weil es schwerer ist eine fstab aus der GUI zu verwalten als die settings in die neutrino.conf-(Müllhalde) zu pappen.

recording.start
recording.stop
stanby.on
standby.off

genau diese mountorgien in o.g. scripten fallen dann weg! lies meine Ausführungen weiter oben

[palace]

Also, ich wäre auch dafür, das bisherige mounten durch den Automounter zu ERSETZEN.

[palace]

Also, ich wäre auch dafür, das bisherige mounten durch den Automounter zu ERSETZEN.

Nur mal aus reiner neugier: Wird da was gemacht oder bleibt es bei beiden Methoden?

[Tommy]

ich persönlich brauchs nicht da ich während der buildzeit symlinks von /var/autofs nach /mnt lege. Auf diese Art komme ich klar wie gehabt und die automounts sind (in Form der symlinks) sichtbar - also in allen GUI optionen verwendbar.

Nicht schön aber funktioniert. Ich bin trotzdem dafür das der Automounter fest integriert wird - dazu gehört dann auch das er GUI konfigurierbar ist. Mit Sicherheit sinds nur ein paar Zeilen code - nur wer machts

[palace]

Ich bin trotzdem dafür das der Automounter fest integriert wird - dazu gehört dann auch das er GUI konfigurierbar ist. Mit Sicherheit sinds nur ein paar Zeilen code - nur wer machts

Danach frag ich ja
Es ist nicht wirklich wichtig, aber ein nice to have Feature...
Leider bin ich nur "Konsument" (nicht für DBox programmieren kann, sich in Linux quasi nich auskenn')

[Barf]

Erstmals möchte ich abwarten, bis Kernel 2.6 Standard ist. Grund ist dass der Automounter ein kernelnahe Komponente ist, und evtl. ein kleines Tick anders als bei 2.4 funktioniert.

Zweitens sind wir eingentlich nicht völlig fertig: Ghosting sollte funktionieren. Ich habe es irgendwo erwähnt; ich habe ein sehr überflächliges Versuch gemacht, dies zum Laufen zu bringen, mein sehr überflächliches Versuch ging nicht, und ich habe es nicht weiterverfolgt. (Und auch niemand Anderes.) Ausserdem "muss" es eine saubere Methode, ungenützte Funktionalität zu entfernen; jemand (Papst?) hat vorgeschlagen, einige .so zu löschen; es sollte auch einen sauberen Weg geben.

Langfristig ist es sicherlich sinnvoll, die Mountfunktionalität aus Neutrino zu entfernen. Besonderes elegant ist es auch nicht implementiert (system("mount ...") statt Systemanrufe). Funktionen wie Warmduschereditieren von fstab oder auto.net sollte (falls überhaupt!) zu Plugins ausgelagert werden.

[zexma]

Erstmals möchte ich abwarten, bis Kernel 2.6 Standard ist.

ob er das im Rahmen des Neutrino/Tuxbox-Projekts noch jemals werden wird?
Das wage ich zu bezweifeln.

[Gorcon]

Langfristig ist es sicherlich sinnvoll, die Mountfunktionalität aus Neutrino zu entfernen.

Solange nicht irhendwelche Probleme auftreten, geht das auch in Ordnung.
Aber machmal werden die User ja hier einfach vor vollendete Tatsachen gestellt (siehe Movieplayer der nach dem Einbau des zusätzlichen Puffers bei mir nicht mehr zu gebrauchen ist).

Mal schaun ob das mit meiner Hardware auch alles so läuft.

Gruß Gorcon

[Tommy]

Erstmals möchte ich abwarten, bis Kernel 2.6 Standard ist.

ob er das im Rahmen des Neutrino/Tuxbox-Projekts noch jemals werden wird?
Das wage ich zu bezweifeln.

soweit ich weis kann man mit newmake diesbezügl schon yadd's bauen also zumindest testen

[Papst]

Hab mir grade die ghostinggeschichte angesehen. Es muss nur der Kernel gepatched werden damit das läuft.
In diesem Archiv ist der benötigte Patch:
http://www.kernel.org/pub/linux/daemons ... 404.tar.gz

Und zwar module-patches/autofs4-2.4.29.patch

Den Patch einfach in tuxbox-cvs/cdk/linux kopieren und mit patch -p1 < autofs4-2.4.29.patch anwenden.

Nun den automounter noch zusätzlich mit der Option -g starten und die Verzeichnisse sind immer sichtbar. Auch wenn sie grade nicht gemounted sind.

Ein fertig gepachtes Autofs4 Kernelmodul hab ich hier hochgeladen:
http://rapidshare.de/files/19607146/autofs4.o.html

[Tommy]

Langfristig ist es sicherlich sinnvoll, die Mountfunktionalität aus Neutrino zu entfernen.

Solange nicht irhendwelche Probleme auftreten, geht das auch in Ordnung.
Aber machmal werden die User ja hier einfach vor vollendete Tatsachen gestellt (siehe Movieplayer der nach dem Einbau des zusätzlichen Puffers bei mir nicht mehr zu gebrauchen ist).

wenn sich von zig Leuten nur einer beschwert nennt sich das glaub ich colateralschaden (auch wenns blöd klingt). Ich denke mit dem IDE Interface wirds auch was mit dem Timeshift.

Mal schaun ob das mit meiner Hardware auch alles so läuft.

Gruß Gorcon

eher besser als schlechter - es wird ja nicht das Mounten an sich geändert sondern das wann und wie. Unter Linux stehen nunmal alle FS in der fstab und nicht in der neutrino.conf. Wie gesagt - wurde damals bestimmt quick&dirty gemacht und nie wieder angefaßt (außer das die Anzahl der mounts von 4 irgendwann auf 8 hochgeschraubt wurde.)

[PT-1]

Ein fertig gepachtes Autofs4 Kernelmodul hab ich hier hochgeladen:
http://rapidshare.de/files/19607146/autofs4.o.html

Koenntest du eventuell auch auf http://www.yousendit.com hochladen ..?

Dein Link geht nicht mehr

[Papst]

Bei mir geht der Link zwar aber hier:
http://download.yousendit.com/BDCE7431624D7E41

[Papst]

@Barf
Was sagste dazu? Kannstes vielleicht mal einchecken?

[yjogol]

Automount klingt ja gut.

Habe ich bisher noch nicht eingebaut ...
Also für das yadd "make automount" und CONFIG_AUTOFS_FS=y setzen.
Ok.

Hält nur die auto.net die Mountdaten?
Welcher Befehl muß dann aufgerufen werden, wenn die Konfiguration sich geändert hat.

Wenn es bei mir im yadd läuft, dann bau ich es in yWeb 2.0 ein.

Gruß
yjogol

[Barf]

Automount klingt ja gut.

Nicht nur klingt...

CONFIG_AUTOFS_FS=y

Nein. CONFIG_AUTOFS4_FS=y (wichtig!)

nur die auto.net die Mountdaten?

Yup.

Welcher Befehl muß dann aufgerufen werden, wenn die Konfiguration sich geändert hat.

Code: Alles auswählen

kill -HUP `cat /var/run/automount.pid`

(fordert eventuell Ghosting?)

Wenn es bei mir im yadd läuft, dann bau ich es in yWeb 2.0 ein.

[yjogol]

Automount klingt ja gut.

Nicht nur klingt...

CONFIG_AUTOFS_FS=y

Nein. CONFIG_AUTOFS4_FS=y (wichtig!)

nur die auto.net die Mountdaten?

Yup.

Welcher Befehl muß dann aufgerufen werden, wenn die Konfiguration sich geändert hat.

Code: Alles auswählen

kill -HUP `cat /var/run/automount.pid`

(fordert eventuell Ghosting?)

Wenn es bei mir im yadd läuft, dann bau ich es in yWeb 2.0 ein.

Jup, jetzt läufts.

Frage: wo wird die auto.net sein? In /etc bei yadd / JFFs2 und in /var/etc bei squash?
Und/oder könnte man die Variable MAPFILE exportieren, so dass sie im System zur Verfügung steht?

Gruß
yjogol

[Nico 77]

Das Automount Feature bekommt ja sehr viel Zustimmung das es Sinn machen würde standartmäßig im CVS komplett zu aktivieren.

Meiner Meinung nach wäre es auch am sinnvollsten wenn das Feature dann /var/ bereichsmäßig aufgebaut würde für cramfs/squashfs Nutzer.