Use case: VPN client
martin f krafft
madduck at debian.org
Thu May 10 10:47:57 UTC 2007
also sprach Marcus Better <marcus at better.se> [2007.05.10.1231 +0200]:
> 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.
the default policy applies to all interfaces and it is dhcp, then
link-local or for wireless interfaces poweroff on battery and ad-hoc
link-local when connected to ac. interfaces can override this, but
if they don't, that's what will happen anyway, provided the needed
(recommended) packages are installed.
> 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.
what if there isn't a route yet and the users asks the VPN tunnel to
> 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.
Well, all those run.d directories are kind of part of what makes
Debian be Debian, and except for parameter passing, they all have
the same "run-parts" semantics, no?
> 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.
Sure this is nice, but why would netconf have to depend on it? It
could run hooks and signal upstart if it's installed for better
performance, but if it's not installed, then it'll just do stuff the
regular run.d way.
> 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.
That's something for the upstart mailing list, which I would
certainly welcome. Still, I am unsure about the dependency. It
should be an optional add-on, well-integrated if installed.
.''`. martin f. krafft <madduck at debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
anyone who says sunshine brings happiness
has never danced in the rain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20070510/e19bd880/attachment.pgp
More information about the netconf-devel