Hallo,
zuerst mal die ...
EINTEILUNG:
Ich habe die Funktionshinweise nun ausgegliedert, um in einem neuen Thread einzig und alleine die Paket- und Mod-Entwicklung zu diskutieren. Wenn du das willst, dann bist du hier genau richtig.
Hier gibts den aktuellen Mod:
danisahne-mod >>
Hier also kein User-Support, das ist Developer-Bereich 
Fragen bitte einfach im ds-mod Unterforum stellen
HINWEISE:
Hier sollten jetzt nur Developer und Interessierte sein. Dieser Thread richtet sich an alle, die am Mod mitwirken wollen. Dazu ist jeder herzlich eingeladen. Wer ein Paket erstellen will, meldet sich bitte bei mir Zwecks Absprache (soll ja nichts doppelt gemacht werden). Ihr behaltet dann die Hoheit über euer Paket, d.h. Änderungen am Paket nehmt nur ihr vor. Ich aktualisiere dann immer nur euer Paket im Mod.
Inhalt
- Allgemeines
- Eigene rc Skripte
- Eigene Dateien ins Image packen
- Eigene Pakete
- Konfiguration
- Dokumentation
1. Allgemeines
Die Konfiguration wird in einem eigenen character device /var/flash/ds_mod gespeichert. Es enthält ein tar Archiv des Ordners /var/tmp/flash (ist das selbe wie /tmp/flash, Symlink! Nicht mit /var/flash verwechseln!!!). Beim Booten wird das Archiv entpackt, so dass Dateien, die einen Reboot überleben sollen einfach nach /tmp/flash kopiert werden können, gefolgt von einem 'modsave flash'. Ich habe ein Hardlimit von 30KB als Standard gewählt, das durch
Code:
modconf set mod MOD_LIMIT=<bytes>
modsave
geändert werden kann. Eine Sicherheitsbarriere, mit der das Bearbeiten von Konfiguartionsdateien über das Webinterface eingeschränkt werden kann ist das "Sicherheits Level":
Code:
echo x > /tmp/flash/security
modsave
# wobei x folgende Werte annehmen kann:
# 0 : keine Einschränkungen
# 1 : Dateien mit Shell Befehlen dürfen nicht bearbeitet werden, der Rest schon
# 2 : keine Konfigurationsdatei darf bearbeitet werden
Das "Sicherheits Level" bestimmt in ähnlicher Weise auch, welche Skripte unter "Extras" ausgeführt werden dürfen und welche nicht.
Wrapper-Skripte für Textdateien (erfordern kein 'modsave'):
- Dateien in /var/flash: nvi
z.B.: nvi /var/flash/debug.cfg - Dateien in /tmp/flash: mvi
z.B.: mvi /tmp/flash/meine_datei.txt
2. Eigene rc Skripte
- /var/flash/debug.cfg: Diese Datei wird vom mod nicht verwendet und steht weiterhin gewohnt zur freien Verfügung. Zu beachten ist nur, dass die debug.cfg VOR dem eigentlichen Mod ausgeführt wird (rc.mod).
- /tmp/flash/rc.custom: Diese Datei wird beim Booten als letztes aufgerufen, wenn sie existiert. Sie kann folgendermaßen angelegt werden:
Code:
mvi /tmp/flash/rc.custom # -> bearbeiten -> :wq
Reihenfolge beim Booten:
Code:
-> rc.S
|-> rc.{dsl|net|viop|telefon|...}
|-> debug.cfg
'-> rc.mod
|-> rc.{bftpd|dropbear|...} (Pakete)
'-> rc.custom
Eine Ausnahme ist rc.dnsmasq (und auch rc.callmonitor), wenn statisch in der Firmware enthalten, welches direkt vor multid in der rc.net gestartet wird (da sonst das Binden der Ports fehlschlägt; vor dem multid startend wird ein Neustart des multid vermieden, der sonst z.B. bei 'rc.dnsmasq restart' immer erfolgt).
Das Verzeichnis /mod/ (bzw. /var/mod/) ist im RAM und stellt ein quasi root Verzeichnis für den Mod dar. Die rc Skripte der Pakete sind alle in /mod/etc/init.d/rc.* bzw. dort verlinkt.
3. Eigene Dateien ins Image packen
Entweder ein eigenes Paket erstellen (siehe 6.4.) oder einfach die Dateien ins Verzeichnis root/ an die stelle kopieren, wo sie im Squashfs landen sollen (root/bin/test ist auf der Box /bin/test).
4. Eigene Pakete
An ein Paket stellen sich folgende Anforderungen:
- rc Skript: etc/init.d/rc.<paketname> [start|stop|load|unload|restart|status]
Wenn konfigurierbar:
- Default Konfiguration: etc/default.<paketname>/<paketname>.cfg
- Optional: cgi Skript für die Weboberfläche: usr/lib/cgi-bin/<paketname>.cgi
- Optional: Extra cgi Skripte in usr/lib/cgi-bin/<paketname>/
Sonstige Default Dateien sollten auch ins Verzeichnis etc/default.<paketname>/ gepackt werden.
HINWEIS: Ich werd noch ein Skript schreiben, mit dem man einen Paketrahmen erzeugen kann.
Statische Pakete werden auf der Box nach / entpackt, dynamische nach /mod/. Egal ob dynamisch oder statisch
- /mod/etc/init.d/rc.<paketname>
- /mod/default.<paketname>/*
- /mod/usr/lib/cgi-bin/<paketname>.cgi
- /mod/usr/lib/cgi-bin/<paketname>/*
sind immer gültig (sofern im Paket enthalten) und werden bei statischen Paketen über Symlinks realisiert. Eine spezielle Bedeutung kommt dem Pfad /mod/pkg/<paketname> zu. Er ist entweder ein Symlink auf / oder auf /mod und zeigt auf "Root" für das Paket (sollte in der Regel nicht benötigt werden). Binaries sollten nach bin, sbin, usr/bin oder usr/sbin, damit sie sowohl in statischen als auch dynamischen Paketen aufrufbar sind (die PATH Variable enthält auch /mod/bin, /mod/sbin, /mod/usr/bin und /mod/usr/sbin). Libraries funktionieren mit statischen wie auch dynamischen Paketen in lib (LD_LIBRARY_PATH=/mod/lib => Library wird in /lib und /mod/lib gesucht)
Benötigt ein Daemon eines Paketes eine Konfigurationsdatei (z.B. bftpd.conf), die für diesen Daemon spezifisch ist, so wird sie in der Regel im rc Skript vor dem Starten des Daemons erzeugt. Ich habe dafür folgende Konvention gewählt (ist aber kein muss), welche am Beispiel der bftpd.conf erläutert ist:
- Suche nach Skript /tmp/flash/bftpd_conf, welches die bftpd.conf als Ausgabe hat; existiert? -> goto 3.
- Führe Skript /etc/default.bftpd/bftpd_conf aus, die Ausgabe ergibt wie bei 2. die bftpd.conf (meistens ist dies der Fall)
- Existiert /tmp/flash/bftpd.conf.extra? -> füge sie an die in 1. oder 2. generierte bftpd.conf an
Das sollte alle Möglichkeiten des "Feintunings" offen lassen. 3. macht nicht immer Sinn, darum ist es optional. Wäre schön, wenn jeder, der ein Paket erstellt, die Konventionen einhält. Das Skript bftpd_conf muss stets mit exportierten Variablen aus /mod/etc/conf/bftpd.cfg aufgerufen werden. So wird die bftpd.conf je nach Paket-Konfiguration individuell erstellt.
5. Konfiguration
Jedes Paket besitzt ein Konfigurationsdatei /mod/etc/conf/<paketname>.cfg, welche wie folgt aufgebaut ist:
Code:
export <PAKETNAME>_OPTION1='bla'
export <PAKETNAME>_OPTION2='blub'
...
Sie enthält alle Optionen, die auch übers Webinterface eingestellt werden können und ist in Shell Syntax. Damit kann die aktuelle Konfiguration mit
Code:
. /mod/etc/conf/<paketname>.cfg
eingelesen werden. In der Datei /mod/etc/default.<paketname>/<paketname>.cfg sind die default Einstellungen gespeichert. Beim Speichern werden nur die sich von den Defaults unterscheidenden Variablen in die /tmp/flash/<paketname>.diff transferiert und mit dem ganzen Verzeichnis /tmp/flash/ ins tffs abgelegt. Die Basis-Konfiguration hat den Paketnamen 'mod'. Die Befehle dazu sind:
Code:
modconf load <paketname>
# -> erzeugt die Datei /mod/etc/conf/<paketname>.cfg aus den Defaults und der <paketname>.diff
modconf save <paketname>
# -> erzeugt die Datei <paketname>.diff aus den Defaults und der /mod/etc/conf/<paketname>.cfg
modsave
# -> ruft unter anderem für alle Pakete 'modconf save' auf und speichert das Verzeichnis /tmp/flash ins tffs
modsave flash
# -> speichert nur das Verzeichnis /tmp/flash ins tffs
Das dauerhafte Abschalten des Webinterfaces geht damit so (Variable MOD_HTTPD in der Basis-Konfiguration 'mod'):
Code:
vi /mod/etc/conf/mod.cfg # -> MOD_HTTPD='yes' durch MOD_HTTPD='no' ersetzen
modconf save mod # nun ist mod.diff up-to-date
modsave flash # damit ist mod.diff im tffs
# oder
vi /mod/etc/conf/mod.cfg # -> MOD_HTTPD='yes' durch MOD_HTTPD='no' ersetzen
modsave # erzeugt alle diff Dateien neu und speichert ins tffs
Soviel zur Veranschaulichung. Komfortabler ist folgendes:
Code:
modconf set mod MOD_HTTPD=no
modconf save mod
modsave flash
# bzw.
modconf set mod MOD_HTTPD=no
modsave
6. Dokumentation
Ich möchte dann auch mal noch die wichtigsten Befehle mit Bedeutung auflisten und eine Dokumentation für jedes Paket beginnen, worin die Optionen des Webinterface detailliert beschrieben sind (aber auch ein paar Howtos, z.B. "Wie erstelle ich Benutzerkonten für den bftpd").
So, nun schießt mal los mit den Detailfragen zum Innenleben des Mods 
Mfg,
danisahne
)
Zitat von Massa
