Architektur FRITZ!Box (speziell 7490) und von Fritz!OS sowie Freetz und die Möglichkeiten eines Mods

[gneiss]

Hallo,

ich lese hier schon länger mit, habe aber bisher noch nichts geschrieben. Jetzt bin ich allerdings total verwirrt.
Zum Hintergrund:
Bisher war ich mit der AvM Fw der Fritz!Box eigentlich recht zufrieden.
Das was ich brauche war vorhanden und funktionierte.

Im wesentlichen sind das:
- ftp-Zugang via I-Net
- mount cifs im Heimnetz
auf ein an die Box angeschlossenes Speichermedium.
So kann ich "bequem" Daten sowohl von unterwegs als auch zu Hause bearbeiten.
Bin ich unterwegs synchronisiere ich (via lftp command mirror) die Daten mit einer lokalen Kopie, zu Hause arbeite ich direkt auf dem mount.

Seit ich jedoch auf die neue Version 7.21 upgedatet habe funktioniert weder der ftp- noch der cifs-Zugang korrekt.
Dateien die ich via ftp hochgeladen habe "gehören" mir nicht und ich kann sie dann zwar löschen aber nicht ändern !?!
Seltsamerweise funktioniert es mit filezilla, wohl weil filezilla andere Kommandos nutzt (SITE..).
Ähnlich verhält es sich mit den gemounteten Dateien.
Irgendwie ist das ganze "mapping" von user, group und mod durcheinander.
Auf meinen Haupt-PC zu Hause habe ich sowohl ftp als auch samba installiert und dort funktioniert alles so wie ich es gewohnt bin.
Ich arbeite grundsätzlich mit linux und Samba mit smb3 versteht posix , so das dort alle Dateieigenschaften 1:1 durchgereicht werden (und nichts "gemappt" werden muss).

OK, dachte ich, dann kommt jetzt doch freetz auf die Box.
Dort gibt es ja mit vsftd & samba eine "vernünftige" Implementation.

Erst einmal muss ich dann leider feststellen (wie auch schon andere hier), dass das Projekt Freetz leider sehr sehr unübersichtlich geworden ist.
Wegen einem Forenbeitrag hier (war irgendwas mit freetz wenig aktivität, freetz-ng sehr aktiv) habe ich mir dann ein passendes image mit freetz-ng erstellt und auf die Box geladen.
Ob es sinnvoller gewesen wäre ein "original" freetz zu nehmen lasse ich mal so stehen, Tatsache ist jedoch das die links & Beschreibung dorthin zur Zeit mehr oder weniger "irreführend" sind.
Egal: Ich komme prinzipiell mit freetz-ng klar, was mit nicht gefällt kann ich (später) immer noch selber anpassen (oder halt als Bug melden, 2 habe ich ja schon gemeldet ;-)

Ich hatte dann auch das ganze mal so weit das ich sowohl via ftp als auch cifs auf die Box zugreifen konnte. Da ich die Konfiguration aber "nach linux-standard" gemacht hatte (und noch nicht wusste das man Veränderungen mit modsave speichern muss) war alles nach einem reboot wieder weg und ich bekomme immer ein "permission denied" beim Zugriff. Irgend etwas ist wohl "durcheinander" geraten. Alle Versuche wieder den Zustand vor dem reboot hin zu bekommen sind gescheitert. Das hat wohl etwas mit dem IMHO verkorksten User-Management der Box zu tun.

Daher die 1. Frage (auf die ich auch nach intensiver suche hier keine Antwort gefunden habe):
Wie stelle ich die "Werkseinstellung" auch (und gerade auch) für alle Einstellung des "mods" her ?
Soweit ich bisher informiert bin löscht ein "Werksreset" via AvM WebIF diese Einstellungen ja nicht. Wenn es denn aber (auch) notwendig ist stellt das auch kein Problem dar.
Dazu unten mehr...

Das User-Management der AvM Fw habe ich nicht wirklich verstanden, daher meine 2. Frage:
Was hat es mit den "boxusr<xx>" usw. auf sich ?
Liegt der Fehler möglicherweise daran das ich einen (echten) linux user mit gleichem Namen & pw angelegt habe wie er auch über das WebIF angelegt wurde ?
Hintergrund, damit das mit den Dateirechten über mehrere Rechner sauber funktioniert lege ich auf den beteiligten Rechnern überall den gleichen user (mit gleichen UID & GID) an. So gibt es keinerlei Problem beim Dateiaustauch.

Die 3. Frage die ich stelle ist:
Warum ist die Konfiguration (speziell der beiden Pakete vsftpd & samba) so "verkompliziert" worden ?
Speziell liegen Konfigurations-Dateien "irgendwo" anders als es bei einer normalen Installation der Fall ist.
Für meine Zwecke benötige ich nur einen share auf den mehrere user (mit gleicher gruppe) Zugriff haben.
Damit kann ich dann z.B. sehen von welchem user aus die letzten Änderungen durchgeführt wurden.

Meine 4. Frage:
Gibt es eine Möglichkeit ein aktuelles samba (mit smb3) auf die Box zu bekommen ?


Hier mein derzeitige Kenntnisstand (bitte korrigiert mich wo ich falsch liege):
Klar, das es sich bei dem system-root (/) der Box um ein RAM handelt müssen persistente (NVF, non volatile files) Daten irgendwie gesichert werden.
Soweit ich das jetzt verstanden habe werden diese NVF (vor einem reboot, bzw. durch modsave) zunächst in die Datei "/var.tar" gesichert.
Dann wird diese Datei ins flash kopiert. Beim booten passiert das ganze dann umgekehrt.
Um das ganze "einfach" zu halten liegen alle NVF daher unter /var/flash.
... und die NVF von freetz unter /var/flash/freetz ?

Soweit kann ich das alles nachvollziehen.

Warum man aber die sourcen patched damit das Paket seine Dateien auch dort ablegt/benutzt ist mir nicht klar.
Ich hätte erwartet das man (z.B. für samba) einfach einen link anlegt der /etc/samba auf /var/flash/etc/samba umlenkt.
Klar dann müssen nach dem auspacken der var.tar immer die links wieder neu angelegt werden, aber dafür sind doch die entspr. rc.<pkg> da.
Diese Vorgehensweise würde einige patches (und damit die Abhängigkeit von speziellen Versionen) überflüssig machen.

Anmerkungen zu meiner 1. Frage:
Wenn meine Annahmen richtig sind müsste:
- Ein Komplet-Reset (Freetz + AvM-Konfig) der Box durch:
Speichern einer frische Kopie der var.tar (wie im image enthalten) ins flash und einem anschließenden Reset am "Sichern der Einstellungen vorbei" (einfach Stecker ziehen ?) machbar sein ???
- Ein Reset nur der freetz Konfiguration (wenn meine obige Annahme das diese alle unter /var/flash/freetz liegen richtig ist) durch:
Löschen von /var/flash/freetz + modsave + reboot möglich sein ??

 

[PeterPawn]

Wenn meine Annahmen richtig sind

Sind sie nicht ... die Wurzel des Dateisystems bei AVM ist ein SquashFS-Image, wobei bei VR9-Geräten (wo die 7490 dazugehört) als allererstes tatsächlich eine (auch nur "read-only" gemountete) Flash-Partition mit YAFFS2-Format verwendet wird und das erwähnte SquashFS-Image erst per pivot_root gegen die YAFFS2-Partition ausgetauscht wird. Dabei landet dann die vorherige Root-Partition unterhalb des Verzeichnisses wrapper - die Inhalte kann man sich bei Freetz ja in einer Shell-Session ansehen - und das "wirkliche" Root-Dateisystem ist in der dort liegenden filesystem_core.squashfs enthalten.

Damit gibt es schon mal (spätestens nach dem pivot_root, was man dann in der /etc/inittab in der YAFFS2-Partition "nachlesen" kann) per se gar keine Stelle im Root-Dateisystem, die man irgendwie beschreiben könnte ... daher wird unterhalb von /var eine (unlimitierte) tmpfs-Instanz gemountet (der "übliche" Pfad /tmp im SquashFS-Image ist ein Symlink nach /var/tmp) und anstatt den (benötigten) Inhalt dieses tmpfs-Dateisystems jetzt mit einzelnen Kommandos Schritt für Schritt zu erstellen (offenkundig braucht es ja zumindest ein Unterverzeichnis tmp dort, damit der Symlink /tmp nicht ins Leere läuft), wurde der zuvor (einmalig) erzeugt und im TAR-File /var.tar im Root-Verzeichnis der filesystem_core.squashfs gespeichert. Diese Datei wird dann einfach entpackt (relativ zu /) und damit ist der Anfangszustand der Dateien im beschreibbaren Teil des Dateisystems auch schon hergestellt.

Spätestens aus dieser Beschreibung kann/sollte man jetzt aber auch erkennen, daß ebendiese /var.tar gar nicht dazu dienen KANN, da irgendwelche Einstellungen zu speichern - sie liegt ja im (unveränderlichen) SquashFS-Image (zumindest ist es so lange unveränderlich, wie man es nicht auf der Box komplett neu erstellen läßt) und das ist per Definition auch "read-only".

Wie also speichert AVM denn dann die Einstellungen? In grauer Vorzeit hat AVM mal ein Format für diese Einstellungen entwickelt, was einerseits den damals verwendeten NOR-Flash nicht ständig neu beschreiben sollte (jeder Löschvorgang dort verringert die "Restlaufzeit") und andererseits aber auch etwas wie Transaktionssicherheit bieten sollte, damit eine Unterbrechung zu einem Zeitpunkt, wo der Flash-Speicher gerade gelöscht war (ein Schreibvorgang dort erfordert ja zuvor ein Löschen aller alten Inhalte in einer "erase line"), das Gerät nicht in einem unbrauchbaren/undefinierten Zustand zurück ließ. Mit ein paar zusätzlichen Kniffen wurden dann auch noch die notwendigen Lösch-Vorgänge verringert, indem der Treiber für dieses Dateisystem in der Lage war, die Daten im Flash "fortzuschreiben".

Wie genau das ging, ist zwar nicht wirklich wichtig, aber doch "erzählenswert": Beim Löschen werden bei Flash-Speicher alle Zellen/Bits auf "1" gesetzt und beim Schreiben werden an den Stellen, wo eine "0" gebraucht wird, gezielt "Löcher" erzeugt - das kann man zum "Fortschreiben" ausnutzen (auch wenn man eine komplette "page" schreibt), indem man die noch nicht genutzten Bereiche hinter den eigentlichen Daten auf "1" läßt, also bis zum Ende mit 0xFF auffüllt. Dann kann man bei der nächsten Schreiboperation den bisher geschriebenen Inhalt einfach am Ende um die neuen Daten ergänzen und noch einmal schreiben lassen - das erfordert keinen Löschvorgang und verringert die Endurance des Flash-Speichers nicht.

Damit ist dann zwar das Ziel der Minimierung von Löschvorgängen schon mal erreicht und die Zeit, in der der Flash tatsächlich "gelöscht" da steht, ebenso verringert - aber auch das ist noch nicht wirklich "transaktionssicher". Und so ging man hin und nahm einfach zwei Flash-Partitionen, die man jeweils abwechselnd beschreibt - aber erst dann, wenn es erforderlich ist und der Füllstand der einen Partition einen Schwellwert überschreitet ... bis dahin wird die erste Partition eben "fortgeschrieben" und da das kein Löschen erfordert, gibt es auch bei einer Unterbrechung der Stromversorgung o.ä. nur ein extrem kleines Fenster, wo tatsächlich mal ungültige Daten in einer solchen Partition stehen können (wenn der Schreibvorgang zwar gestartet wurde, aber nicht bis zum Ende kam). Ist jetzt die erste Partition beim max. vorgesehenen Füllstand angekommen, werden die Daten in diesem Dateisystem "verdichtet" (dabei werden alte Einstellungen, die beim Fortschreiben durch neuere ersetzt wurden, entfernt) und das komprimierte Image landet dann - zusammen mit einem passenden Zähler, der es als die neuere Version ausweist - in der anderen Flash-Partition, die dann ihrerseits so lange fortgeschrieben wird, wie es möglich oder erwünscht ist.

Ach so ... dieses Dateisystem-Format nennt AVM dann "AVM (T)iny (F)lash (F)ile (S)ystem" oder auch kurz: TFFS - und die FRITZ!Box-Modelle, bei denen die Einstellungen in NOR- oder SPI-Flash gespeichert werden (bei NAND-Flash hat AVM das Format und das Vorgehen dann später geändert - aber die VR9-Boxen (auch die 7490) arbeiten noch mit SPI-Flash für die Einstellungen), die haben dann jeweils auch zwei Flash-Partitionen dafür:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00400000 00020000 "kernel"
mtd1: 03000000 00020000 "filesystem"
mtd2: 00400000 00020000 "reserved-kernel"
mtd3: 03000000 00020000 "reserved-filesystem"
mtd4: 00200000 00020000 "config"
mtd5: 19600000 00020000 "nand-filesystem"
mtd6: 00040000 00001000 "urlader"
mtd7: 00060000 00001000 "tffs (1)"
mtd8: 00060000 00001000 "tffs (2)"
#

Ins Linux eingebunden wird das dann alles über den TFFS-Treiber von AVM, der dieses TFFS in einzelne "streams" aufteilt und den Zugriff auf diese Streams über "character devices" bereitstellt. Die einzelnen Einstellungsdateien von AVM (die man auch in den Export-Dateien sehen kann) sind dabei jeweils ein solcher "stream" und sie werden zur weiteren Steigerung der Effizienz beim Schreiben "on the fly" komprimiert (mit zlib-Kompression) und beim Lesen wieder dekomprimiert. Das hat dann zur Folge, daß für jede dieser Einstellungsdateien ein passender Node für ein solches "character device" benötigt wird, wobei die Major-Number natürlich die des TFFS-Treibers ist (die wechselt auch von Modell zu Modell und muß üblicherweise aus der /proc/devices ermittelt werden) und für jede der Dateien von AVM eine entsprechende Minor-Number zugeordnet wurde. Diese Zuordnung habe ich mal niedergeschrieben: https://github.com/PeterPawn/YourFritz/blob/master/tffs/data/tffs.files - bei AVM findet man sie aber auch an ein paar Stellen (in den Init-Dateien und natürlich in den Quelltext-Paketen für die OpenSource-Komponenten).

Die Nodes für die TFFS-Streams werden jetzt tatsächlich nach jedem Systemstart neu angelegt - auch das muß natürlich an einer Stelle im Dateisystem geschehen, die beschreibbar ist. Und so gibt es im FRITZ!OS unterhalb von /var dann eben das Verzeichnis /var/flash ... das kann entweder auch "nur" im tmpfs unterhalb von /var liegen oder dort ist (nicht bei allen Modellen) eine weitere Partition (üblicherweise die mit dem Namen "config") gemountet - die enthält aber eben nicht selbst die Einstellungen (also die Konfiguration), sondern tatsächlich nur die "character device"-Nodes für die TFFS-Streams:

# ls -l /var/flash
crw-r--r--    1 root     root      243, 225 Jan  1  1970 aha.cfg
crw-r--r--    1 root     root      243, 228 Jan  1  1970 ahadect.cfg
crw-r--r--    1 root     root      243, 230 Jan  1  1970 ahaglobal.cfg
crw-r--r--    1 root     root      243, 227 Jan  1  1970 ahalua.cfg
crw-r--r--    1 root     root      243, 229 Jan  1  1970 ahanet.cfg
crw-r--r--    1 root     root      243, 231 Jan  1  1970 ahapushmail.cfg
crw-r--r--    1 root     root      243, 226 Jan  1  1970 ahausr.cfg
crw-r--r--    1 root     root      243, 113 Jan  1  1970 ar7.cfg
crw-r--r--    1 root     root      243, 240 Jan  1  1970 asec
crw-r--r--    1 root     root      243, 160 Jan  1  1970 aura-usb
crw-r--r--    1 root     root      243, 205 Jan  1  1970 avmnexus.cfg
crw-r--r--    1 root     root      243, 168 Jan  1  1970 browser-data
crw-r--r--    1 root     root      243, 141 Jan  1  1970 calllog
crw-r--r--    1 root     root      243, 208 Jan  1  1970 cert.cfg
crw-r--r--    1 root     root      243, 161 Jan  1  1970 configd
crw-r--r--    1 root     root      243, 177 Jan  1  1970 dect_eeprom
crw-r--r--    1 root     root      243, 176 Jan  1  1970 dect_misc
crw-r--r--    1 root     root      243, 178 Jan  1  1970 dmgr_handset_user
crw-r--r--    1 root     root      243, 162 Jan  1  1970 ewnwstatus.cfg
crw-r--r--    1 root     root      243, 215 Jan  1  1970 featovl.cfg
crw-r--r--    1 root     root      243, 143 Jan  1  1970 fonctrl
crw-r--r--    1 root     root      243, 163 Jan  1  1970 fwupdatetrace.cfg
crw-r--r--    1 root     root      243, 132 Jan  1  1970 fx_cg
crw-r--r--    1 root     root      243, 129 Jan  1  1970 fx_conf
crw-r--r--    1 root     root      243,  99 Apr 19  2020 fx_def
crw-r--r--    1 root     root      243, 130 Jan  1  1970 fx_lcr
crw-r--r--    1 root     root      243, 131 Jan  1  1970 fx_moh
crw-r--r--    1 root     root      243, 241 Jan  1  1970 import_asec.tmp
crw-r--r--    1 root     root      243, 204 Jan  1  1970 letsencrypt_cert.pem
crw-r--r--    1 root     root      243, 203 Jan  1  1970 letsencrypt_key.pem
drwx------    1 root     root          2048 Jan  1  1970 lost+found
crw-r--r--    1 root     root      243, 212 Jan  1  1970 maild.xml
crw-r--r--    1 root     root      243, 206 Jan  1  1970 meshd.cfg
crw-r--r--    1 root     root      243, 218 Jan  1  1970 modulemem
crw-r--r--    1 root     root      243, 112 Jan  1  1970 multid.leases
crw-r--r--    1 root     root      243, 117 Jan  1  1970 net.update
crw-r--r--    1 root     root      243, 142 Jan  1  1970 phonebook
drwxr-xr-x    1 root     root          2048 Dec 23 22:47 provider_default
crw-r--r--    1 root     root      243,  29 Apr 19  2020 provideradditive.tar
crw-r--r--    1 root     root      243, 116 Jan  1  1970 stat.cfg
crw-r--r--    1 root     root      243, 145 Jan  1  1970 tamconf
crw-r--r--    1 root     root      243, 133 Jan  1  1970 telefon_misc
crw-r--r--    1 root     root      243, 213 Jan  1  1970 timeprofile.cfg
crw-r--r--    1 root     root      243, 119 Jan  1  1970 tr069.cfg
crw-r--r--    1 root     root      243, 146 Jan  1  1970 tr369.cfg
crw-r--r--    1 root     root      243, 211 Jan  1  1970 umts.cfg
crw-r--r--    1 root     root      243, 209 Jan  1  1970 usb.cfg
crw-r--r--    1 root     root      243, 216 Jan  1  1970 usbgsm.cfg
crw-r--r--    1 root     root      243, 120 Jan  1  1970 user.cfg
crw-r--r--    1 root     root      243, 121 Jan  1  1970 userstat.cfg
crw-r--r--    1 root     root      243, 114 Jan  1  1970 voip.cfg
crw-r--r--    1 root     root      243, 122 Jan  1  1970 voipd_call_stat
crw-r--r--    1 root     root      243, 118 Jan  1  1970 vpn.cfg
crw-r--r--    1 root     root      243, 202 Jan  1  1970 websrv_ssl_cert.pem
crw-r--r--    1 root     root      243, 201 Jan  1  1970 websrv_ssl_key.pem
crw-r--r--    1 root     root      243, 115 Jan  1  1970 wlan.cfg
crw-r--r--    1 root     root      243, 210 Jan  1  1970 xdslmode
#

Der besondere Aufbau dieser Einstellungen erfordert auch besondere Vorkehrungen beim Zugriff auf diese Einstellungen ... der TFFS-Treiber implementiert nämlich für die Streams nur die rudimentären I/O-Operationen und daher kann man dort tatsächlich nur Zeichen für Zeichen lesen und schreiben und weder die Größe der im Stream gespeicherten Daten ermitteln (ohne sie dafür Byte für Byte zu lesen), noch sich irgendwie an das "Ende" eines solchen Streams positionieren, um da vorhandene Daten anfügen zu können - das heißt auch, daß man so einen Stream immer komplett neu schreiben muß, wenn man darin etwas ändern oder etwas an ihn anhängen will. Außerdem begrenzen die im TFFS verwendeten Datenstrukturen die Größe eines komprimierten Streams auf 32 KByte - Daten, die nach dem Komprimieren immer noch größer wären, kann das TFFS nicht speichern.

Für das TFFS hat sich jetzt AVM auch noch etwas anderes einfallen lassen ... es kann sowohl Einstellungen speichern, die beim Zurücksetzen auf die Werkseinstellungen gelöscht werden, als auch solche, die dieses Zurücksetzen überdauern sollen - dazu wurde bei der Minor-ID 100 eine "magische Grenze" eingezogen und alles jenseits dieser Minor-ID wird gelöscht, während alles darunter das Zurücksetzen schadlos übersteht. Wobei das nur für das Zurücksetzen aus dem laufenden FRITZ!OS heraus gilt ... verwendet man das Recovery-Programm von AVM, schreibt dieses ein komplettes neues TFFS-Image in die beiden TFFS-Partitionen und dabei gehen dann auch die Streams mit Minor-ID < 100 verloren.

Und damit kommen wir jetzt zu Freetz (was auch für Freetz-NG gilt, obwohl es dort wohl erste Versuche gibt, das abzuändern (insb. wohl wg. des 32 KB-Limits) - wie weit die gediehen sind, ist schwer einzuschätzen, weil es auch schwer nachzulesen/zu finden ist) ... denn Freetz geht jetzt hin und definiert für alle installierten Pakete "Standardeinstellungen", die ebenfalls im SquashFS-Image abgelegt und damit erst einmal unveränderlich sind. Aus diesen Standardeinstellungen werden jetzt die Einstellungen für die Freetz-Pakete unter /mod (was auch wieder ein Symlink nach /var/mod ist) beim Start generiert und wenn der Benutzer etwas an diesen Einstellungen ändert, werden diese Änderungen an den dort liegenden Daten vorgenommen (die sind ja wieder "schreibbar").

Die Verwaltung der Einstellungen für ein solches Paket erfolgt dann mittels modconf (https://github.com/Freetz/freetz/blob/master/make/mod/files/root/usr/bin/modconf) - das ist dann dafür zuständig, die Standardeinstellungen und die vom Benutzer vorgenommenen Änderungen beim Start zu Mischen und beim Speichern auseinander zu pflücken, damit beim Speichern der Freetz-Einstellungen tatsächlich auch nur die geänderten Werte berücksichtigt werden müssen - das reduziert (bei intelligent gewählten Standardeinstellungen) in den meisten Fällen die Größe der Einstellungsdatei von Freetz. Denn diese ist letztlich nichts anderes als ein TAR-Archiv all der Änderungen der Standardwerte, das dann im TFFS-Stream mit der Minor-ID 60 gespeichert wird ... und damit (wer vorher aufgepaßt hat, weiß das jetzt aus dem Stand) auch das Zurücksetzen der AVM-Einstellungen beim "Factory-Reset" überlebt, aber genauso vom 32 KB-Limit für die komprimierten Daten betroffen ist und das kann schnell erreicht sein, wenn da große RSA-Schlüssel (4096 Bit) oder entsprechende Zertifikate u.ä. gespeichert werden müssen.

Damit das System jetzt aber weiß, wann es Änderungen an den Einstellungen eines Pakets gab, die der Speicherung bedürfen, sollte man solche Änderungen entweder über das GUI vornehmen (das kümmert sich dann schon um die persistente Speicherung) oder - wenn man sie von Hand in der Shell vornehmen möchte - dafür auf das schon erwähnte modconf zurückgreifen (spätestens zum Speichern).

Es ist eben beim FRITZ!OS lange nicht alles "wie üblich" in anderen Geräten aus dieser Liga (von anderen Herstellern) und man sollte seine Annahmen (die meist ja darauf beruhen, wie man das von anderen Geräten kennt) hier immer noch einmal auf den Prüfstand stellen - wobei man einiges von dem, was ich oben zusammengeschrieben habe, auch schon selbst hätte finden können in den Freetz-Dokumentationen: https://freetz.github.io/wiki/help/howtos/development.html

EDIT: Ach so ... ich habe jetzt auf:

Wie stelle ich die "Werkseinstellung" auch (und gerade auch) für alle Einstellung des "mods" her ?

nicht explizit geantwortet ... aber mit dem Wissen von oben sollte man ja erkennen können, daß es zum Löschen der Freetz-Einstellungen nur das Löschen des Inhalts der Minor-ID 60 im TFFS braucht - dazu gibt es dann ein "Kommando" mit dem Namen clear_id, das man an den procfs-Node senden kann, der vom TFFS-Treiber bereitgestellt wird (unter /proc/tffs). Das nimmt als Parameter noch die (dezimale) Minor-ID des zu löschenden Streams ... ein echo clear_id 60 > /proc/tffs sendet also alle gespeicherten Freetz-Einstellungen dahin, wo Winnetou wohl schon lange wartet. Wobei man dann auch noch aufpassen sollte, daß nicht irgendein erneutes Speichern diese Einstellungen gleich wiederherstellt - denn die liegen natürlich weiterhin unter /mod/flash und würden beim nächsten Speichern erneut zusammengepackt und in den TFFS-Node geschrieben werden.

Die Benutzerverwaltung von AVM (zu der sowohl die Accounts in der ar7.cfg zählen als auch die "normalen" Linux-Accounts in der /etc/passwd (bzw. /etc/shadow - ich bin gerade nicht sicher, ob Freetz da trennt), die vom (AVM-)FTP und vermutlich auch für Samba verwendet werden - wobei das beim nqcs alles nicht wirklich untersucht ist m.W.) ist dann wieder ein anderes Thema ... Du solltest erst mal das hier verdaut haben, bevor Du Dich damit dann befaßt. Normalerweise bietet Dir auch das Paket für den vsftpd ein passendes GUI an: https://github.com/Freetz/freetz/blob/master/make/vsftpd/files/root/usr/lib/cgi-bin/vsftpd.cgi und wenn das nicht Deinen Vorstellungen/Anforderungen entspricht, solltest Du zuerst einmal (richtig) verstehen, wie das dort funktioniert, bevor Du Dich von Hand an die Konfiguration machst oder Dir gar das GUI nach Deinen Wünschen anpaßt. Auch die Einrichtung des vsftpd-Pakets ist bei Freetz bereits dokumentiert - inkl. der Frage, wann da wie welche Benutzer einzurichten wären: https://freetz.github.io/wiki/packages/vsftpd.html (oder analog irgendwo auch bei Freetz-NG).

 

[gneiss]

Hallo Peter,

erst einmal sehr sehr herzlichen Dank für die ausführlichen Erklärungen.

Ich hatte mir zwar schon einige der von Dir zitierten/verlinkten Artikel angesehen, aber ohne den Überblick den Du oben gegeben hast sind die einzelnen Schritte eben für mich leider nicht verständlich gewesen.
Ganz wichtig (für mein Verständnis) waren Deine Aussagen was beim booten passiert (wo und wie die SquashFS/YAFFS2 Partitionen/fs gemountet werden und wo man die im laufenden Betrieb wiederfindet).

Spätestens aus dieser Beschreibung .. /var.tar gar nicht dazu dienen KANN ...

Klar hier habe ich wohl einiges durcheinander gebracht.
Ich hatte mir schon modsave angeschaut, dort ist es aber das FLASHFILE (/var/flash/freetz), das auf dem von dir beschriebenen Weg geschrieben wird. Das es sich dabei um ein "Node im TFFS" handelte hatte ich da aber noch nicht gewusst.
Auch die (diversen) Beschreibungen zum TFFS hatte ich schon gelesen, war aber (warum auch immer) der Meinung, dass das in der 7490 gar nicht mehr (für das speichern der Einstellungen) verwendet wird, da es dort ja das (verhältnismäßig riesige) MTD "config" gibt. Hier hatte ich wohl etwas falsch verstanden :-(
Irgendwo hatte ich auch mal das script "flash_update" angesehen um eben den Vorgang wie Du Ihn jetzt so schön beschrieben hast irgenwie zu verstehen. Daher kommt wohl meine "Verwechselung" mit /var.tar".
(So etwas ähnliches wie das TFFS habe ich selber schon mal für einen Zähler im Flash eingesetzt um dort mit wenigen ERASE-Zyklen einen hohen Zählerstand realisieren zu können)
Aber damit wird auch klar warum es nicht so leicht ist die Konfig-Dateien dort zu belassen wo sie normalerweise liegen. Die "Umlenk-Links" müssten ansonsten ja schon im squashfs angelegt werden.
Obwohl das durchaus eine Mögliche Alternative zum patchen der sourcen wäre!

Die Nodes für die TFFS-Streams werden jetzt tatsächlich nach jedem Systemstart neu angelegt

OK, soweit verstanden /var/flash enthält also (zunächst/ohne mod) die persistenten Dateien für das Fritz!OS.
Bzw. die Character-Devices zu den entsprechenden TFFS-Streams und damit den eigentlichen persistenten Teil. Ob es jetzt dazu noch (je) eine Datei im im RAM gibt die laufenden Betrieb verwendet wird und nur vor einem Reboot hierhin gesichert wird ist mir noch nicht klar. Ohne eine solche "Kopie" müssen hat alle Programme die darauf zugreifen auch mit Character-Devices umgehen können.

Und damit kommen wir jetzt zu Freetz (was auch für Freetz-NG gilt...

Tja, ich hatte ja schon geschrieben das ich mir das dort verwendete modsave angeschaut habe....
Da wird der Inhalt von /tmp/flash in ein tar gepackt, was dann in den TFFS (/var/flash/freetz) geschrieben wird. Wobei vor dem schreiben noch geprüft wird ob es überhaupt eine Veränderung gibt (um Schreibzugriffe zu minimieren).
... und hier hatte ich wohl nicht aufgepasst ...
Damit liegen dann ja wohl die Kopien der persistenten Dateien von freetz-ng alle in /tmp/flash, die persistenten Dateien im TFFS /var/flash/freetz.
-> Womit dann ein rm -r /tmp/flash/* + modsave alles zurückstellen würde..
Ich hoffe DAS ist jetzt korrekt und eine Alternative zu dem direkten löschen des Nodes.

Die Nodes für die TFFS-Streams ... das kann entweder auch "nur" im tmpfs unterhalb von /var liegen oder dort ist (nicht bei allen Modellen) eine weitere Partition (üblicherweise die mit dem Namen "config") gemountet - die enthält aber eben nicht selbst die Einstellungen (also die Konfiguration), sondern tatsächlich nur die "character device"-Nodes für die TFFS-Streams:

Das habe ich jetzt (immer noch nicht) verstanden :-(
In der 7490 gibt es doch:
mtd7/8 tffs
mtd4 config
Das sind doch separate Flash-Partitionen, oder ?
Soll das heißen, das bei der 7490 (die ja das "config" mtd hat) dort eben auch ein TFFS "über das mtd4 Flash gelegt wurde" und die character devices in /var/flash dann eben in dieses TFFS zeigen, statt in eines was über die mtd7/8 gelegt wurde ? (da fehlt mir dann aber die 2. mtd, kann also eigentlich nicht sein)
Hier fehlt mir wohl noch etwas für das Verständnis!

Die Verwaltung der Einstellungen für ein solches Paket erfolgt dann mittels modconf

Davon höre ich jetzt zum ersten mal, bisher war mir nur modsave bekannt. Aber jetzt macht auch (z.B.) die Datei avm.diff in /tmp/flash sinn. Das ist genau so eine Datei die (via modconf) nur die Unterschiede enthält, dann via modsave gespeichert wird. In der Hilfe von (z.B.) vsftp wird nur erwähnt, das nach Änderungen modsave aufzurufen ist.
Wobei (ich habe mal kurz in den Link geschaut) die Benutzung dieses Scripts (welches command macht was, was ist der unterschied load/save & merge/diff) leider auch nicht selbsterklärend ist.
Bei den ganzen "toten" links hier sucht man sich danach wohl wieder 'nen Wolf.

Es ist eben beim FRITZ!OS lange nicht alles "wie üblich" in anderen Geräten ...

Tja, da ich bisher noch nie ein ähnliches Gerät "bearbeitet" habe ist halt alles für mich neu. Allerdings habe ich einige Erfahrung mit Linux (allerdings weniger mit embedded). Und Anscheinend sind die Unterschiede größer als erwartet. Auf der anderen Seite programmiere ich beruflich µPs "bare Metal" und kenne schon die speziellen Probleme auf Systemen ohne "Standard" Speicher.

... wobei man einiges von dem, was ich oben zusammengeschrieben habe, auch schon selbst hätte finden können in den Freetz-Dokumentationen

Da ist leider sehr viel "Tobak" auf einmal. Einiges davon habe ich schon gelesen, vieles aber noch nicht wirklich verstanden.
Mit den Erläuterungen hier werde ich einiges noch mal durchlesen und dann hoffentlich mehr verstehen.

Die Benutzerverwaltung von AVM ... ich bin gerade nicht sicher, ob Freetz da trennt...

Die modusers habe ich mir schon angeschaut, hier werden alle 4 Dateien 1:1 gespeichert, Beim auslesen werden jedoch die speziellen users "grep -vE '^(app|boxusr|ftpuser)[0-9]* ..." ausgefiltert.
Die sind auch bei mir nach einem reboot wieder so wie ich sie eingestellt habe.

wobei das beim nqcs

Du meinst Boxmatrix ?
Ich habe explizit samba ausgewählt, dessen Konfiguration (auf desktop-linux) kenne ich ja gut genug.

Normalerweise bietet Dir auch das Paket für den vsftpd ein passendes GUI

Das nicht (richtig) funktioniert :-(
Die von mir gewünschte Konfiguration ist damit schlicht nicht möglich.
Die default Konfiguration wird immer den User-Einstellungen vorangestellt und lässt sich dort auch nicht Ändern :-(
Das ist auch der Punkt den ich bei anderen Mods "bemängele". Statt eine Eingabemöglichkeit für die Config zur Verfügung zu stellen werden nur einzelne Parts "editierbar" angeboten..
Mit Deinen Schilderungen kann ich jetzt zwar erahnen was die Motivation war, macht das ganze aber nicht eben leichter wenn man etwas anderes will.

wenn das nicht Deinen Vorstellungen/Anforderungen entspricht, solltest Du zuerst einmal (richtig) verstehen, wie das dort funktioniert, bevor Du Dich von Hand an die Konfiguration machst

Na, ja selbst mit dem gui sind Anpassungen "von Hand notwendig" (wie auch in dem von Dir verlinkten Artikel beschrieben). Das man da ohne viel Hintergrundwissen Fehler macht ist eigentlich vorprogrammiert.
Eben selbst wenn man so eine Config hat, wie Sie auf einem Desktop-Linux funktioniert, ist es nicht gerade leicht wo welche Abwandlung notwendig ist.

Auch die Einrichtung des vsftpd-Pakets ist bei Freetz bereits dokumentiert - inkl. der Frage, wann da wie welche Benutzer einzurichten wären:

Da wird nur ein Spezialfall (Zugriff aus je ein Home-Verzeichnis + ein Share) beschrieben.
... und genau das habe ich nachvollzogen ... um eine Start-Basis zu haben..
Ergebnis: permission denied für alle angelegten user :-((

Fazit:
Meine obigen Fragen sind damit weitgehend beantwortet. Offen sind noch:

Das User-Management der AvM Fw habe ich nicht wirklich verstanden, daher meine 2. Frage:
Was hat es mit den "boxusr<xx>" usw. auf sich ?
Liegt der Fehler möglicherweise daran das ich einen (echten) linux user mit gleichem Namen & pw angelegt habe wie er auch über das WebIF angelegt wurde ?
Gelesen hatte ich schon das diese User vom "ctrlmgr" angelegt werden genaueres habe ich dazu aber nciht finden können.

Meine 4. Frage:
Gibt es eine Möglichkeit ein aktuelles samba (mit smb3) auf die Box zu bekommen ?

 

[NDiIPP]

Gibt es eine Möglichkeit ein aktuelles samba (mit smb3) auf die Box zu bekommen ?

Wenn es da eine einigermaßen einfache Möglichkeit gäbe, hätte AVM für SMB im aktuellen FRITZ!OS wohl nicht Samba durch eine proprietäre Software ersetzt.

 

[gneiss]

@NDiIPP:

Wenn es da eine einigermaßen einfache Möglichkeit gäbe...

Hab ich befürchtet.
Das das (proprietäre Software nutzen statt samba nutzen) eine "blöde" Idee war ist aber spätestens seit den damit verbunden Problemen klar.
AvM hatte ja schon mal Anfang letzten Jahres die SMB2 Lösung aus der Labor wieder entfernen müssen weil es damit Problem gibt.
Jetzt wurde sie auf "den normal User" losgelassen (sprich ist in der 7.21 drin).
Arbeitet aber immer noch nicht korrekt.

@peter:
Nachdem ich "noch mal eine Nacht darüber geschlafen habe"
weiß ich nun warum ich den Gedanken-Fehler gemacht habe (Dateisystem-Wurzel liegt im RAM).
Bisher bin ich noch nicht viel mit RO Dateisystemen in Kontakt gekommen. Auf einem Desktop-Linux ist das ja meist ein mount auf /dev/sdX (o.ä.).
Ich hatte komplett übersehen, das ich innerhalb einer RO gemountete Verzeichnisstruktur einen mount anlegen kann.
Wie das genau funktioniert (intern beim abarbeiten einer Verzeichnisstruktur) ist sicherlich interessant, denn es benötigt eine Sonderbehandlung für alle dirs in denen etwas gemountet ist...
Wichtig ist hier aber erst mal nur das es möglich und es z.B. bei dem mount von /var in das tmpfs ja auch genutzt wird...

Nachdem ich mir nochmal die man-page(s) von mount angesehen habe stelle ich fest das man sogar eine einzelne Datei auf diese weise "ummounten" kann (wohl ein eher selten genutztes feature).
Damit könnte man dann auch ein "Overlay-fs für arme" realisieren
Wobei mir nicht klar ist wie groß der durch ein mount erzeugte "overhead" ist bzw. ob ein link "schneller/effizienter" ist als ein entspr. mount (vermute das aber schon).

Noch was zu TFFS & der Realisierung der persistenten Dateien:
Gibt (gab) es auf der FB noch kein overlay fs ?
Das wäre doch für so etwas prädestiniert.
Die defaults liegen im squashfs über diese wird ein overlay fs gestülpt wird das (via copy on write) die Schreibzugriffe umleitet und die so geänderten Daten passend (u.a. beim reboot) "sichert".
Klar, einen "normalen" overlayfs fehlt (idR) die Optimierung nur das "delta" zu ermitteln" und zu speichern, ob das aber den Aufwand lohnt ?
Der ganze Aufwand ist wahrscheinlich alles dem Kostendruck für die Hardware geschuldet hier auf "preiswerte" Speicherlösungen zu setzen.
Denn (zumindest) heute sind Speicherlösungen die auf flash basieren durch passende vorgeschaltete Controller "transparent" als RW Speicher benutzbar (jeder USB-Stick arbeitet so).

 

[PeterPawn]

Wenn das jetzt so weit "ausfranst", solltest Du den Thread-Titel ändern ... das, was man jetzt für Dich aufschreiben müßte/soll, wäre nämlich sicherlich auch noch für andere interessant (es geht ja inzwischen viel mehr in die Richtung der Architekturen der verschiedenen FRITZ!Boxen und ihres OS bzw. was man da wie machen könnte beim Modifizieren, als um die Stichwörter im Titel des Threads), aber selbst wenn die es wegen eines passenden Suchbegriffs in ihrer Ergebnisliste hätten, würden sie bei diesem Titel wohl nicht mal einen Blick hineinwerfen in den Thread, wenn's nicht auch bei ihnen gerade um "7490 | vsftpd | samba" gehen sollte.

Da das ja erneut ein "bunter Strauß" an Fragen ist, picke ich jetzt erst mal einzelne Aspekte heraus und versuche darauf einzugehen - fangen wir hinten an.

============================================

Gibt (gab) es auf der FB noch kein overlay fs ?

Ja und nein. Erstens ist das overlayfs tatsächlich erst seit Kernel-Version 3.18 in den Kernel integriert: https://en.wikipedia.org/wiki/OverlayFS - auch wenn es Backports bis 3.10 gibt, soweit ich weiß.

Aber um diese verwenden zu können, müßte man in jedem Falle seinen eigenen Kernel bauen und (ggf. zusammen mit Freetz) verwenden - das ist bei Freetz zwar eine Option, aber solange es keine echte Notwendigkeit dafür gibt, sollte man das vermeiden (zumindest nach meiner Ansicht), weil es ein paar Kernel-Quellen gibt, die AVM den veröffentlichten Paketen nicht beilegt (https://www.ip-phone-forum.de/threa...opensource-paket-von-avm.287995/#post-2184482 - das gilt weitgehend auch heute noch) und wo wir (hier meine ich generell die "FRITZ!OS-Modifizierer", zu denen Freetz-Benutzer auch gehören, egal welcher Fork) auf eigene Quelltexte zurückgreifen müssen, die durch Reverse-Engineering entstanden sind und - dem Anschein nach zumindest - auch das machen, was sie sollen.

Aber das ist eben auch nicht garantiert und so sollte man den eigenen Kernel nur dann anstreben, wenn es sich nicht vermeiden läßt - auch für andere Probleme, die ein paar Änderungen durch AVM an den Kernel-Quellen verursachen, gibt es eher andere Lösungen (u.a. https://www.ip-phone-forum.de/threa...590-kein-tun-modul.300433/page-2#post-2309153) und es wird versucht, auf das Ersetzen des Kernels zu verzichten. Man weiß eben nicht genau, was sich bei AVM (außer dem Offensichtlichen) noch in den Quellen unterscheiden könnte und wo man sich vielleicht Probleme einfängt, die man nicht braucht.

Dann kommt noch hinzu, daß Freetz ja über viele verschiedene Modelle funktioniert (oder das zumindest soll) und die haben eben auch eine ebenso breite Palette an Kernel-Versionen, die sie benutzen - das geht/ging früher bei 2.4 los, wobei erst ab 2.6 Freetz so richtig in Schwung kam. Selbst Deine 7490 hat heute immer noch einen Kernel 3.10 (ich weiß nicht mal, ob AVM den overlayfs-Backport da gemerged hat - der Support dafür ist jedenfalls nicht im AVM-Kernel) und erst die neueren Modelle benutzen dann auch neuere Kernel-Versionen (die DOCSIS-Boxen bis inkl. Puma6 sind immer noch nicht beim 3er-Kernel angekommen).

Da, wo AVM das overlayfs tatsächlich selbst in den Kernel integriert (dann findet es sich ja im Inhalt von /proc/filesystems), da kann man das natürlich auch verwenden, wenn man möchte ... nur sind das nicht so viele Modelle und da Freetz nun mal auch auf den Geräten ohne diesen Support funktionieren soll/muß (selbst wenn man hingehen würde und bei 06.8x einen Schnitt machte, reicht das nicht, um sicher von der Verfügbarkeit von overlayfs auszugehen), macht da die Verwendung unter Freetz auch nur sehr begrenzten Sinn.

Trotzdem kann man das - sofern man es selbst implementiert - natürlich auch nutzen ... ich weiß nicht, wie gut Du Dich mit Shell-Programmierung auskennst und ob Dir Beispiele viel bringen. Sollte das so sein, kannst Du Dir gerne einmal ansehen, wie man sowohl mit overlayfs als auch mit mount -o bind ... Stellen im FRITZ!OS "beschreibbar" machen kann, die üblicherweise "read-only" sind: https://github.com/PeterPawn/YourFritz/blob/master/framework/implant_public_key

============================================

und die so geänderten Daten passend (u.a. beim reboot) "sichert"

Das klingt zwar auf den ersten Blick logisch, wird aber - ohne entsprechende Maßnahmen - sofort zur galoppierenden Sicherheitslücke, wenn man diese Kopie des upperdir sichern will (um die Änderungen persistent zu machen und diese Kopie beim nächsten Mal direkt wieder als upperdir zu verwenden) und dabei aber (mangels passendem internen Speicherort) auf ein USB-Volume an der Box zurückgreifen muß. Denn wenn man dann diese Kopie nicht irgendwie signiert, um die Datenintegrität sicherzustellen, kann jemand mit Zugang (nicht Zugriff) zur FRITZ!Box diesen Speicher dort einfach abziehen, die Kopie modifizieren und die Box dann mit dieser Kopie neu starten ... damit hätte er (praktisch ohne Aufwand) die Box schon übernommen. Ganz so simpel darf man das also nicht angehen ... selbst wenn man es für sich in Angriff nehmen wollte (und wenn man es für andere machen will, sollte man sich auch erst recht einmal die Konsequenzen (für die anderen, nicht nur für sich) überlegen).

Dazu kommt dann noch, daß man dafür natürlich auch erst einmal den Initialisierungsprozess des FRITZ!OS selbst so anpassen muß, daß da überhaupt Teile des Dateisystems über overlayfs gemountet werden - das ist bei der "stock firmware" (von AVM) ja auch nicht der Fall. Rechnet man dann noch hinzu, daß sich die Verfügbarkeit von overlayfs im Moment auf nur wenige Modelle beschränkt, mag das zwar für die Besitzer eines solchen Modells eine Option sein (Deine 7490 gehört da aber auch nicht dazu, zumindest nicht, ohne daß der Kernel ersetzt wurde), aber das sollte auch die Frage beantworten, warum Freetz da nicht automatisch auf overlayfs setzt.

============================================

Statt eine Eingabemöglichkeit für die Config zur Verfügung zu stellen werden nur einzelne Parts "editierbar" angeboten..

Und damit kommen wir jetzt wieder zu Freetz und den Möglichkeiten, die es seinen Benutzern bietet. Was meinst Du, wenn Du mal genau darüber nachdenkst, welche Variante der Konfiguration eines zusätzlichen Pakets (nehmen wir ruhig gleich den vsftpd) bei der größeren Zahl von Freetz-Benutzern/-Interessenten zu weniger Problemen führt ... die, wo man die notwendigen Einstellungen über ein GUI vornehmen kann, aus denen dann eine passende Konfiguration generiert wird (selbst wenn es noch eine Anleitung für ein paar "Nebentätigkeiten" braucht) oder eine andere, wo man als Benutzer die komplette Konfiguration selbst erstellen muß (wie Du das möchtest) und sich dafür (a) mit der Konfiguration des verwendeten Daemons und (b) mit den Besonderheiten der FRITZ!Box und des FRITZ!OS von AVM auskennen muß? Ich vermute mal, die Antwort kann sich jeder denken.

============================================

Damit stellt sich mir halt auch die Frage, warum Du dann unbedingt Freetz verwenden willst, wenn Du doch mit dem GUI (und dem Freetz-Mod in weiten Teilen) gar nichts anfangen kannst und/oder willst (jedenfalls habe ich diesen Eindruck gewonnen aus dem Text, der rund um das letzte Zitat oben zu lesen ist).

Alles, was Du zur Realisierung dessen, was Du uns hier als "Anliegen" aufgeschrieben hast, bräuchtest, wären die passenden Programme (Binärdateien) für die richtige Architektur (die 7490 verwendet MIPS mit BE-Speicherung) und die kannst Du Dir jederzeit selbst aus den Verzeichnissen Deines Freetz-Builds herausziehen. Sollte es beim vsftpd zu viele Abhängigkeiten von weiteren Bibliotheken geben, sollte man den lieber statisch linken (ich weiß nicht, ob er das im Moment in der Freetz-Buildchain anbietet, notfalls muß man es ebenso selbst patchen, wie man ggf. andere Pfade für die Konfiguration einbauen sollte) ... aber dann kann man den natürlich auch in einer selbst modifizierten Firmware verwenden.

Alles was man dazu noch machen muß, ist das Erstellen eines passenden Services für den supervisor und wenn man dabei ein (ebenfalls noch selbst zu schreibendes) Start-Skript aufruft, kann man auch mit ein paar vorbereitenden Kommandos in diesem Skript dafür sorgen, daß im beschreibbaren Teil des Dateisystems eine passende Konfiguration erstellt wird. Um genau solche eigenen Änderungen an der AVM-Firmware vorzunehmen, gibt es ja "modfs" eigentlich nur (https://github.com/PeterPawn/modfs / https://www.ip-phone-forum.de/threa...-ändern-für-nand-basierte-fritz-boxen.273304/) ... wenn Dir also die "Vorgaben", die Dir beim vsftpd-Paket durch Freetz gemacht werden, nicht passen sollten, steht es Dir problemlos frei, exakt diese Dinge selbst in das FRITZ!OS einzubauen - der Aufwand hält sich (wo Du das ohnehin von Hand konfigurieren willst) in überschaubaren Grenzen.

============================================

Ja, selbst mit dem Prinzip, was ich für das Implantieren von Shell-in-a-Box bei den VR9-Boxen gezeigt habe, könnte man sich den passenden vsftpd-Service in die eigene Box integrieren - auch das habe ich ausführlich erklärt, wie es funktioniert und was man dafür machen müßte ... lediglich das passende Binary müßte man sich noch besorgen und das findet man eben in der Freetz-Buildumgebung, wenn es erst einmal gebaut wurde (und wie ich gerade gesehen habe, hat das Paket sogar schon die Option zum statischen Linken: https://github.com/Freetz/freetz/blob/master/make/vsftpd/vsftpd.mk#L20). Also muß man nur noch die Pfade im entsprechenden Patch (https://github.com/Freetz/freetz/blob/master/make/vsftpd/patches/100-freetz_paths.patch) etwas tunen und an die eigenen Erfordernisse anpassen - dann kann man sich notfalls auch schon Symlinks von /etc nach /var/etc (oder ähnlich) einbauen lassen ins SquashFS-Image, so daß man die Konfiguration nur noch an der richtigen Stelle unterhalb von /var ablegen muß. Oder man geht eben gleich auf passendere Pfade, wie ich das bei meinen Patches für /var/custom auch jeweils mache - die fertig übersetzten Binaries in yf_bin (https://github.com/PeterPawn/yf_bin) verwenden ja üblicherweise diesen Pfad als "Basis" für die Suche nach abhängigen Dateien, weil man den so schön "einrichten" kann auf der FRITZ!Box - wie das mit den "custom extensions" funktionieren kann, habe ich auch hier irgendwo erklärt (ich glaube, es war im "modfs"-Thread).

Irgendwie habe ich halt im Moment den Eindruck, Du versuchst auf "Teufel komm raus" mit dem falschen Tool etwas zu erreichen, was auf anderen Wegen viel einfacher zu realisieren wäre - allerdings setzt das dann tatsächlich wieder ein paar (Linux-)Kenntnisse voraus - bis hin zum Konfigurieren von Software-Paketen aus fremden Quellen (was aber Linux-Benutzern auch täglich über den Weg läuft, wenn es für ihre Distribution keine fertig konfigurierten und übersetzten Pakete eines benötigten Programms gibt).

============================================

Womit dann ein rm -r /tmp/flash/* + modsave alles zurückstellen würde..

Das weiß ich im Moment gar nicht ... ist eigentlich auch nicht mein Tisch. Da mußt Du das Skript schon selbst analysieren - sollte sich durch das einfache Löschen der Dateien unter /tmp/flash wieder ein Unterschied zum "Standard" ergeben (damit werden bei Dir ja auch all die Einstellungen entfernt, die aus den Standardeinstellungen im SquashFS-Image generiert wurden), KÖNNTE ich mir zumindest vorstellen, daß das für jede dieser gelöschten Einstellungen eine "Änderung" ergibt. Ich weiß nicht, wie das dort ausgewertet wird (und ich sehe jetzt auch nicht nach), aber wenn man ein diff mit entsprechenden Optionen aufruft und eine der beiden zu vergleichenden Dateien existiert nicht, gibt das auch schon mal ein "Vollbild" der existierenden Datei und keine Fehler:

peh@vidar:~> diff -Nau /var/missing <(printf "Line1\nLine2\nLine3")
--- /var/missing        1970-01-01 01:00:00.000000000 +0100
+++ /dev/fd/63  2021-02-09 15:42:28.223963375 +0100
@@ -0,0 +1,3 @@
+Line1
+Line2
+Line3
\ No newline at end of file
peh@vidar:~>

Wenn da also zum Ermitteln der Unterschiede etwas in dieser Richtung verwendet werden sollte (gegen die (erneut) aus den Standardwerten generierte, temporäre Datei), dann hast Du danach erst recht sinnlose Einstellungen gespeichert. Ich würde mir das also entweder gut überlegen oder gut und gründlich ansehen - wenn Du unbedingt eigene Wege gehen willst. Das mit dem clear_id wirkt jedenfalls zuverlässig, wenn man die Box danach direkt neu startet - dann sind die Freetz-Einstellungen wieder dieselben, wie beim allerersten Start (mit Freetz).

============================================

Soll das heißen, das bei der 7490 (die ja das "config" mtd hat) dort eben auch ein TFFS "über das mtd4 Flash gelegt wurde" und die character devices in /var/flash dann eben in dieses TFFS zeigen, statt in eines was über die mtd7/8 gelegt wurde ?

Nein, das soll es natürlich nicht heißen. Du hast doch zumindest ein Freetz (samt Shell) auf der Box, warum siehst Du nicht mal nach? In /proc/mounts findest Du den Mount-Point für diese Partition und wenn man dann dort mal ein ls -l macht (Spoiler: das habe ich weiter oben ja schon gemacht und gezeigt, denn der Mount-Point ist ja genau /var/flash), dann sieht man dort auch die ganzen "character device"-Nodes für die AVM-Einstellungen herumliegen - jeweils mit den Namen, die man auch im Export-File wiederfinden kann (nicht alle, aber die meisten).

============================================

Du meinst Boxmatrix ?

Nein, warum sollte ich? Ich meine den proprietären Samba-/CIFS-Server, den AVM eingekauft hat und jetzt in der Firmware verwendet - der nennt sich nun mal so. Auch dazu gibt es hier irgendwo einen Thread (oder zumindest ein paar Beiträge in irgendeinem Thread), was das wohl heißen könnte und warum AVM das so und nicht anders machen dürfte.

============================================

Zur AVM-Benutzerverwaltung nur (eher kurz) so viel: Es gibt da tatsächlich zwei getrennte "Layer". Die AVM-Benutzer werden in der ar7.cfg verwaltet und kriegen dort jeweils auch eine (AVM-)User-ID (ich nenne die mal AID, im Gegensatz zur Linux-UID). Für den größten Teil der AVM-eigenen Software wird dann auch dieser Layer verwendet (der wird über den ctlmgr verwaltet) und es gibt nur ein paar wenige andere Programme in der AVM-Firmware, die ihrerseits wieder auf die bekannten "Linux-Strukturen" der Benutzerverwaltung zugreifen wollen. Und so generiert der ctlmgr aus den Angaben in der ar7.cfg dann eine passende /etc/passwd, in der für jeden Benutzer ein Eintrag boxusr<AID> und ein Eintrag boxusr<AID>int enthalten ist. Letzterer wird genutzt, wenn auf einen Dienst (der eine Benutzerprüfung vornehmen will) aus dem Internet zugegriffen wird. Dazu kommen dann (in neueren Versionen) noch die Konten für spezielle "Apps", die etwas ähnliches wie Benutzer sind, aber eben nur Berechtigungen für einzelne Apps (über ein API einzurichten) verwalten (die damit kein gesondertes Benutzerkonto in der AVM-Benutzerverwaltung brauchen).

Das Mapping zwischen den AVM-Benutzern und den Linux-Benutzern steht dann in der (dynamisch erzeugten) Datei /var/tmp/users.map und die Zugriffsrechte (speziell für NAS-Pfade) stehen in der /var/tmp/users.acl. In den Komponenten von AVM, die auf OpenSource-Paketen beruhen und wo AVM daher die (geänderten) Quellen auch veröffentlichen muß, erfolgt die Berechtigungsprüfung über eine definierte Schnittstelle (die Quellen der Library sind in den OpenSource-Paketen enthalten) mit dem Namen "libavmacl2.so".

Da die /etc/passwd vom ctlmgr dynamisch generiert wird, braucht es ein paar Vorkehrungen, wenn man dort eigene Eintragungen vornehmen will ... daher sollte man (nach Möglichkeit) auf diesen Mechanismus verzichten und stattdessen für den eigenen FTP-Daemon besser auch eine eigene Nutzer-Datei verwenden (nennt sich beim vsftpd dann "virtual user", wenn ich mich richtig erinnere). Wenn man nur eine Stelle haben möchte, wo die Benutzer verwaltet werden, kann man ja die o.g. Dateien aus dem AVM-Mapping passend auswerten - nur muß man dann auch auf dynamische Änderungen dort reagieren können, sonst müßte man ggf. den eigenen Service erst neu starten (oder gar die Box, je nachdem, welche "Fähigkeiten" zur Dienstkontrolle man dort eingebaut hat). Auf diesem Weg erspart man sich jedenfalls manches Problem, was sich aus der Benutzung der /etc/passwd ergeben könnte.

 

[gneiss]

@peter.
Erst mal wieder einen herzlichen Dank an deine ausführlichen Antworten. Ich hab schon viel von Dir hier gelesen und schätze diese Beiträge sehr.

Generelle Frage: Wie fügt man diese Boxen (von Dir z.B. bei "upper dir" verwendet) ein ?

Zum Titel des Threads:
Was würdest Du denn vorschlagen als Titel, so das er auch von (In diese Richtung interessierten) gefunden werden kann. Ich bin da für alles offen...

Zu overlay fs und kernel:
Klar das ist ein "ständiges" Problem von embeded linux. Da dort meist umfangreiche Änderungen (an Treibern & Kernel) vorgenommen werden müssen damit das ganze auf der Hw läuft ist es nicht leicht einen neunen Kernel zu verwenden. Als "Modder" (und das trifft ja hier auf das gesamte Freetz zu) erst recht, wenn die Patches & spezial Treiber nicht zur Verfügung stehen erst recht. Das ist ja auch etwas was ich hier echt bewundere wie viel Energie in das "reverse engeniering" gesteckt wurde um das alles ans laufen zu bekommen. AvM hat da wohl mit dem veröffentlichen Teile einen Teil zu beigetragen (hab ich zwar schon von gehört, mich aber noch nicht mit beschäftigt). Das das aber eben nicht alles ist und damit nicht ausreicht um einen (neuen/neueren) kernel zu bauen habe ich schon mitbekommen.

Ich hatte die Frage auch weniger darauf ausgerichtet warum Freetz kein overlay fs nutzt, sonder mehr warum es generell nicht genutzt wurde. Mit deinen Erläuterungen (gab es noch gar nicht bei den ersten Boxen) ist das mir jetzt klar. Warum es später nicht genutzt wurde ist auch klar: Never change a running system

Mir ging es speziell darum zu verstehen warum ein relativ komplexes System (TFFS) "erfunden" wurde für ein Problem das (zumindest in neueren kerneln) "mit Bordmitteln" gelöst werden kann.
Das muss ja auch wieder angepasst werden wenn man neuere kernel nutzen will....

Deine Hinweise wo man was finden kann sind mal wieder Gold wert. Die schaue ich mir gleich mal an...
... und keine Angst, ich hatte ja schon geschrieben, das ich µPs "bare metall" programmiere, da gehört es natürlich dazu, das man sich mit cross-compiling, shell Programierung usw. auskennt. Auch kconfig & make sind mir nicht fremd. Nur bei allem wo es ums WebIF geht (HTML, CGI, Perl usw) tue ich mich schwer, da hab ich nur rudimentäre Kenntnisse.

Allerdings ist das bei Freetz verwendete (kconfig/make) schon "'ne Hausnummer", alleine wegen des Umfangs. Wer da nicht "von Anfang an" dabei war oder sich wenigstens schon länger damit beschäftigt hat wird halt einfach von der Masse erschlagen (und da tragen die oft veralteten HowTo's oder verweiste Links nicht gerade zum besseren/schnelleren Verständnis bei, deshalb bin ich ja auch so froh hier einen Kompetenten Ansprechpartner gefunden zu haben. Jeder Deiner Hinweise bringt mich dem Verständnis des Gesamtsystems einen Schritt näher).

Die von Dir angesprochenen Probleme wenn man das upperdir auf einen externen speicher auslagern (muss) sind mir natürlich klar. Deshalb finde ich auch das HowTo für vsftpd schlecht. Hier wird nämlich die Konfiguration für die shares auf /var/media/ftp abgelegt, was ich für genau so ein Sicherheitsrisiko halte wie Du es für das upper dir beschrieben hast..

Ich hatte das ganze mehr generell gesehen und dachte (denke ich immer noch), das (zumindest die 7490) doch genügend internen Flash (in config) hat.... Das ist mir (bis hier) noch immer nicht klar.
Bei dem "Limit" von 32 kB im TFFS stößt man da ja leider zu schnell an die Grenzen (klar).

Zu Eingabemöglichkeit für die Config:
Klar, für den "normal" user mag es einfacher sein wenn er eine aufs notwendige reduzierte Konfiguration selber vornehmen muss.
Ich hatte ja auch geschrieben das ich die dahinter stehende Motivation langsam zu verstehen glaube.
Wer aber schon einen linux rechner hat auf dem eine funktionierende Konfiguration existiert ist sicherlich mit einer Möglichkeit diese einfach zu übertragen besser "bedient".
Der Spagat dazwischen ist nicht leicht, auch klar.
Mein Vorschlag/Ansatz: Man kann es selber wählen was man will.
1. Ansatz: Wird der Expert-Modus (für ein Paket) gewählt: Zeigt die GUI nur einen Editor für die Konfig-Datei(en) des jeweiligen Paketes. (ansonsten wie gehabt)
2. Bei den mir jetzt vorliegenden Infos zu den ganzen Speicher-Problemen, könnte man noch ergänzen:
Die "default"-Config kann schon beim build eingegeben (und damit ins sqashfs geschrieben) werden. Dann minimiert man noch den Platz der im Flash (TFFS) benötigt wird (durch den von Dir beschriebenen "Delta-Mechanismus). (Nur ein Vorschlag/Ansatz)

Damit stellt sich mir halt auch die Frage, warum Du dann unbedingt Freetz verwenden willst
So wie Du es schilderst sieht das wirklich nach der (für mich) besseren Methode aus. Man muss halt nur wissen das es diese Möglichkeit gibt und wo sie zu finden ist. werde ich mir auch mal ansehen.
Da ich (wie Du richtig erkannt hast) ja "nur": SSH, (s)ftp & samba benötige, die Konfigurationen für so etwas alle schon auf desktop-PC "am laufen" habe ist das wahrscheinlich wirklich die angesagte Methode (muss mich dann mal durch modfs & Yf durcharbeiten).

Womit dann ein rm -r /tmp/flash/* + modsave alles zurückstellen würde..
Zumindest das was ich dort derzeit sehe (in modsave) führt der Vorgang dazu das die aus /tmp/flash generierte und dann in den TFFS-Stream geschrieben wird zu dem (einzigen) Unterschied (zu clear_id) das dort dann eine leere Tar liegt (anstatt einem leeren TFFS stream).
Die ermittlung/erstellung der diff-Dateien (z.B. avm.diff) erfolgt ja (vorher?) in der modconf (hier ist ḿir der genaue Ablauf noch nicht klar).
Die persistenten Daten (bzw. deren Kopien im laufenden Betreib) des Fritz!OS sind ja in /var/flash, die von Freetz in /tmp/flash/ das sollte also die Fritz!OS Daten unberührt lassen.
Aber ich glaube ich weiß jetzt was Du meinst.
Wenn Freetz das erste Mal startet ist eben der TFFS stream leer, darauf könnten Pakete angewiesen werden, weil sie dann (erst beim ersten Start) ein diff erzeugen. Da macht es dann (u.U.) schon einen Unterschied ob der stream leer ist oder eine leere Tar enthält.
OK, also doch das clear id nutzen (davor hatte ich allerdings "respekt", weil id falsch -> Box tod).
Also 3x checken ob man die richtige id verwendet (ist aber jetzt ja klar).

Zu "config" mtd
> warum siehst Du nicht mal nach? In /proc/mounts ...
OMG, erst nach diesem ausdrücklichen "stupser" hab ich das verstanden. (Ich hatte nicht auf den mount point geachtet)

cat /proc/mounts oder auch einfach mount gibt aus:
/dev/mtdblock4 on /var/flash type yaffs2 (rw,sync,relatime)

Damit ist dann klar, das selbst dieser beschreibbare Teil der Verzeichnisstruktur im Flash (und nicht in RAM) liegt.

Was mich jetzt aber (noch mehr) verwirrt.
Klar dort liegen dann auch die "character device"-Nodes aber (wenn ich das richtig verstanden habe) leiten die doch alle die schreib/lesezugriffe in das TFFS weiter. Belegen also im yaffs2 (keinen/kaum) Platz.
Nur die dort angelegten Directories (bei mir ist das neben dem "lost+found" nur noch ein "provider_default" welche dann wiederum nur "character device"-Nodes enthält.
Damit dürfte der größte Teil der config partition ungenutzt sein.
Da mtd7 + 8 zusammen gerade mal 0x2000, config aber 0x20000 (also die 10fache) Größe hat/haben.

Wenn ich jetzt hier nicht wieder einen "Denkfehler" habe, bräuchte man dann die ganze Sicherung der Freetz Einstellungen in ein TFFS nicht, wenn man diese Dateien direkt unterhalb von /var/flash an/ablegt.
Voraussetzung ist allerdings, das dieses yaffs2 beim booten nicht immer wieder neu erzeugt wird (das habe ich noch nicht gefunden).
... und klar das funktioniert dann nur auf Boxen mit config mtd, also nicht portable genug für Freetz

zu "nqcs" "Boxmatrix":
Na nqcs sagte mir halt nichts und beim suchen (google) wurde ich zu Boxmatrix geführt.
Hab ich wohl falsch gesucht. Werde da hier im Forum nochmal machen um die von Dir angeführten Thread zu finden.

Zur AVM-Benutzerverwaltung
Das hilft mir dann schon mal für das Verständnis wie das umgesetzt wurde.
Wenn man über /var/tmp/users.map die zuordnung <name> -> boxuser<nr> ermitteln kann kann man den user des shares ja vorher entsprechend setzen.
Nach Deinen anderen Ausführungen werde ich mich aber wohl erst einmal in yF einlesen. Das scheint mir der für mich bessere/schnellere Weg zu sein.
Klar auch da muss ich dann sehen wie/wo ich die user + deren rechte ablege, aber das ist mom. das kleinste Problem.

zu samba/(s)ftp
Mir ist es halt wichtig hier ein funktionierendes aktuelles system zu haben.
smb1 ist keine alternative mehr. Erst smb3.1.1 inklusive posix extensions ermöglichte den Zugriff auf ein NAS mit so das alle permissions auch 1:1 dem der auf dem PC verwendeten entsprechen...
... und das funktioniert halt mit dem aktuellen Fritz!OS 7.21 nicht (mehr).
Auch der ftp-server ist "kaputt" (wie ich schon geschrieben habe ist er nicht mehr kompatible zu lftp.
Das ist/war meine Motivation für Freetz.
Allerdings sehe ich (weil samba 4 wohl nicht auf die Box zu bekommen ist) leider auch hier kein weiterkommen.
Mittlerweile bin ich schon so langsam auf dem Weg zur separaten NAS...


Ist wieder sehr viel geworden und ich hab noch viel zu lesen....
Nochmal danke für deine Ausführlichen Erläuterungen.

LG
Günter

PS.: Nachdem ich deinen Thread "Unter die Haube geschaut" beim suchen nach nqcs gefunden habe, noch eine Anmerkung dazu.
Natürlich habe ich beim auftreten des samba-Rechteproblem mich an die Hotline an Avm gewendet. Nach einigem hin und her (bei mir wurde der Eindruck erweckt das der Fehler vollkommen neu sei). Hieß es dann, das man da nichts dran machen könne und ich auf die nächste OS-Version werten solle...
Klasse, hätte ich nur nicht die neue Version eingespielt, die alte lief wenigstens korrekt (auch wenn ich das UID & GID forcen musste)

 

[PeterPawn]

weil id falsch -> Box tod

Schwer, unwahrscheinlich - bis unmöglich.

Das Kommando wirkt nur auf den TFFS-Inhalt - und die meisten Boxen (auch die 7490) starten sogar ohne passendes TFFS-Image in einer Art Notfall-Modus und kommen damit mindestens bis zum FTP-Server im Bootloader, womit man dann in jedem Falle noch mit dem Recovery-Programm arbeiten könnte. Die anderen Partitionen (jenseits der "tffs (1|2)") bleiben gänzlich unberührt dabei - das ist also eines des eher "gutartigen" Kommandos (für das proc-Interface des TFFS) und wird - mit der Minor-ID 87 - sogar ziemlich häufig hier im IPPF zu finden sein, weil es ein einfacher Weg ist, das "Vom Hersteller nicht unterstützte Änderungen" im GUI zurückzusetzen, auch ohne die Anzeige gleich komplett zu patchen.

Wie fügt man diese Boxen (von Dir z.B. bei "upper dir" verwendet) ein ?

Das ist "Inline Code" (BBCODE-Tag "ICODE") - ich nutze es immer häufiger anstelle von Anführungszeichen, um Begriffe, die "Computer-Slang" wären oder eben direkt "Kommandos", von anderem Text abzugrenzen.

Wenn ich jetzt hier nicht wieder einen "Denkfehler" habe

Hast Du diesmal tatsächlich nicht ... das ist halt über verschiedene Modelle kompliziert (und unterscheidet sich iirc sogar zwischen 7490 und 7412: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2152322) und wenn ich mich nicht irre, ist es bei der AVM-Initialisierung sogar so, daß die Partition beim geringsten Mount-Problem (das YAFFS2 ist ja dann auch nicht zwingend transaktionssicher, wenn ich mich recht erinnere - das ist aber wieder "aus dem Kopf") einfach komplett gelöscht wird (das YAFFS2 richtet dann beim Mounten die Strukturen automatisch neu ein).

Das ist nicht unbedingt das, was man von einem verläßlichen Speicher für Einstellungen erwartet ... aber man kann den trotzdem nutzen, wenn man möchte. Ein paar Alternativen, wo man solche eigenen Einstellungen ablegen könnte, habe ich (iirc gerade auch im Kontext einer 7490) im "modfs"-Thread mal beschrieben: https://www.ip-phone-forum.de/threads/modfs-squashfs-image-avm-firmware-ändern-für-nand-basierte-fritz-boxen.273304/post-2156232 - das ist zwar auch fast fünf Jahre alt, aber es sollte sich nicht soo viel geändert haben (auch wenn ich das jetzt nicht alles selbst noch einmal gelesen habe, was ich damals schrieb). Neu wäre da lediglich die Möglichkeit, diese Einstellungen in ein TAR-File zu packen und dieses dann tatsächlich mit dem RSA-Schlüssel der Box zu signieren (den sie auch für das GUI verwendet), so daß man es auch auf einem USB-Volume ablegen kann und trotzdem (wenn man vor dem Auspacken diese Signatur wieder prüft) sicher sein kann, daß da niemand an der Datei herumgepfuscht hat: https://www.ip-phone-forum.de/threa...ignieren-der-avm-firmware.286213/post-2165906 - das eröffnet einem dann tatsächlich wieder deutlich größere Möglichkeiten, sowohl was Generationsprinzipien als auch Speicherbedarf bei der Sicherung von Einstellungen (und anderen Daten) angeht. Es führen halt viele Wege in die Stadt in Italien.

Na nqcs sagte mir halt nichts

Unter anderem hier:

[Info] - Unter die Haube geschaut - Änderungen/Neuigkeiten im FRITZ!OS der Labor-Reihe 07.19

Ich mache hier mal einen Thread auf, in dessen erstem Beitrag ich - in loser Reihenfolge - die wichtigsten Sachen aufführen will, die mir beim Blick in die Innereien der neuen Labor-Version 113.07.19-73512 (auch wenn die nach Labor-Maßstäben schon fast wieder angestaubt ist) aufgefallen sind...

www.ip-phone-forum.de

[Info] - Unter die Haube geschaut - Änderungen/Neuigkeiten im FRITZ!OS der Labor-Reihe 07.19

Ich mache hier mal einen Thread auf, in dessen erstem Beitrag ich - in loser Reihenfolge - die wichtigsten Sachen aufführen will, die mir beim Blick in die Innereien der neuen Labor-Version 113.07.19-73512 (auch wenn die nach Labor-Maßstäben schon fast wieder angestaubt ist) aufgefallen sind...

www.ip-phone-forum.de

- diese Links habe ich tatsächlich in meiner eigenen Sammlung, weil ich da immer mal wieder "fortsetzen" wollte.

hätte ich nur nicht die neue Version eingespielt, die alte lief wenigstens korrekt

Solches "Bereuen" sollte eigentlich unnötig sein - es ist ja nun wirklich kein Problem, auch eine ältere FRITZ!OS-Version wieder auf dem Gerät zu installieren. Wenn das in 07.12 noch funktionierte (halt eben nur mit SMB1 und das willst Du ja offenbar auch nicht mehr?) und Dir der ganze andere Schnodder der 07.2x nichts bringt, kann Dich ja niemand daran hindern, die SMB1-Kröte dennoch zu schlucken und zur 07.12 zurückzukehren.

Hier verstehe ich also jetzt gerade das Problem nicht wirklich ... 07.12 = SMB1 ist Tor A und 07.21 mit eigenen Änderungen (wo Du SMB3 (von AVM) aber nicht nutzen kannst/willst) und vielen zusätzlichen Möglichkeiten ist Tor B. Solange es jetzt kein Tor C mit dem Zonk gibt, kannst Du Dich doch ohne Risiko entscheiden.

PS: OK, den "Unter der Haube"-Thread hattest Du selbst gefunden - egal.

 

[NDiIPP]

Spoiler: OffTopic

... weil ich da immer mal wieder "fortsetzen" wollte.

Darum wird gebeten. Auch im Hinblick auf FRITZ!OS 7.25. DuW

 

[gneiss]

@peter
Zum Titel des Threads:
Hattest Du leider nichts geschrieben...
Ich ändere den dann mal auf:
Architektur FRITZ!Box (speziell 7490) und von Fritz!OS sowie Freetz und die Möglichkeiten eines Mods
Ich hoffe das passt.

Zu clear id:
Ok, jetzt wird die Box hier auch so angezeigt wie in Deinen Beiträgen
Dann hab ich wohl einige Beiträge hier im Forum falsch interpretiert. Bei mir war der Eindruck entstanden damit recht schnell die Box killen zu können.

Zu "vorherige Version"
Das ist wohl wirklich das Resümee das ich aus der ganzen Diskussion hier ziehen kann.
Tor A: SMB1 ist zwar Sicherheitstechnisch nicht gerade das beste, da es aber nur in meinem Heimnetz (welches ansonsten gut gesichert ist) läuft wohl tatsächlich das beste für meinen Fall.
Tor B: Neue Möglichkeiten der 7.21: Sind für mich nicht wirklich wichtig.
Tor C: SMB3.1.1 mit posix extension. Wird (auf absehbarer Sicht) nicht auf der Box laufen.

Tor D
Da ich aber den SSH-Zugang nicht mehr missen möchte werde ich mal schauen ob ich nicht ein Freetz auf Basis der 7.12 baue in dem dann nur SSH zusätzlich läuft.
Das dürfte für meinen Fall die beste derzeitig realisierbare Alternative sein.

Die andere Alternative (separate NAS mit smb3), sehen auch nicht wirklich gut aus.
Ob eine (preiswerte) NAS smb3 (inkl. posix extension) bietet ist aus deren techn. Daten nicht sicher erkennbar.
Würde also nur ein Eigenbau in Frage kommen. Aber das ist mir dann doch zu viel Aufwand (und noch mal ein Gerät das dauerhaft Strom verbraucht).
Dafür sind meine Anforderungen an eine NAS dann auch wieder viel zu gering. (Ich brauche dort keine TB Daten und auch keinen Media-Server usw..)

Fazit:
Ich werde wohl Tor D nehmen.

Nochmal herzlichen dank für die Mühe die Du Dir hier gemacht hast, die ganzen Zusammenhänge zu erklären.
Ich habe viel gelernt über die Box, die bisher bei mir halt "einfach nur genutzt wurde"

PS.: Das bauen der Version 7.12 mit Freetz hat dann schon mal geklappt. Am WE werde ich das mal installieren & testen..

 

[gneiss]

Nur als Abschluss: Die Box läuft mir der Lösung so wie ich es brauche...