Re: [Vserver] hrm... another odd thing.. /dev/initctl?
On Mon, 17 Nov 2003, Enrico Scholz wrote: that would do a context id check (ie where's it coming from and what's it trying to apply those changes to) and then if everything checks out, does the vserver context-id-resolves-to-this-name start/stop/restart. How will you do this resolving for vserver-in-a-vserver? When we get to the stage where nested vservers are possible, I'm sure it will be a relatively simple kernel task to send the event to the correct context. Some structure within the kernel will need to know parent/child context relationships anyway. Mark. ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] hrm... another odd thing.. /dev/initctl?
[EMAIL PROTECTED] (Allen D. Parker II) writes: I'm no programmer, but I do believe, it would be pretty nice if the owner of a context (fake root user) could halt/reboot *their* vserver via /sbin/init, /sbin/reboot or /sbin/halt. It'd be nice to have a way to pass messages *securely* back to something on the outside Developed for another project, vserver-djinni[1] is doing this. Basic ideas are described here[2] but in final implementation some details were changed and some restrictions lowered. that would do a context id check (ie where's it coming from and what's it trying to apply those changes to) and then if everything checks out, does the vserver context-id-resolves-to-this-name start/stop/restart. How will you do this resolving for vserver-in-a-vserver? Enrico Footnotes: [1] http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/ C89/gcc-2.95 ports are not planned; you will need gcc-3.3 and alpha util-vserver [2] http://www.fedora.us/pipermail/fedora-devel/2003-September/002097.html ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
RE: [Vserver] hrm... another odd thing.. /dev/initctl?
I'm no programmer, but I do believe, it would be pretty nice if the owner of a context (fake root user) could halt/reboot *their* vserver via /sbin/init, /sbin/reboot or /sbin/halt. It'd be nice to have a way to pass messages *securely* back to something on the outside that would do a context id check (ie where's it coming from and what's it trying to apply those changes to) and then if everything checks out, does the vserver context-id-resolves-to-this-name start/stop/restart. I personally can't figure out what to do about this *other* than figure out what the hell keeps calling it and removing it from the halt script (the same one that kills errant processes on vserver vsname stop). Just my $.02 Allen Parker -Original Message- From: [EMAIL PROTECTED] [mailto:vserver- [EMAIL PROTECTED] On Behalf Of Herbert Poetzl Sent: Saturday, November 15, 2003 7:07 AM To: Allen Parker Cc: [EMAIL PROTECTED] Subject: Re: [Vserver] hrm... another odd thing.. /dev/initctl? On Sat, Nov 15, 2003 at 03:35:23AM -0500, Allen Parker wrote: init: timeout opening/writing control channel /dev/initctl on a 'normal' server, init and telinit are often the same binary, and the 'init' process knows that it is init by verifying that it's pid equals 1 ... when init is started, it opens a pipe, which reads the commands given by telinit and halt, poweroff, etc. possible causes for this message therefor are: - init/telinit is called but not as pid == 1 - reboot, halt, poweroff are called without -f - init is started as 'faked' pid 1 but this doesn't work as expected yet ... possible solutions: - add some userspace tool outside the vserver which opens/reads the pipe and acts accordingly - find the 'bad' invocation and 'improve' it or remove it, if not required - demonstrate that it is a vserver misbehaviour which requires some code change ;) HTH, Herbert util-vserver-0.24 kernel-2.4.22-vs1.00 Allen Dale Parker [EMAIL PROTECTED] ego sum ens ompnipotens ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] hrm... another odd thing.. /dev/initctl?
On Sun, Nov 16, 2003 at 07:13:48AM -0500, Allen D. Parker II wrote: I'm no programmer, but I do believe, it would be pretty nice if the owner of a context (fake root user) could halt/reboot *their* vserver via /sbin/init, /sbin/reboot or /sbin/halt. It'd be nice to have a way to pass messages *securely* back to something on the outside that would do a context id check (ie where's it coming from and what's it trying to apply those changes to) and then if everything checks out, does the vserver context-id-resolves-to-this-name start/stop/restart. I personally can't figure out what to do about this *other* than figure out what the hell keeps calling it and removing it from the halt script (the same one that kills errant processes on vserver vsname stop). hey cool idea! maybe that was the reason I included it in the latest development release vs1.1.3 ;) if you give it a try, and experiment a little with the reboot userspace helper, please let me know how it works for you ... TIA, Herbert Just my $.02 Allen Parker -Original Message- From: [EMAIL PROTECTED] [mailto:vserver- [EMAIL PROTECTED] On Behalf Of Herbert Poetzl Sent: Saturday, November 15, 2003 7:07 AM To: Allen Parker Cc: [EMAIL PROTECTED] Subject: Re: [Vserver] hrm... another odd thing.. /dev/initctl? On Sat, Nov 15, 2003 at 03:35:23AM -0500, Allen Parker wrote: init: timeout opening/writing control channel /dev/initctl on a 'normal' server, init and telinit are often the same binary, and the 'init' process knows that it is init by verifying that it's pid equals 1 ... when init is started, it opens a pipe, which reads the commands given by telinit and halt, poweroff, etc. possible causes for this message therefor are: - init/telinit is called but not as pid == 1 - reboot, halt, poweroff are called without -f - init is started as 'faked' pid 1 but this doesn't work as expected yet ... possible solutions: - add some userspace tool outside the vserver which opens/reads the pipe and acts accordingly - find the 'bad' invocation and 'improve' it or remove it, if not required - demonstrate that it is a vserver misbehaviour which requires some code change ;) HTH, Herbert util-vserver-0.24 kernel-2.4.22-vs1.00 Allen Dale Parker [EMAIL PROTECTED] ego sum ens ompnipotens ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
