[Gelöst] Freetz-NG: Fehler in der Verwaltung von Freetz Benutzern (7520/7530 7.2x ggf. weitere Modelle betroffen)

[PeterPawn]

Das habe ich auch nicht geschrieben ... wo stünde das? Ich habe - im Gegenteil - einen Thread in GitHub verlinkt, wo @cuma dazu etwas geschrieben hat und wer sich noch weit genug zurückerinnern kann, dem fällt dann auch wieder dieser Thread ein: https://www.ip-phone-forum.de/threads/verarschen.308916/ - und der war/ist auch für @cuma kein Ruhmesblatt.

Und @CommanderAdama konnte es sich dann auch nicht verkneifen, in dem von mir verlinkten (GitHub-)Thread gleich noch einmal zu erklären, daß @cuma (aus seiner Sicht) in GitHub genauso handeln würde. Was denkst DU denn, hat er sich davon versprochen? Daß @cuma jetzt "reumütig" wird und sich bei ihm für "ungerechte Behandlung" entschuldigt?

Die nehmen sich da beide nichts ... und @Fox.Mulder setzt das dann eben hier weiter fort (#14 - die "Eingangsbemerkung" hätte es gar nicht gebraucht und auch die Änderung in "bunt und fett" erfolgte erst nachträglich), wenn er es in GitHub nicht mehr kann. Daher auch meine anfängliche Skepsis (die auch noch nicht vollkommen verschwunden ist), was die Motivation für diesen Thread anbelangt: https://www.ip-phone-forum.de/threads/freetz-ng-fehler-und-probleme.309949/#post-2422610

Wobei der "Zensurvorwurf", mit dem da @janfreetz in einem GitHub-Thread "eine Sau durchs Dorf treiben" wollte, auch noch unklar ist, denn niemand weiß, was dort für ein Link gestanden haben soll - wenn's doch einer zum DEB gewesen sein sollte, wäre das "gelebte Praxis" (die ich persönlich auch begrüße) und nichts, was @antonvm zu solcher "Überraschung" veranlassen könnte: https://www.ip-phone-forum.de/threads/freetz-ng-fritzbox-stürzt-bei-verbindung-mit-vsftpd-ab.309351/#post-2411128.

Üblicherweise werden aber auch solche Links nicht einfach nur gelöscht, sondern es wird noch ein Hinweis angebracht, DASS da gelöscht wurde. Wenn der fehlt, sollte man zumindest auch noch eine "Fehlbedienung" durch den Autoren in Betracht ziehen ... oder auch seine "Unkenntnis", was denn "die Developer von Freetz-NG" eigentlich sind. Denn Links zum DEB wurden hier "schon immer" entschärft (wenn auch i.d.R. mit Markierung), da es dort auch Inhalte gibt, die nicht so ganz mit der deutschen Rechtssprechung vereinbar sind. Links zu den "Discussions" im GitHub-Repo von Freetz-NG (das ist es dann, was ICH unter "Developer von Freetz-NG" verstehen würde) sind hingegen - ganz offensichtlich - unproblematisch, denn die gibt es hier im Thread ja auch.

Daher wäre es wohl auch besser gewesen, wenn @antonvm da "etwas genauer" gewesen wäre und sich @janfreetz auch erst mal ein paar Gedanken dazu gemacht hätte, BEVOR er den Thread in GitHub erstellt hat.

---

Aber erneut: Die "Gründe" der jeweiligen Protagonisten sind mir eigentlich komplett schnuppe ... man kann auch - im ersten Aufbrausen - mal unvernünftig reagieren, das geht wohl jedem mal so, wenn er/sie sich ärgert (ein probates Mittel ist es dann, die Tastatur für die nächsten 30 Minuten erst mal gar nicht weiter zu benutzen).

Das dann aber als "Banner" ständig vor sich her zu tragen, bei jeder sich bietenden Gelegenheit erneut aufzuwärmen (ich ärgere mich auch heute noch über "Frechheiten" (und das ist eigentlich noch eine Untertreibung), die mir "per Moderation" hier in 2014 untergejubelt wurden - aber davon lasse ich nicht alles weitere bestimmen) und dabei die "Arbeit" am Problem zu sabotieren (und das ist unvermeidlich, wenn es - wie hier - immer zwei getrennte Erzählstränge geben muß), ist Kindergarten. Man muß auch nicht jeden mögen ... @cuma und ich werden garantiert auch nicht mehr BFF; aber wenn es um das Lösen von Problemen geht oder um das Weiterentwickeln des Projekts, dann sollte man trotzdem noch in der Lage sein, sich einigermaßen zivilisiert auszutauschen.

Wie machen das eigentlich diejenigen, die das hier nicht auf die Kette bringen, IRL? Sitzen sich da auch zwei (nehmen wir mal an: Entwickler und Tester) gegenüber und reden gar nicht direkt miteinander, sondern nur noch per E-Mail oder über die Team-Assistent*innen? Es müssen auch nicht gleich Zungenküsse oder Intimitäten sein, die man miteinander austauscht ... aber einen "zivilisierten Umgang" miteinander, sollte doch jeder halbwegs Erwachsene gelernt haben, oder? Und solange es "um die Sache" geht, haben weder "ad personam"- noch "ad hominem"-Argumente etwas in einer (ernsthaften!) Diskussion zu suchen.

 

[Fox.Mulder]

Wir sollten uns lieber um die technischen Themen kümmern, denn da sehe ich eine gute gemeinsame Basis.

Mit den zuletzt im Git geposteten Thema (vsftpd/Benutzerverwaltung) war cuma zunächst kooperativ. Als ich dann etwas tiefer eingestiegen bin, war mein Eindruck, dass er bewusst versucht hat, sich darüber lustig zu machen. Kann man alles ab https://github.com/Freetz-NG/freetz-ng/issues/236#issuecomment-808415212 nachlesen. Als im Git keine weitere kooperative Basis gegeben war, habe ich hier versucht Hilfe zu bekommen. Als Cuma, der hier noch mitliest, dies gesehen hat, hat er einen Verweis auf IPPF am Ende des Issues geschrieben, dass es nun hier weitergeht und den Issue geschlossen. Das er außerdem meine Accounts blockiert hat, habe ich erst gestern gesehen.

Ich finde es schade, dass Cuma so reagiert, anstatt kooperativ an Freetz-NG Themen mit allen Interessenten zusammenzuarbeiten. Immerhin haben wir es gemeinsam in kurzer Zeit geschafft, das Problem zu analysieren und eine Lösung für die Benutzerverwaltung zu finden. Das hilft am Ende allen Benutzern von Freetz-NG. Lasst uns in diesem Sinne weiterarbeiten.

 

[Cataclysm_177]

Wobei du aber nicht unschuldig daran bist! Du hast dort sehr herablassend geschrieben.

 

[Fox.Mulder]

Wobei du aber nicht unschuldig daran bist! Du hast dort sehr herablassend geschrieben.

Tut mir leid, das sehe ich anders. Im verlinkten Issue habe das Ergebnis meiner Analyse beschrieben und eine mögliche Lösung aufgezeigt und nach Alternativen gefragt. Cuma hat mehrfach versucht, ein vermeintliches Unverständnis vorzuspielen. Außerdem hat er erst mit fragwürdigen Maßnamen reagiert, nachdem ich hier gepostet hatte und er dies gelesen hat. Wir sollten diese OT Diskussion lieber beenden.

 

[Cataclysm_177]

Ich sehe da min 2 Beiträge von cuma, wo er versucht hat dich zu fragen und du sie einfach ignoriert hast.
Was ich noch gesehen habe war, als du nicht deinen willen bekommen hast, hast du hier ein Thema aufgemacht.

Cuma hat mehrfach versucht, ein vermeintliches Unverständnis vorzuspielen.

Dieser Satz ist genau das was ich gemeint habe, ich stimme dir ausnahmsweise mal zu, hier weiter zu reden bringt nichts.

edit:
So hier jetzt mal ein Test mit einer 7272:

Using username "root".
Authenticating with public key "Fritzbox Privatkey"
Welcome at fritz.box

   _____              _            _   _  ____
  |  ___| __ ___  ___| |_ ____    | \ | |/ ___|
  | |_ | '__/ _ \/ _ \ __|_  /____|  \| | |  _
  |  _|| | |  __/  __/ |_ / /_____| |\  | |_| |
  |_|  |_|  \___|\___|\__/___|    |_| \_|\____|


BusyBox v1.27.2 (2021-03-18 15:40:58 CET) built-in shell (ash)

root@fritz:/var/mod/root# cat /var/tmp/passwd
nobody:x:100:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
sshd:x:101:1001:sshd:/home/sshd:/bin/false
boxusr11:$1$mszwscn$/I0tGELungNKh7BEgPRmc1:1011:0:box user:/home-not-used:/bin/sh
boxusr11int:$1$ndqiokn$t0F2SWzKD./mlsivmW5kX1:2011:0:box user:/home-not-used:/bin/sh
boxusr10:$1$zravuoo$uYAP2H/.5IBWP7E/avdDg.:1010:0:box user:/home-not-used:/bin/sh
boxusr10int:$1$njsktkq$52c7M3qNRomNWYmKDmcfb/:2010:0:box user:/home-not-used:/bin/sh
boxusr100:$1$sslhpbs$i6iXjgXd9fqJzQRdy9VFj/:1100:0:box user:/home-not-used:/bin/sh
boxusr100int:$1$vcuovqc$WFnjV8mWFoR8kbQOaAn2X.:2100:0:box user:/home-not-used:/bin/sh
ftpuser:x:102:1:ftpuser:/var/media/ftp:/bin/false
root@fritz:/var/mod/root# adduser -h /var/media/ftp/USB admin
Changing password for admin
New password:
Retype password:
passwd: password for admin changed by root
root@fritz:/var/mod/root# cat /var/tmp/passwd
nobody:x:100:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
sshd:x:101:1001:sshd:/home/sshd:/bin/false
boxusr11:$1$mszwscn$/I0tGELungNKh7BEgPRmc1:1011:0:box user:/home-not-used:/bin/sh
boxusr11int:$1$ndqiokn$t0F2SWzKD./mlsivmW5kX1:2011:0:box user:/home-not-used:/bin/sh
boxusr10:$1$zravuoo$uYAP2H/.5IBWP7E/avdDg.:1010:0:box user:/home-not-used:/bin/sh
boxusr10int:$1$njsktkq$52c7M3qNRomNWYmKDmcfb/:2010:0:box user:/home-not-used:/bin/sh
boxusr100:$1$sslhpbs$i6iXjgXd9fqJzQRdy9VFj/:1100:0:box user:/home-not-used:/bin/sh
boxusr100int:$1$vcuovqc$WFnjV8mWFoR8kbQOaAn2X.:2100:0:box user:/home-not-used:/bin/sh
ftpuser:x:102:1:ftpuser:/var/media/ftp:/bin/false
admin:x:1002:1002:Linux User,,,:/var/media/ftp/USB:/bin/sh
root@fritz:/var/mod/root# modsave all
Saving users, groups and passwords ... done.
Saving config ... done.
Writing 9654 bytes to /var/flash/freetz ... done.
root@fritz:/var/mod/root# cat /var/tmp/passwd
nobody:x:100:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
sshd:x:101:1001:sshd:/home/sshd:/bin/false
boxusr11:$1$mszwscn$/I0tGELungNKh7BEgPRmc1:1011:0:box user:/home-not-used:/bin/sh
boxusr11int:$1$ndqiokn$t0F2SWzKD./mlsivmW5kX1:2011:0:box user:/home-not-used:/bin/sh
boxusr10:$1$zravuoo$uYAP2H/.5IBWP7E/avdDg.:1010:0:box user:/home-not-used:/bin/sh
boxusr10int:$1$njsktkq$52c7M3qNRomNWYmKDmcfb/:2010:0:box user:/home-not-used:/bin/sh
boxusr100:$1$sslhpbs$i6iXjgXd9fqJzQRdy9VFj/:1100:0:box user:/home-not-used:/bin/sh
boxusr100int:$1$vcuovqc$WFnjV8mWFoR8kbQOaAn2X.:2100:0:box user:/home-not-used:/bin/sh
ftpuser:x:102:1:ftpuser:/var/media/ftp:/bin/false
admin:x:1002:1002:Linux User,,,:/var/media/ftp/USB:/bin/sh
root@fritz:/var/mod/root# reboot
root@fritz:/var/mod/root#
Using username "root".
Authenticating with public key "Fritzbox Privatkey"
Welcome at fritz.box

   _____              _            _   _  ____
  |  ___| __ ___  ___| |_ ____    | \ | |/ ___|
  | |_ | '__/ _ \/ _ \ __|_  /____|  \| | |  _
  |  _|| | |  __/  __/ |_ / /_____| |\  | |_| |
  |_|  |_|  \___|\___|\__/___|    |_| \_|\____|


BusyBox v1.27.2 (2021-03-18 15:40:58 CET) built-in shell (ash)

root@fritz:/var/mod/root# cat /var/tmp/passwd
admin:x:1002:1002:Linux User,,,:/var/media/ftp/USB:/bin/sh
nobody:x:100:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
sshd:x:101:1001:sshd:/home/sshd:/bin/false
boxusr11:$1$ktzykbw$BAXQGupf/CaNPa2Y492Gh.:1011:0:box user:/home-not-used:/bin/sh
boxusr11int:$1$nzsbhdr$MPDNOc.uygL1qqirg0U5h0:2011:0:box user:/home-not-used:/bin/sh
boxusr10:$1$auptpdn$2pjn5.WUFvzy7sKDz3DFl.:1010:0:box user:/home-not-used:/bin/sh
boxusr10int:$1$hefmzes$m343snxPZ7E04G9Nzd7hD1:2010:0:box user:/home-not-used:/bin/sh
boxusr100:$1$xuwrrwn$LF14LsBsB03HhHUh8ZZQ80:1100:0:box user:/home-not-used:/bin/sh
boxusr100int:$1$ndvgsnr$Czs4YtOId.5Z4A4MHGcEE1:2100:0:box user:/home-not-used:/bin/sh
ftpuser:x:102:1:ftpuser:/var/media/ftp:/bin/false
root@fritz:/var/mod/root#

man sieht also deutlich, das es kein generelles freetz-ng Problem ist, da es mit der uralten FW 6.87 funktioniert.
Es ist also ein FW spezifisches Problem, wo hier mit freetz-ng vorliegt.

 

[PeterPawn]

Nur zur Info ... mittlerweile haben wir (@cuma und ich) das Problem, wann Konten vom ctlmgr "ausgesiebt" werden und wann nicht, vermutlich etwas genauer eingrenzen können: https://github.com/Freetz-NG/freetz-ng/commit/4d7bd9c526c8926864337bc8c44e9f56eeb3cc76 - da das in Kommentaren zu einem Commit erfolgt ist, kriegt das auch nicht jeder automatisch mit, außer er folgt @cuma oder mir auf GitHub, dann könnte er entsprechende Benachrichtigungen in seinem Dashboard sehen.

Nach dem, was dort steht, sollen JETZT die Änderungen auch soweit abgeschlossen und "stabil" sein, daß man das mal testen kann.

Ich habe mir die Commits noch nicht angesehen (mache ich heute auch nicht mehr, "I'm too tired.") und kann daher auch nichts zu den Inhalten der neuen Änderungen sagen/schreiben.

 

[stoney]

denn niemand weiß, was dort für ein Link gestanden haben sol

leider lässt sich da aus ModBerechtigung her nichts erkennen?

Auch wenn ich die einzelnen Versionen mir in "roh" anschaue, sehe ich da keinen anderen Link, entweder werden DEB Links nun automatisch geblockt/umgebogen/kP kann ich mir aber kaum vorstellen (vorallem wer sollte auf die Idee kommen dies auf's IPPF auf Freetz-NG zu legen?!)

 

[Cataclysm_177]

@stoney Wen man davon ausgeht, das der User nicht geschwindelt hat und man nichts in der Historie sieht, könnte es ein Forum Software seitiger Filter sein, die Bearbeitung würde dann nämlich nicht gespeichert werden und würde da nicht auftauchen.

 

[stoney]

Jup, dahwr mein Hint

entweder werden DEB Links nun automatisch geblockt/umgebogen/kP

Aber dies ist nur eine Annahme meinerseits und müsste von @dmin Seite aus beantwortet werden.

 

[PeterPawn]

Ob DEB-Links automatisch blockiert werden, ist ja leicht zu testen ... einfach mal "Jehova, Jehova" schreien (

) und einen solchen Link selbst anbringen.

https://www.***.com/threads/oscam-a...rherstellung-der-freetz-einstellungen.496451/

Wenn der stehen bleibt, ändere ich ihn hinterher noch selbst.

Ich glaube aber immer noch (denn das war ja schon vor dem letzten Update der Board-Software, wenn ich mich richtig erinnere und bis dahin war so eine automatische Filterung ja definitiv nicht drin), daß da jemand mit der Bedienung der Board-Software überfordert war und die Änderung, in der dieser Link vorhanden gewesen sein soll, nie wirklich den Weg bis in die Datenbank auf dem Server gefunden hat.

Wobei natürlich auch ein Server-Problem in Frage kommt ... das habe ich ab und an mit Cloudflare auch und dann muß ich erneut entsprechende Requests starten. Aber auch dann muß man eben als Benutzer aufpassen, daß/ob die eigenen Änderungen auch wirklich gespeichert wurden. Offenbar gab es ja insgesamt drei Updates von @antonvm für diesen Beitrag, wenn man dem Screenshot glauben will.

EDIT: Er blieb unverändert stehen ... und ehe ich mich jetzt selbst "melde", habe ich ihn einfach noch einmal geändert. Aber damit dürfte die "automatische Filterung" (zumindest wenn es um DEB-Links geht) auszuschließen sein ... auch noch nach dem letzten Update der Software.

 

[Fox.Mulder]

Ich habe gerade die aktuelle Git Version getestet. Neue Benutzer lassen sich hinzufügen und sind das in den Dateien in /tmp und /tmp/flash/users vorhanden. Auch wenn man modsave flash ausführt, sind diese Benutzer in /tmp/passwd nach einem Neustart nicht vorhanden.

Schade, weil mein letzter Test mit der Änderung von modusers load auf modusers update funktioniert hatte.

 

[PeterPawn]

Dir ist aber schon bewußt, daß vor einem modsave flash noch ein modusers save auszuführen wäre?

Benutzer dauerhaft in der passwd speichern

Firmware modification for AVM FRITZ!Box devices

freetz-ng.github.io

Und daß das schon seit Freetz-1.2 so war?

help/howtos/common/user – Freetz

freetz.github.io

Vermutlich hast Du nur vergessen, dieses modusers save (was auch noch existiert: https://github.com/Freetz-NG/freetz...74ff/make/mod/files/root/usr/bin/modusers#L63) in Deinem Text in #31 zu erwähnen und hast es hoffentlich trotzdem ausgeführt? Waren denn die neuen Benutzer danach auch noch in den Dateien vorhanden? Wie wäre es mit dem Log der Session?

 

[Fox.Mulder]

Warum sollte ich modusers save ausführen, wenn die Dateien in /tmp/flash/users nun automatisch aktualisiert werden?

root@fritz:/var/mod/root# nano /etc/group # Entfernen Benutzer test
root@fritz:/var/mod/root# nano /etc/shadow # Entfernen Benutzer test
root@fritz:/var/mod/root# modusers save # Aktualisierung /tmp/flash/users
root@fritz:/var/mod/root# nano /tmp/flash/users/passwd # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# nano /tmp/flash/users/group # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# nano /tmp/flash/users/shadow # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# adduser test -G users -h /var/media/ftp # Benutzer test neu anlegen
addgroup: can't find users in /etc/../var/tmp/gshadow
Changing password for test
New password:
Bad password: too short
Retype password:
passwd: password for test changed by root
root@fritz:/var/mod/root# nano /tmp/flash/users/passwd # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# nano /tmp/flash/users/shadow # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# nano /tmp/flash/users/group # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# modsave flash # Speichern im Flash
Writing 8154 bytes to /var/flash/freetz ... done.
root@fritz:/var/mod/root# nano /tmp/flash/users/passwd # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# nano /tmp/flash/users/group # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# nano /tmp/flash/users/shadow # Überprüfen des Dateiinhaltes
root@fritz:/var/mod/root# reboot

Nach Reboot:

root@fritz:/var/mod/root# cat /etc/passwd
asec::101:101::/nonexistent:/noshell
bittorrent:x:104:80:bittorrent:/home/bittorrent:/bin/false
ftp:x:105:80:ftp:/home/ftp:/bin/false
nobody:x:102:1000:nobody:/home/nobody:/bin/false
root:x:0:0:root:/mod/root:/bin/sh
smb::100:100::/nonexistent:/noshell
ftpuser:x:103:80:ftpuser:/var/media/ftp:/bin/false
boxusr31:...:0:box user:/home-not-used:/bin/sh
...
app70int:...:2031:0:box user:/home-not-used:/bin/sh

Ich nehme an, dass nach den letzten Änderungen von Cuma die Wiederherstellung nach dem Reboot nicht mehr korrekt funktioniert.

 

[PeterPawn]

Ich gehe einfach mal davon aus, daß Du den GitHub-Thread dazu mittlerweile auch gelesen hast und auch die Tests, die in den Commit-Kommentaren von mir gezeigt wurden.

Ich habe mir das auch nicht angesehen, was da mit der zusätzlichen Datei (irgendetwas von modxxxpasswd habe ich in der Commit-Liste gelesen) tatsächlich passiert und ob das dann auch alles passen sollte.

Aber DASS noch darüber diskutiert wird, OB und wenn ja, WIE man die automatisch von adduser vergebenen UIDs nun "einteilen" sollte, wird Dir sicherlich auch nicht entgangen sein. Wenn Du also gerne möchtest, daß Dein Benutzer test "überlebt", bliebe Dir ja die Option, dem selbst beim adduser mit der passenden Option eine UID zu geben, die auch von AVM nicht aus der Datei entfernt wird.

Denn ganz ehrlich ... wer soll aus Deinen "Kunststückchen" im oben gezeigten Protokoll denn schlau werden und das irgendwie nachvollziehen können, wenn das einzige Mal, wo ein INHALT einer Datei zu sehen ist, erst nach dem Reboot wäre? Wenn ich das richtig sehe (und so, wie das oben steht, habe ich fast keine Lust mehr, das überhaupt zu lesen), ist das einzige modusers save, was Du da machst, genau das nach dem ENTFERNEN eines zuvor vorhandenen Benutzers test.

Danach legst Du einen neuen Benutzer test an und der kriegt - beim derzeitigen Stand in GitHub - eine UID jenseits der 1000 - wird also von AVM aus der Datei wieder entfernt, wenn der ctlmgr nach dem modload ganz am Beginn der Initialisierung nach dem Reboot, die /var/tmp/passwd neu schreibt.

Und da muß ich jetzt nicht mal nachsehen, was da tatsächlich in den Skript-Dateien geschieht ... die Dokumentation fordert immer noch ausdrücklich dazu auf, nach dem manuellen Hinzufügen von Benutzern erst mal ein modusers save zu machen (was dann die Änderungen in die gespiegelten Dateien in /tmp/flash/users kopieren soll) und wenn Du NACHWEISEN willst, daß da etwas nicht so funktioniert, wie es beschrieben ist, kannst Du schlecht einfach etwas anderes machen, als in der Beschreibung steht. Wenn das - trotz modusers save und ANSCHLIESSENDEM modsave flash - immer noch zu demselben Problem führt, DANN ist das ein (nachvollziehbares) Problem - aber Du kannst nicht einfach Deinerseits hingehen und eine neue Abfolge von Kommandos bestimmen und danach dann monieren, daß das Ergebnis auch von dem beschriebenen abweicht.

---

Und das oben gilt (für mich) auch dann, wenn ich selbst der Ansicht bin, daß das noch nicht endgültig geklärt und wirklich "sicher" implementiert ist: https://github.com/Freetz-NG/freetz-ng/discussions/261#discussion-3313495 - ich verstehe da den letzten Beitrag von @cuma auch nicht so richtig, weil ich gar keine Idee habe, von welchem modadduser er da schreibt.

Ich rate mal, daß er da wieder der Ansicht ist/war, jeder müsse jeden seiner Commits "mitlesen" und damit ständig "auf dem Laufenden" sein, um mit SEINEM Freetz-NG arbeiten zu können ... das geht mir genauso auf den Sack. Ich finde weder in NEWS noch in CHANGELOG irgendeinen Hinweis auf irgendwelche Änderungen, noch habe ich bisher irgendeine "Erwähnung" eines modadduser in irgendeiner "Unterhaltung" mit ihm gesehen ... und ich sehe meine Lebensaufgabe definitiv nicht darin, mir irgendwelche Commit-Wüsten anzusehen.

Da greife ich dann lieber zu einem guten Buch und bin aus dieser ganzen Geschichte erst mal wieder raus. Ich bin mir sicher, daß @cuma das auch mitbekommt, wenn er es hier liest und daß ich das nicht noch einmal explizit in GitHub erwähnen muß.

Wenn man schon solche Änderungen vornimmt, dann sollte man das wenigstens irgendwo so ERKLÄREN, daß die "Zielgruppe" es (a) überhaupt mitbekommt und (b) damit auch etwas anfangen kann. So, wie das derzeit wieder läuft, habe ich so gar keine Lust, weiterhin irgendwelche Zeit zu verschwenden und jedesmal erst suchen zu müssen, ob sich wieder etwas geändert hat oder nicht. Mir reicht es jetzt erst mal für die nächsten sieben Tage - sowohl hier im IPPF, wenn es um Freetz-NG geht, als auch im GitHub-Repo.

Hier lebt jeder seine Neurosen aus, man muß ständig auf zwei Hochzeiten tanzen und wird am Ende noch verarscht (und ich nutze hier das "böse Wort", was wohl der Stein des Anstoßes an anderer Stelle war, auch absichtlich - wer das tatsächlich "zensieren" möchte, tue sich keinen Zwang an, lese aber zuvor vielleicht mal den Duden: https://www.duden.de/rechtschreibung/verarschen und überlege, ob die erste Bedeutung nicht ganz gut passen würde an dieser Stelle), indem man ständig von A nach B gejagt wird und sich das Projekt schon wieder dreimal geändert hat, während man noch etwas zur ersten Änderung schreibt.

Ich bin mittlerweile schon extrem erstaunt, daß es überhaupt noch Freetz-NG-Benutzer gibt, die das auch noch mitmachen - wer sich ein Image baut und mit dem irgendein Problem bekommt, kann ja praktisch gar nicht mehr genau sagen, mit welchem Stand das tatsächlich geschah und vor allem können die Benutzer, die sich generell mit Programmierung und dem Lesen von Änderungen in VCS nicht so richtig auskennen, ja gar nicht mehr erkennen, ob ihr "Problem" nicht mit dem nächsten Commit (60 Sekunden, nachdem sie selbst den letzten Checkout machten und dann 1, 2 oder auch 4 Stunden in einen Build investierten - je nachdem, was man da alles macht) bereits wieder "behoben" wurde und sie jetzt eigentlich wieder von vorne beginnen müßten (zumindest die letzten Änderungen noch "ziehen" sollten) und dann noch einmal ein Image bauen und testen müßten. Wie kann man sich so etwas eigentlich gefallen lassen? Oder ist es nur die fehlende Alternative?

 

[Fox.Mulder]

Ich habe meinen Fehler gefunden. Beim Update des lokalen Git Repo wurde die von mir gepatchte Datei make/mod/files/usr/bin/modpasswd nicht überschrieben. Wenn ich die Datei aus dem Freetz-NG Git verwende, funktioniert die persistente Speicherung.

Cuma hat zusätzliche Skripte modadduser und moddeluser hinzugefügt. Das Erstellen neuer Benutzer und persitente Speicherung erfolgt nun wie folgt:

modadduser test -G users -h /var/media/ftp
modsave flash

modusers save ist nicht mehr erforderlich.

---

Zwischenzeitlich wurde das Thema anders gelöst. Da ctlmgr UIDs < 1000 beläßt, wie sie sind, wurde die Inotify Lösung verworfen und lediglich busybox so eingestellt, dass neue UIDs > 899 angelegt werden. Das anlegen und die Sicherung von zusätzlichen Benutzern erfolgt nun wieder mit adduser, modusers save und modsave flash.