From: Kilian Krause (kk_at_verfaction.de)
Date: Thu 30 Dec 2004 - 00:06:06 GMT
Hi Herbert,
Am Mittwoch, den 29.12.2004, 00:01 +0100 schrieb Herbert Poetzl:
> > > chkconfig --del network
> > >
> > > and it removes all the links from the various runlevels
> > > so that 'network' isn't started anymore ...
> >
> > The problem is that as soon as the next update to the "network"
> > package happens it will re-enable the service.
> >
> > So you have to manually stop it and disable it (ugly, error prone,
> > maintenance intensive) or write a hook for your packaging system to
> > stop it (still ugly).
>
> wait you are saying that your distro re-enables
> disabled services when they get updated? sounds
> like a bug to me, I would not want a distro to
> decide which services I run, just consider the
> security impact, when I disable telnet and the
> distro decides to re-enable it 'just' because
> a new telnet package was available ...
well, it doesn't forcibly re-activate them. Just update-rc.d has a logic
that when *NONE* of the runlevels has any symlink for either
S??$SERVICENAME or K??$SERVICENAME then it'll try to create them for
it's thinking it's being installed for the first time. That does remove
overhead for a more special configuration of first and update install.
So the clean "fix" is to remove all but one symlink (which will be a K99
or so) to have this made working.
In my idea the guest-vserver virtual package could/should provide as
many services as we need to be "available, but not original daemons and
then offer a debconf dialog to the user querying about all the other
daemons to be shut off. Poking around /etc/rc*.d/[SK]* symlinks is valid
from debconf as far as i know the policy in case you do that upon user
request. Of course altering any symlinks except for our own without
asking or even telling the user is out of the limits we should be
staying within.
> I do not think that any serious distro will do
> that ... so I guess it is 'safe' to disable those
> services right after guest installation ...
...which would be a nice task for a vserver-guest virtual package
including a fancy postinst script.
-- Best regards, Kilian
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver