thanks to vda

[Denys Vlasenko]

On Mon, Dec 6, 2010 at 12:09 PM, David Collier
<from_busybox_maillist at dexdyne.com> wrote:
>
> I thought I's explain why I'm blitzing this mailing list, or apologise,
> whichever seems most appropriate :-)
>
> I have read
>
> http://www.busybox.net/~vda/no_ifup.txt
>
> and as it happens we do things close to the way it is recommended
> already!
>
> That file hints at stuff which pretty much covers the scope of the task I
> have set myself, which is:
>
> optionally configure eth0 from dhcp, otherwise optionally run on
> user-fixed address or set interface quiescent. Run the dhcp forever and
> correctly handle any future changes of details, or NAKs to renewals.
>
> optionally run a PPP link over a gprs link, especially on units with no
> land-line. Deal with all the wonderful stuff that happens on such a
> connection like "gprs unavailable" status.
>
> optionally run a VPN, which should persistently use whatever route it can
> grab to connect to a fixed server.
>
> optionally run this lot in fail-over mode, so the WAN connection is used
> when present, but the GPRS takes over if it isn't, provided a GPRS link
> an be made. All the while monitoring the WAN, and switching back if it
> reappears.
>
> send SMS messages using the modem which runs GPRS, even if that has only
> one port, so involves temporarily taking the GPRS link up and down.
>
> ----------------------------------
> It brings up all sorts of interesting stuff like when you get a new dhcp
> lease, you must implement ip and mask NOW, but only set DNS and gateway
> if the current default route is over eth0, or that later becomes the
> default.
>
> what I'm not doing properly is semaphoring the process of changing
> routing tables etc - so there will be moments when a new dhcp lease DNS
> would get lost because the PPP s/w has just that moment decided it has
> just got a connection.... that's a job for later, see below.

busybox/examples/var_service needs a README, so let me try to create it:

In many cases, network configuration makes it necessary to run several daemons:
dhcp, zeroconf, ppp, openvpn and such. They need to be controlled,
and in many cases you also want to babysit them. runsvdir is a good
tool for this.
examples/var_service directory provides a few examples. It is meant to be used
this way: copy it somewhere (say, /var/service) and run something like

env - PATH=... <other vars=...> runsvdir /var/service &

from one of system startup scripts. (Google "man runsvdir" and "man runsv"
for more info about these tools).

Some existing examples:

var_service/dhcp_if -
controls a udhcpc instance which provides dhpc-assigned IP
address on interface named "if". Copy/rename this directory as needed to run
udhcpc on other interfaces (var_service/dhcp_if/run script uses _foo suffix
or the parent directory as interface name). When IP address is obtained or lost,
var_service/dhcp_if/dhcp_handler is run. It saves new config data to
/var/run/service/fw/dhcp_if.ipconf and (re)starts /var/service/fw service.

var_service/ifplugd_if -
watches link status of interface if. Downs and ups /var/service/dhcp_if
service accordingly. In effect, it allows you to
unplug/plug-to-different-network
and have your IP properly re-negotiated at once.

var_service/dhcp_if_pinger -
Uses var_service/dhcp_if's data (/var/service/dhcp_if/dhcp_if.out file)
to determine router IP. Pings it. If ping fails, restarts /var/service/dhcp_if
service. Basically, an example of watchdog service for networks
which are not reliable and need babysitting.

var_service/fw -
An *one-shot* service which reconfigures network based on current known state
of ALL interfaces. Uses conf/*.ipconf (static config) and
/var/run/service/fw/*.ipconf
(dynamic config from dhcp/ppp/vpn/etc) to determine what to do.
One-shot-ness of this service means that it shuts itself off after single run.

However, any dhcp/ppp/vpn or similar service can restart it anytime
when it senses the change in network configuration.
This even works while fw service runs: if dhcp signals fw to (re)start
while fw runs, fw will not stop after its execution, but will re-execute once,
picking up dhcp's new configuration.
(This is achieved very simply by having
# Make ourself one-shot
sv o .
at the very beginning of fw/run script, not at the end.
Therefore, any "sv u /var/run/service/fw" command by any other
script "undoes" o(ne-shot) command)

System administrators are expected to edit fw/run script, since
network configuration needs are likely to be very complex and different
for non-trivial installations.

-- 
vda