Weiter: 8.8 Paket "`template"' Hoch: 8. Entwickler-Dokumentation Zurück: 8.6 CGI-Erstellung für das
fli4l 2.0 sollte eine saubere Installation auf eine Festplatte oder ein CompactFlash(TM)-Medium bieten, aber auch eine Installation auf ein Zip-Medium oder die Erstellung einer bootfähigen CD-ROM sollte möglich sein. Zusätzlich sollte die Festplattenversion sich nicht grundlegend von einer Installation auf Diskette8.10 unterscheiden.
Diese Anforderungen wurden realisiert, indem die Dateien des opt.img-Archivs aus der bisherigen RAM-Disk auf eine anderes Medium verlagert werden können. Dies kann eine Partition auf einer Festplatte bzw. einem CF-Medium sein. Dieses zweite Volume wird unter /opt eingehängt, und dort liegende Programme werden nur noch über symbolische Links in das RootFS integriert. Das entstehende Layout im RootFS-Dateisystem entspricht dann dem im opt-Verzeichnis der ausgepackten fli4l-Distribution mit einer Ausnahme - das files-Präfix entfällt. Die Datei opt/etc/rc ist dann also direkt unter /etc/rc zu finden, opt/files/bin/busybox unter /bin/busybox. Dass diese Dateien unter Umständen nur symbolische Verknüpfungen auf ein im Nur-Lese-Modus eingehängtes Volume sind, kann man ignorieren, solange man die Dateien nicht modifizieren möchte. Will man dies tun, muss man die Dateien vorher mit mk_writable (s.u.) schreibbar machen.
Skripte, die beim Hochfahren des Systems ausgeführt werden sollen, befinden sich in den Verzeichnissen opt/etc/boot.d/ und opt/etc/rc.d/ und werden auch in dieser Reihenfolge ausgeführt. Des Weiteren befinden sich in opt/etc/rc0.d/ Skripte, die beim Herunterfahren des Systems ausgefühlt werden.
Wichtig: Da zum Ausführen dieser Skripte kein separater Prozess
erzeugt wird, dürfen sie nicht mit "`exit"' abgeschlossen
werden. Ein solcher Befehl führt zum vorzeitigen Abbruch des Bootvorgangs!
Skripte, die in diesem Verzeichnis liegen, werden als erstes ausgeführt. Ihre Aufgabe ist es, das Boot-Volume einzuhängen, die auf dem Boot-Medium liegende Konfigurationsdatei rc.cfg einzulesen und das Opt-Archiv zu entpacken. Je nach Boot-Typ sind diese Skripte mehr oder weniger kompliziert und tun die folgenden Dinge:
Damit die Skripte überhaupt eine Chance haben, etwas über die fli4l-Konfiguration zu erfahren, wird die Konfigurationsdatei auch ins RootFS-Archiv unter /etc/rc.cfg eingebunden; die Konfigurationsvariablen in dieser Datei stehen den Start-Skripten in opt/etc/boot.d/ direkt zur Verfügung. Nach dem Einhängen des Boot-Volumes wird die /etc/rc.cfg durch die Konfigurationsdatei vom Boot-Volume ersetzt, so dass den Start-Skripten in opt/etc/rc.d/ (s.u.) die aktuelle Konfiguration vom Boot-Volume zur Verfügung steht. 8.11
Befehle, die immer beim Starten des Routers ausgeführt werden müssen, können in Skripten im Verzeichnis opt/etc/rc.d/ abgelegt werden. Hierbei gelten folgende Konventionen:
rc<dreistellige Zahl>.<Name des OPTs>
Die Skripte werden in aufsteigender Reihenfolge der Zahlen gestartet. Ist mehreren Skripten dieselbe Zahl zugeordnet, entscheidet die alphabetische Sortierung nach dem Punkt. Falls der Start eines Pakets erst nach einem anderen erfolgen darf, wird das durch die Zahl festgelegt.
Hier eine ungefähre Richtlinie, welche Nummern für welche Aufgaben verwendet werden sollten:
| Nummer | Aufgabe |
| 000-099 | Grundsystem (Hardware, Zeitzone, Dateisystem) |
| 100-199 | Kernel-Module (Treiber) |
| 200-299 | externe Verbindungen (PPPoE, ISDN4Linux, PPtP) |
| 300-399 | Netzwerk (Routing, Interfaces, Paketfilter) |
| 400-499 | Server (DHCP, HTTPD, Proxy, etc.) |
| 500-900 | beliebig |
| 900-997 | Alles, was eine Einwahl hervorrufen könnte |
| 998-999 | reserviert (bitte nicht benutzen!) |
Wichtig: mk_writable muss direkt auf Dateien im RootFS angewandt
werden, nicht über den Umweg des opt-Verzeichnisses. Will man
also /usr/local/bin/foo modifizieren, ruft man
mk_writable mit dem Argument /usr/local/bin/foo auf.
if [ "$OPT_<OPT-Name>" = "yes" ]
then
...
# Hier OPT starten!
...
fi
if [ "$OPT_<OPT-Name>" = "yes" ]
then
begin_script FOO "configuring foo ..."
...
end_script
fi
Die Fehlersuche einzelner Start-Skripte kann man dann einfach via
FOO_DO_DEBUG='yes' aktivieren.
Jeder Rechner muss mal heruntergefahren oder neu gestartet werden. Nun kann es vorkommen, dass man Vorgänge ausführen muss, bevor der Rechner heruntergefahren oder neu gestartet wird. Zum Herunterfahren und Neustarten sind die Befehle "`halt"' bzw. "`reboot"' zuständig. Diese Befehle werden auch aufgerufen, wenn man im IMONC oder in der Web-GUI auf die entsprechenden Schaltflächen klickt.
Alle Stopp-Skripte liegen im Verzeichnis opt/etc/rc0.d/. Ihre Dateinamen werden analog zu den Start-Skripten gebildet. Sie werden ebenfalls in aufsteigender Reihenfolge der Zahlen ausgeführt.
In /etc/boot.d/base-helper werden verschiedene Funktionen bereitgestellt, die von den Start- und anderen Skripten verwendet werden können. Das betrifft Dinge wie Unterstützung zur Fehlersuche, Laden von Kernel-Modulen oder Ausgabe von Meldungen. Die einzelnen Funktionen werden im Folgenden aufgelistet und kurz beschrieben.
if do_modprobe -q acpi-cpufreq
then
# kein CPU-Frequenzsteuerung via ACPI
log_error "CPU-Frequenzsteuerung via ACPI nicht verfügbar!"
# [...]
else
log_info "CPU-Frequenzsteuerung via ACPI aktiviert."
# [...]
fi
Wichtig: Das Modul muss tatsächlich unter dem angegebenen Modulnamen existieren,
der Modulname darf kein Alias sein. Bei einem Alias wird direkt
do_modprobe aufgerufen.
Das Ergebnis der Übersetzung wird in der Variable gespeichert, deren Name im dritten Parameter übergeben wird; fehlt dieser Parameter, wird das Ergebnis in der Variable res gespeichert. Der Variablenname, der im zweiten Parameter übergeben wird, wird nur für Fehlermeldungen benutzt, falls die Übersetzung fehlschlägt; hier kann also vom Aufrufer die Quelle des zu übersetzenden Wertes angegeben werden. Im Fehlerfall wird dann eine Meldung wie
Unable to translate value '<Wert>' contained in <Variablenname>.
ausgegeben.
Der Rückgabewert ist null, falls die Übersetzung erfolgreich war, und ungleich null, falls ein Fehler aufgetreten ist.
Für die ttyI-Geräte (/dev/ttyI0 .../dev/ttyI15), über welche die "`Modem-Emulation"' der ISDN-Karte genutzt werden kann, existiert ein Zähler, um Konflikte zwischen verschiedenen Paketen, die diese Geräte nutzen, zu vermeiden. Hierzu wird beim Start des Routers die Datei /var/run/next_ttyI angelegt, die von den verschiedenen OPTs abgefragt und fortgezählt werden kann. Mit dem folgenden Beispielskript kann dieser Wert abgefragt, um eins erhöht und wieder für das nächste OPT exportiert werden.
ttydev_error=
ttydev=$(cat /var/run/next_ttyI)
if [ $ttydev -le 16 ]
then # ttyI device available? yes
ttydev=$((ttydev + 1)) # ttyI device + 1
echo $ttydev >/var/run/next_ttyI # save it
else # ttyI device available? no
log_error "No ttyI device for <Name deines OPTs> available!"
ttydev_error=true # set error for later use
fi
if [ -z "$ttydev_error" ] # start OPT only if next tty device
then # was available to minimize error
... # messages and minimize the
# risk of uncomplete boot
fi
Nach dem Herstellen bzw. Trennen einer Wählverbindung werden die Skripte in /etc/ppp/ abgearbeitet. Hier können OPTs Aktionen hinterlegen, die nach dem Herstellen bzw. Auflegen der Verbindung nötig sind. Benannt werden die Dateien wie folgt:
| ip-up<dreistellige Zahl>.<OPT-Name> |
| ip-down<dreistellige Zahl>.<OPT-Name> |
Dabei werden die ip-up-Skripte nach dem Aufbau und die ip-down-Skripte nach dem Abbau der Verbindung ausgeführt.
Wichtig: In den ip-down-Skripten dürfen keine Aktionen ausgeführt
werden, die zu einer erneuten Einwahl führen, da dadurch nur ein
Dauer-Online-Zustand erreicht wird, was für Nicht-Flatrate-Benutzer
ein teures Unterfangen ist.
Wichtig: Da für die einzelnen Skripte kein eigener Prozess erzeugt wird, dürfen
auch diese Skripte nicht mit "`exit"' abgeschlossen werden!
Hinweis: Wenn ein Skript prüfen will, ob überhaupt die ip-up-Skripte ausgeführt werden, kann es ab rc400 die Variable ip_up_events prüfen. Steht diese auf "`yes"', gibt es Wählverbindungen, und die ip-up-Skripte werden ausgeführt. Steht diese auf "`no"', sind keine Wählverbindungen konfiguriert, und es werden keine ip-up-Skripte ausgeführt. Von dieser Regel gibt es eine Ausnahme: Wenn ein reiner Ethernet-Router ohne Wählverbindungen konfiguriert wurde, aber eine Default-Route (0.0.0.0/0) existiert, so werden am Ende des Boot-Vorgangs die ip-up-Skripte genau einmal ausgeführt. (Analog werden vor dem Herunterfahren einmalig die ip-down-Skripte ausgeführt.)
Durch das spezielle Aufrufkonzept stehen die folgenden Variablen den ip-up- und ip-down-Skripten zur Verfügung:
| real_interface | die aktuelle Schnittstelle, also z.B. ppp0, ippp0, ... |
| interface | das IMOND-Interface, also pppoe, ippp0, ... |
| tty | verbundenes Terminal, möglicherweise leer! |
| speed | die Verbindunggeschwindigkeit, bei ISDN z.B. 64000 |
| local | die eigene IP-Adresse |
| remote | die IP-Adresse des Point-To-Point-Partners |
| is_default_route | gibt an, ob das aktuelle ip-up/ip-down für die Schnittstelle durchgeführt wird, über welche die Default-Route geht (kann "`yes"' oder "`no"' sein) |
Seit Version 2.1.0 werden die ip-up/ip-down-Skripte nicht nur für die Schnittstelle ausgeführt, über welche die Default-Route geht, sondern für alle Verbindungen, welche die ip-up- und ip-down-Skripte aufrufen. Um das alte Verhalten zu simulieren, muss in ip-up- und ip-down-Skripten die folgende Abfrage eingefügt werden:
# is a default-route-interface going up?
if [ "$is_default_route" = "yes" ]
then
# die eigentlichen Aktionen
fi
Natürlich darf das neue Verhalten auch für spezielle Aktionen ausgenutzt werden.