Use case: VPN client

[Marcus Better]

martin f krafft wrote:
> The way I see it is *not* that the system automatically links up to
> the net whenever it can. Rather, netconfd gets notified about new
> devices and link changes and then observes policy.

Agreed, it should be up to policy. The policy should be configurable per 
interface, like with ifupdown. Additionally we need a "default" policy for 
other unspecified, or new, interfaces.

> Agreed. But if netconfd needs to establish a link and there's
> a carrier to a link-local net on eth0, an encrypted and thus
> inaccessible wlan network close by, and ppp0 linked to the GSM
> modem, what does it do? What if the wlan network is open but of crap
> quality?

In the event-based scenario it should work: The link-local net would not be 
considered, since the VPN gateway cannot be reached through it. The 
inaccessible encrypted network would not be considered, since it would never 
reach an "up" (operational) state. Bringing up the ppp0 connection would 
create a default route, and that would trigger the VPN connection. (I don't 
know what should happen if we subsequently plug in a cable and get a nicer 
connection. It's a corner case.)

In the dependency case, when the user requests the VPN connection, it would 
check if the VPN server is reachable. It would find that there is a route 
through ppp0 and use that.

> > ================
> > ~$ cat /etc/network/if-up.d/upstart
> > #!/bin/sh
> >
> > exec /sbin/initctl emit interface-up $IFACE
>
> This is nice, but is it necessary? Why do you let hooks notify
> upstart to run scripts, instead of running the scripts directly from
> if-up.d?

I can use of upstart's event and job handling. Let's say upstart determines 
that OpenSwan should be started. It will keep track of the state of the 
OpenSwan process for me. Upstart will not try to start OpenSwan again while 
it is running if a second "up" event arrives. Otherwise I would have to write 
code to check if it's running, and every daemon does that differently (and 
often unreliably). Plus, if the daemon dies, upstart will (can) restart it 
automatically.

This uniform handling of jobs is a very attractive feature in upstart. Another 
example is that it can easily replace all those run.d directories which are 
scattered everywhere, which all have slightly different, sometimes 
undocumented, semantics: execution order, special handling of files with .sh 
extension, ways of passing parameters... All that makes it a headache to 
write scripts for various subsystems.

Now consider the situation where there are several events, or circumstances, 
that can cause a particular job to be started, let's say OpenSwan. With the 
traditional approach I would probably have commands to start OpenSwan in a 
bunch of different places. Now I decide that I would like to run some extra 
command just after OpenSwan starts - for instance change some firewall rules. 
So I have to change every script that starts OpenSwan.

With upstart this is trivial: just add a job that gets run on the "started 
openswan" event that is emitted automatically by upstart.

> I am pasting more and more of my unfinished but already announced
> document, but my idea of netconfd is a daemon that monitors the
> kernel and a control socket. ifup/ifdown interact with the control
> socket, as does a bridging handler to the dbus protocol. netconf
> also provides a number of hooks, which can be used to signal such
> tools as upstart.

Sounds good.

> netconf depend on upstart? You see, upstart isn't just an event
> handler, it's designed to replace /sbin/init,

Yes, I though about that a bit. I wonder if upstart could be split into two 
parts, so that the event mechanism can be used independently of the init 
daemon.

Marcus
-------------- 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/20070510/accfb8db/attachment.pgp