Use case: VPN client

[Marcus Better]

martin f krafft wrote:
> Fair enough, although I think this might be a job for the VPN
> client?

Yes, maybe. OpenSwan 3.x is supposed to get some functionality in this 
direction - dynamically discovering that interfaces go up and down etc. But I 
don't know if it will have the logic to decide if a connection should be 
brought up. That should be checked...

> I want to solve this with dependencies. vpn0 pre-depends on
> a default gateway, so try to configure network interfaces in
> a defined order until you get a connection.

An IPsec connection in Linux 2.6 is not a separate network interface (like it 
was in 2.4, or with the KLIPS module). But I guess it could be a virtual 
interface.

I'm not sure the dependency approach is optimal here though. For this to work, 
there has to be a decision to start the vpn0 "interface". In other words 
there must be an ultimate goal which starts a dependency resolution chain. 
This is not how it works in reality. A user should just plug in the network 
card, or move into a WiFi zone, and automatically the interface is brought 
up, wpa_supplicant does its thing, we get an IP address and some routes with 
DHCP, and finally the VPN connection is started. Or a local file server is 
launched etc.

Note that there is no probing of network interfaces in some order. Such an 
order may be hard to define ahead of time, since the list of possible network 
interfaces is not known. You should be able to plug in a completely new 
network card.

It may be instructive to read the comparison between Upstart and Initng [1] in 
this context.

> So upstart can run scripts when it receives events but it has no
> knowledge (yet) of network events?

Yes. For instance I have the following files (from upstathat wire ifupdown to 
upstart:

================
~$ cat /etc/network/if-up.d/upstart
#!/bin/sh

exec /sbin/initctl emit interface-up $IFACE

~$ cat /etc/network/if-down.d/upstart
#!/bin/sh

exec /sbin/initctl emit interface-down $IFACE
================

Then I have a script /etc/event.d/check-local-network which gets started on 
the interface-up event. It does some checks to see which network I'm 
connected to, and emits further "home-lan-connected", "office-lan-connected" 
and "inet-connected" events. Other scripts can trigger on those events. For 
instance "inet-connected" would start an IPsec tunnel unless we are between 
the "office-lan-connected" and "office-lan-disconnected" events.

(The latter rather complex specification seems not to be implemented in 
upstart yet, so I have a temporary hack with the same effect. It seems to 
work well in principle.)

> What exactly does upstart provide that you think would be stupid to
> reimplement?

*Event handling: which jobs are triggered by an event.
*Job state management: keep track of which jobs (services) are running.
*Specification of complex conditions for a job to be started, such as this 
[2]: "Or maybe we only want to be run if a network interface comes up before 
bind9 has been started:
  on network-interface-up and from startup until started bind9"

(All of this assumes that we want an event-based mechanism.)

Marcus

[1] http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe
[2] http://www.netsplit.com/blog/articles/2006/12/14/upstart-0-3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20070509/e0c43e68/attachment-0001.pgp