Hi, I have an idea for solving the lack of console issue for fakeinit vservers. I would like to run it past this list before I start coding.
The problem is basically this: /dev/console in a vserver should not be the same device node as in the root host. If it was, then all contexts would share the same real console which is both a security issue and messy with regards to program output. /dev/console can also not just be a regular file, because /sbin/init assumes that it has the properties of a real or pseudo-terminal. When some of the calls it makes (fcntl, tcgetattr, tcsetattr, tcflush etc) fail, init gives up. It would be nice to: a) give init what it thinks is a real console b) store the output from this "console" for viewing from the root host or vserver c) not steal any valid pty/tty's (eg tty9, tty10) from the root host (this wouldn't scale) d) not heavily modify the kernel to do this We already have dynamic pty allocation available through /dev/ptmx and /dev/pts. My idea is when starting a vserver, open a new pty and create /vservers/$vs/dev/console with the same major and minor numbers. For all intensive purposes init thinks this is ok and continues merrily on its way. Anything written to this device is copied to a normal file somewhere for viewing as desired. There are a couple of issues (which I believe can be coded around): * The pty creation should be done in the same context as the vserver so that no other contexts can see it. However most vservers don't have the capability of creating device nodes * The process that creates the pty has to stay alive for the lifetime of the vserver. It also cannot exec init directly because the first thing init does is close all open file descriptors. We also want the file descriptor/pty released when the virtual server is stopped. I think this can be done with a small new binary, and some hacking of the vserver script. I wouldn't mind hearing some feedback before I start working on this so please mail your comments. Thanks, Mark. -- [EMAIL PROTECTED]
