Subsections

8.7 Hochfahren, Herunterfahren, Einwählen und Auflegen unter fli4l

8.7.1 Bootkonzept

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.13 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/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.

8.7.2 Start- und Stopp-Skripte

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!

8.7.2.1 Start-Skripte in opt/etc/boot.d/

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.14

8.7.2.2 Start-Skripte in opt/etc/rc.d/

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:

  1. Es gilt folgende Namenskonvention:

        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-497 Server (DHCP, HTTPD, Proxy, etc.)
    498-499 reserviert (Aktivierung des Circuit-Systems)
    500-997 nach Belieben (ab hier können Skripte von Circuits kontrollierte Verbindungen nutzen und laufen möglicherweise parallel zu einer Einwahl)
    998-999 reserviert (bitte nicht benutzen!)

  2. In diesen Skripten müssen alle Funktionen, die das RootFS verändern, hinterlegt werden, etwa das Anlegen eines Verzeichnisses /var/log/lpd.

  3. In diesen Skripten dürfen keine Schreibzugriffe auf Dateien erfolgen, die Teil des Opt-Archivs sein können, da diese Dateien auf einem im Nur-Lese-Modus eingehängten Volume liegen können. Muss man eine solche Datei modifizieren, muss man sie vorher mit Hilfe der Funktion mk_writable (s.u.) beschreibbar machen. Durch den Aufruf der Funktion wird die Datei (wenn nötig) als beschreibbare Kopie im RootFS abgelegt. Ist die Datei bereits beschreibbar, bewirkt der mk_writable-Aufruf nichts.


    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.

  4. Diese Skripte müssen vor der Ausführung der eigentlichen Befehle prüfen, ob das dazugehörige OPT auch aktiv ist. Das ist normalerweise durch eine einfache Fallunterscheidung erledigt:

        if [ "$OPT_<OPT-Name>" = "yes" ]
        then
            ...
            # Hier OPT starten!
            ...
        fi
    

  5. Um die Fehlersuche zu erleichtern, sollten die Skripte mit begin_script und end_script geklammert werden:

        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.

  6. Den Skripten stehen alle Konfigurationsvariablen direkt zur Verfügung. Im Abschnitt "`Umgang mit Konfigurationsvariablen"' wird erklärt, wie man von anderen Skripten aus auf die Konfigurationsvariablen zugreifen kann.

  7. Der Pfad /opt darf auch nicht als Speicherplatz für Datenbestände der OPTs benutzt werden. Falls zusätzlicher Speicherplatz benötigt wird, sollte dem Benutzer über eine Konfigurationsvariable die Möglichkeit gegeben werden, einen geeigneten Pfad auszuwählen. Je nach Art der zu speichernden Daten (persistente oder transiente Daten) sind verschiedene Standard-Belegungen sinnvoll. So bieten sich für transiente Daten etwa Pfade unterhalb von /var/run/ an; für persistente Daten sollte die Funktion map2persistent in Kombination mit einer geeigneten Konfigurationsvariable verwendet werden.

8.7.2.3 Stopp-Skripte in opt/etc/rc0.d/

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.

8.7.3 Hilfsfunktionen

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.

8.7.3.1 Skript-Steuerung

begin_script <Symbol> <Meldung>:
Gibt eine Meldung aus und aktiviert die Fehlersuche im Skript mittels set -x, falls <Symbol>_DO_DEBUG auf "`yes"' steht.

end_script:
Gibt eine Abschluss-Meldung aus und deaktiviert die Fehlersuche, falls sie mit begin_script aktiviert wurde. Für jeden begin_script-Aufruf muss es einen zugehörigen end_script-Aufruf geben (und umgekehrt).

8.7.3.2 Laden von Kernel-Modulen

do_modprobe [-q] <Modul> <Parameter>*:
Lädt ein Kernel-Modul inkl. eventueller Parameter bei gleichzeitiger Auflösung der Modulabhängigkeiten. Der Parameter "`-q"' verhindert, dass im Fehlerfall eine Meldung auf der Konsole ausgegeben und ins Boot-Protokoll geschrieben wird. Die Funktion liefert im Erfolgsfall den Rückgabewert null zurück und im Fehlerfall einen Wert ungleich null. Damit lässt sich Code schreiben, der ein Fehlschlagen des Ladens eines Kernel-Moduls geeignet behandelt:

    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

do_modrobe_if_exists [-q] <Modulpfad> <Modul> <Parameter>*:

Prüft, ob das Modul /lib/modules/<Kernel-Version>/<Modulpfad>/<Modul> existiert und ruft bei Vorhandensein die Funktion do_modprobe auf.


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.

8.7.3.3 Meldungen und Fehlerbehandlung

log_info <Meldung>:
Schreibt eine Meldung auf die Konsole und nach /bootmsg.txt. Wird keine Meldung als Parameter übergeben, liest log_info von der Standard-Eingabe. Die Funktion liefert als Rückgabewert immer null zurück.

log_warn <Meldung>:
Schreibt eine Warnmeldung auf die Konsole und nach /bootmsg.txt, wobei vor die Meldung die Zeichenkette WARN: gesetzt wird. Wird keine Meldung als Parameter übergeben, liest log_warn von der Standard-Eingabe. Die Funktion liefert als Rückgabewert immer null zurück.

log_error <Meldung>:
Schreibt eine Fehlermeldung auf die Konsole und nach /bootmsg.txt, wobei vor die Meldung die Zeichenkette ERR: gesetzt wird. Wird keine Meldung als Parameter übergeben, liest log_error von der Standard-Eingabe. Die Funktion liefert als Rückgabewert immer einen Wert ungleich null zurück.

set_error <Meldung>:
Gibt die Fehlermeldung aus und setzt eine interne Fehlervariable, das später via is_error geprüft werden kann.

is_error:
Setzt die interne Fehlervariable zurück und liefert wahr zurück, falls sie vorher durch set_error gesetzt wurde.

8.7.3.4 Netzwerk-Funktionen

translate_ip_net <Wert> <Variablenname> [<Ergebnisvariable>]:
Ersetzt symbolische Referenzen in Parametern. Momentan finden folgende Übersetzungen statt:
Host- oder Netzwerk-Adressen
werden nicht übersetzt
any
wird durch 0.0.0.0/0 ersetzt
dynamic
wird durch die dynamische IPv4-Adresse des Routers ersetzt; das ist die IPv4-Adresse, die der Router beim Einwählen über einen Circuit mit einer Default-Route zugewiesen bekommt
IP_NET_x
wird durch das in der Konfiguration stehende Netzwerk ersetzt; referenziert die Variable einen Circuit, so wird das dem Circuit zugewiesene IPv4-Netz zurückgegeben
IP_NET_x_IPADDR
wird durch die in der Konfiguration stehende IP-Adresse ersetzt; referenziert die Variable einen Circuit, so wird die dem Circuit zugewiesene IPv4-Adresse zurückgegeben
IP_ROUTE_x
wird durch das in der Konfiguration stehende geroutete Netzwerk ersetzt
@<Hostname>
wird durch die in der Konfiguration für den angegeben Host spezifizierte IP-Adresse ersetzt
{<circuit>}
wird durch das dem Circuit zugewiesene IPv4-Netz ersetzt

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.

8.7.3.5 Diverses

mk_writable <Datei>:
Stellt sicher, dass die übergebene Datei beschreibbar ist. Befindet sich die Datei auf einem im Nur-Lese-Modus eingehängten Volume und ist lediglich über eine symbolische Verknüpfung ins Dateisystem eingebunden, wird eine lokale Kopie angelegt, die dann beschreibbar ist.

list_unique <Liste>:
Entfernt Duplikate aus der übergebenen Liste. Das Resultat wird in die Standard-Ausgabe geschrieben.

8.7.4 mdev-Regeln

Für OPTs ist es möglich, zusätzliche mdev-Regeln zu etablieren, die spezielle Aktionen beim Erscheinen oder Verschwinden bestimmter Geräte vornehmen. Das OPT_AUTOMOUNT im hd-Paket verwendet beispielsweise eine solche Regel, um auftauchende Speichermedien automatisch einzuhängen. Will man eine zusätzliche mdev-Regel integrieren, muss man ein Skript der Form

    /etc/mdev.d/mdev<Nummer>.<Name>

ins RootFS einbauen, wobei die Nummer ähnlich den Start- und Stopp-Skripten aus drei Ziffern bestehen muss und der Name beliebig gewählt werden kann. Innerhalb dieses Skriptes werden sämtliche Ausgaben an die Standardausgabe in die resultierende /etc/mdev.conf integriert. Ein Beispiel aus dem oben erwähnten OPT_AUTOMOUNT:

#!/bin/sh
#----------------------------------------------------------------------------
# /etc/mdev.d/mdev500.automount - mdev HD automounting rules     __FLI4LVER__
#
#
# Last Update:  $Id: dev_main_boot_dial.tex 51959 2018-03-11 22:18:24Z kristov $
#----------------------------------------------------------------------------

cat <<"EOF"
#
# mdev500.automount
#

-SUBSYSTEM=block;DEVTYPE=partition;.+       0:0 660 */lib/mdev/automount

EOF

Zu der Syntax der Regeln sei auf den Dateikopf der /etc/mdev.conf sowie auf die mdev-Dokumentation unter http://git.busybox.net/busybox/plain/docs/mdev.txt verwiesen. Falls eine Regel ein Skript aufruft (wie /lib/mdev/automount im obigen Beispiel), dann hat es Zugriff auf alle Variablen des auslösenden Kernel-``uevent''s, insbesondere auf:

Beispiele für Kernel-Subsysteme:

block
Blockgeräte (Speichermedien) wie sda (erste Festplatte), sr0 (erstes CD-Laufwerk) oder ram1 (zweite RAM-Disk)
input
Geräte für Eingaben von Tastatur, Maus etc. wie input/event0; welche Gerätedateien welchen Geräten zugeordnet sind, ist nicht festgelegt und muss im sysfs ermittelt werden
mem
Geräte zum Zugriff auf den Speicher und Hardware-Ports wie mem und ports; hier fallen auch Pseudo-Geräte wie zero (liefert ununterbrochen das ASCII-Zeichen mit Wert null) und null (liefert nichts, verschluckt alles) darunter
sound
diverse Geräte für die Tonausgabe, Benennung uneinheitlich
tty
Geräte zum Zugriff auf physische und virtuelle Konsolen wie tty1 (erste virtuelle Konsole) oder ttyS0 (erste serielle Konsole)

Ein Beispiel für die ersten beiden seriellen Schnittstellen:

mdev[42]: 30.050644 add@/devices/pnp0/00:04/tty/ttyS0
mdev[42]:   ACTION=add
mdev[42]:   DEVPATH=/devices/pnp0/00:04/tty/ttyS0
mdev[42]:   SUBSYSTEM=tty
mdev[42]:   MAJOR=4
mdev[42]:   MINOR=64
mdev[42]:   DEVNAME=ttyS0
mdev[42]:   SEQNUM=613

mdev[42]: 30.051477 add@/devices/platform/serial8250/tty/ttyS1
mdev[42]:   ACTION=add
mdev[42]:   DEVPATH=/devices/platform/serial8250/tty/ttyS1
mdev[42]:   SUBSYSTEM=tty
mdev[42]:   MAJOR=4
mdev[42]:   MINOR=65
mdev[42]:   DEVNAME=ttyS1
mdev[42]:   SEQNUM=614

Ein Beispiel für eine angeschlossene MF II-Tastatur:

mdev[41]: 4.030653 add@/devices/platform/i8042/serio0/input/input0
mdev[41]:   ACTION=add
mdev[41]:   DEVPATH=/devices/platform/i8042/serio0/input/input0
mdev[41]:   SUBSYSTEM=input
mdev[41]:   PRODUCT=11/1/1/ab41
mdev[41]:   NAME="AT Translated Set 2 keyboard"
mdev[41]:   PHYS="isa0060/serio0/input0"
mdev[41]:   PROP=0
mdev[41]:   EV=120013
mdev[41]:   KEY=4 2000000 3803078 f800d001 feffffdf ffefffff ffffffff fffffffe
mdev[41]:   MSC=10
mdev[41]:   LED=7
mdev[41]:   MODALIAS=input:b0011v0001p0001eAB41-e0,1,4,11,14,k71,72,73,74,75,76,77,79,
7A,7B,7C,7D,7E,7F,80,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,D9,E2,ram4,l0,
1,2,sfw
mdev[41]:   SEQNUM=604

Ein Beispiel für ein geladenes USB-Kernelmodul (uhci_hcd):

mdev[41]: 6.537506 add@/module/uhci_hcd
mdev[41]:   ACTION=add
mdev[41]:   DEVPATH=/module/uhci_hcd
mdev[41]:   SUBSYSTEM=module
mdev[41]:   SEQNUM=633

Ein Beispiel für eine angeschlossene Festplatte:

mdev[41]: 7.267527 add@/devices/pci0000:00/0000:00:07.1/ata1/host0/target0:0:0/0:0:0:0/block/sda
mdev[41]:   ACTION=add
mdev[41]:   DEVPATH=/devices/pci0000:00/0000:00:07.1/ata1/host0/target0:0:0/0:0:0:0/block/sda
mdev[41]:   SUBSYSTEM=block
mdev[41]:   MAJOR=8
mdev[41]:   MINOR=0
mdev[41]:   DEVNAME=sda
mdev[41]:   DEVTYPE=disk
mdev[41]:   SEQNUM=688

Dies ist eine ATA/IDE-Festplatte (ata1), die über den Gerätenamen sda angesprochen werden sollte.

Ein Beispiel für ein entferntes Blockgerät (die Zuordnung einer Image-Datei zu einer fli4l-VM wurde via virsh detach-device gelöst):

mdev[42]: 52.600646 remove@/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb/vdb1
mdev[42]:   ACTION=remove
mdev[42]:   DEVPATH=/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb/vdb1
mdev[42]:   SUBSYSTEM=block
mdev[42]:   MAJOR=254
mdev[42]:   MINOR=17
mdev[42]:   DEVNAME=vdb1
mdev[42]:   DEVTYPE=partition
mdev[42]:   SEQNUM=776

mdev[42]: 52.644642 remove@/devices/virtual/bdi/254:16
mdev[42]:   ACTION=remove
mdev[42]:   DEVPATH=/devices/virtual/bdi/254:16
mdev[42]:   SUBSYSTEM=bdi
mdev[42]:   SEQNUM=777

mdev[42]: 52.644718 remove@/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb
mdev[42]:   ACTION=remove
mdev[42]:   DEVPATH=/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb
mdev[42]:   SUBSYSTEM=block
mdev[42]:   MAJOR=254
mdev[42]:   MINOR=16
mdev[42]:   DEVNAME=vdb
mdev[42]:   DEVTYPE=disk
mdev[42]:   SEQNUM=778

mdev[42]: 52.644777 remove@/devices/pci0000:00/0000:00:0a.0/virtio5
mdev[42]:   ACTION=remove
mdev[42]:   DEVPATH=/devices/pci0000:00/0000:00:0a.0/virtio5
mdev[42]:   SUBSYSTEM=virtio
mdev[42]:   MODALIAS=virtio:d00000002v00001AF4
mdev[42]:   SEQNUM=779

mdev[42]: 52.644973 remove@/devices/pci0000:00/0000:00:0a.0
mdev[42]:   ACTION=remove
mdev[42]:   DEVPATH=/devices/pci0000:00/0000:00:0a.0
mdev[42]:   SUBSYSTEM=pci
mdev[42]:   PCI_CLASS=10000
mdev[42]:   PCI_ID=1AF4:1001
mdev[42]:   PCI_SUBSYS_ID=1AF4:0002
mdev[42]:   PCI_SLOT_NAME=0000:00:0a.0
mdev[42]:   MODALIAS=pci:v00001AF4d00001001sv00001AF4sd00000002bc01sc00i00
mdev[42]:   SEQNUM=780

Wie man sehen kann, sind bei einer solchen Entfernung diverse Kernel-Subsysteme involviert (hier block, bdi, virtio und pci).

8.7.5 ttyI-Geräte

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

8.7.6 Skripte beim Einwählen und Auflegen

8.7.6.1 Allgemeines

Nach dem Herstellen bzw. Trennen einer Circuit-Verbindung 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!

8.7.6.2 Variablen

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)

8.7.6.3 Default-Route

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.



Footnotes

... Diskette8.13
Ursprünglich konnte fli4l auch von einer Diskette betrieben werden. Da fli4l inzwischen dafür zu groß geworden ist, wird dies nicht mehr unterstützt.
... steht.8.14
Normalerweise sind diese beiden Dateien identisch. Eine Abweichung entsteht nur, wenn die Konfigurationsdatei auf dem Boot-Volume händisch editiert wird, etwa um die Konfiguration nachträglich abzuändern, ohne die fli4l-Archive neu zu bauen.
© 2001-2022 Das fli4l-Team - August 12, 2022