Next: 8.8 Package ``template"' Up: 8. Documentation for Developers Previous: 8.6 CGI-Creation for Package
FLI4L 2.0 should offer a clean install on a hard disk or a CompactFlash (TM) media, but also an installation on a Zip medium or the creation of a bootable CD-ROM should be possible. In addition, the hard drive version should not be fundamentally different from the one on an installation disk8.10.
These requirements have been implemented by making it possible to move the files of the opt.img archive from the previous RAM disk to another medium, be it a partition on a hard disk or a CF medium. This second volume is mounted to /opt and only symbolic links are created from there to the rootfs. The resulting layout in the root file system then corresponds to the one unpacked in the opt directory of the fli4l distribution with one exception - the files prefix is not applicable. The file opt/etc/rc is then found directly under /etc/rc, opt/files/bin/busybox under /bin/busybox. It can be ignored that these files may be only links to a directory mounted read only as long as you do not want to modify them. If you want to do this, you have to make the files writable before by using mk_writable (see below).
Scripts intended to be executed on system boot are located in the directories opt/etc/boot.d/ and opt/etc/rc.d/ and will also get executed in this sequence. Furthermore, scripts executed on shutdown are to be found in opt/etc/rc0.d/.
Important: These script must not contain an ``exit'', because no separate
process is created for their execution. This command would lead to a premature
ending of the boot process!
Scripts located in this directory are executed at first. They mount the boot volume, parse the config file rc.cfg located on the boot medium and unpack the opt archive. Depending on the boot type these scripts are more or less complex and do the following things:
To make the scripts aware of the fli4l configuration, the configuration file /etc/rc.cfg is also integrated in the Rootfs archive. The configuration variables in this file are parsed by the start scripts in opt/etc/boot.d/. After mounting the boot volume /etc/rc.cfg is replaced by the configuration file there, so that the the current configuration of the boot volume is available for startup scripts in opt/etc/rc.d/ (see below). 8.11
Commands that are executed at every start of the router can be stored in the directory opt/etc/rc.d/. The following conventions apply:
rc<three-digit number>.<Name of the OPT>
The scripts are started in ascending order of the numbers. If multiple scripts have the same number assigned, they will be sorted alphabetically at that point. In case that the start of a package is dependant on another one, this is the determined by the number.
Here's a general outline which numbers should be used for which tasks:
| Number | Task |
| 000-099 | Base system (hardware, time zone, file system) |
| 100-199 | Kernel modules (drivers) |
| 200-299 | External connections (PPPoE, ISDN4Linux, PPtP) |
| 300-399 | Network (Routing, Interfaces, Packet filter) |
| 400-499 | Server (DHCP, HTTPD, Proxy, a.s.o.) |
| 500-900 | Any |
| 900-997 | Anything causing a dialin |
| 998-999 | reserved (please do not use!) |
Important: mk_writable has to be applied directly to files in RootFS,
not indirectly via the opt directory. If, for example, you want to
modify /usr/local/bin/foo, the function mk_writable has to be called
with the argument /usr/local/bin/foo.
if [ "$OPT_<OPT-Name>" = "yes" ]
then
...
# Start OPT here!
...
fi
if [ "$OPT_<OPT-Name>" = "yes" ]
then
begin_script FOO "configuring foo ..."
...
end_script
fi
Debugging of start-scripts may be activated simply via
FOO_DO_DEBUG='yes'.
Each machine must be shut down or restarted from time to time. It is perfectly possible that you have to perform operations before the computer is shut down or restarted. To shut down and restart the commands ``halt'' or ``reboot'' are used. These commands are also invoked when the corresponding buttons in IMONC or the Web GUI are clicked.
All stop scripts can be found in the opt/etc/rc0.d/. The file names have to be created using the same rules as for the scripts. They are as well executed in ascending order of numbers.
/etc/boot.d/base-helper provides a number of different functions that can be used in Start- and other scripts. They contian support for debugging, loading of kernel modules, or message output. The functions are listed and explained in short below
if do_modprobe -q acpi-cpufreq
then
# no CPU frequency scaling via ACPI
log_error "CPU frequency scaling via ACPI not available!"
# [...]
else
log_info "CPU frequency scaling via ACPI activated."
# [...]
fi
Important: The module has to exist exactly by this name, no aliases may be used.
When using an alias do_modprobe will be called immediately.
The result of the translation is stored in the variable whose name is passed in the third parameter, if this parameter is missing, the result is stored in the variable res. The variable name that is passed in the second parameter is used only for error messages if the translation fails, to enable the caller to pass the source of the value to be translated. In case of failure a message like
Unable to translate value '<Value>' contained in <Variable name>.
will be printed.
The return value is 0 in case of success, and unequal to zero in case of errors.
For ttyI devices (/dev/ttyI0 .../dev/ttyI15) used by the ``modem emulation'' of the ISDN card a counter exists to avoid conflicts between multiple packages using these devices. For this purpose the file /var/run/next_ttyI is created on router start which can be queried and incremented by the OPTs. The following example script can query this value, increment it by one and export it again for the next OPT.
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 of your OPT> 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
After dialin resp. hangup of a dial-up connection the scripts placed in /etc/ppp/ are executed. OPTs may store actions here that have to be executed after connecting resp. hanging up of a connection. The name scheme for the files is as follows:
| ip-up<three-digit number>.<OPT-Name> |
| ip-down<three-digit number>.<OPT-Name> |
ip-up scripts will be excuted after establishing and ip-down scripts after hangig up of the connection.
Important: In ip-down scripts no actions may be taken that lead
to another dialin because this would create a permanent-online condition
not desired for users without a flatrate.
Important: Since no separate process is created for these scripts, they may
not invoke ``exit'' as well!
Hint: If a script wants to check for ip-up scripts being executed the variable ip_up_events may be sourced from rc400 and up. If it is set to ``yes'' dialup-connections exist and ip-up scripts will be executed. No dialup-connections are configured if it is set to ``no'' and ip-up scripts will not get executed. There is an exeception to this rule: If an Ethernet router is configured without dialup-connections but a default-Route (0.0.0.0/0) exists, ip-up scripts will get executed only once at the end of the boot process. (And as well the ip-down scripts on rooter shutdown.)
Due to the special call concept of the ip-up and ip-down scripts the following variables apply:
| real_interface | the real interface, ie. ppp0, ippp0, ... |
| interface | the IMOND interface, ie. pppoe, ippp0, ... |
| tty | terminal connected, may be empty! |
| speed | connection speed, for ISDN ie. 64000 |
| local | own IP address |
| remote | IP address of the Point-To-Point partner |
| is_default_route | specifies if the current ip-up/ip-down is for the interface of the default route (may be ``yes'' or ``no'') |
As of version 2.1.0 ip-up/ip-down scripts are executed for all connections, not only for the interface of the default route. To emulate the old behaviour you have to include the following in ip-up and ip-down scripts:
# is a default-route-interface going up?
if [ "$is_default_route" = "yes" ]
then
# actions to be taken
fi
Of course, the new behaviour can also be used for specific actions.