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

Re: dh_installinetd



On Sun, Mar 09, 2003 at 11:44:44AM +0100, Andreas Metzler wrote:
> Hello,
> *inetd seems to die a slow death anyway, the problem is not a missing
> dh_installinetd but the support tools below.
> 
> update-inetd does not know which package added an entry, if you have
> two different packages providing and containing an executable with the
> same name your a in trouble: Take for example foo and bar, both
> contain /usr/sbin/blah and manage an entry in inetd-conf, foo is
> active and installed, bar is uninstalled with its inetd-entry
> disabled. Now you choose to purge bar, its postrm invokes
> 'update-inetd --remove blah' and /usr/sbin/blah is gone from
> inetd.conf although foo is still installed.
> 
> Test it yourself:
> *prompt* touch /tmp/inetd.test
> *prompt* /usr/sbin/update-inetd --file /tmp/inetd.test --group MAIL \
>   --comment-chars \#foo.disabled\# --add \
>   "finger   stream  tcp     nowait  mail    /usr/sbin/blah"
> *prompt* /usr/sbin/update-inetd --file /tmp/inetd.test --group MAIL \
>    --comment-chars \#foo.disabled\# --disable finger
> *prompt* /usr/sbin/update-inetd --file /tmp/inetd.test --group MAIL \
>   --comment-chars \#bar.disabled\# --add \
>   "finger   stream  tcp     nowait  mail    /usr/sbin/blah"
> *prompt* /usr/sbin/update-inetd --remove blah
> 
> In case you wonder, it does not help to specify --comment-chars to the
> --remove. 

The code I copied "fixes" this, it does:

update-inetd --pattern '[ \t]#command#' --disable #service# (remove)
update-inetd --remove '#service#[ \t].*[ \t]#command#'  (purge)

Or in the above case:

update-inetd --pattern '[ \t]/usr/sbin/blah' --disable finger (remove)
update-inetd --remove 'finger[ \t].*[ \t]/usr/sbin/blah' (purge)

Which still is pretty dodgy IMHO, especially the purge command,
but not quite as bad.

However it does illustrate that there are numerous ways you can
work around the braindeadness of update-inetd in your maintainer
scripts. Hence why I want to try and create a standard way
of interfacing with it...

> The missing integration of xinetd is another problem (I am lookin at
> woody, I've read mails about fixing this, but do not know whether it
> has happend yet).

I think you would have to change the command line of update-inetd, I
can't imagine any of the commands mentioned above working with xinetd.

If the command line was changed, then it it would require was updating
dh_installinetd, and all applications would be updated on the next
rebuild.
-- 
Brian May <bam@debian.org>



Reply to: