Re: the netbase/inetd conspiracy
On Tue, Sep 24, 2002 at 01:16:35PM +1000, Anthony Towns wrote:
> What it really needs is for someone to give a good reason why randomly
> deleting config files of installed packages is the best way to go about
> things, and should be supported.
How about, our basic packaging tools have always explicitly supported it?
>From ye olde Packaging Manual (currently E.1):
However, note that `dpkg' will _not_ replace a conffile that was
removed by the user (or by a script). This is necessary because with
some programs a missing file produces an effect hard or impossible to
achieve in another way, so that a missing file needs to be kept that
way if the user did it.
If you handle configuration files in the postinst, then I think you
should make an effort to handle them the same way dpkg does, to preserve
the principle of least surprise. I don't think an admin should have to
be explicitly aware of whether a particular configuration file is handled
by dpkg or not.
However, I think it's reasonable to make that consideration depend
on whether the configuration file is for one of the programs described
here, where deleting the file has an effect hard or impossible to achieve
in another way.
Anthony, the reason that nobody brought this up before for inetd might
be because nobody has found a use for deleting /etc/inetd.conf before.
Now that a use was found, I think it's up to you to decide if it meets
these criteria.
As far as I can tell, the only intended effect of deleting the file
is to make inetd abort when it starts, to ensure that it will never run.
I think this feature is of interest at least during the transition,
before inetd can be simply uninstalled.
At first glance, I can't find any other way to do it. inetd seems
to happily skip invalid syntax in the configuration file.
Oh... I experimented a bit and found that deleting the configuration
file doesn't work either. inetd will still run, it just won't open
any ports. So scratch that idea. Diverting /usr/sbin/inetd to
a filesystem that's mounted noexec sounds like a better bet :-)
Richard Braakman
Reply to: