Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Thu, Aug 20, 2009 at 11:08:40AM +0100, Roger Leigh wrote [edited]: For this reason, I would prefer to stick with perl, but it's your choice. Sure, I'll just have to add way more test cases :) Since xinetd already has the parsing code, it might be worth looking at that as a starting point (xinetd/confparse.c, I think). Good point (xinetd/parse.c actually) Sounds good. inetd-base might be a slightly better name, since it's something all the inetd implementations will depend upon (but packages /providing/ inetd fragments won't need to, since the TTBOMK file triggers happen transparently). This will mean these packages won't need to do anything except provide the config fragment. That's fine by me. I understand that renaming a pkg can be done transparently (wrt rdepends) using replaces+provides+conflicts against update-inetd (according to devref 5.9.3). In that case I'll use /etc/inetd.base.d instead of /etc/inetd.conf.d (I suppose it's OK to close bugs belonging to update-inetd from the changelog of inetd-base) I'm not sure if any additional steps would need to be taken on removal, e.g. if the service should be stopped in prerm. If I understand correctly, this is an issue only for standalone servers, not for services instantiated by inetd (those will seize to run as soon as the server binary is gone and any pending instances exit). Removed packages should definitely call update-inetd, to give it a chance to go through the fragments in /etc/inetd.base.d, set ``disable=yes'' to those that refer to non-existent server binaries, and update the actual (x)inetd configuration. (Otherwise (x)inetd will spam logs for failing to invoke missing servers) -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Sat, Aug 22, 2009 at 10:33:51PM +0200, Serafeim Zanikolas wrote: On Thu, Aug 20, 2009 at 11:08:40AM +0100, Roger Leigh wrote [edited]: Sounds good. inetd-base might be a slightly better name, since it's something all the inetd implementations will depend upon (but packages /providing/ inetd fragments won't need to, since the TTBOMK file triggers happen transparently). This will mean these packages won't need to do anything except provide the config fragment. That's fine by me. I understand that renaming a pkg can be done transparently (wrt rdepends) using replaces+provides+conflicts against update-inetd (according to devref 5.9.3). In that case I'll use /etc/inetd.base.d instead of /etc/inetd.conf.d That should be fine. However, if you implement this in the existing update-inetd, you won't need to do any migration. (I suppose it's OK to close bugs belonging to update-inetd from the changelog of inetd-base) I would reassign them first, though it should be fine. I'm not sure if any additional steps would need to be taken on removal, e.g. if the service should be stopped in prerm. If I understand correctly, this is an issue only for standalone servers, not for services instantiated by inetd (those will seize to run as soon as the server binary is gone and any pending instances exit). I think this should be correct, though any running servers may not be overly happy over having their files removed as they are running (though this shouldn't be much of a problem in practice; it's something non-inetd using servers could potentially also suffer from if they fork off a child to handle a connection during removal). Removed packages should definitely call update-inetd, to give it a chance to go through the fragments in /etc/inetd.base.d, set ``disable=yes'' to those that refer to non-existent server binaries, and update the actual (x)inetd configuration. (Otherwise (x)inetd will spam logs for failing to invoke missing servers) I hadn't fully considered the case where you have removed the package but not purged the config files. It's not really appropriate to alter the user configuration. The approach I would take here is to check the state of the package owning the file, and to skip it if its state is not installed. If there's no reference to the package then you don't skip, since it's probably a custom fragment added by the admin. You can't check for the presence of the program, since for many it will be TCP wrappers (/usr/sbin/tcpd), so it probably should be the package state. This needs some more thought, since doing it via dpkg -S will be slow. 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
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Thu, Aug 20, 2009 at 11:08:40AM +0100, Roger Leigh wrote: The next bit would be writing the update-inetd replacement (which could just be part of the existing update-inetd, used when called with no arguments, and/or run on every invocation). If called with arguments, it will work as usual; the old code would be removed after the transition is done so it just does nothing, or emits a warning. I'd prefer something more explicit: maintain update-inetd as is, and add update-inetd-ng. (Also, because I'd rather write the new functionality in python. I like perl but I'm more confident with python). I'm not sure if update-inetd is still pulled into base installs, but it may well drag in python into default installs, which will bloat its size somewhat. For this reason, I would prefer to stick with perl, but it's your choice. python is part of the standard system nowadays, whereas update-inetd is Priority: optional. I don't think the python dependency should be a problem. I do object to ng appearing anywhere in the name of this tool, though. The name of the tool is codified in the Debian Policy, and there are numerous packages that depend on the package and tool - reimplementation or not, the next version should use the same name. -- 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Sat, Aug 22, 2009 at 10:33:51PM +0200, Serafeim Zanikolas wrote: Sounds good. inetd-base might be a slightly better name, since it's something all the inetd implementations will depend upon (but packages /providing/ inetd fragments won't need to, since the TTBOMK file triggers happen transparently). This will mean these packages won't need to do anything except provide the config fragment. That's fine by me. I understand that renaming a pkg can be done transparently (wrt rdepends) using replaces+provides+conflicts against update-inetd (according to devref 5.9.3). In that case I'll use /etc/inetd.base.d instead of /etc/inetd.conf.d (I suppose it's OK to close bugs belonging to update-inetd from the changelog of inetd-base) No, that would leave the bugs in an inconsistent state, still listed as being open in the update-inetd package but closed in another package that they aren't assigned to. Yet another reason not to rename the package. (And why is this discussion happening in a bug report against debian-policy? Please take this discussion to the debian-devel mailing list.) -- 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Thu, Aug 20, 2009 at 12:56:29AM +0200, Serafeim Zanikolas wrote: [I'm not switching to private emails as we're getting valuable feedback here] On Tue, Aug 18, 2009 at 11:34:11PM +0100, Roger Leigh wrote [edited]: Alternatively, the xinetd format is /currently/ the superset, but that's perhaps not flexible enough for the future since we're then tied into being compatible with that single implementation. Please see my email to Russ. I've seen it and agree with this. The next bit would be writing the update-inetd replacement (which could just be part of the existing update-inetd, used when called with no arguments, and/or run on every invocation). If called with arguments, it will work as usual; the old code would be removed after the transition is done so it just does nothing, or emits a warning. I'd prefer something more explicit: maintain update-inetd as is, and add update-inetd-ng. (Also, because I'd rather write the new functionality in python. I like perl but I'm more confident with python). I'm not sure if update-inetd is still pulled into base installs, but it may well drag in python into default installs, which will bloat its size somewhat. For this reason, I would prefer to stick with perl, but it's your choice. Since xinetd already has the parsing code, it might be worth looking at that as a starting point (xinetd/confparse.c, I think). I've filed an ITA for update-inetd (#472470). Short-term action plan: - prepare a release to take ownership of the package and fix some major bugs (sponsorship anyone?) - write and document update-inetd-ng - provide migration guidelines and modify packages to use both scripts Sounds good. inetd-base might be a slightly better name, since it's something all the inetd implementations will depend upon (but packages /providing/ inetd fragments won't need to, since the TTBOMK file triggers happen transparently). This will mean these packages won't need to do anything except provide the config fragment. I'm not sure if any additional steps would need to be taken on removal, e.g. if the service should be stopped in prerm. 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
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Hi! On Tue, 2009-08-18 at 23:34:11 +0100, Roger Leigh wrote: Once that's in place, packages can then start providing the fragments in /etc/inetd.d. At this point, there won't be any use of the generated file(s), but we can verify it's all working correctly. Once done, the inetds can start using the new generated configs, and then it's done. It would be wonderful to see this happen, it's something that I've been thinking about doing but never found the time. But, please do not use “/etc/inetd.d/” as at least inetutils-inetd supports that directory for inetd.conf fragments already upstream. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Wed, Aug 19, 2009 at 08:46:57PM +0200, Guillem Jover wrote [edited]: But, please do not use “/etc/inetd.d/” as at least inetutils-inetd supports that directory for inetd.conf fragments already upstream. Thanks for pointing that out. For now I'll assume /etc/inetd.conf.d -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Serafeim Zanikolas ser...@hellug.gr writes: On Tue, Aug 18, 2009 at 03:46:04PM -0700, Russ Allbery wrote: And then xinetd wouldn't have to go through update-inetd and could just use the fragments directly, which would resolve that integration problem in what I think is a cleaner way. In the long run, we might have to extend the vocabulary of xinetd fragments to support features that will be unique to a brand new inetd. To deal with that scenario seamlessly, we're best passing xinetd fragments through the conf translator anyway, even though it won't have to translate/strip anything until that shiny brand new inetd comes along. Yeah, that's probably a reasonable point. I do think starting with the xinetd syntax for the fragment syntax would be nice. A lot of upstreams already provide xinetd configuration fragments. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Tue, Aug 18, 2009 at 03:46:04PM -0700, Russ Allbery wrote: I'd love to see a solution that would involve packages shipping xinetd fragments and stripping those fragments down for inetd if inetd were in use instead. The xinetd syntax is more expressive and is used by other distributions, so we wouldn't be inventing something new that's specific to Debian. Agreed. And then xinetd wouldn't have to go through update-inetd and could just use the fragments directly, which would resolve that integration problem in what I think is a cleaner way. In the long run, we might have to extend the vocabulary of xinetd fragments to support features that will be unique to a brand new inetd. To deal with that scenario seamlessly, we're best passing xinetd fragments through the conf translator anyway, even though it won't have to translate/strip anything until that shiny brand new inetd comes along. -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
[I'm not switching to private emails as we're getting valuable feedback here] On Tue, Aug 18, 2009 at 11:34:11PM +0100, Roger Leigh wrote [edited]: Alternatively, the xinetd format is /currently/ the superset, but that's perhaps not flexible enough for the future since we're then tied into being compatible with that single implementation. Please see my email to Russ. The next bit would be writing the update-inetd replacement (which could just be part of the existing update-inetd, used when called with no arguments, and/or run on every invocation). If called with arguments, it will work as usual; the old code would be removed after the transition is done so it just does nothing, or emits a warning. I'd prefer something more explicit: maintain update-inetd as is, and add update-inetd-ng. (Also, because I'd rather write the new functionality in python. I like perl but I'm more confident with python). I've filed an ITA for update-inetd (#472470). Short-term action plan: - prepare a release to take ownership of the package and fix some major bugs (sponsorship anyone?) - write and document update-inetd-ng - provide migration guidelines and modify packages to use both scripts Cheers, Serafeim -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Mon, Aug 17, 2009 at 04:18:13PM -0700, Steve Langasek wrote [edted]: I would suggest disallowing example entries altogether; let packages use the '#off#' syntax instead. Or is there some reason I'm missing why we would want to support so many different ways for packages to add lines to update-inetd? I'm all for simplicity, so by all means let's disallow example entries. - If a package wants to install an example entry into `/etc/inetd.conf', - the entry must be preceded with exactly one hash character (`#'). - Such lines are treated as commented out by user by the - `update-inetd' script and are not changed or activated during package - updates. + Lines preceded with exactly one hash character (`#') are treated as + commented out by user by the `update-inetd' script and must not be + changed or activated during package updates. The case of example entries is beyond the scope of policy. update-inetd can easily get a new ``--add-disabled'' switch (which will be identical to ``--add'' except for prefixing the entry with '#off# '). -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Tue, Aug 18, 2009 at 01:43:47AM +0100, Roger Leigh wrote [edited]: I would really rather we went with the proposal I put forward in this thread: http://lists.debian.org/debian-devel/2009/03/msg00496.html in this message: http://lists.debian.org/debian-devel/2009/03/msg00573.html Sorry too many downsides: - too disruptive, too much work - how are you going to keep track of user-policy along the lines of I don't want ftp enabled no matter what packages are installed in the future? - you'll have to re-implement update-inetd from scratch, except that now the functionality will be spread all over the place - you need to ship fragments for every supported format Having read several criticisms of update-inetd, I still think that we're better off fixing it than starting from scratch (please don't spend any time trying to convince me otherwise; if you feel like it, let's discuss how to fix it's problems than hypothetical alternative approaches). update-inetd has many open bugs: - it _is_ actually buggy (most notably #510406) - the documentation is not in-your-face explicit about user-disabled entries being preceded with only one '#'; '##' won't do, '# ' or anything else won't do either - policy doesn't help (hence this bug) and it's silent on how update-inetd should deal with service entries that are commented out with neither '#' nor '#off#' (how about adding a lintian warning for these cases?) - perhaps due to policy and the --comment-chars misfeature, maintainer scripts might not always do the right thing (meaning, never disable a service with anything but the default comment-chars) -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Serafeim Zanikolas ser...@hellug.gr writes: On Mon, Aug 17, 2009 at 04:18:13PM -0700, Steve Langasek wrote [edted]: I would suggest disallowing example entries altogether; let packages use the '#off#' syntax instead. Or is there some reason I'm missing why we would want to support so many different ways for packages to add lines to update-inetd? I'm all for simplicity, so by all means let's disallow example entries. - If a package wants to install an example entry into `/etc/inetd.conf', - the entry must be preceded with exactly one hash character (`#'). - Such lines are treated as commented out by user by the - `update-inetd' script and are not changed or activated during package - updates. + Lines preceded with exactly one hash character (`#') are treated as + commented out by user by the `update-inetd' script and must not be + changed or activated during package updates. The case of example entries is beyond the scope of policy. update-inetd can easily get a new ``--add-disabled'' switch (which will be identical to ``--add'' except for prefixing the entry with '#off# '). I agree with this in principle, but adding that as a must is going to make a fair number of packages instantly buggy. We should have some sort of transition plan and advance warning for packages that install example inetd entries, I think. It shouldn't be too difficult to detect calls to update-inetd where the service is commented out. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Tue, Aug 18, 2009 at 08:02:33PM +0200, Serafeim Zanikolas wrote: On Tue, Aug 18, 2009 at 01:43:47AM +0100, Roger Leigh wrote [edited]: I would really rather we went with the proposal I put forward in this thread: http://lists.debian.org/debian-devel/2009/03/msg00496.html in this message: http://lists.debian.org/debian-devel/2009/03/msg00573.html Sorry too many downsides: - too disruptive, too much work Not really, it would be the same as any transition. Just two simple changes to each package. And since both old and new mechanisms are in place during the transition, the length of time isn't too important. iwj, who was originally involved with update-inetd, agreed that this was a good plan. In fact, it can really just be one change, since the new tool can just be run as a dpkg file trigger, so there's no strict requirement to remove use of update-inetd to complete the transition. - how are you going to keep track of user-policy along the lines of I don't want ftp enabled no matter what packages are installed in the future? Just edit the entry for the package. If you read the original threads, you would have seen that since everything becomes a conffile, this would be managed entirely via dpkg conffile handling. You'd just have the equivalent of enabled=false in the file, and rerun update-inetd. This is achieved simply by having packages providing the service install the config fragment by the same name. The idea of preserving that particular configuration choice is a bit suspect however. If you don't want a service enabled, you don't install it. Non-inetd-using services don't function this way, so this is a rather odd requirement. - you'll have to re-implement update-inetd from scratch, except that now the functionality will be spread all over the place No, it's in a single place. And it's idempotent, and robust. This re-implementation will be dead simple. It just reads each file in and spits out a generated inetd.conf. Nothing else. This is why we gain idempotency and robustness: there's no editing of the entries; we let the dpkg conffile mechanism handle everything else. As a one-time transition mechanism, we could read the old inetd.conf and update the fragments with that state so the inetd configuration is carried over. Again, that's pretty trivial. - you need to ship fragments for every supported format No, the single tool can generate all supported formats in a single run. The fragments would be a superset of the configuration for all currently available inetds, including xinetd. The tool would read them all in, and generate a set of inetd configuration files under /var, one per format supported. Realistically, there's basically just two: inetd and xinetd. We could support variants on the inetd format to support the various minor extensions and features of individual inetds. Each inetd implementation would then be patched to read the appropriate configuration file. Having read several criticisms of update-inetd, I still think that we're better off fixing it than starting from scratch (please don't spend any time trying to convince me otherwise; if you feel like it, let's discuss how to fix it's problems than hypothetical alternative approaches). Unfortunately, the whole concept of update-inetd is horribly broken. It needs scrapping. There's a reason why no one has fixed it in years, it's due to the fact that its problems are design faults. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
I like this proposal, thanks for ignoring my request to not write about alternatives ;) I'll take some time to think about it and read up on triggers/etc. I might bug you in private about this as I think we're getting off-topic here. -S -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Tue, Aug 18, 2009 at 10:16:47PM +0200, Serafeim Zanikolas wrote: I like this proposal, thanks for ignoring my request to not write about alternatives ;) I'll take some time to think about it and read up on triggers/etc. I might bug you in private about this as I think we're getting off-topic here. No worries. The other things that this will be useful for are full IPv6 support (currently needs two separate entries, so every update-inetd user needs to call it twice, but no packages I've seen do this--it's IPv4 only), and also transparent migration between inetd implementations (e.g. inetd←→xinetd and other future programs. upstart?). Currently these are both completely unsupported. The initial work that needs doing is defining a suitable file format. A simple key=value or Key: Value scheme would probably be sufficient if there's only one service per file. Alternatively, the xinetd format is /currently/ the superset, but that's perhaps not flexible enough for the future since we're then tied into being compatible with that single implementation. The next bit would be writing the update-inetd replacement (which could just be part of the existing update-inetd, used when called with no arguments, and/or run on every invocation). If called with arguments, it will work as usual; the old code would be removed after the transition is done so it just does nothing, or emits a warning. Until the transition is complete, and this would most likely be over a stable release, it would also need to update the fragments from inetd.conf since during this period that would remain the definitive configuration. Once complete this would be stopped. Once that's in place, packages can then start providing the fragments in /etc/inetd.d. At this point, there won't be any use of the generated file(s), but we can verify it's all working correctly. Once done, the inetds can start using the new generated configs, and then it's done. 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
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Roger Leigh rle...@codelibre.net writes: The initial work that needs doing is defining a suitable file format. A simple key=value or Key: Value scheme would probably be sufficient if there's only one service per file. Alternatively, the xinetd format is /currently/ the superset, but that's perhaps not flexible enough for the future since we're then tied into being compatible with that single implementation. I'd love to see a solution that would involve packages shipping xinetd fragments and stripping those fragments down for inetd if inetd were in use instead. The xinetd syntax is more expressive and is used by other distributions, so we wouldn't be inventing something new that's specific to Debian. And then xinetd wouldn't have to go through update-inetd and could just use the fragments directly, which would resolve that integration problem in what I think is a cleaner way. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Sun, Aug 16, 2009 at 09:55:29PM +0200, Serafeim Zanikolas wrote: Package: debian-policy Version: 3.8.2.0 Severity: normal Hello policy makers :) update-inetd is seriously bug infested, IMHO to some extent because of the issue below. Policy 11.2 says: If a package wants to install an example entry into `/etc/inetd.conf', the entry must be preceded with exactly one hash character (`#'). Such lines are treated as commented out by user by the `update-inetd' script and are not changed or activated during package updates. [presumably, not changed here implies also not deleted] Effectively this means that we cannot distinguish between two entirely different things: local-admin-policy and examples generated by postinst maintainer scripts. Now how does this lead to bugs? Say I install ftp-daemon-a, which adds an example entry to /etc/inetd.conf, and then I uninstall the package. The example entry will survive the package's removal (even if prerm calls update-inetd, it won't be removed because it's indistinguishable from local-admin-policy). Then I decide to install ftp-daemon-b. If the package's postinst calls update-inetd to enable the new service, the new entry won't be added because it's apparently local-admin-policy that ftp should be disabled. A potential fix would be to prescribe that example entries added by maintainer scripts are preceded with '#example# ' (to be consistent with '#off# ' which is what update-inetd uses by default to denote disabled entries). I would suggest disallowing example entries altogether; let packages use the '#off#' syntax instead. Or is there some reason I'm missing why we would want to support so many different ways for packages to add lines to update-inetd? -- 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
On Mon, Aug 17, 2009 at 04:18:13PM -0700, Steve Langasek wrote: On Sun, Aug 16, 2009 at 09:55:29PM +0200, Serafeim Zanikolas wrote: Package: debian-policy Version: 3.8.2.0 Severity: normal Hello policy makers :) update-inetd is seriously bug infested, IMHO to some extent because of the issue below. Policy 11.2 says: If a package wants to install an example entry into `/etc/inetd.conf', the entry must be preceded with exactly one hash character (`#'). Such lines are treated as commented out by user by the `update-inetd' script and are not changed or activated during package updates. [presumably, not changed here implies also not deleted] Effectively this means that we cannot distinguish between two entirely different things: local-admin-policy and examples generated by postinst maintainer scripts. Now how does this lead to bugs? Say I install ftp-daemon-a, which adds an example entry to /etc/inetd.conf, and then I uninstall the package. The example entry will survive the package's removal (even if prerm calls update-inetd, it won't be removed because it's indistinguishable from local-admin-policy). Then I decide to install ftp-daemon-b. If the package's postinst calls update-inetd to enable the new service, the new entry won't be added because it's apparently local-admin-policy that ftp should be disabled. A potential fix would be to prescribe that example entries added by maintainer scripts are preceded with '#example# ' (to be consistent with '#off# ' which is what update-inetd uses by default to denote disabled entries). I would suggest disallowing example entries altogether; let packages use the '#off#' syntax instead. Or is there some reason I'm missing why we would want to support so many different ways for packages to add lines to update-inetd? I would really rather we went with the proposal I put forward in this thread: http://lists.debian.org/debian-devel/2009/03/msg00496.html in this message: http://lists.debian.org/debian-devel/2009/03/msg00573.html This is a relatively simple task, just one that needs a reasonably labour-intensive transition over a few releases of the fixed update-inetd package 1) Add functionality to process fragments in addition to command-line args. 2) Update all packages calling update-inetd to ship a fragment. At this point both the old and new mechanisms will still work, with the inetds using /etc/inetd.conf. 3) Switch inetds to use the appropriate generated config file. 4) Update all packages to remove use of update-inetd with arguments (maybe make it into a dpkg trigger?) 4) Remove old update-inetd code to leave only new clean and simple code. At this point, /etc/inetd.conf is obsolete and unused. Unfortunately, I lack the time to write the code and push this forward, otherwise I would have tried to get this done for Squeeze. But it's not technically difficult to do, it just needs time. The advantage of this approach is that is removes *all* of the many update-inetd bugs by throwing the whole mess into the bin. It should also allow a smooth transition, though the above example plan doesn't account for migrating active settings over to the new config file fragments. It shouldn't be too hard to do. 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541872: debian-policy: identical notation for disabled-by-user and auto-generated entries in /etc/inetd.conf
Package: debian-policy Version: 3.8.2.0 Severity: normal Hello policy makers :) update-inetd is seriously bug infested, IMHO to some extent because of the issue below. Policy 11.2 says: If a package wants to install an example entry into `/etc/inetd.conf', the entry must be preceded with exactly one hash character (`#'). Such lines are treated as commented out by user by the `update-inetd' script and are not changed or activated during package updates. [presumably, not changed here implies also not deleted] Effectively this means that we cannot distinguish between two entirely different things: local-admin-policy and examples generated by postinst maintainer scripts. Now how does this lead to bugs? Say I install ftp-daemon-a, which adds an example entry to /etc/inetd.conf, and then I uninstall the package. The example entry will survive the package's removal (even if prerm calls update-inetd, it won't be removed because it's indistinguishable from local-admin-policy). Then I decide to install ftp-daemon-b. If the package's postinst calls update-inetd to enable the new service, the new entry won't be added because it's apparently local-admin-policy that ftp should be disabled. A potential fix would be to prescribe that example entries added by maintainer scripts are preceded with '#example# ' (to be consistent with '#off# ' which is what update-inetd uses by default to denote disabled entries). Cheers, Serafeim -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (100, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: pn doc-base none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
