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.

I'm terribly pleased that Marion has generously agreed to contribute some more information on server setup to this project. Please read on for more information on DNS, Web hosting, and Email server (Sendmail and IMAP) setup. Many thanks, Marion. :-)

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
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 . 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@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 for more info.


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.


You get a single IP address for your virtual machine. Any servers you run can be found at that address.

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.


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.

(some) Answers to (some) Common Questions
about Administering Your UML

by William Stearns <wstearns at>
transcribed by Marion Bates <mbates at>

Students of computer science are probably familiar with the famous thought experiment put forth by philosopher John Searle -- "The Chinese Room." Searle developed the idea of an "operator" alone in a room with nothing but a dictionary of Chinese characters (the operator speaks no Chinese), who exchanges slips of paper with another entity through a slot in the wall. These slips of paper contain instructions that the operator cannot understand (because they're in Chinese), but he can look them up in his dictionary and write down more characters to "respond." Searle's point is that the operator in the room does not need to possess intelligence to manipulate symbols and thus "appear to understand" the symbols on the little slips of paper, and therefore he concludes that the Turing Test of machine intelligence is flawed.

When it comes to Linux system administration, I am, in many cases, the operator in the Chinese room. I know what to type to make the following things work, but I don't really know what it all means. So, take this howto with an enormous boulder of salt. :)


I have not yet tried running BIND on my own UML, so this is incomplete. I use the UML (hereafter known as "slart") to do DNS for me. But this info would still be applicable -- they just assume that BIND is already installed and running. You should perform the following steps BEFORE you register your domain name, because some registrars will poll the DNS servers you specify before allowing you to claim the domain name. You will need root privileges for the next few steps. On the DNS server, edit /etc/named.conf. This is where you will specify the location of the db file for your new domain. You should add a line like the following:	/var/named/
(or wherever you plan to keep the db file)

Create /var/named/ and edit it in your favorite text editor, which should be vim. ;) Here is a template. Note that this template assumes that you are using slart as the primary DNS server:

; Authoritative data for (ORIGIN assumed

$ttl 38400
$ORIGIN com.
goober         IN      SOA (
                2002100402      ; Serial
                10800           ; Refresh 3 hours
                3600            ; Retry 1 hour
                3600000         ; Expire 1000 hours
                7200            ; Minimum 2 hours
                )    IN      NS    IN      NS    IN      MX      5

localhost       IN      A   	IN      A       your.uml.ip.address
mail            IN      A       your.uml.ip.address
www             IN      A       your.uml.ip.address
ftp             IN      A       your.uml.ip.address
What these things mean:

The first three lines (preceded by semicolons) are comments. $ttl is time to live, Bill what does that mean in this context? $ORIGIN is a variable defined for this file, I forget how it works here, duh sorry.

The next block of text designates slart as the SOA (Start Of Authority) for this domain, and specifies some time limits for how long the domain information is cached. The first number, "Serial", is key -- you will need to update this number BEFORE you restart named, otherwise the db file will not be read in. If you are making changes for the first time on a given day, the serial number ought to be of the format YYYYMMDD01. Year, month, today's date, and number 01. If you edit the file again on the same day, increment the number to 02, etc. If you edit the file the next day, reset the trailing number to 01 and increment the date appropriately.

The next block defines both primary and secondary nameservers for The secondary nameserver ideally ought to be on a different network from the primary, to maximize redundancy. A good idea is to swap secondary DNS duties with the admin of another server (i.e., you each do secondary DNS for each other's domains). The third line here tells named where to send email for; you'll define's IP later. The 5 represents mailserver priority (or something? help)

Note the trailing dots (".com.") in all of these entries. If you leave those off, named will try to resolve requests for and turn them into "" etc. Also note that up to this point, we are only using domain names, not IP addresses.

The last block defines the possible prefixes of your domain. These will probably all point to your UML, but you can have them correspond to separate IPs -- for example, direct to one IP and to another. The second line (note the trailing dot!), which seems redundant, exists to handle the case where a user enters "" without the www.

Keep in mind that the prefixes you choose here do not imply specific protocols -- in other words, "" does not have to be a webserver, nor does "ftp" have to be a file server, etc. -- the names and their implied protocols are meaningless, as far named is concerned. Here, you are simply accounting for whatever possible domain name strings you expect users to type, or that you yourself want to have. The user's use of "http://" or an FTP program will determine what ports/services they connect to on your UML.

You will need to restart named for your changes to take effect (don't forget to update the serial number).

Once you've configured named on your end, you can go to your favorite registrar and register your domain. Be careful about the registrar's options -- you do NOT want their company to "park" your domain! That would mean that THEIR nameservers are claiming authority for your domain. Some registrars will have an "advanced" button or something similar; whatever they call it, you want to be taken to a screen where you can specify the nameservers for your domain. ( definitely allows this.) In our example, the first nameserver is slart (you'll need to know the domain name and IP of each of your nameservers) and the secondary is (with its corresponding IP). After a day or two, your domain registration will percolate up to the root nameservers, and they will direct requests for to slart (or to the secondary, if slart is unavailable).

If you want to test things before the registration has taken effect, you can do so by editing /etc/resolv.conf on your local machine such that the only nameserver listed is the primary you specified for your domain (in this case, resolv.conf would have just slart's IP). Then try accessing, etc. If you have problems, check the syntax in the db file (make sure the dots are all where they're supposed to be, that you used names or IPs where appropriate, check the serial number, etc.) Or, start nslookup and type:

server slart 	# or your primary DNS server
set type=A
See if the results point to the correct IP.

II. Web hosting with Apache's VirtualHosts option

If you have registered multiple domains, and you want to serve webpages for each of them from your single UML, you can achieve this through the use of the VirtualHosts directive in /etc/httpd/conf/httpd.conf. Scroll down until you find the Virtual Hosts section, and edit it accordingly, using the following as a template:

### Section 3: Virtual Hosts
# ...
# Use name-based virtual hosting.
NameVirtualHost *

# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#<VirtualHost *>
#    ServerAdmin
#    DocumentRoot /www/docs/
#    ServerName
#    ErrorLog logs/
#    CustomLog logs/ common

<VirtualHost *>
        DocumentRoot /home/
        ScriptAlias /cgi-bin/ /home/
        ErrorLog logs/
        TransferLog logs/
        <Directory /home/>
                Options Indexes FollowSymLinks

<VirtualHost *>
        DocumentRoot /home/
        ScriptAlias /cgi-bin/ /home/
        ErrorLog logs/
        TransferLog logs/
        <Directory /home/>
                Options Indexes FollowSymLinks

Create appropriate directories for each website's HTML, cgi, etc. and restart httpd. Assuming the example above, if a user enters "" into his browser, he will receive the index.html (if it exists) that resides in /home/ If he enters "" into the browser, he'll get that domain's index.html file instead. Apache will hand off the appropriate set of HTML files based on the name it gets from the user.

Note that if you enable public_html directories for the users on your UML, they will, under this setup, be accessible via "" AND via "". There is probably a way around that, but I didn't care. :)

III. Email with sendmail and IMAP

As root, on your UML (soon to be mailserver), edit /etc/mail/local-host-names -- add the domains for which you want to handle email. A template:

# local-host-names - include all aliases for your machine here. 		# (your umlŐs IP)		# probably donŐt need this, only the next line
Then, edit /etc/mail/access and add your domain(s):
# by default we allow relaying from localhost...
localhost.localdomain	RELAY
localhost				RELAY				RELAY				RELAY				RELAY
Now, edit /etc/ (good idea to make a backup copy first) and find the line that says "# SMTP daemon options". Below that there should be a line that looks like the following:
O DaemonPortOptions=Port=smtp, Name=MTA, Addr=,
Move the Addr= part to its own line and comment it out, leaving:
#Addr=, O DaemonPortOptions=Port=smtp, Name=MTA
This allows sendmail to receive connections from hosts besides localhost. Save changes and restart sendmail.

In a separate terminal, type tail -f /var/log/maillog so you can see what sendmail's doing as you begin testing. From another terminal, type

telnet your-uml-ip 25
You should get back something like this:
	Trying Connected to Escape character is '^]'. 220 ESMTP Sendmail 8.11.6/8.11.6; Wed, 9 Oct 2002 11:34:02 -0400
From here on, your entries are left-justified, the server responses are indented:
	250 Hello [], pleased to meet you


	250 2.1.0 Sender ok


	250 2.1.5 Recipient ok

DATA (return)

	354 Enter mail, end with "." on a line by itself
Type some message, then:
.  (return)

	250 2.0.0 g99FgAK00839 Message accepted for delivery
Exit session and quit telnet.

Make sure that you're not an open spam relay. Do same as above, except use different email addresses, neither of which are listed in local-domains -- for example:

	(Sender ok) 
	(550 5.7.1 Relaying denied. 
	IP name lookup failed [] )
Current versions of sendmail should be configured to deny relaying by default, but make sure.

If, when you send normal email to your new mail accounts, you get majordomo errors regarding name service, check your DNS db records and make sure you defined the MX record properly. Check with dig:

bash-2.05a# dig MX

	; <<>> DiG 9.2.1 <<>> MX
	;; global options: printcmd
	;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11482
	;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

	; IN MX

If all you want to do is be able to receive mail for, then you're basically done. Create a .forward file in your home directory and put your "real" email address in there; now, email sent to will be forwarded to your real address.

If you want to be able to have other various email addresses routed to certain accounts (for example, ""), you can either create accounts for those users (unnecessary) or edit /etc/mail/virtusertable (this file also allows you to have "" and "" go to different accounts, if you are doing multiple virtual hostnames): 	localuser 		anotherlocaluser
Note line 2. If you want to direct "" to a user account on THIS system, do not add -- in other words, if your domain is, and your email account is, just put joeblow in the second column.

Furthermore, there is rule-ordering possible in the virtusertable file. See the following:    user1    user2	user3 	user4 	user5    		user1       	user4
This allows your real users to get their email, and anything else will go to user1. So, if your customers take a guess that you've got a webmaster account (which you may not have explicitly defined) and they try sending email to, user1 (you, probably) will receive it. And this works for your other domains as well. Be careful not to enter this into virtusertable:
Or you get this:
----- The following addresses had permanent fatal errors -----

----- Transcript of session follows ----- ... while talking to >>> RCPT To: <<< 554 5.0.0 rewrite: excessive recursion (max
50), ruleset canonify 554 ... Service unavailable

In other words, sendmail went into a bad loop trying to re-direct email to itself.

Now, if you want to do more than just .forward your domain's mail, i.e., you want to be able to login and send/receive mail from this account directly, you can set up IMAP to do this. Check to see if IMAP is installed (rpm -q imap for RedHat users). If it is, edit /etc/xinetd.d/imap (and imaps if you want to do SSL-enabled IMAP, but you have to generate an SSL certificate first, which I don't know how to do). Find the line that says disable=yes and change it to disable=no. Reload/restart xinetd. Check with netstat to see if IMAP is running:

bash-2.05a# netstat -anp | egrep '(:110|:143|:993)'
tcp        0      0   *               LISTEN      1339/xinetd         
tcp        0      0   *               LISTEN      1339/xinetd    
Port 143 is IMAP, port 993 is IMAPS.

You can test it by hand, as with sendmail, but it's slightly different. Type:

telnet localhost 143

	Connected to localhost.
	Escape character is '^]'.
	* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] localhost IMAP4rev1 2001.315rh at Wed, 9 Oct 2002 17:21:51 -0400 (EDT)


	* BYE IMAP4rev1 server terminating connection
	A0001 OK LOGOUT completed
	Connection closed by foreign host.
If you get that, then it's working.

Now configure your mail client (and move/rename your .forward file, if you had one). The fields in your mail client should be self-explanatory -- your mailserver for both IMAP and SMTP is (unless you named it something else in the db file) and your username and password are what you use to log in to your uml. In my case, the tricky part was specifying the path to the actual mail -- my client at first thought that my entire home directory was email, and dutifully fetched all my web files etc. and made them into email messages. :) In my client settings, there was a slot for Account Path Prefix (it may have another name in a different client) and I filled in

Then it worked just fine. Your Mileage May Vary.

The end, for now...


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

Last edited: 10/10/2002

Best viewed with something that can show web pages... <grin>