Verständnisfrage automount / Freetz 1.13

Gero013

Neuer User
Mitglied seit
5 Mai 2010
Beiträge
190
Punkte für Reaktionen
0
Punkte
0
Hallo,

aktuell habe ich das "Problem", dass autoend.sh nicht automatisch aufgerufen wird. Leider weiß ich nicht, ob es eine Fehlbedienung oder Fehleinschätzung meinerseits ist.

Ich meine (bin mir aber nicht sicher), dass der Aufruf von autoend.sh schon mal geklappt hätte. Könnte natürlich sein, dass das mit dem trunk-image war.
Aktuell habe ich wieder ein 1.13 drauf und der Aufruf von autorun.sh beim Einstecken, bzw. Einschalten der Platte funzt.

Muss ich einen anderen Befehl (commandline via ssh) anstatt "umount" aufrufen, damit autoend.sh ausgeführt wird, oder funktioniert das nicht mit 1.13?

Gruß Gero
 
Ich glaube, dass umount damit nichts zu tun hat, sondern das umounten aus dem Webinterface gemeint ist.
 
Danke für die Hinweise. Habe mir noch einen wrapper für umount geschrieben. Jetzt ist die Sache rund :)

Gruß Gero
 
Sollte so ein Wrapper bei autostart/autoend nicht vllt. ins image?
 
Der Aufruf beim Mounten passiert ja automatisch, da braucht es keine Wrapper.
Beim Autoend bin ich mir nicht sicher. Die meisten werden dafür das Web-Interface verwenden. Aber wir können dafür ein Skript erstellen, das dann auch vom Web-Interface aufgerufen werden kann.
 
Und den hat er schon geschrieben und stellt ihn vllt. zur Verfügung...
 
Wir haben im trunk einen "unmount" Button im Webinterface. Ich nehme an, dass hier autoend aufgerufen wird?

MfG Oliver
 
Hallo,

ich habe hier im ersten Beitrag alles zusammen getragen, was ich jetzt aktuell auf der Platte habe, um sie so ein- und auszubinden, wie ich mir das vorstellte.

Wenn Ihr es wert erachtet, in Freetz zu integrieren - ok, der Code gehört Euch :)

Gruß Gero
 
Ich weiß nicht, was mit 1.13 geht und was nicht. Ich kann nur das erklären, was ich damals gemacht hatte:
1. Unmount-Knopf macht kein unmount in dem Sinne, sondern bedient hotplug-Skripts von AVM. Dies ist notwendig, um z.B. FAT-Partitionen mit TAM-Daten sauber unmounten zu können. Aus diesen hotplug-Skripten wird unter anderem umount aufgerufen, aber nicht nur.
2. Die AVM-hotplug-Skripte werden mit dem FREETZMOUNT gepatcht. Im Unterschied zu alten automount-Skripten werden hier die ganzen Funktionen / Sektionen nach libmodmount.sh ausgelagert.
3. Jeder ist willkommen libmodmount.sh zu erweitern und zu modifizieren. Denn ich hatte lediglich rudimentäre Sachen da reingepackt gehabt. Geplant war viel mehr.
4. UUID-Support könnte man sicherlich neben dem LABEL-Support einbauen. AVM hatte ja auch etwas UUID-ähnliches mal gehabt. Allerdings muss man sicherstellen, dass UUID erkannt wird. Also, entweder blkid mit UUID-Unterstützung oder eben busybox mit UUID-Support. Beides muss aber erstmal gecheckt werden! blkid ist nicht immer im Image drin!

Deswegen würde ich dir Gero013 anraten sich die bestehenden FREETZMOUNT-Sachen anzuschauen, bevor du das Rad neu erfindest. Eine sinnvolle Erweiterung für FREETZMOUNT wäre sicherlich wünschenswert, aber bitte nicht so spezifisch gestalten, wie im zitierten Beispiel, sondern etwas universeller. Bei den hotplug-Skripten finden sich z.B. die Starts/Stops vom ftpd, die man evtl. mit einem reload ersetzen könnte und anstatt von AVM-ftpd z.B. vsftpd verwenden.

MfG
 
Hallo Herman,

tut mir leid, wenn Du Dich durch die Scripte angegriffen fühltest.
War nicht meine Absicht.

Ich habe vorher Deinen Fred zum Thema automount gelesen gehabt, aber die Sache mit dem umount war mir unklar gewesen (vielleicht auch bedingt dadurch, dass ich jetzt mehrfach zwischen trunk und 1.13 gewechselt habe und meinte autoend.sh wäre bei umount ausgeführt worden).

Meine Scripte oben sind weder Ersatz noch Erweiterung für Freetzmount, sie verwenden Freetzmount und würden ohne garnicht funktionieren.
Ich habe auch Deine ablehnende Haltung zu UUID gelesen und kann sie sogar unterstützen.
Würde ich automount so erweitern, dass UUID verwendet würde, müsste ich von allen Platten, die ich anstöpseln will, die UUID in fstab eintragen. Das ist nicht das, was ich wollte. Deshalb bin ich den anderen Weg gegangen und habe von der eingebundenen Platte aus die UUID ermittelt (da ich weiß, dass alle meine Platten UUID haben und es auf meiner Box ein blkid gibt, ist das kein Risiko) und anschließend die Benutzer angelegt und die Verzeichnisse eingebunden.
Ohne Dein automount würden meine Scripte garnicht ins Spiel kommen.

Labels habe ich eher selten verwendet und bin nicht sicher, ob ich da, wenn vorhanden, wirklich immer unterschiedliche verwendet habe. Bei UUID kann ich davon ausgehen, dass die eindeutig ist und nur nach einer Eindeutigkeit habe ich gesucht.

Klar ist die Geschichte mit den Benutzern und deren Verzeichnisse sehr individuell, aber der Weg könnte vielleicht auch für andere interessant sein. Ich kann so unterschiedliche Benutzer und unterschiedliche Verzeichnisse unterstützen und kann die Platten am PC vorbereiten, sodass das Hotplugging an der FB funktioniert, ohne dass ich die fstab ändern muss.

Die unmount-Erweiterung kam nur dazu, weil ich sehr viel auf Befehlszeile arbeite (sei es um Logs anzuzeigen, oder, oder, oder ...) und von dort die Platte zum abschalten vorbereiten wollte.

Dir kann ich nur raten, etwas relaxter zu sein. Ich verwende viele Deiner Erfindungen und bin froh, dass es so Leute wie Dich gibt. Ich bin kein Erfinder, kann nur Bestehendes verbessern - also eigentlich kann ich nur meckern wirklich gut ;)

Gruß Gero
 
@Gero013: Ich hatte aus deinen autorun/autoend-Skripten es aber so verstanden, dass du sie zuerst geschrieben hast, bevor du die hotplug-Skripte und unsere Modifikationen darin (sei es automount-Patches oder FREETZMOUNT) studiert hast. Daher kam die Anmerkung mit dem Raderfinden.
Wie wir alle sehen, hast du viel Potential, Gero013. Du hast aber ein kleines Problem: Du versuchst alles von Null an selbst zu erfinden. Und das ist kontraproduktiv. FREETZ existiert schon seit mehr als 5 Jahren (wenn man alle seine Vorgänger dazu zählt) und da hat sich bereits ein menge an Stoff angesammelt. Auch die AVMs schlafen nicht immer und werkeln an einer oder anderer Ecke (obwohl sie es manchmal lieber unterlassen hätten). Man kann natürlich das alles ignorieren und komplett von vorne anfangen. Solche Ansätze bringen oft bessere Erfolge, meistens ist es aber besser die Vorarbeiten wenigstens zu beachten und versuchen zu verstehen.
Konkret zu FREETZMOUNT. Ich hatte libmodmount.sh extra dafür erschaffen, damit alle daran basteln können. Warum willst du nicht deine tolle UUID-Methode da rein intergrieren? Ich lade dich extra dazu ausdrücklich ein. Wenn man dazu 2-3 Zeilen in der automount-Sektion von WebIF spendiert und vielleicht eine conf-datei mit den bekannten UUIDs anlegt, dann wäre es was, oder?
Die usrprüngliche Idee von FREETZMOUNT war unter anderem so eine Art fstab zu erschaffen, um die Mountpoints besser zu verwalten. Eine Möglichkeit dies eindeutig zu machen wäre LABELs, die andere wäre UUIDs. Wie gesagt, wenn du deine Sachen noch weiter entwickeln würdest und in FREETZMOUNT integrieren, wird dir keiner hier böse sein. Dafür müssen die Sachen aber eben etwas allgemeiner gestaltet werden, damit alle es nutzen können.

MfG
 
Du hast aber ein kleines Problem: Du versuchst alles von Null an selbst zu erfinden. Und das ist kontraproduktiv.
Sorry, aber ganz so kann ich das nicht stehen lassen.

Im konkreten Fall ist es so, dass ich einen kleinen Hub an der FB habe und eines Tages hat das Einbinden der Platte nicht geklappt. Beim nachschauen entdeckte ich dann das übliche USB-Problem, dass das erste device sda ist und das folgende sdb etc. Dieser Benamsung folgt auch Freetzmount, was ja durchaus "standard" ist, aber für mich nicht brauchbar war. Ich wollte zwischen Platten und Stick unterscheiden, am besten sogar noch zwischen den einzelnen Platten.

An meinem Desktop ist es so, dass ich alle UUIDs in der fstab eingetragen habe. Seit einiger Zeit fahre ich mit RO-root und weiß, wie lästig eine Änderung an der fstab ist (bei der FB wäre ja jedesmal ein flashen angesagt).

Mir war schnell klar, dass ich das auf der FB nicht wollte, also gab es keine Veranlassung für mich, Bestehendes ändern zu wollen. Statt dessen suchte ich nach einem Weg, Freetzmount (bzw. den automount-Mechanismus) zu verwenden und trotzdem eine eindeutige Kennung der Medien zu haben, die nicht von der Reihenfolge der Aktivierung abhängt.

Die UUID war das naheliegendste (weil mir bereits vertraut) und so habe ich etwas gegurgelt und im Freetz gegrabbt, um rauszufinden, was möglich ist und wie.

Wenn ich meine Scripte anschaue, dann habe ich nix nachcodiert oder das Rad neu erfunden, sondern habe eine Lösung entwickelt, die (ausschließlich) meinen Anforderungen entspricht.

Vielleicht war es vermessen, anzunehmen, dass jemand anderes in der gleichen Lage wie ich wäre - auf jeden Fall würde ich nicht im Traum daran denke, Patches für Freetzfunktionen zu machen. Schließlich liegen Welten zwischen den Freetz-Scriptern und dem, was bei mir so als Script rauskommt. Ich komme eben aus ner ganz anderen Ecke, bin aber pragmatisch genug, um auch mit meinem einfachen Programmierstil zufrieden zu sein.
Inzwischen habe ich mir Deine Lib mal angeschaut und festgestellt, dass ich zuwenig Ahnung von der Materie habe, um eine Erweiterung zu erstellen.
Wenn Du meinst, dass in meinen Scripten was brauchbares für Deine Lib dabei ist, dann darfst Du Dich gerne bedienen. Dafür habe ich sie ja gepostet.

Deine Idee mit der Benutzer-VW finde ich gut und bin schon dabei es umzusetzen. Habe dazu meine rc.local so geändert, dass sie Benutzer und Verzeichnisse aus einer Datei liest, das klappt schon (ich aktualisiere mal den ersten Post im anderen Fred). Fehlt nur noch die Oberfläche um die Datei zu erstellen/bearbeiten.

Gruß Gero
 
@Gero013: Die Sachen in libmodmount.sh sind nicht so ganz wild, wenn man sich damit etwas befasst hat. Und sie kommen meistens von AVM und nicht von mir. Wie gesagt, ich hatte nur das Nötigste da ausgelagert, damit wir es "bei uns" in FREETZ haben und daran werkeln können. Früher hat man mit automount-Patches die hotplug-Skripte von AVM direkt gepatcht, was relativ schwer für alle Boxen zu pflegen war. FREETZMOUNT macht es so, dass alles, was wir patchen wollen nach libmodmount.sh kommt. Daher kann man es deutlich bequemer an einer Stelle pflegen.
Ich bin auch kein Programmierer und meine Shell-Skripte sind ganz weit von dem entfernt, was man als ideal bezeichnen würde, dennoch poste ich meine Sachen hier und sie fließen dann in FREETZ ein, wenn es eine entsprechende Resonanz findet.
Das Problem bei den eigenen nur für sich angepassten Lösungen besteht darin, dass sie von nur wenigen hier angeschaut werden, sodass deine Idee relativ schnell in den Tiefen von IPPF versinkt. Nach 2-3 Monaten kommt noch einer Gero0815 und fängt wieder von vorne an. Und das ist kontraproduktiv. Deswegen versuche bitte -soweit es geht- deine Sachen so zu gestalten, dass man sie entweder direkt oder nach einer kleinen Anpassung in FREETZ einpflegen könnte. Idealerweise postet man hier patches gegen trunk. Dann haben die Anderen und die Devs es am leichtesten mit Minimalaufwand deine Sachen zu testen. Und dann fließt es schneller in trunk rein.
Trunk ist wiederum eine gute Möglichkeit deine Ideen breit und weit zu testen (wenn sie natürlich halbwegs ausgereift sind). Deswegen sollte man immer streben, die Sachen in den trunk zu bringen, selbst wenn man sich noch nicht 100% im Klaren ist, dass sie tun.
Was denkst du, wie gefährlich und mutig von uns damals war FREETZMOUNT in trunk aufzunehmen? Solche Sachen, die an den Wurzeln vom System werkeln sind meistens am Gefährlichsten. Deswegen kommt FREETZMOUNT zunächst als Zusatz zu automount-Patches und nicht als Ersatz, damit man eine gewisse Rückfallebene hat.

Zu deiner Benutzerverwaltung und Oberfläche mach dir keine Sorgen. Wenn du es auf Skript-Ebene gelöst hast, werden wir schon dazu ein passendes WebIF zurecht basteln können. Möglichkeiten sind alle da.

MfG
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.