How to package a network connectivity daemon "the Debian way"
[ resent, wasn't subscribed to -devel before ... apologies if duplicate ] 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
How to package a network connectivity daemon "the Debian way"
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
