[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: update-inetd migration to dpkp-triggers

On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote [edited]:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:

> Invocations of update-inetd that lead to local policy overrides are bugs in
> the caller, not in update-inetd.  There is an explicitly reserved comment
> string (#<off>#) for the only case relevant for package use.

Indeed, many maintainer scripts are buggy, largely because documentation is
unhpelful on how update-inetd should be used by postinst and postrm scripts.
Some scripts override the default comment string (or equally worse, add
entries with service names like "## ftp"), some use --disable instead of
--remove in postrm ... you get the idea :)

> > and doesn't support xinetd (#8927)
> This is a bug, yes.
> > The Rosy Future
> > * update-inetd will drop its current switches to
> >   add/remove/enable/disable services;
> This doesn't sound like a good idea; it sounds like a transition that's
> going to break a lot of packages (either silently or noisily, depending on
> the implementation).  How do you intend to transition away from this without
> either a) dropping existing package-provided entries on the floor, or b)
> leaving packages with no way to clean up those same entries?

This is meant to be in squeeze+1, at which point all update-inetd using
deamon packages must be modified to install a fragment in /etc/inetd.conf.d/
instead of using --add. In that mode of operation --remove will not be
applicable (fragments will be left behind, as is the case with xinetd). As for
enable/disable, they shouldn't be used by maintainer scripts in the first

> > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
> >   /var/lib/update-inetd/inetd.conf and auto-populate fragments in
> >   /var/lib/update-inetd/xinetd.d/ using xinetd fragments installed by deamon
> >   packages in /etc/inetd.conf.d/
> Likewise, then, what happens to existing entries in /etc/xinetd.d?

Just to clarify, this whole section refers to squeeze+1. As long as
/etc/inetd.conf and /etc/xinetd.d/ exist, update-inetd will use them as input,
along with /etc/inetd.conf.d/, to update /var/lib/update-inetd.

update-inetd will print a warning asking the user to migrate all settings to
/etc/inetd.conf.d and rename /etc/inetd.conf and /etc/xinetd.d (or have a
--migrate switch to do so, but only to be invoked by the user)

> > * document that local policy will live in /etc/inetd.conf.d/ and any manual
> >   changes will be made effective by running update-inetd
> I think this violates the principle of least surprise (restarting the daemon
> after making your changes has been enough to make those changes take effect
> since the inception of these daemons), and will be displeasing to many
> admins as a result.

This is a justified concern but I think it's a price we need to pay to be able
to support both inetd and xinetd with a single source of policy.

The need to run update-inetd will be remarked wherever we document that the
new local policy has moved to /etc/inetd.conf.d. The number of steps remains
the same though (instead of reloading inetd, one will have to run

> > * all (4) superservers will lookup their config under /var/lib/update-inetd/
> > * after deamon package installations, update-inetd will be invoked via a file
> >   trigger on /etc/inetd.conf.d/ to update the (x)inetd's actual configuration
> >   under /var/lib/ and reload (x)inetd
> This part seems reasonable.
> > How to Get There
> > The migration could(?) be done within one stable release, but I assume a more
> > conservative approach over two releases.
> > * squeeze
> >     * all deamon packages that use update-inetd [1]:
> >         * should version-depend in the update-inetd version that is shipped in
> >           squeeze (so that /etc/inetd.conf.d/ is in place)
> >         * should install xinetd fragments in /etc/inetd.conf.d/ (and in
> >           /etc/xinetd.d/ if they did so already)
> >         * must continue calling update-inetd in postinst/prerm scripts as
> >           before
> >     * update-inetd will:
> >         * install /etc/inetd.conf.d/ and declare file-trigger interest in it
> >         * keep the old functionality, but additionally to updating
> >           /etc/inetd.conf, also update /var/lib/update-inetd/* using as input
> >           both /etc/inetd.conf and /etc/inetd.conf.d (and /etc/xinetd.d if
> >           installed)
> So with these packages that are calling update-inetd *and* installing a
> snippet, what ends up being copied to /var/lib?

The logic that combines /etc/inetd.conf and /etc/inetd.conf.d/ will have to
filter out duplicates.

On a second thought though, there's not much point in populating /var/lib in
squeeze as it won't be used until inetds are patched (in squeeze+1).

> >     * update-inetd must:
> >         * sync effective inetd configurations based on /etc/inetd.conf.d/ and
> >           reload inetd when invoked without any arguments
> >         * only run as as result of being triggered by a deaemon
> >           (un)installation, or an explicit user invocation
> >         * drop the old functionality and print a warning but otherwise succeed
> >           when invoked with any of the old command line switches
> So: silent failure of update-inetd invocations.
> Noisy would be better.  Silent failures hide bugs.

By noisy you mean non-zero exit status? Isn't warning+success noisy enough?

Warning+success means that deamons from (pre)squeeze that have been dropped in
squeeze+1 but are still installed, will succeed in uninstalling despite
invoking update-inetd the old way.


debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp

Reply to: