Re: inetd's status in Debian
ke, 2009-03-11 kello 00:00 +, Roger Leigh kirjoitti: Additionally, not all inetds support IPv6, so adding these lines will break some inetds. Should we consider lack of IPv6 support as a bug? Ah yes, it's been a release goal since etch. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
On Wed, Mar 11, 2009 at 08:12:56AM +0200, Lars Wirzenius wrote: ke, 2009-03-11 kello 00:00 +, Roger Leigh kirjoitti: Additionally, not all inetds support IPv6, so adding these lines will break some inetds. Should we consider lack of IPv6 support as a bug? Ah yes, it's been a release goal since etch. Yes, we absolutely should. I did try to push this for etch: http://lists.debian.org/debian-devel/2006/08/msg00483.html But didn't have much success persuading people. update-inetd is a horror. We should just dump it. I did point out back then it was badly broken, but my proposal to fix it was not taken up. The fact that update-inetd directly updates inetd.conf and inetd.conf can also be edited by users means that you can actually get a screwed up inetd.conf just by editing and installing/upgrading/removing a package in the wrong order. update-inetd is not idempotent, and is not clever enough to not screw up inetd.conf in certain circumstances. I did propose we switch to inetd-using packages providing a config file fragment in e.g. /etc/inetd.d, and having update-inetd simply regenerate inetd.conf from these pieces (and it would be trivial for it to preserve user edits with this mechanism), and it would also be idempotent. It has the benefits of simplicity and robustness, since it doesn't require calling a postinst script to run update-inetd with a specific (and limited) set of options. The current approach relies of update-inetd being hugely complex, when it really doesn't need to be. If we regard IPv6 support as a requirement, it would be great if all of the inetds *not* supporting IPv6 could be removed from the archive. Unless things have changed, this includes micro-inetd and superd. rlinetd does have support, but can't directly replace inetd, so can't be considered as a useful alternative. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
Roger Leigh wrote: I did propose we switch to inetd-using packages providing a config file fragment in e.g. /etc/inetd.d, and having update-inetd simply regenerate inetd.conf from these pieces (and it would be trivial for it to preserve user edits with this mechanism), and it would also be idempotent. It has the benefits of simplicity and robustness, since it doesn't require calling a postinst script to run update-inetd with a specific (and limited) set of options. The current approach relies of update-inetd being hugely complex, when it really doesn't need to be. Ideally we need something that isn't specific to the format of inetd.conf - last I checked some of our inetd's use different file formats (e.g. xinetd). -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
Roger Leigh writes (Re: inetd's status in Debian): The fact that update-inetd directly updates inetd.conf and inetd.conf Since this was my fault, I would just like to apologise again. I did propose we switch to inetd-using packages providing a config file fragment in e.g. /etc/inetd.d, and having update-inetd simply regenerate inetd.conf from these pieces (and it would be trivial for it to preserve user edits with this mechanism), and it would also be idempotent. It has the benefits of simplicity and robustness, since it doesn't require calling a postinst script to run update-inetd with a specific (and limited) set of options. The current approach relies of update-inetd being hugely complex, when it really doesn't need to be. Yes, please. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
On Thu, Mar 12, 2009 at 09:22:50AM +1100, Brian May wrote: Roger Leigh wrote: I did propose we switch to inetd-using packages providing a config file fragment in e.g. /etc/inetd.d, and having update-inetd simply regenerate inetd.conf from these pieces (and it would be trivial for it to preserve user edits with this mechanism), and it would also be idempotent. It has the benefits of simplicity and robustness, since it doesn't require calling a postinst script to run update-inetd with a specific (and limited) set of options. The current approach relies of update-inetd being hugely complex, when it really doesn't need to be. Ideally we need something that isn't specific to the format of inetd.conf - last I checked some of our inetd's use different file formats (e.g. xinetd). Totally agreed. If we support a superset of all of the various inetd configuration options, then it should be possible to support all inetd implementations as first-class citizens (e.g. xinetd). Implementations can then feel free to ignore options they can't support (such as the extended xinetd options, or particular socket options). The format needn't be that complex. If we have one file per package/service, it could just be a simple set of key-value pairs. Each inetd could provide their own update-inetd which just parses the file and spits out their config. Since most inetds have a common format, it might make sense to have a package providing this lowest common denominator implementation. If we have a big comment at the top of the generated file saying in effect do not edit; edit /etc/inetd.conf.d/xxx and run update-inetd, we shouldn't have too many problems. It's already done elsewhere. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: inetd's status in Debian
On Wed, Mar 11, 2009 at 10:58:31PM +, Roger Leigh wrote: If we have a big comment at the top of the generated file saying in effect do not edit; edit /etc/inetd.conf.d/xxx and run update-inetd, we shouldn't have too many problems. It's already done elsewhere. Then move that file far, far away from /etc, because it is no longer a configuration file and is an FHS violation. It is *not ok* to try to disclaim the policy requirement to preserve admin changes to config files with the use of a do not edit comment. This meme needs to die a horrible flaming death. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
Steve Langasek wrote: On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote: I'm wondering if making super servers become optionnal wouldn't be a worthy goal for squeeze. Why? If it ain't broke, don't fix it. Having a superserver installed isn't broken. Why should every daemon have to implement connection handling when they can offload that to the inetd? Demoting inetd from standard to optional seems to me like a reasonable release goal; that doesn't require patching lots of upstream code that works just fine the way it is already. In fact, AFAICS it doesn't require patching any of our packages. Right, isn't that the proposal: demote inetd and update-inetd to optional/extra? Btw, lots of packages are depending on update-inetd while it's guaranteed to be available when depending on inet-superserver. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
On Tue, Mar 10, 2009 at 07:31:35AM +0100, Luk Claes wrote: Steve Langasek wrote: On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote: I'm wondering if making super servers become optionnal wouldn't be a worthy goal for squeeze. Why? If it ain't broke, don't fix it. Having a superserver installed isn't broken. Why should every daemon have to implement connection handling when they can offload that to the inetd? Demoting inetd from standard to optional seems to me like a reasonable release goal; that doesn't require patching lots of upstream code that works just fine the way it is already. In fact, AFAICS it doesn't require patching any of our packages. Right, isn't that the proposal: demote inetd and update-inetd to optional/extra? Perhaps I misunderstood, but I read this as a proposal to make /use/ of inetd optional for the packages that currently depend on it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
On Mar 10, Luk Claes l...@debian.org wrote: Btw, lots of packages are depending on update-inetd while it's guaranteed to be available when depending on inet-superserver. Indeed, this is broken. IIRC some helpful soul started reporting bugs asking to depend on update-inetd too... -- ciao, Marco signature.asc Description: Digital signature
Re: inetd's status in Debian
On moandei 9 Maart 2009, Pierre Habouzit wrote: Just looking at the packages requiring an inet superserver, you'll see that it's probably that nowadays users don't need a superserver at all[0]. I'm wondering if making super servers become optionnal wouldn't be a worthy goal for squeeze. Yes, I think it would make sense to make them priority optional. Currently the standard installation does not include any active services so inetd just lingers around doing nothing. Demoting it to optional will do the right thing, installing a super server just in time: when you're also installing some package depending on it. cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: inetd's status in Debian
On Tue, Mar 10, 2009 at 08:44:06AM +0100, Marco d'Itri wrote: On Mar 10, Luk Claes l...@debian.org wrote: Btw, lots of packages are depending on update-inetd while it's guaranteed to be available when depending on inet-superserver. Indeed, this is broken. IIRC some helpful soul started reporting bugs asking to depend on update-inetd too... That remembers me a point: maybe it makes sense having a debhelper dh_ script to manage automagically the call to update-inetd when available or eventually warn the user to install update-inetd and update inetd/xinetd configuration manually, when update-inetd is NOT available. That would avoid to depend on update-inetd or inet-superserver at all Having a snippet of code like that replicated for every package is pointless. Also, update-inetd is a very partial solution for managing superserver configurations, but that's another problem... -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: inetd's status in Debian
On Tue, Mar 10, 2009 at 06:39:23AM +, Steve Langasek wrote: On Tue, Mar 10, 2009 at 07:31:35AM +0100, Luk Claes wrote: Steve Langasek wrote: On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote: I'm wondering if making super servers become optionnal wouldn't be a worthy goal for squeeze. Why? If it ain't broke, don't fix it. Having a superserver installed isn't broken. Why should every daemon have to implement connection handling when they can offload that to the inetd? Demoting inetd from standard to optional seems to me like a reasonable release goal; that doesn't require patching lots of upstream code that works just fine the way it is already. In fact, AFAICS it doesn't require patching any of our packages. Right, isn't that the proposal: demote inetd and update-inetd to optional/extra? Perhaps I misunderstood, but I read this as a proposal to make /use/ of inetd optional for the packages that currently depend on it. That's probably because of my broken english because what luk and you said was what I proposed: demote inetd to extra/optionnal instead of standard. It could make space on the CDs to more useful stuff e.g. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpC6sOyHTM36.pgp Description: PGP signature
Re: inetd's status in Debian
On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote: Most machines nowadays have enough memory, and most daemons provide a standalone mode (I mean who configures apache as an inetd service ?). Just looking at the packages requiring an inet superserver, you'll see that it's probably that nowadays users don't need a superserver at all[0]. I'm wondering if making super servers become optionnal wouldn't be a worthy goal for squeeze. I agree with this goal. One major lack in our current inetd support is for services which should run on IPv6 (tcp6 and udp6). While the current default inetd (openbsd-inetd) can support IPv6, in practice no maintainer scripts are actually adding tcp6/udp6 lines to inetd.conf in addition to tcp/udp lines. Additionally, not all inetds support IPv6, so adding these lines will break some inetds. While packages requiring inetd support will of course need to keep inetd around, it would be nice if packages offering both inetd and standalone operation could drop inetd support in favour of standalone operation only (since starting up the server every time for e.g. apache and even services like proftpd is less efficient than just having the dæmon sleep when not in use). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: inetd's status in Debian
On Mon, Mar 09, 2009 at 08:06:16PM +0100, Pierre Habouzit wrote: Just looking at the packages requiring an inet superserver, you'll see that it's probably that nowadays users don't need a superserver at all[0]. Yes, and many users no longer have a superserver installed for that reason. I'm wondering if making super servers become optionnal wouldn't be a worthy goal for squeeze. Why? If it ain't broke, don't fix it. Having a superserver installed isn't broken. Why should every daemon have to implement connection handling when they can offload that to the inetd? Demoting inetd from standard to optional seems to me like a reasonable release goal; that doesn't require patching lots of upstream code that works just fine the way it is already. In fact, AFAICS it doesn't require patching any of our packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
