Date: Tue 26 Feb 2002 - 19:18:05 GMT
On Tue, 26 Feb 2002, John Lyons wrote:
> Hmm, if this is correct then there are implications here.
> ie I build 10 unified vservers. That's nice, low disk usage, shared binary
> files and libs keep the server running well.
> If each root vs user decides to have a go at removing say apache/php/mysql
> and installs their own, then on the basis of what you've said above they
> could easily delete the packages and install their own. I then have 10
> servers using a bigger chunk of disk space and using separate binaries/libs
> so performance suffers.
> Same would be true if someone subscribed to Up2Date as their vs could very
> quickly become out of sync with the other vs's.
> I'm just trying to think of the implications for using this in a commercial
> environment from the position that we need to maintain a set of almost
> identical vs's allowing the users to customise conf files for existing
> packages, add new packages but not to be able to modify the existing
> packages wrt removing or upgrading.
> Have I missed something here or am I roughly correct in my concerns?
As I understand it, the immutable tag itself prevents unlinking as well.
However, there's an immutable-mayunlink tag (or maybe its now part of the
immutable tag), that enables it. If you don't want them to be able to
modify packages, you could try setting the immutable-mayunlink only on
the conf files, leave the rest totally locked down.
Of course, this is as I understand it. If I have this wrong, someone tell