|
Because, for example, gcc in every virtual server is
actually a hard-link to gcc in the skel, upgrading the binary in the skel
will effectively upgrade gcc in every virtual server. However, it is not quite
this straightforward, as the old version of the binary must be un-linked from
every virtual server before being replaced and the new binary must be re-linked
to all virtual servers before it can be used by them. The script
vs-linkvs.pl provides an example of how this can be achieved. It will take
a an existing virtual server, unlink from its current skel and
re-link it to a new skel. So, to achieve an upgrade of gcc you would
need to duplicate then register your existing skel, using 'vsdadm
part_skeladd'. Upgrade the gcc in this new skel using rpm --root. Then use
vsd-vslinkvs.pl to switch an individual virtual server (or all virtual servers)
across to the new skel...
I have
considered incorporating/recommending the use of Bastille Linux as part of the
installation of freeVSD on a fresh installation, but haven't used it
thoroughly enough to give a proper recommendation. I can't think that
it would cause any problems but it will only affect the hosting server, assuming
you used a pre-built skel. For Bastille to affect the security wihtin virtual
server you would need to run Bastille on a hosting server before using
vsd-genskel.pl to generate your skel. Any attempts which Bastille makes to
manipulate file ownership/permissions would probably be lost in the virtual
servers because they are specifically set by vsd-vsbatch.pl during virtual
server creation...
I have
no idea what running Bastille in a virtual server would
do...
Tim
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rod Longhofer Sent: 16 June 2001 05:02 To: [EMAIL PROTECTED] Subject: Question on System Upgrading / security
|
- RE: Question on System Upgrading / security Dean
- Tim Sellar
