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
place.
> > * 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
update-inetd)
> > * 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.
Thanks,
Serafeim
--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp
Reply to: