Good day, all. Here are a few notes on using your virtual machine on Zaphod. They're not intended to be a complete guide to using Linux, but a few notes on how your virtual machine is set up.

Sharing the system

While User-Mode Linux and the host system will do their best to share resources evenly, keep in mind that you are sharing a physical box.

What you get

Your virtual machine has:

Note that all of the above are completely negotiable - I'm happy to extend any of the above limits.

Simple math with 25+ users and the above limits shows we are oversubscribing on memory and disk; that's not a problem. I've talked quite a bit with Jeff Dike and we agree that since not everyone is going to use all the resources given, we can quite reasonably share this way.

I would like to sincerely encourage you to put anything you need to store somewhere under /home. If you later decide to upgrade to a new Redhat or simply want to move to a new distribution, it's trivial to carry the files in /home along. Anything in / needs to be identified and manually carried over, and that takes a bit of time.

If you know you're going to be creating content that would normally fall in a directory under /, the best approach is to make a directory under /home, move the files there, delete the old directory, and make a symlink to the corresponding directory. For example:

mkdir /home/var/named
mv /var/named/* /home/var/named
rmdir /var/named
ln -sf ../../home/var/named /var/named

Now all your files get actually saved in /home, making it much easier to do things like replace a root filesystem, should you ever want to.

/shared is for files you'd like to make available to anyone else with a virtual machine on Zaphod. /pub is for files you're willing to share with anyone in the world. As I set up your virtual machines, I will set up directories to which each of us can write under those two. Later I'll set up a virtual machine that will publish aything in /pub via web, ftp, and rsync.

Applications and distributions

If you're missing Linux rpm packages, they're all available in /pub/mirrors/rh73updates or /pub/mirrors/rh73 . You can install them with 

rpm -Uvh /pub/mirrors/rh73updates/name_of_package.rpm
or 
rpm -Uvh /pub/mirrors/rh73/name_of_package.rpm

If you'd like to use a distribution other than Redhat 7.3, no problem! Take a look at the distributions available at http://uml-pub.ists.dartmouth.edu/uml/ . If one of those appeals to you, I can pull those in. If you have a UML root filesystem from some other location I can get those too. Please let me know.

I've already had three requests for a debian root filesystem, and Jereme has offered to send me a URL for debian woody. My understanding from Jonas is that a quick change to an apt configuration file and an "apt-get dist-upgrade" or something like that should let you move up to one of the other debian distributions without too much work.

I'll be setting up a virtual machine that will pull down files from ftp, http, or rsync servers every 6 hours. If you have a collection of files you'd like to have automatically pulled (and placed in /pub/) please give me the URL to the site or mirror from which the content should come.

You should be able to run any applications that would run on a normal linux system, with the exception of a very small number of programs that need to talk directly to hardware (hwclock, X windows servers, scanner applications, fdisk, hardware probe tools, etc.). To run command line apps, simply ssh to your system and run them:

[wstearns@sparrow wstearns]$ whoami
wstearns
[wstearns@sparrow wstearns]$ mcedit
#Midnight commander's editor starts up.

To run X windows (graphical applications), just run them with an ampersand at the end to get your prompt back:

[wstearns@sparrow wstearns]$ xclock &
[1] 6974
[wstearns@sparrow wstearns]$

SSH will carry the graphical output back to your own box; see http://www.stearns.org/doc/ssh-techniques.current.html for more info.

Snapshots

The files you store in in / and /home can be snapshotted. If you get to a point where the system is set up just the way you want it, I can make copies of your root and /home filesystems. Think of them as backups in case of emergency. Also, we can roll back you system to the last good snapshot if you are ever broken into or lose some crucial files.

As drive space fills, old backups will be the first things I'll ask people about removing. :-)

To actually do this, you'll shut down your virtual machine with the halt command, I'll make copies of your filesystems, and then start your machine back up again. This isn't automatic - let me know if you'd like to do this and we can arrange a time to do so.

Addresses

You get a single IP address for your virtual machine. Any servers you run can be found at that address. Your IP address will be 66.59.11.X, where X is between 160 and 191.

If you'd like a second virtual machine for some reason, or if you simply don't need to run your own servers, I have an unlimited number of private addresses that can be assigned to your machines. We can set up networking in such a way that you can ssh to them.

Privacy

Your virtual system is yours and yours alone. I do set up a root password with you over the phone, but that is temporary and you should change it as soon as you've logged in.

At the moment, I'm the only one with access to the host system, although Jeff Dike may get access to the host for UML troubleshooting and I may get some backup admins at some point. While I do not have direct access to your VM (you did change your root password, right?), I can indirectly see and do some things from the host:

Seeing Processes
I can get a list of all the tasks running on the host or in VM's, including the actual program names. I will do this from time to time as part of running top or ps.
Process priority
I can also change the "nice" level of a task up or down to give it less or more priority for processor time. I may do this for surprise processor hogs until we can discuss them.
Killing or pausing processes
I have the ability to kill off or pause individual processes as well, although this tends to be dicey. I would only use this ability to kill a runaway process, and would get in touch with you about it.
Killing or pausing VM's
In the case of an entire VM that's out of control - and I don't see this happening much, if at all - I can kill off or pause the entire VM.
Viewing or modifying files
I can technically see, mount, and modify any of your filesystems. I won't do this without your permission or an order from a law enforcement agency.
Sniffing and firewalling network traffic
As all your packets get routed through the host, I also have the ability to sniff, record, and or firewall network traffic. On the other hand, so does the ISP. :-)
Terminal session sniffing
There's a custom patch to the UML kernel designed for honeypots where the UML kernel will record all traffic flowing to a pty and all traffic coming back from that terminal session - even if the session is encrypted with ssh. I will not use that patch in the kernel used by subscribers, although I will use it for non-subscriber VM's (honeypots and automated process VM's, for example).

Don't let the above list scare you. I'm letting you know the privacy issues in using a shared machine, and they're better than using a machine with a root user. I've let you know under what circumstances I'd do the above. I'm hoping you know me well enough to put some trust in my respect for your privacy.

You can run anything you'd like in your VM. In the interest of sharing the host resources, I'd ask that you pay attention to your CPU, disk, memory and network bandwidth utilization. If you think you'll need quite a bit of any of the first 3, please let me (William) know - we can probably work something out. If you expect a spike in network utilization, please try to let me or Pat know in advance.

Problems?

If you come across any problems or have any requests, please let me know. William Stearns <wstearns@pobox.com>.