Use case: VPN client
Marcus Better
marcus at better.se
Thu May 10 10:31:26 UTC 2007
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
More information about the netconf-devel
mailing list