Encountered the PE1650 LVM root caveat. Hardware_Documentation/PE1650_+_Lenny_Caveat

Setting up Xen on the Dom0:

apt-get install xen-linux-system-2.6.26-2-xen-686
apt-get install libc6-xen
apt-get install xen-utils
apt-get install bridge-utils

Edit /boot/grub/menu.lst:

# kopt=root=/dev/mapper/dy.root-dy.root ro
# xenhopt=com1=9600,8n1 console=com1
# xenkopt=console=hvc0

Add to /etc/inittab:

H0:2345:respawn:/sbin/getty 38400 hvc0

Modify /etc/network/interfaces:

s/allow-hotplug/auto/g
s/eth0/br0/g
for br0 stanza, add "bridge_ports eth0"
add "inet manual" br1 stanza, empty except for "bridge_ports eth1" and "bridge_maxwait 0"

Reboot into Xen.

apt-get install sudo

Add the following to /etc/sudoers:

console ALL=(root) NOPASSWD: /usr/sbin/xm console *

Setting up the DomU:

Not that special...

Big thing is network configuration. Add eth1 stanza for the console network.

In the Xen configuration, make sure the vifs are connected to the right ethernet bridges. I.e., eth0 => br0 for the club subnet, eth1 => br1 for the console network.

Need some packages that debootstrap doesn't install, but awesie's script takes care of it.

May need to manually install libc6-xen.

Pre-requisites:

apt-get install daemontools daemontools-run telnet # screen
# At the present lenny-cclub isn't really set up, and we need a MAXWIN-patched screen
scp unix:~kbare/console/screen_4.0.3-11+cclub.002_i386.deb /tmp # or _amd64.deb
dpkg -i /tmp/screen_4.0.3-11+cclub.002_i386.deb # or _amd64.deb

Approximately How the Thing Works

If you know anything about about how the console worked on GALLIUM, this configuration is pretty similar. There's just extra indirection to let the thing grow and breathe.

First, the layout of /var/console:

by-name/

directory of symlinks, where each symlink is the name of a screen/machine

by-number/

directory of symlinks, where each symlink is the number of a screen

console.keytab

keytab used when SSH-ing to Xen Dom0s, for Xen consoles

dirs/

actual directories where screen-specific files are stored (i.e, by-name and by-number symlinks have targets in here)

dirs/*/name

indicates the name of the screen/machine this directory is for

dirs/*/number

indicates the number of the screen this directory is for

dirs/*/portspec

port specifier for this directory; a script in specs/, and its arguments

fifos/

numbered fifos used for the associated screen number's logging output

logs/

log directories, for each screen/machine name

logs-by-number/

symlinks to the log directories for the associated screen numbers

running

if present, indicates that the console screen session is currently running

screenrc

generated screen configuration

specs/

directory of scripts implementing various types of consoles

specs/portmaster

script for connecting to a console via one of the portmasters

specs/xmconsole

script for connecting to a Xen DomU's console

svc/

directory of supervise directories

svc/log-*/

supervise directory for logging the given screen number

svc/port-*/

supervise directory for connecting to the console for the given screen number

svc/screen/

supervise directory for the console screen session

So, there's a lot of indirection via symlinks. This perhaps makes maintaining the directory more difficult, but there's a script for doing that. Indirection does however give us the nice property that it's a lot easier to move things around without essentially deleting and re-creating each port.

So, more as to how it works.

This is taken from the GALLIUM console. Essentially, each screen is a script that's run by supervise. That way, if a telnet session dies, supervise will restart it. To set up the screens, we use a screenrc file. We also enable logging for each screen in the screenrc file. The script generates the screenrc, since making it by hand would be painful.

A bit more on portspecs. These are a :-separated list of strings. The first element is the name of a script in the specs/ directory. The following elements are the arguments to the script. If you need a colon in any of the arguments, you should be able to escape it with a '\'. Probably can also avoid escaping a colon by escaping the '\' with another '\'. But, the regexes implementing this are scary, so it might not work.

The two scripts so far are:

Logging attempts to keep the logs for a given _machine_ in the same place no matter what screen number the machine happens to be on. As a result, logs are for names, and numbers can point to different names. For example, if machine foo is on screen number 10, and then moves to screen number 12, and one tells this to the script, all logging for the machine foo will go to the log for foo, except for the brief window when the console's notion of the screen to machine mapping is wrong.

Umm... I'm not really remembering what else I was going to say about the script. Here's its usage information:

console:~# console-setup/console-setup.pl 
USAGE: console-setup.pl <command>

Where <commmand> is one of:
        delete  (-n <num> | <name>)
        init
        rename  (-n <num> | <name>) <newname>
        set     [-n <num>] <name> <portspec>
        start
        stop

Currently there isn't a renumber command, but it probably wouldn't require much effort to add one.

The Code

https://svn.club.cc.cmu.edu/cclub/console-setup/trunk

kbare at CLUB.CC.CMU.EDU/Console Notes (last edited 2009-11-14 23:05:03 by kbare)