Sorry, aber ich halte wirklich nichts davon, User Plattren mounten/umoßunten zu lassen. Auch gibt das Webinterface so etweas aktuell nicht her. Wenn du allerdings eine komplette Userwerwaltung mit Rightsmanagment schreiben möchtest fürs Webinterface....
[im trunk]: Mountfähige mounted.cgi
- Ersteller hermann72pb
- Erstellt am
Sorry, aber ich halte wirklich nichts davon, User Plattren mounten/umoßunten zu lassen. Auch gibt das Webinterface so etweas aktuell nicht her. Wenn du allerdings eine komplette Userwerwaltung mit Rightsmanagment schreiben möchtest fürs Webinterface....
Glaub fast wie reden aneinander vorbei.
Irgendwelche user sollen natürlich NICHT die Platten mounten/unmounten können. Das geschieht ja nachwievor über den user, standardmäßig in freetz der "admin", der am freetz.IF angemeldet ist. So wie jetzt halt auch.
Ich meinte, das "admin" quasi den usern (ich sag mal, siehe passwd) die entsprechenden Lese-/Schreibrechte geben/entziehen kann.
Ach so 
Das ist was vollkommen anderes als das mounten der Platten, und hätte dort gar nichts zu suchen. Diese Sachen regelt man am bestne mit einem Filesystem, was Userrechte versteht (fat und ntfs eben nicht unter linux) und dann über user/gruppenzugehörigkeiten. Das zu setzen/entziehen übersteigt bei weitem das, um was es hier geht.
Das ist was vollkommen anderes als das mounten der Platten, und hätte dort gar nichts zu suchen. Diese Sachen regelt man am bestne mit einem Filesystem, was Userrechte versteht (fat und ntfs eben nicht unter linux) und dann über user/gruppenzugehörigkeiten. Das zu setzen/entziehen übersteigt bei weitem das, um was es hier geht.
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
@colonia:
1. Ich verstehe leider nicht, was das mit den mount-Sachen zu tun hat. Wie Silent-Tears zu Recht sagt, mount ist eine reine root-Sache. Das ist allgemein bei Linux so üblich.
2. Das Minimum an Farben werde ich da schon lassen. Sonst kann man es schlecht kompakt machen. Farbe ist sowas wie eine dritte Dimension, wenn man damit vernünftig umgeht.
3. Die alten "neuen Designs" werden wenigstens bei meinen Balken nicht funktionieren, wenn wir es so implementieren, wie ich es vorschlage. An die Designs hatte ich eigenlich gar nicht gedacht. ABER... Ich realisiere alles mit CSS, sodass mein Konzept sich noch einfacher für die Designs eignet. Mann muss es nur konsequent durchziehen und die style-Definitionen aus der cgi in Richtung style.css (oder wie immer diese globale Datei auch heißt) schieben. Dann ließen sich "neue Designs" in wenigen Sekunden durch Anpassung einer einzigen Datei (style.css) realisieren. Ich hatte mir die jetzige Implementierung von den Designs nicht angeschaut, mag sein, dass es teilweise schon in die Richtung geht.
Edit: Silent-Tears war schneller...
MfG
1. Ich verstehe leider nicht, was das mit den mount-Sachen zu tun hat. Wie Silent-Tears zu Recht sagt, mount ist eine reine root-Sache. Das ist allgemein bei Linux so üblich.
2. Das Minimum an Farben werde ich da schon lassen. Sonst kann man es schlecht kompakt machen. Farbe ist sowas wie eine dritte Dimension, wenn man damit vernünftig umgeht.
3. Die alten "neuen Designs" werden wenigstens bei meinen Balken nicht funktionieren, wenn wir es so implementieren, wie ich es vorschlage. An die Designs hatte ich eigenlich gar nicht gedacht. ABER... Ich realisiere alles mit CSS, sodass mein Konzept sich noch einfacher für die Designs eignet. Mann muss es nur konsequent durchziehen und die style-Definitionen aus der cgi in Richtung style.css (oder wie immer diese globale Datei auch heißt) schieben. Dann ließen sich "neue Designs" in wenigen Sekunden durch Anpassung einer einzigen Datei (style.css) realisieren. Ich hatte mir die jetzige Implementierung von den Designs nicht angeschaut, mag sein, dass es teilweise schon in die Richtung geht.
Edit: Silent-Tears war schneller...
MfG
Is schon klar. Genau dein Einwand bzgl. userrechte und verschiedene filesystems kam mir später selbst in den Sinn.
Aber ob sich sowas auch im IF darstellen ließe?!?
Vielleicht beim nächsten mal, wenn Hermann wieder Luft & Lust hast hat ;-)
@Hermann: wenn ich wüsste wie, würd ich sogar helfen. Leider hab ich von dem ganzen Zeug keine Ahnung. Ich bin sozusagen nur User und gebe gerne Feedback/Anregungen/Verbesserungsmöglichkeiten.
Das "Schlachtfeld überlass ich gern euch
[EDIT] ich Honk, merke grad, daß ich den in #18 angesprochenen screenshot gar nicht angehangen hab.
Habt ihr wahrscheinlich schon gemerkt...... warum sagt ihr denn nichts
Hab ihn in #18 jetzt beigepackt
Aber ob sich sowas auch im IF darstellen ließe?!?
Vielleicht beim nächsten mal, wenn Hermann wieder Luft & Lust hast hat ;-)
@Hermann: wenn ich wüsste wie, würd ich sogar helfen. Leider hab ich von dem ganzen Zeug keine Ahnung. Ich bin sozusagen nur User und gebe gerne Feedback/Anregungen/Verbesserungsmöglichkeiten.
Das "Schlachtfeld überlass ich gern euch
[EDIT] ich Honk, merke grad, daß ich den in #18 angesprochenen screenshot gar nicht angehangen hab.
Habt ihr wahrscheinlich schon gemerkt...... warum sagt ihr denn nichts
Hab ihn in #18 jetzt beigepackt
Zuletzt bearbeitet von einem Moderator:
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Jetzt habe ich kapiert was du eigentlich gemeint hast. Wahrscheinlich gefällt dir die Idee mit "R" und "W" - Knöpfen und du dachtest, dass man sowas ähnliches für die Freigabe von Ordnern nutzen könnte. Die Idee an sich ist nicht schlecht und ließe sich bestimmt irgendwie realisieren. Aber man sollte dort vielleicht dann eher mit Checkboxen arbeiten und einen oder höchstens zwei Knöpfe für "setzen" und "löschen" haben. Die Realisierung kann man sich wiederum bei AVM-Firewall-CGI abgucken. Dort wird sowas gemacht.
Ich persönlich sehe an diesem WebUI-Rechtendingens aber keinen großen Bedarf. Deswegen steht es bei mir nicht an der höchsten Prio-Liste. Lass uns mal zunächst diese Sache hier vernünftig zu Ende bringen. Gleichzeitig an mehreren Baustellen zu arbeiten tue ich nur auf der Arbeit. Hier im Forum wird mein Multitasking abgeschaltet. Und alleine bei dieser mount-Problematik gibt es noch vieles, was man noch machen könnte / sollte.
MfG
Ich persönlich sehe an diesem WebUI-Rechtendingens aber keinen großen Bedarf. Deswegen steht es bei mir nicht an der höchsten Prio-Liste. Lass uns mal zunächst diese Sache hier vernünftig zu Ende bringen. Gleichzeitig an mehreren Baustellen zu arbeiten tue ich nur auf der Arbeit. Hier im Forum wird mein Multitasking abgeschaltet. Und alleine bei dieser mount-Problematik gibt es noch vieles, was man noch machen könnte / sollte.
MfG
Sorry, das kommt davon, daß du dich mit Amateuren unterhälst
Grundsätzlich richtig erkannt, allerdings hatte ich dabei gar nicht an die diversen Ordner und Verzeichnisse gedacht die sich auf den Speichermedien befinden können.
In erster Linie ging es mir um die Partition im Ganzen.
Aber aufgrund dessen, daß sich darauf ja unzählige Mengen an Unterverzichnissen befinden könnten, würde das ganze wohl too much für das Web-IF.
Denke also auch, wir lassen das erstmal.
trotzdem schonmal danke fürs Gedankenmachen.
Übrigens, wegen mir kann dein mounted-patch in den trunk.
Es sei denn du bist noch dran und versuchst ihn auch für die Anzeige auf der Hauptseite verfügbar zu machen.
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Wenn das schon in den trunk soll, dann bedarf es erstmal einer Überarbeitung. Bei dieser Überarbeitung werden in die cgi zunächst mal "lang"-Konstrukte einfließen, damit es zweisprachig wird. Dadurch, dass wir da vieles an Wörtern ausgespart haben und Rest voll mit Anglizismen gefüllt hatten, dürfte das eigentlich recht unproblematisch sein.
Danach werde ich natürlich schauen, dass die Hauptseite auch "mitspielt". Im Grunde wird dort die gleiche cgi einfach "included", aber man muss da mit Bibliotheken genau schauen. Evtl. lohnt sich in diesem Züge das Balkendarstellungsprogramm in libfreetz oder eine andere Bibliothek (Sammlung von häufig verwendeten Shell-Skripts) reinzunehmen. Man muss es aber schauen. Und mit den Style-Sheets sollte man es vernünftigerweise auch entsprechend in "style.css" reinpacken.
Danach sollte man noch einen Blick in all diesen "Design-Patches" werfen (danke für Hinweis), was die da alles verbrechen und vor allem wie. Evtl. wird es dann nötig die Design-Patches zu ändern, damit du deinen Liblingsgrauenbalken auswählen kannst.
MfG
Danach werde ich natürlich schauen, dass die Hauptseite auch "mitspielt". Im Grunde wird dort die gleiche cgi einfach "included", aber man muss da mit Bibliotheken genau schauen. Evtl. lohnt sich in diesem Züge das Balkendarstellungsprogramm in libfreetz oder eine andere Bibliothek (Sammlung von häufig verwendeten Shell-Skripts) reinzunehmen. Man muss es aber schauen. Und mit den Style-Sheets sollte man es vernünftigerweise auch entsprechend in "style.css" reinpacken.
Danach sollte man noch einen Blick in all diesen "Design-Patches" werfen (danke für Hinweis), was die da alles verbrechen und vor allem wie. Evtl. wird es dann nötig die Design-Patches zu ändern, damit du deinen Liblingsgrauenbalken auswählen kannst.
MfG
Bei Linux-Dateisystemen werden die Rechte bei jeder einzelnen Datei/Verzeichnis gespeichert. Bei den Windows-Dateisystemen werden die Linux-Rechte global vergeben. Die richtige Stelle dafür sind die Mount-Optionen.
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Das ist richtig. Trotzdem würde das hierhin schlecht passen. Denn die meisten Partitionen bei mir sind EXT und nicht FAT.
Appropos Dateisystemart. Das könnte man hier in der mounted.cgi anzeigen lassen. Damit man endlich weiß, wo dadrunter die FAT-Partition versteckt ist. Ich schaue es mir an.
MfG
Appropos Dateisystemart. Das könnte man hier in der mounted.cgi anzeigen lassen. Damit man endlich weiß, wo dadrunter die FAT-Partition versteckt ist. Ich schaue es mir an.
MfG
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Nee, mache ich anders. Da wird sowieso "mount" aufgerufen und danach durchs awk durchgejagt. Ich versuche alternativ die Parameter mit sed da rauszufischen. Evtl. wird es dadurch etwas schneller. Und wenn man da sowieso in den Zeilen nach dem "type" das fertige "fstyp" stehen hat, dann sollte man es schon von dort nehmen. Zudem, dass man für fstyp nicht den mountpoint verwenden kann. Ich müsste dann ja erst die dazugehörige /dev/sdX rausfischen und dann mit der "fstyp" füttern.
MfG
MfG
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Was meint ihr, ist die Sache hier so wie sie ist schon trunk-reif? Soll ich es für den trunk als patch vorbereiten, oder sollen wir noch weiter an dieser "on-the-fly"-Version basteln? Natürlich wird es zunächst zum testen als patch hier publiziert. Aber dann wird man es wohl nicht mehr so leicht "on-the-fly" testen können.
Hat es jemand schon mit usbroot getestet?
MfG
Hat es jemand schon mit usbroot getestet?
MfG
Mach einen Patch fertig. Denn den kann man prinzipiell auch auf der Box ausführen. Wenn man denn PAtch und diff auf der Box hat.
Darkyputz
Aktives Mitglied
- Mitglied seit
- 27 Jul 2005
- Beiträge
- 2,324
- Punkte für Reaktionen
- 0
- Punkte
- 36
Habe es eh schon Live bei mir im Image laufen...
Wenns also nu n den Trunk käme...mit nur recht...vor allem weil es in dem Partitionsdialog UND auch als Stand alone auffer Hauptseite funzt...
Danke dafür nochmal
Wenns also nu n den Trunk käme...mit nur recht...vor allem weil es in dem Partitionsdialog UND auch als Stand alone auffer Hauptseite funzt...
Danke dafür nochmal
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Es gibt da einige Probleme, die ich bereits angesprochen hatte und die ich im Züge der trunk-Vorbereitung gleich machen würde.
1. Ich würde gerne den patch "patches/cond/bar-style_n_cache-usage.patch" in die bestehende Konstruktion mitintegrieren. Wenn die zusätzliche Anzeige vom cache keinen hier stört, würde ich sie komplett in mounted.cgi übernehmen. Farben könnte man dann optional per menuconfig wählbar machen, sodass diese "graue Option" da immer noch bleibt, bzw. man könnte dann auch 2-3 Varianten da definieren.
2. Unterprogramm "stat_bar()" wandelt in irgendeine Skriptsammlung. Z.B. in "libmodcgi.sh" oder auch in eine separate Datei.
3. Style-Definitionen werde ich nach Möglichkeit in style.css einpflegen. Die Veränderung von Farben wird dann durch das Ersetzen von style.css ermöglicht.
4. Wenn mir Zeit übrig bleibt und ich Lust dazu habe, werde ich versuchen die Farbenanpassung der Bars im laufenden Betrieb zu ermöglichen.
MfG
1. Ich würde gerne den patch "patches/cond/bar-style_n_cache-usage.patch" in die bestehende Konstruktion mitintegrieren. Wenn die zusätzliche Anzeige vom cache keinen hier stört, würde ich sie komplett in mounted.cgi übernehmen. Farben könnte man dann optional per menuconfig wählbar machen, sodass diese "graue Option" da immer noch bleibt, bzw. man könnte dann auch 2-3 Varianten da definieren.
2. Unterprogramm "stat_bar()" wandelt in irgendeine Skriptsammlung. Z.B. in "libmodcgi.sh" oder auch in eine separate Datei.
3. Style-Definitionen werde ich nach Möglichkeit in style.css einpflegen. Die Veränderung von Farben wird dann durch das Ersetzen von style.css ermöglicht.
4. Wenn mir Zeit übrig bleibt und ich Lust dazu habe, werde ich versuchen die Farbenanpassung der Bars im laufenden Betrieb zu ermöglichen.
MfG
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Version 0.3
Nun bin ich damit fertig, die Version "trunkreif" zu machen. Bildchen und patch gegen trunk 3722 finden sich im ersten Posting.
Änderungen und Neuigkeiten:
1. patches/cond/bar-style_n_cache-usage.patch fliegt raus und wird teilweise im default-Design implementiert.
2. root/usr/share/style.css fliegt raus und wird durch style-colored.css und style-grey.css ersetzt. Im menuconfig kann man nun zwischen dem farbigen und grauen Schema umschalten. Theoretisch kann man hier weiter ausbauen und völlig neue Designs erstellen.
3. Die meisten Styles sind im Style-Sheet und nicht im Skript.
4. stat_bar() ist nun in libmodcgi.sh
5. "..., XYZ KB frei" eingeführt
6. Bars etwas dicker geworden. Dafür haben sie eine integrierte Prozentenanzeige bekommen.
7. Man kann auch aus dem Hauptmenu heraus mount-Operationen ausführen
8. jffs-Partitionen und davfs sollen nun auch angezeigt werden. davfs konnte ich nicht testen
Probleme und evtl. weitere todos:
1. Darstellung der Partitionen braucht auf meiner 7170 relativ viel Zeit. Liegt an der awk-Bearbeitung der mount/df-Ausgaben. Ich hatte da etwas rumoptimiert, habe aber nicht viel erreicht.
2. Ich wollte noch den Typ der Partition anzeigen (ext2/ext3), hatte aber bis jetzt auch nicht gemacht. Vermutlich wird die Ermittlung vom Partitiontyp auch etwas an Resourcen fressen und Darstellung verlangsamen.
Ansonsten einfach testen und wenn keine Einwände entstehen, dann bitte einchecken.
MfG
Nun bin ich damit fertig, die Version "trunkreif" zu machen. Bildchen und patch gegen trunk 3722 finden sich im ersten Posting.
Änderungen und Neuigkeiten:
1. patches/cond/bar-style_n_cache-usage.patch fliegt raus und wird teilweise im default-Design implementiert.
2. root/usr/share/style.css fliegt raus und wird durch style-colored.css und style-grey.css ersetzt. Im menuconfig kann man nun zwischen dem farbigen und grauen Schema umschalten. Theoretisch kann man hier weiter ausbauen und völlig neue Designs erstellen.
3. Die meisten Styles sind im Style-Sheet und nicht im Skript.
4. stat_bar() ist nun in libmodcgi.sh
5. "..., XYZ KB frei" eingeführt
6. Bars etwas dicker geworden. Dafür haben sie eine integrierte Prozentenanzeige bekommen.
7. Man kann auch aus dem Hauptmenu heraus mount-Operationen ausführen
8. jffs-Partitionen und davfs sollen nun auch angezeigt werden. davfs konnte ich nicht testen
Probleme und evtl. weitere todos:
1. Darstellung der Partitionen braucht auf meiner 7170 relativ viel Zeit. Liegt an der awk-Bearbeitung der mount/df-Ausgaben. Ich hatte da etwas rumoptimiert, habe aber nicht viel erreicht.
2. Ich wollte noch den Typ der Partition anzeigen (ext2/ext3), hatte aber bis jetzt auch nicht gemacht. Vermutlich wird die Ermittlung vom Partitiontyp auch etwas an Resourcen fressen und Darstellung verlangsamen.
Ansonsten einfach testen und wenn keine Einwände entstehen, dann bitte einchecken.
MfG
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
@cuma: Im Posting 1 gibt es doch schon ein Screenshoot. Da kann man mehr oder weniger fast alles erkennen. Oder willst es noch in Grau haben? Zum Grau muss ich sagen, dass ich es doch nicht 100% farbig getroffen hatte, wie es in diesem Patch realisiert war. Da hat man auch die borders fürs Grau eingeführt. Bei meinen div-s hat es leider nicht so richtig hingehauen, deswegen hatte ich bei grau die borders rausgenommen.
Wer war eigentlich der Author von dem "grauen Patch"? Ich hoffe, ich trette ihm nicht zu nah in dem ich diesen Patch da wegoptimiert hatte und die Ideen und einige Realisierungen von dort abgeschaut hatte.
Übrigens, dieses stat_bar()-Unterprogramm hatte ich versucht möglichst universell zu gestalten. Es ist also theoretisch möglich Balken mit sehr vielen Bereichen darzustellen. Man muss lediglich dazu stylesheet-Formate erweitern. Ich ziele dabei immer noch auf die Gesamtdarstellung des gesamten Flash-Inhaltes der Box in so einem Balken. So ähnlich, wie dass die Parttionsprogramme machen. Aber bis ich es halbwegs sicher hinkriege, wird es noch eine Weile dauern. AVM ändert ständig vieles an ihren mtd-Bereichen, sodass man eine große Fallunterscheidung je nach Boxtyp braucht.
Ansonsten würde mich hier interessieren, wie sich z.B. die alternativen Mountpoints (jffs, nfs, davfs) verhalten. Wird alles richtig angezeigt? Dauert es dadurch irrelange? Lassen sich die Sachen re-/unmounten? Wie ist es eigentlich mit USB-ROOT? Kriegt man da die Partition überhaupt zu sehen? Kann man sie remounten?
MfG
Wer war eigentlich der Author von dem "grauen Patch"? Ich hoffe, ich trette ihm nicht zu nah in dem ich diesen Patch da wegoptimiert hatte und die Ideen und einige Realisierungen von dort abgeschaut hatte.
Übrigens, dieses stat_bar()-Unterprogramm hatte ich versucht möglichst universell zu gestalten. Es ist also theoretisch möglich Balken mit sehr vielen Bereichen darzustellen. Man muss lediglich dazu stylesheet-Formate erweitern. Ich ziele dabei immer noch auf die Gesamtdarstellung des gesamten Flash-Inhaltes der Box in so einem Balken. So ähnlich, wie dass die Parttionsprogramme machen. Aber bis ich es halbwegs sicher hinkriege, wird es noch eine Weile dauern. AVM ändert ständig vieles an ihren mtd-Bereichen, sodass man eine große Fallunterscheidung je nach Boxtyp braucht.
Ansonsten würde mich hier interessieren, wie sich z.B. die alternativen Mountpoints (jffs, nfs, davfs) verhalten. Wird alles richtig angezeigt? Dauert es dadurch irrelange? Lassen sich die Sachen re-/unmounten? Wie ist es eigentlich mit USB-ROOT? Kriegt man da die Partition überhaupt zu sehen? Kann man sie remounten?
MfG
Neueste Beiträge
-
FRITZ!Box 7590 - INHAUS - Smart24P1 - 7.90 - Sammelthema- Letzte: Jstessi
-
Glasfaser Fritzbox mit internen S0/ISDN ausser FB 5491?
- Letzte: agfeofan
-
-
FRITZ!Box 7590 - Labor 7.90 - Sammelthema- Letzte: Grisu_
-
[Frage] wieder mal TAPI Problem
- Letzte: strzata3
-
[Sammlung] FRITZ!Box 4050, 5690 Pro und 7690
- Letzte: BeeHaa