Re: RFC: update-inetd migration to dpkp-triggers
[apologies for the late response]
On Mon, Sep 07, 2009 at 05:35:37PM -0700, Steve Langasek wrote [edited]:
> On Tue, Sep 08, 2009 at 01:13:45AM +0200, Serafeim Zanikolas wrote:
> > On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> > > On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > > > but the primary benefits are making inetd support in maintainer scripts
> > > > both robust and idempotent.
>
> > > update-inetd in its present form can already be used to achieve this.
>
> > I beg to differ. update-inetd assumes that a service name (``ftp'') is
> > sufficient to enable, disable and remove a service, whereas to be certain of
> > what service is selected, one has to additionally specify protocol and path to
> > the server binary. This currently can be done with a little bit of imagination
> > using the optional --pattern switch (which strangely though is not available
> > in --remove mode)
>
> The --remove option is specified to accept a regexp as its argument. Does
> this not work?
> Perhaps packages today aren't /using/ --remove in a way that's robust and
> idempotent, but again, that seems to be a documentation problem.
No wonder it's not used properly: in contrast to what's documented, the
argument to --remove is only matched against the service name only, not the
whole entry:
/^$service\s+/ or /^$sep$service\s+/
where $sep is the value of comment-chars. How do you suggest that this is
changed to match the whole entry without breaking existing scripts (ie,
making them match wrong entries)?
> The packages I maintain that use update-inetd are the only things in the
> archive providing the service in question, so I'd always considered using
> the service name to be unambiguous.)
Even if it's unambiguous now, it's not certain that it'll also be in the
future.
> Ah, another case that I hadn't considered because I don't have to deal with
> multiple packages providing the same service.
>
> Wouldn't it suffice to support an additional --pattern argument to
> update-inetd --add? That way packages could specify the minimal match
> needed for re-enabling instead of adding a new entry.
The argument to --add is a whole entry. Instead of requiring --pattern along
with --add, we could just change the semantics of --add (eg, to not add a line
when an existing line has the same service name protocol and binary, instead
of only the service name).
IMHO to avoid issues like #168847, all invocation modes should require all 3
fields (service name, protocol and server name for external services).
Switching to xinetd fragments is a much more elegant and extensible way to
address this requirement.
> Alternatively, packages could use --comment-chars '#<removed># ' for
> enabling/disabling as part of a package removal.
How does this differ from the default comment chars '#<OFF># '?
> Here's a rough cut at a robust set of update-inetd calls for maintainer
> scripts to use. It's ugly, of course, and verbose - something that could
> probably be remedied with only minor enhancements to update-inetd.
Thanks for these snippets. Before I consider them, however, I'd like to put
forward a less intrusive version of the original proposal:
- replace --add with installation of fragments under /etc/inetd.conf.d
- forget about /var/lib and keep /etc/inetd.conf (and /etc/xinetd.d) as the
effective configuration
- replace --remove with a postrm script that simply removes a package's
fragments
- deprecate enable/disable since the shipped configuration will be in
fragments, only to be removed in purge mode
The fragments in /etc/inetd.conf.d/ will be used to update /etc/inetd.conf
similarly to what's currently done, instead of re-generating the whole file
from scratch (which is what the original proposal was about).
It's simpler for maintainers, and doesn't change much from the user's
perspective except for one caveat: to keep an installed service disabled the
user has to comment out its entry in /etc/inetd.conf (as opposed to removing
it) or remove its entry _and_ set disable=yes in the corresponding fragment
under /etc/inetd.conf.d
Here's a rough cut of scripts from the packagers' point of view:
installation:
- no {pre,post}inst scripts
- ship a fragment under /etc/inetd.conf.d/
removal:
package1.postrm:
fragment=/etc/inetd.conf.d/package1-serv
if [ "x$1" = "xpurge" ]; then
if [ -e $fragment ]; then
rm -f $fragment
if [ -x /usr/sbin/update-inetd ]; then
update-inetd
fi
fi
;;
fi
> # FIXME: why doesn't this regexp match?
> update-inetd --remove \
> '(#<removed># |#<off># )*inetd-test.*tcp.*/usr/sbin/inetd-test\b'
See first paragraph in this reply.
--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp
Reply to: