Re: [Vserver] A possible new idea
On Mon, May 15, 2006 at 02:37:45PM -0400, Fareha Shafique wrote: [utmost important stuff zapped] >>> 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? sell them, provide root shells to friends or whatever somebody does with a root environment in a guest >> - 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 ... 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 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
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 ... - 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
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
> > 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
Re: [Vserver] A possible new idea
On Thu, May 11, 2006 at 07:57:36AM +0200, Sebastian Harl wrote:
> 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...
well, bind mounts should work out-of-the-box, basically
just add them to the fstab in the guest config
HTH,
Herbert
> Cheers,
> Sebastian
> --
> Sebastian "tokkee" Harl
> GnuPG-ID: 0x8501C7FC
> http://tokkee.org/
>
> ___
> 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
Sorry, the email escaped:
On Thu, 2006-05-11 at 10:18 +0200, Bernd Petrovitsch wrote:
> 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.
And removal to (of already removed files).
Sorry, this doesn't really work with .deb and .rpm AFAIK.
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
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
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
Re: [Vserver] A possible new idea
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).
The vserver vhashify solution is an attempt in the same direction but
because it uses hard links it's not necessarily so space efficient
(you need at least one copy of the guest files in the /vserver tree,
whereas a read-only loopback mount doesn't need it). The vserver solution
allows each guest to modify the files as needed (break the immutable hard
link, create a new file) whereas Solaris 10 zones are read-only; you can not
modify /bin/bash in a zone(guest).
--
rgds
Stephen
___
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
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 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
