Re: [Vserver] A possible new idea
Herbert Poetzl wrote: On Fri, May 12, 2006 at 03:17:47PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 05:17:55PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. well, yes, they did :) So they thought about it, but found it infeasible? or unecessary? the thing is, there are a bunch of arguments against this setup, namely: - the host system usually is a minimal setup tailored to administration and management of the guests including security stuff and backup/failover - you do not change the host system very often, you want to keep it updated in regard to security though - for security reasons, you do not 'share' the host system with any guest you give avay ... I'm not quite sure I understand what you mean by 'give away'. Can you please explain this more? - disk space is very cheap, so doing a similar approach with a 'guest template', which is shared or unified with many guests is not a big deal - different distros require different userspace, the amount of shared files is minimal across distros - CoW works fine, but reombining with a 'read-only' base which can be changed is a hard task, and usually not worth the efford ... So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) aha, good, well, what would be the advantage over the currently established way to do this, i.e. have a template (some cleaned up version of your host system) and update guests either individually or at-once with the v* tools (like vrpm, vapt, vyum ...)? why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? It will 1) save space: Esp. in the example I gave of using vservers to provide MAC. So if we want to provide different permissions for different users/applications, the permissions can be defined per vserver. Rather than each vserver having a copy of the host filesystem, the guest and host can share filesystems...I'm thinking this method will make access policies easier to write than those of SELinux. how much will it save, 400MB or maybe 1GB? I don't think this is really an issue, except on embedded systems 2) make upgrades more manageable. For example, rather than having a test vserver to test upgrades and have a separate production vserver to which all tested upgrades have to be moved and configuration re-done, sharing a filesystem will allow a 'commit-like' functionality to automatically handle passing an upgrade from the vserver to the host. that is something which might be interesting, but I think no current filesystem/overlay/cow feature can handle 'commits' yet I'm talking to others and think that there might be a few other uses of this kind of 'isolated' filesysetm. Comments? keep thinking about it, usually the best ideas start with 'impossible' or 'useless' :) best, Herbert thanks, -FS note: I'm just trying to figure the rationale behind this suggestion ... best, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Herbert Poetzl wrote: On Wed, May 10, 2006 at 05:17:55PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. well, yes, they did :) So they thought about it, but found it infeasible? or unecessary? So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) aha, good, well, what would be the advantage over the currently established way to do this, i.e. have a template (some cleaned up version of your host system) and update guests either individually or at-once with the v* tools (like vrpm, vapt, vyum ...)? why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? It will 1) save space: Esp. in the example I gave of using vservers to provide MAC. So if we want to provide different permissions for different users/applications, the permissions can be defined per vserver. Rather than each vserver having a copy of the host filesystem, the guest and host can share filesystems...I'm thinking this method will make access policies easier to write than those of SELinux. 2) make upgrades more manageable. For example, rather than having a test vserver to test upgrades and have a separate production vserver to which all tested upgrades have to be moved and configuration re-done, sharing a filesystem will allow a 'commit-like' functionality to automatically handle passing an upgrade from the vserver to the host. I'm talking to others and think that there might be a few other uses of this kind of 'isolated' filesysetm. Comments? thanks, -FS note: I'm just trying to figure the rationale behind this suggestion ... best, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Risking to get off-topic: On Wed, 2006-05-10 at 23:20 -0400, Stephen Harris wrote: On Thu, May 11, 2006 at 12:35:38AM +0200, Herbert Poetzl wrote: why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? This is actually how Solaris 10 zones work. In a Solaris 10 zone the filesystems /usr /bin /lib and so on are read-only loop-back mounts to the host OS. It makes the guest a lot smaller as a result. Pretty much most of the overhead of a guest (zone in Solaris terms) is the local files in writeable filesystems to ensure OS stability (eg /var/sadm for package maintenance). You don't have to worry about patching each guest because each guest is using the host OS; patch the host, reboot the guest and it's automatically patched. Yes, this requires native OS support (eg the patch utilities need to know that a guest exists and so updates it's package state files; the patch _contents_ would appear automatically as a result of the loopback mounts; it's merely the package state files that need updating). On Solaris not even that is necessary - the package mgmt tools can handle the update of already updated files (e.g. on read-only mounted NFS-volumes) since ages cleanly. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
You could use unionfs or bind-mounts to share directories between host- and guest-filesystem. Of course this would need some manuall work... well, bind mounts should work out-of-the-box, basically just add them to the fstab in the guest config Well, besides having to compile the unionfs module by hand it should work out-of-the-box as well. What I wanted to say is basically that you have to add the appropriate entries to fstab manually. There is no tool (at least none that I know of ;-) that automates the process of sharing static directories between guest and host. You have to decide for yourself which directories to share and add those to fstab. Pretty obvious though... ;-) Cheers, Sebastian -- Sebastian tokkee Harl GnuPG-ID: 0x8501C7FC http://tokkee.org/ signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] A possible new idea
After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? Thanks. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Thanks. -FS ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
On Wed, May 10, 2006 at 05:17:55PM -0400, Fareha Shafique wrote: Herbert Poetzl wrote: On Wed, May 10, 2006 at 02:46:34PM -0400, Fareha Shafique wrote: After asking various questions about unification, I don't think vhashify quite supports what I have in mind. I wanted to get some opinions/ideas from the users of this mailing list. I am thinking if vservers can somehow be used to provide MAC (Mandatory Access Control) through containers. For example, a vserver shares the same filesystem as the host server, with read and write access to the host files being defined through a set of MAC policies. In this way, different policies can be defined for different vservers. Also, writes can be contained within a vserver (so that if a file is written to, a copy is made in the vserver's space) and integrated with the host only through explicit 'commits' to allow, for example, new configurations to be tested in an environment exactly the same as the host server and then transferred to the host using a commit. Any comments please? sounds interesting, any ideas how to realize this? Well, my first impression of vservers was that it provided a kind of containment that I have mentioned. I mean after quickly going over the short introduction, I thought that a vserver has read only access to the host server's files and CoW is used whenever the vserver modifes a file. However, after installing a vserver, I realized this was not the case. And after asking a few questions on the mailing list, I learnt that there is no direct way to do this. I was hoping to find out what some of those involved in the development of linux-vserver thought about the feasibility of this idea. well, yes, they did :) So basically, at the moment, I don't really have much idea how to realize this, but I am hoping those more involved with vserver will some ideas to share :) aha, good, well, what would be the advantage over the currently established way to do this, i.e. have a template (some cleaned up version of your host system) and update guests either individually or at-once with the v* tools (like vrpm, vapt, vyum ...)? why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? note: I'm just trying to figure the rationale behind this suggestion ... best, Herbert ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] A possible new idea
Hi, why would somebody want to _share_ the host files with the guest, instead of having a separate filesystem for them? This is actually how Solaris 10 zones work. In a Solaris 10 zone the filesystems /usr /bin /lib and so on are read-only loop-back mounts to the host OS. It makes the guest a lot smaller as a result. Pretty much most of the overhead of a guest (zone in Solaris terms) is the local files in writeable filesystems to ensure OS stability (eg /var/sadm for package maintenance). You could use unionfs or bind-mounts to share directories between host- and guest-filesystem. Of course this would need some manuall work... Cheers, Sebastian -- Sebastian tokkee Harl GnuPG-ID: 0x8501C7FC http://tokkee.org/ signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
