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.
Reply to: