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

Hello all,
I have just joined the mailing list. And downloaded and have browsed the doucmentation. I had a few questions before I start loading the software up.
 
I understand how the vc in general work, will learn with time the details. I looked thru the faqs and was able to glean some information on my security issues.
 
The first questions is inside each vc, the programs available to them are hard linked back to the system functions, is this correct? ie.. the gcc compiler in their vc is hard linked back to gcc.
 
Assuming the above, when there are updates to RH all will be updated via the links back to the origional program?
 
 
 
Next, I usually run bastile linux to go thru and remove suid's ect, change gcc to root only, change the system passwords so nobody can log in as root and must su to the admin name, ect.. Tidy things up. Will this break freevsd?
 
Another issue, I usually setup ipchains on the interface, does this mean that I will have to setup ipchains on each vc? do they talk directly to the network cards, or is communications via the underlying system.
 
Any insight or pointers to the doucmentation on this would be greatly appreciated.
 
Regards,
Rod Longhofer
 

Reply via email to