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. :-)
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.
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.
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.rpmor
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.
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:
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.
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 Slartibartfast.pa.net 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:
goober.com /var/named/db.goober.com(or wherever you plan to keep the db file)
Create /var/named/db.goober.com 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 goober.com (ORIGIN assumed goober.com)
;
$ttl 38400
$ORIGIN com.
goober IN SOA slartibartfast.pa.net. root.slartibartfast.pa.net. (
2002100402 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
7200 ; Minimum 2 hours
)
goober.com. IN NS slartibartfast.pa.net.
goober.com. IN NS secondary-dns.not-slart.com.
goober.com. IN MX 5 mail.goober.com.
$ORIGIN goober.com.
localhost IN A 127.0.0.1
goober.com. 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 goober.com. 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 goober.com; you'll define mail.goober.com'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 goober.com and turn them into "goober.com.com" 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 www.goober.com to one IP and ftp.goober.com to another. The second line (note the trailing dot!), which seems redundant, exists to handle the case where a user enters "http://goober.com/" without the www.
Keep in mind that the prefixes you choose here do not imply specific protocols -- in other words, "www.goober.com" 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. (Joker.com 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 secondary-dns.not-slart.com. (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 goober.com 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 www.goober.com, 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 www.goober.comSee if the results point to the correct IP.
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
#<snip>
# ...
# 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 webmaster@dummy-host.example.com
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>
# www.yourfirstdomain.com
<VirtualHost *>
ServerAdmin your-email@whatever.com
DocumentRoot /home/www.yourfirstdomain.com/html
ServerName www.yourfirstdomain.com
ScriptAlias /cgi-bin/ /home/www.yourfirstdomain.com/cgi-bin/
ErrorLog logs/www.yourfirstdomain.com-error_log
TransferLog logs/www.yourfirstdomain.com-access_log
<Directory /home/www.yourfirstdomain.com/html>
Options Indexes FollowSymLinks
</Directory>
</VirtualHost>
# www.yourseconddomain.com
<VirtualHost *>
ServerAdmin your-email@whatever.com
DocumentRoot /home/www.yourseconddomain.com/html
ServerName www.yourseconddomain.com
ScriptAlias /cgi-bin/ /home/www.yourseconddomain.com/cgi-bin/
ErrorLog logs/www.yourseconddomain.com-error_log
TransferLog logs/www.yourseconddomain.com-access_log
<Directory /home/www.yourseconddomain.com/html>
Options Indexes FollowSymLinks
</Directory>
</VirtualHost>
Create appropriate directories for each website's HTML, cgi, etc. and restart httpd. Assuming the example above, if a user enters "http://www.yourfirstdomain.com/" into his browser, he will receive the index.html (if it exists) that resides in /home/www.yourfirstdomain.com/html/. If he enters "http://www.yourseconddomain.com/" 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 "http://www.yourfirstdomain.com/~username/" AND via "http://www.yourseconddomain.com/~username/". There is probably a way around that, but I didn't care. :)
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. 66.59.xxx.xxx # (your umlŐs IP) mail.goober.com # probably donŐt need this, only the next line goober.com anotherdomain.comThen, edit /etc/mail/access and add your domain(s):
# by default we allow relaying from localhost... localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY goober.com RELAY foobar.com RELAYNow, edit /etc/sendmail.cf (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=127.0.0.1,Move the Addr= part to its own line and comment it out, leaving:
#Addr=127.0.0.1, O DaemonPortOptions=Port=smtp, Name=MTAThis 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 25You should get back something like this:
Trying 66.59.xxx.xxx... Connected to goober.com. Escape character is '^]'. 220 goober.com ESMTP Sendmail 8.11.6/8.11.6; Wed, 9 Oct 2002 11:34:02 -0400From here on, your entries are left-justified, the server responses are indented:
HELO GOOBER.COM 250 whoopis.com Hello [66.59.111.182], pleased to meet you MAIL FROM: mbates@dartmouth.edu 250 2.1.0 mbates@dartmouth.edu... Sender ok RCPT TO: root@whoopis.com 250 2.1.5 root@whoopis.com... Recipient ok DATA (return) 354 Enter mail, end with "." on a line by itselfType some message, then:
. (return) 250 2.0.0 g99FgAK00839 Message accepted for deliveryExit 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:
MAIL FROM: spleen@yahoo.com (Sender ok) RCPT TO: goober@netscape.com (550 5.7.1 goober@netscape.com... Relaying denied. IP name lookup failed [66.59.xxx.xxx] )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 goober.com MX ; <<>> DiG 9.2.1 <<>> goober.com 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 ;; QUESTION SECTION: ;goober.com. IN MX ;; ANSWER SECTION: goober.com. 38400 IN MX 5 mail.goober.com.If all you want to do is be able to receive mail for username@domain.com, 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 yourusername@yourdomain.com 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, "sales@yourdomain.com"), you can either create accounts for those users (unnecessary) or edit /etc/mail/virtusertable (this file also allows you to have "info@firstdomain.com" and "info@seconddomain.com" go to different accounts, if you are doing multiple virtual hostnames):
info@domain1.com joeblow@randomisp.com info@domain2.com localuser @domain3.com anotherlocaluser @domain4.org user@otherisp.comNote line 2. If you want to direct "info@domain2.com" to a user account on THIS system, do not add @domain.com -- in other words, if your domain is goober.com, and your email account is joeblow@goober.com, just put joeblow in the second column.
Furthermore, there is rule-ordering possible in the virtusertable file. See the following:
user1@goober.com user1 user2@goober.com user2 user3@goober.com user3 user1@foobar.com user4 user2@foobar.com user5 @goober.com user1 @foobar.com user4This allows your real users to get their email, and anything else @goober.com 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 webmaster@goober.com, user1 (you, probably) will receive it. And this works for your other domains as well. Be careful not to enter this into virtusertable:
@whoopis.com mbates@whoopis.comOr you get this:
----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mail.whoopis.com.: >>> RCPT To: <<< 554 5.0.0 rewrite: excessive recursion (max 50), ruleset canonify 554 ... Service unavailableIn other words, sendmail went into a bad loop trying to re-direct whoopis.com 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 0.0.0.0:993 0.0.0.0:* LISTEN 1339/xinetd tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 1339/xinetdPort 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 Trying 127.0.0.1... 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) A0001 LOGOUT * BYE whoopis.com 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 mail.goober.com (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
goober:/var/spool/mail/usernameThen 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 <wstearns@pobox.com>.
Last edited: 10/10/2002
Best viewed with something that can show web pages... <grin>