From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 10 Sep 2003 - 17:45:17 BST
On Wed, Sep 10, 2003 at 03:46:11PM +0100, Chris Murton wrote:
> Herbert,
>
> As per your instructions on context disk quota, I've now installed the
> server with the appropriate support. Having said that now, i'm getting
> unusual errors;
>
> Starting the virtual server vsname
> Server vsname is not running
> /usr/sbin/vserver: line 485: ulimit: max user processes: cannot modify
> limit: Invalid argument
this sounds like the ulimit issue introduced by 2.4.23
(or to be precise with some prerelease)
from now on, you cannot set the Hard Limit below
the Soft Limit and vice versa, so you could either
revert this change by using my ulimit-unfix patch
or start living with it and set both hard and soft
limits (-HS) as other people do ...
> ipv4root is now 192.168.1.5
> Host name is now vsname
> New security context is 2
> /usr/lib/vserver/save_s_context: line 8: /var/run/vservers/vsname.ctx:
> Permission denied
> /usr/lib/vserver/save_s_context: line 9: /var/run/vservers/vsname.ctx:
> Permission denied
this sounds like /var/run/vservers/ not existant/writeable
save_s_context stores the context information there ...
> Kernel do not support chrootsafe(), using chroot()
> Starting system log daemon: syslogd.
> Starting domain name service: named.
> /etc/init.d/rc: /etc/rc2.d/S18quotarpc: Permission denied
>
I would say, you neglected rule #1 USE STATIC CONTEXT IDS ...
but it could also be that you changed the way CTX-IDs
are stored in the filesystem.
basically you problem is, that some files (those with
permission errors) belong (or seem to belong) to another
context ... so any access is denied ...
I had an opinion poll on this issues, and the question
asked was: how should a file from another context be handled.
the answer was, because this should never happen, like a
file which cannot be accessed ...
> Also after this, I manually set S_CONTEXT="2" for this VS,
> and tried to set up support for quotaing:
>
> server-1:~/vr-tools-0.13# chcontext --ctx 2 cqhadd -v /dev/hda8
> New security context is 2
> adding quota hash for /dev/hda8 ... succeeded.
> server-1:~/vr-tools-0.13# vserver vsname enter
> /usr/sbin/vserver: line 634: ulimit: max user processes: cannot modify
> limit: Invalid argument
> ipv4root is now 192.168.1.5
> Host name is now vsname
> New security context is 2
> /usr/lib/vserver/save_s_context: line 8: /var/run/vservers/vsname.ctx:
> Permission denied
> /usr/lib/vserver/save_s_context: line 9: /var/run/vservers/vsname.ctx:
> Permission denied
> Kernel do not support chrootsafe(), using chroot()
> root_at_vsname:/# quotacheck -vaug
> bash: /sbin/quotacheck: Permission denied
>
> Any thoughts!? :)
simplest way is to compile the e2fsprogs with my cti patch
and use the 'new' chctx command to assign a context id
to the whole directory of the vserver recursively ...
I would suggest to use S_CONTEXTs of 1000 and above, so
you can be sure that no dynamic context will use this id ...
HTH,
Herbert
> --
> Chris Murton
> Mail: chris_at_areti.net, Tel: +44 (0)20-8402-4041
> Areti Internet Ltd, http://www.areti.net