Re: problem with update-inetd!
On Sat 05 Feb 2000, Turbo Fredriksson wrote:
> Could someone please explain this?
>
> ----- s n i p -----
> [donald.ttyp0]$ grep ident /etc/inetd.conf
> ident stream tcp wait identd /usr/sbin/identd identd
> [donald.ttyp0]$ sudo update-inetd --disable ident
> [donald.ttyp0]$ grep ident /etc/inetd.conf
> #<off># ident stream tcp wait identd /usr/sbin/identd identd
> [donald.ttyp0]$ sudo update-inetd --group INFO --add "ident stream tcp nowait identd /usr/sbin/midentd midentd"
> [donald.ttyp0]$ grep ident /etc/inetd.conf
> ident stream tcp wait identd /usr/sbin/identd identd
> [donald.ttyp0]$
> ----- s n i p -----
The update-inetd script is seriously unstable. I've also submitted a bug
#56251 about it grepping incorrectly (it removes a line
Anyway, the problem you're seeing is that if there's a disabled service
in inetd.conf and you're adding a line for that service, the old one is
explicitly re-enabled instead of using the supplied one. I think this is
covered by the manpage entry for DebianNet (whose routines are used by
update-inetd):
DESCRIPTION
You can use the functions in DebianNet.pm to to add,
remove, enable or disable entries in the /etc/inetd.conf
file. After the /etc/inetd.conf file has been changed, a
SIGHUP signal will be sent to the inetd process to make
sure that inetd will use the new /etc/inetd.conf file. The
functions can also be used to add entries that are com
mented out by default. They will be treated like normal
entries. That also means that if you already have an entry
that is commented out you can't add an entry for the same
service without removing the old one first.
Note especially the last line. And from the update-inetd manpage:
If you are trying to add an entry which already
exists update-inetd won't add the entry. For uncom
mented entries it will do nothing and for entries
that are commented out by the comment-chars (see
option --comment-chars ) it will enable the exist
ing entry. If you want to completely replace an
entry just remove the entry with the --remove
option first.
So you have to --remove the entry instead of --disable-ing it.
Why it doesn't infer your intentions from the arguments you give it,
I don't know. Unfortunately the current behaviour seems to be on
purpose.
Paul Slootman
--
home: paul@wurtel.demon.nl http://www.wurtel.demon.nl/
work: paul@murphy.nl http://www.murphy.nl/
debian: paul@debian.org http://www.debian.org/
isdn4linux: paul@isdn4linux.de http://www.isdn4linux.de/
Reply to: