Hi,
after years being an user occasionally packaging small things in a
rather quick-and-dirty way I have recently taken my first attempt to
build a package that is supposed to be used by a larger crowd (and,
eventually, end up in the Debian repository some day). The package works
fine so far, but there are a few questions on how to structure it.
The application to be packaged is isatapd by Sascha Hlusiak
(http://saschahlusiak.de/linux/isatap.htm), a small userspace daemon
that aids in autoconfiguring RFC5214 (Intra-Site Automatic Tunnels)
tunnels in the Linux kernel. In the end, that's pretty much a standard
proto-41 IPv6-in-IPv4 tunnel with a special addressing structure as
outlined by the RFC.
I have put the first try of packaging into the Ubuntu Launchpad PPA at
https://launchpad.net/~berni/+archive/ppa (actually, it was developed on
Debian Lenny, but my testers wanted amd64 binaries). It's not fully
conforming Debian standards yet (copyright file is wrong for example).
The main question is on how to start the daemon. Generally, the package
should be safe to run out of the box. It will only attempt configuration
if it can resolve the unqualified hostname 'isatap', and it will only
configure addresses/routes and thus provide any sort of connectivity to
the system if it could actually speak to a ISATAP-compliant router on
the other side of the tunnel (determined by said hostname). The only
drawback is that due to the way ISATAP works in the linux kernel there
is no way to depref ISATAP in case other (native?) IPv6 connectivity is
available. That could cause disrupted (if return traffic is sent to the
wrong interface) or suboptimal (tunneled instead of native) IPv6
connectivity.
At the moment I can think of five ways
a) Initscript sourcing /etc/default/isatapd with RUN=yes by default,
started at boot with update-rc.d. Pro/Contra: people have a
chance/hazard to get IPv6 out of the box without configuring anything.
They might as well not notice that they need to configure something if
the hostname/domain is non-standard
b) Initscript sourcing /etc/default/isatapd with RUN=yes, but not
started at boot. Pro: people can choose to run it manually or start it
on boot on their own agenda Contra: does not give IPv6 without manual
intervention
c) Initscript sourcing /etc/default/isatapd with RUN=no by default,
started at boot with update-rc.d. Pro: people have to review the "config
file". Contra: cannot start it manually using the initscript
c1) use RUN=yesno and RUN_ON_BOOT=yesno and check in initscript whether
we're booting. How?
d) get rid of the initscript, plug it into ifupdown and configure the
parameters in /etc/network/interfaces. I'd consider this the Debian way,
but how does this cooperate with NetworkManager and Co?
e) don't provide any scripts, have the user read up and start it manually
What would be the preferred way?
The second question is about reloading. On a SIGHUP the daemon releases
address/routers, redoes the DNS query, then requeries the upstream
ISATAP router.
At the moment that behaviour is linked to the 'reload'-initscript
parameter. However, it does not really reload its configuration (which
are the daemon parameters in /etc/default/isatapd). Is this too
confusing for the user? Should this be renamed (how)? Is this something
that should be in the init script at all?
Last but not least, although isatapd periodically refreshes the
reachability it might end up temporarily blackholing IPv6 connectivity
if IPv4 changes or is shutdown. Would it make sense to package a script
in /etc/network/if-down.d and /etc/ppp/ip-down.d that sends a SIGHUP to
the daemon when any interface goes down?
All comments are appreciated. Also all tips on how to improve the
current packaging are welcome.
Thanks,
Bernhard
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
