From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 10 Sep 2003 - 13:13:10 BST
Chris,
On Wed, Sep 10, 2003 at 09:43:47AM +0100, Chris Murton wrote:
> Herbert,
>
> At present we don't have unification between the servers,
> we have a custom-built script to carry out a number of
> operations, including doing a
> "cp -ar /vserver/template /vserver/newname".
doesn't sound so bad at all, although I prefer dump/restore ;)
> I've looked into doing unification on Debian but there just isn't the
> support (which I'd be happy to use in a production environment).
well, there is a good chance that anybody using debian has
created/found a decent solution to that ...
*** any comments on this issue are welcome!
> > > If so, are
> > > there any options you can specify in the nameofvserver.conf
> > > file to override this as such?
>
> I wondered if there were any flags, such as S_CONTEXT="number"
> which applied for making a vserver 'not use' the user IDs
> for the quotas etc,
I guess I know what you mean, but unforunately this is not
possible the main reason against is, how quota works ...
- first you scan the disk and calculate the used amount
(this is done via quotacheck, data is stored in the quota files)
- if an existing file is modified, it can be _considered_ included
in the accounting done before, so only changes have to be
recorded ...
- if you create a new file it will be simply added ...
now if you put files for different contexts on your disk,
how would you tell to which context they belong? you have
to add a tag, which says, this file belongs to context N,
which can be done either by 'using' some parts of the UID/GID
values (GID24/GID16 mode) or some yet unused parts in the
filesystem (GID32 mode) ...
anyway, you'll have a tool (lsctx/chctx) to examine/change
the assignment of those files to specific contexts ...
> thereby copying the file to a new vserver would not break
> any username/UID mapping.
will not break if you use chctx on the copy to 'tag' it for
the new context number (as always, static context numbers are
an absolute must)
> I can't think of a better way to explain it ;)
if you have a better idea to solve this, I would be glad
to discuss it ...
best,
Herbert
> Thanks,
> Chris.