userscript 0.21 - 25.01.- Übernahme von Nutzereinstellungen

[skara]

/Edit:
Um das Suchen zu erleichtern:
v01 mit allg. Hinweisen
v02 - empfohlener Download mit weiterem Bsp-Skript

Hallo,

das momentane Problem ist ja, dass wir noch keine alternative Firmware haben, aber trotzdem bereits genügend Änderungen/Optimierungen des NAS (zb. Binaries, Änderungen des smbd und proftpd) gibt welche auch funktionieren. Allerdings nur bis zum Neustart.
Daher bin ich dabei, ein einfaches Skript zu basteln, welches die Änderungen bei jedem Neustart ausführt.
Ich nehme dafür die Funktion des NAS zu Hilfe, welche bestimmte Skripte beim Systemstart ausführt - new_software-Ordner, init des ssh-Servers.
Meine Überlegung war, das modular durchzuführen:
Ein Skript welches weitere Skripte ausführt, die sich in einem bestimmten Ordner befinden.
Dieses Startskript habe ich nach public/applications/userscript/ als init gelegt. Die genaue Laufwerksangabe ist egal, das wird im Skript berücksichtigt (USD-Variable)
Anzulegen ist noch userscript/scripts/ - dort kommen alle Skripte rein. Evtl. kann man eine Sammlung von fertigen Textdateien anlegen, welche programmspezifische Sachen beinhalten (bsp: smb-Optimierung für dbox und grosse Dateien oder eine andere Konfiguration für smb-Zugriff auf sehr viele kleine Dateien [zb mp3s]) und nach belieben vom Nutzer einfach via smb/ftp nach userscript/scripts kopiert werden und durch das Skript automatisch entsprechend ausführbar gemacht werden (noch auskommentiert, sollte aber funktionieren) - es gibt genügend Leute hier, die noch weniger Ahnung von Linux haben als ich :8

# get path to script
USD=$(cat /usr/sausalito/codb/objects/1/Disk.rootdir 2> /dev/null)/public/applications/userscript

for i in $USD/scripts/*; do
    [ ! -f  ] && continue
    echo "Do it"
     > /dev/null 2>&1
done

Soweit funktioniert das schonmal. ps zeigt mir zum Beispiel schonmal an, dass das Skript sehr früh ausgeführt wird, ohne das die anderen Dienste schon laufen (ok, hatten wir schon und hätten wir durch herumforschen auch herausbekommen - aber so ists doch einfacher )

Mein Problem ist momentan, dass mein NAS ausgestiegen ist (beide Dioden bleiben trotz Stromziehen aus, NAS nicht erreichbar). Bis das (ohne Datenverlust) wieder funktioniert brauchts erstmal, ausserdem hab ich auch noch andere Sachen zu tun.
Das ist auch der Grund für dieses alpha-Release. Ich will euch aber nicht noch länger warten lassen (ich ahne schlimmes für meine Daten), soll ja auch mal voran gehen mit dem NAS.

Wer möchte hier an dieser Baustelle mit arbeiten? Für Firmware backen reichen meine Linux-Kenntnisse leider nicht.
Bei Desinteresse werde ich das Projekt aber sterben lassen - dieses eine Skript reicht für meine Belange völlig aus, wenn ich alles direkt da rein schreibe.

Ansonsten schwebt mir noch eine automatische Installation über den new_software-Ordner vor - das Grundgerüst einfach als tgz verpacken und schon geht's los

gruss
skara

/Edit: Code entfernt, weil ich ihn grundzätzlich geändert habe. Ich habe aktuell nur die prinzipiellen Sachen übrig gelassen.
Mein NAS funktioniert wieder - war lediglich eine Dummheit :(

[ralf]

Ich hab mal einige Sachen probiert, habe aber wieder aufgehört, weil nach dem Ausführen meines init-Scripts plötzlich der telnet- und SSH-Zugang nicht mehr funktionierten. telnet musste ich neu freischalten und SSH neu installieren. Solange nicht klar ist, in welchem Stadium sich das NAS beim Ausführen der Init-Dateien befindet, macht das IMO wenig sinn.

[vishcompany]

@ skara: Klingt interessant, bitte nicht sterben lassen! Wenn das mal lauffähig sein sollte, wäre das eine absolut denkbare Variante für mich.

[skara]

So. Eine erste Version ist fertig.
Bei mir läuft's ohne Probleme, für Fehlerberichte bin ich natürlich dankbar.

Wie von RS vorgesehen, wird das Paket nach public/applications/new_software gelegt und das NAS neugestartet - Installation geht zwar auch anders, aber so ist's anwenderfreundlich
Dann gibt's einen neuen Ordner: public/applications/userscript/

Inhalt:
init - wird beim Starten des NAS ausgeführt, sorgt dafür dass ...
init.us - ... nach Beendigung des "normalen" Starts ausgeführt wird (nachdem also schon alle RS-Dienste laufen! - so können diese unsere Einstellungen nicht überschreiben)
example/* - Beispielskripte zum ersten Testen (s. unten)
scripts/ - hier müssen die zu startenden Skripte rein. Reine Textfiles reichen aus (wird autom. ausführbar gemacht) aber unix-konforme Bash-Skripte (also mit "#!/bin/sh" am Anfang!!!) mit der Endung ".sh" müssen's sein!!! alles andere wird nicht ausgeführt!
config/ - von mir gedacht, um fertige config-Dateien zu lagern, welche die Standards überschreiben (siehe proftpd-Bsp)

Ich habe gleich noch ein Paar Bsp-Sachen dazu gepackt:
linkhddapp.sh / linkroot.sh - Symlinks von /usr/hddapp/ bzw. / werden unter userscript/hddapp/ / userscript/root/ erstellt - war nützlich zum erstellen von userscript

unlinkhddapp.sh / unlinkroot.sh - tja, was wohl? entfernt die Links wieder.

proftpd.sh - überschreibt die Einstellungen des FTP-Servers mit der proftpd.conf aus userscript/config/proftpd.conf und startet proftpd neu.
Benötigt eine der conf-Dateien aus userscript/example/config/ - ACHTUNG. Je nach eurem Systemlaufwerk (ide1/ide2/md1) die entsprechende conf nehmen, nach userscript/config/ kopieren und in proftpd.conf umbennen! sonst wird's nix.

/edit: Link entfernt, da veraltet. hier gibts v02

gruss
skara

/Edit: Wie gesagt, ist Linux/Bash-Programmierung nicht gerade mein Steckenpferd. Entwicklung hat (nicht immer) Spass gemacht, aber es läuft.
Was ich nicht hinbekommen habe war, das 2. Skript im Hintergrund laufen zu lassen - init hat den Rest des Bootvorgangs geblockt. Habe diverse mir bekannte Varianten probiert (zBsp "./init.us &") - half nix. Daher der Umweg über "backup_button". Falls da noch jemand eine Idee hat ...

[The Chemist]

@skara

super geiles script.... habs ausprobiert und es funzt super

kannst du mir aber bitte die programmzeile in der init erklären ??

mv /sbin/backup_button /sbin/backup_bttn
cat > /sbin/backup_button <<EOF
killall -1 backup_bttn
/sbin/backup_bttn
/bin/sh /usr/userscript/init.us
EOF
chmod 777 /sbin/backup_button

ich würd gern verstehen was da geschied, da ich nach dem restart den Prozess backup_bttn laufen hab...

[skara]

Gern, siehe aber auch mein Edit.
Die init wird sehr früh im Bootvorgang ausgeführt, dh. die Raidsonic/Sausalitos-Änderungen kommen erst danach. Würde man die Änderungen der conf-Dateien da schon durchführen, würden sie im Laufe des Bootvorgangs wieder überschrieben.
Meine Bemühungen, dass Skript "schlafen" zu legen, sind im Sande verlaufen.

Der Bootvorgang läuft NAS-seitig zentral über /etc/rc - die letzte sinnvolle Möglichkeit, eigenen Code nach sausalito einzubinden ist, in Zeile 359 ("/sbin/backup_button")

Die von dir angesprochenen Zeilen

mv /sbin/backup_button /sbin/backup_bttn

benennt backup_button um.

cat > /sbin/backup_button <<EOF
killall -1 backup_bttn
/sbin/backup_bttn
/bin/sh /usr/userscript/init.us
EOF

cat leitet seine Ausgabe nach /sbin/backup_button - erstellt also eine neue Datei, da das ehemalige backup_button verschoben wurde. << sagt, woher die Eingabe erfolgt.
EOF habe ich irgendwann mal aufgeschnappt. Es erlaubt eine mehrzeilige Eingabe, bis EOF als einzelnes Wort in einer Zeile wieder vorkommt. Eine sehr gute Erklärung habe ich gerade hier gefunden. Englisch, aber besser kann ich's auch nicht erklären
Es wird also die neue Datei /sbin/backup_button mit dem Inhalt

killall -1 backup_bttn
/sbin/backup_bttn
/bin/sh /usr/userscript/init.us

erstellt.
killall - weiss nicht mehr warum, aber irgendwann während der Entwicklung das dann mal. Also lieber einmal zu viel abschiessen 8)
backup_bttn - das soll natürlich ausgeführt werden. Backup-Funktion auf angeschlossenes USB-Gerät sollte also wie in der Anleitung von RS uneingeschränkt funktionieren. Daher der von dir beschriebene Prozess. Ohne userscript gibt's den auch, heisst dann halt backup_button.
/bin/sh ... init.us - tja, hier werden nun also letztlich die Skripte ausgeführt.

Wenn jemand eine sauberere Lösung findet - ich bin da aufgeschlossen und lerne gerne hinzu

gruss
skara

[The Chemist]

thx

hatte mich nur gefragt warum diese ganze umbenennerei u.s.w.

Kann ich mir das so vorstellen, daß du den backup_button "leerst" und dann die info für das userscript reinschreibst, so das die box denkt es ist das original.

richtig ??

[skara]

JEIN.
Aus backup_button (einem binary) wird ein Skript, welches das (umbenannte) Original und userscript aufruft.

gruss
skara

[skara]

/Edit: Problem erledigt.

[skara]

Neue Version 0.21
/Edit: v0.21 enthält nur einen kleineren Bugfix für examples/config/proftpd.conf.md1. Wenn Ihr diese Bsp-config sowieso nicht benutzt, müsst ihr nicht aktualisieren!

init.us wird ohne das backup_button-Zeugs (aber dennoch am Ende des Bootvorgangs) ausgeführt. Während ich hier den Startpost schrieb, wurde ein ähnliches Verfahren im Wiki geschrieben - dort hatte ich bis jetzt nicht mehr drin gelesen. Dort ist die Veränderung her.

Hinzugekommen ist noch ein weiteres Bsp-Skript, welches die PATH-Variable für Shellzugriffe anpasst - zb für die ganzen Binary-Downloads hier im Forum nützlich.
"example/path.sh" nach "scripts/", "example/config/path" nach "config/" kopieren und anpassen. Momentan steht userscript/bin/ drin. Wenn mehrere Verzeichnisse eingefügt werden sollen, mit : voneinander trennen.

gruss
skara