Hallo,
ich muss das hier gerade nochmal ausgraben. Ich hab teilweise damit zu kämpfen, dass irgendwelche Putzfrauen da ständig drankommen und würde den gerne standardmäßig deaktivieren.
Gibt es da schon ein Paket oder sowas? Hat den jemand seitens der Firmware standardmäßig deaktiviert?
Grüße
Matthias
Danke für die Info!
<auffuellen auf 20 Zeichen>
Funktioniert das eigentlich? Ich meine, das sei nie fertig geworden.
Der weigert sich das Paket einzubauen, weil das Paket eine schon vorhandene Datei überschreiben würde. Vermutlich müsste man das eher als Patch in OpenWRT reinschmeißen oder so.
Oder gibt es da eine Möglichkeit das Überschreiben zu erzwingen?
@MPW bau doch ein Modul das sich ein upgradescript in die /lib/gluon/upgrade legt, das wird dann bei einem Upgrade einmalig ausgeführt …
… also sowas wie
888-rfkill-button-killer
chmod a+x 888-rfkill-button-killer
und wenn da nur quick&dirty drinsteht
#!/bin/sh
rm /etc/rc.button/rfkill
… kannste hier bei einem ähnlich strukturierten Projekt spickeln
dein skript darf natürlich alles mögliche überschreiben/anpassen … weil das ja erst zur laufzeit /upgradezeit ausgeführt wird
Das ist natürlich eine Möglichkeit. Aber warum kann man das nicht direkt korrekt setzen? Das müsste doch eigentlich gehen…
@MPW der Buildprozess sammelt alle möglichen Pakete zusammen , und wenn der das zulassen würde, dann wäre die Reihenfolge in der Pakete zu dem "master"build zusamen gefasst werden auf einmal sehr wichtig … - es macht schlicht unendlich viel mehr probleme als es löst, daher gibt es das upgrade verzeichnis mit den skripten. Und dort ist dann eben die richtige Stelle für ein rfkill-button-killer script
Okax, das mit der Reihenfolge ergibt Sinn, dann müssen wir das so umbauen.
Bitte hier posten, wenn du das Modul fertig hast
Das SH Script muss aber noch ausführbar im git abgelegt werden… Getestet ist es auch noch nicht… Vlt heute Abend…
das skript kann so nicht funktionieren !!!
Das Script einfach zu überschreiben erscheint mir auch unschön.
Wie wäre denn eine saubere Lösung umzusetzen?
Das hat auch niemand behauptet !!!
Ich hatte nur schon mal Niedergeschrieben was mir in den Sinn gekommen ist von Funktion und fertig hat niemand gesprochen.
Ich persönlich finde es nicht so toll einfach irgendwelche Dateien aus einem System zu löschen. Daher die Idee diese mit anderem wenn auch sinnlosen Inhalt zu füllen.
Gruß Marius
zwischen löschen und sinnfrei machen seh ich echt nicht den großen unterschied.
aber es ist u.U. sicher besser das da weiter ein skript ist …
EIne saubere Lösung wäre eine Checkbox im Webinterface: Tastensperre an/aus.
dazu müsste man eine uci-config option einbauen, die dann auswertet ob das rfkill script aktiv sein soll oder nicht.
ich denke im config mode ist übertrieben, wenn man die rfkill taste tatsächlich braucht, dann schafft man es auch per ssh dies einzugeben:
uci set rfkillbutton.enable=1
oder so.
Also schön wäre, wenn der default deaktiviert ist und man den per ssh aber wieder einfach aktivieren kann
Vielleicht könnte man das original script auch so ändern, dass es in jedem Fall das Wifi immer aktiviert, egal welchen Zustand es vorher hatte?
Falls jemand mit dem Button Wifi vor dem Firmware Update deaktiviert hat und sich durch ein Update das aktivieren erhofft, würde dies zumindest nicht das WiFi „für immer“ deaktiviert lassen.
Ich denke, das sollte man mal ordentlich machen und hier ausarbeiten:
Wir haben hier ein quick 'n dirty Packages erstellt, mit dem man dem Wifi-Taster unterschiedliche Funktionen zuweisen kann.
Wir nutzen folgende:
„Wifi an/aus“
ODER
„Keine Funktion“
ODER
„Wifi-Reset“
ODER
„Temporäres Aktivieren der Status-LEDs (Nacht- oder Stromspar-Modus)“
Das ganze lässt sich im Konfigurationsmodus oder per uci einstellen.
Das Package sollte leicht anpassbar sein und findet sich hier: packages/ffffm-button-bind at master · freifunk-ffm/packages · GitHub
P.S.
Das original Skript rfkill wird zur weiteren Verwendung mit dem Packageskript /lib/gluon/upgrade/888-button-bind weggesichert und durch unser Skript rfkill.btnb ausgetauscht.
Das ganze Gedönse in /etc/init.d/ und /etc/rc.d/ ist nur dazu da, damit die LEDs direkt nach dem Booten abgeschaltet werden können (falls das so konfiguriert wurde).
Da fehlt noch ein Clientnetz on/off
