@Acorn HOWTO
This paper contains checklists and patches that can be used to get a Debian system running within a virtual host at Acorn Hosting. Information In the Acorn Configuration Hints document is not repeated here so do familiarize yourself with it as well. If neither this document nor the hints answer your question, then submit an Acorn Ticket.
Chances are you have a Debian vserver because you are familiar with it and know better than to run a Red Hat vserver. In case you are new to Debian, please take a look at the Debian web site as well as my introduction which highlights a few of the documents you should read first.
The first section discusses the packages or files that you will definitely have to edit. The optional section discusses my experiences with other packages that aren't mandatory but are included in the hopes that you'll find the information useful.
Here is an index of the files and packages described in this document. Those entries listed marked in this color indicate sections that include information that is particular to running at Acorn or in a vserver.
2007-07-28 Updated to etch. The bind version number and files that need to be installed with bind have changed. Note that Acorn no longer exists; you'll have to make other arrangements for defunct Acorn services listed here.
2007-02-21 Security update for Sarge. The bind installation requires a couple more packages, and the version number has changed. Otherwise, the directions are the same.
2006-02-13 Update for Sarge and new server. The adduser
section is gone. The file /etc/apt/apt.conf is now
in /etc/apt/apt.conf.d/local. I no
longer modify /etc/apache/httpd.conf
as all of the configuration is limited
to /etc/apache/local.conf which is now linked
from /etc/apache/conf.d. I now use Subversion instead of
CVS to maintain the web space. The name of the configuration files
changed with the new version of bind. Some of
the configuration variables changed
in Mailman and I added information about
the arch command for rebuilding the archives. Many of
these changes were reflected in the Moving
to Acorn Hosting section as well.
2004-01-07 You can't invoke daemontools from /etc/inittab. Cathy provides a list of
good hosts for /etc/apt/sources.list (see apt). You'll definitely want to replace
mynetworks with mynetworks_style and
update mydestinationin the postfix
configuration.
2003-12-30 Cathy deleted the virtual consoles in
/etc/inittab, I think (see inittab).
Networking is a new section that talks
about adjusting the MTU in your router. Use --force-confold and
--force-confdef instead of the more dangerous --force-confnew when
configuring apt. Don't seem to need to poke a
hole in the firewall at port 953 when configuring bind any more. Mention that Cathy would prefer
that you not run john if you don't have to.
New discussion using the new default version of postfix's configuration file. Added cool new
spam rules in a new etc.postfix.main.cf.spam
file. Mention that tomcat now stops cleanly.
Required
This section includes changes to the listed packages (or files)
that are required to run in a vserver (or any server for that
matter). If you don't run the package, then you can ignore the
sub-section.
/etc/hostname
Change the default value of debian in
/etc/hostname with your fully-qualified hostname. While the
Debian installation scripts seem to prefer a non-fully-qualified
hostname, it is customary for Internet hosts to have a
fully-qualified hostname. It is also strongly suggested to have a
fully-qualified hostname if you are running bind.
You also need to submit a ticket to
have your hostname switched on the server as well.
/etc/hosts
Add your IP address (run ifconfig). Use your
fully-qualified hostname as the official name as well as any
aliases you may use before DNS is running.
It's not required, but it might be helpful, to remove the
127.0.0.1 entry and add localhost to the
entry for your IP address.
/etc/inittab
The /etc/inittab file on the vserver is unusual in that
the entry for every virtual console has either already been
deleted, or should be commented out (and should stay commented
out) since we don't have virtual consoles. In addition, the
z6 entry is also commented out since it respawns
rapidly on the vserver.
Cathy tells me that daemontools doesn't work from inittab; you
need to start it from an script in /etc/init.d.
/etc/mailname
This usually contains your domain name. This is used by MTAs to
ensure that your return address looks like
login@domain.
/etc/timezone
This file is modified by running the tzsetup
command. If you're not sure which timezone to use, consider only
two timezones. One possibility is to use the timezone where the
machine is located. This is America/New_York (the
default). Another choice is to use the timezone where you are
located. I chose the latter, by the way.
apt
The version of /etc/apt/sources.list on your system may have the default Debian archives listed which may not be the closest and fastest sources available. Because ping doesn't work from a vserver, neither will netselect. However, Cathy has created this netselect listing to show the best sites.
One of the first things you should do is run apt-get
update && apt-get upgrade or dselect to get any
security updates that have been released since your virtual server
was created.
Networking
I found that my network connection from my machine at home to
my vserver hung when I copied large files. The solution to this
problem was to dial down the MTU in my router from 1500 to 1492.
Optional
This section includes changes to the listed packages that I
find useful. Your mileage may vary. I would appreciate your not
including these patches blindly. If you don't understand the
changes I made, please read the appropriate manuals and buy every
change before incorporating the patch wholesale.
apt
I use the file /etc/apt/apt.conf.d/local to alter the behavior of apt and dpkg. This file tells apt to show a list of updated packages before upgrading them and compiles sources automatically.
It also perform the default action on configuration files if
such an action is defined; otherwise, old versions of
configuration files will be preserved without asking.
apache
The local file /etc/apache/local.conf sets up some standard variables for my virtual host, performs some rewrites, and allows direct access to mailman. I created a link from /etc/apache/conf.d/local to it.
N.B. The local file is written expressly for my host. You may take ideas for them, but don't use them blindly, as it won't work and may allow me to break into your system if I woke up evil tomorrow.
I found a method to maintain my web site which is both
convenient and minimizes the chance that a user will see a
half-completed page. I first make changes to my system at home.
Once I am happy with my changes, I check them into Subversion and
then log into my Acorn host and run svn update. I
also run make as I have some Makefiles that compile
Java code, make links to directories, and convert Texinfo files
into HTML. If you have not used Subversion over the net before,
see the Subversion footnote.
bind9
Bind works in a vserver, but it is the only package so far that
must be recompiled to do so. Fortunately, the changes are limited
to removing the single option --disable-linux-caps
from the compilation (patch in example below).
Before you start building bind, enter a ticket to request a couple of holes in the firewall. You'll need TCP and UDP on port 53.
In the example below, the commands prefixed with the
# prompt must be run as root. The commands with the
$ prompt may be run as any user. Also, if you're
pulling sources from sid, as I do, you may need to specify a
specific version of the source that matches your installed system
(as in bind9=1:9.2.4-1sarge2) if you find that installing the
.debs requires updated versions of other non-bind packages.
# cd /usr/src
# mkdir bind9
# chmod 777 bind9
$ cd bind9
$ apt-get --no-build source bind9
$ cd bind9-9.4.1/debian
$ patch rules < rules.patch
$ cd ..
$ fakeroot dpkg-buildpackage -uc
$ cd ..
# dpkg --install bind9_9.4.1-1_i386.deb \
libbind9-30_9.4.1-1_i386.deb \
libdns32_9.4.1-1_i386.deb \
libisc32_9.4.1-1_i386.deb \
libisccc30_9.4.1-1_i386.deb \
libisccfg30_9.4.1-1_i386.deb \
liblwres30_9.4.1-1_i386.deb
Bind is also one of the few packages that required some
tweaking in the configuration file as well. In
/etc/bind/named.conf.options, I've modified the
options stanza as follows:
options {
directory "/var/cache/bind";
// Avoids listening on 127.0.0.1.
listen-on {
70.85.162.231;
};
forwarders {
207.218.192.38;
198.6.1.4;
198.6.1.5;
};
auth-nxdomain no; # conform to RFC1035
};
This differs from the default in that we're listening on our IP address. Substitute my IP address with your own. Listening on localhost doesn't work on a vserver. You can use the forwarders as is.
Another stanza that you have to add is to tell the control channel to listen on our IP address rather than localhost, again because we're running on a vserver. Replace my IP address with your own:
// Avoid listening on 127.0.0.1.
// This requires that the default-server option in /etc/bind/rndc.conf
// point to the IP address as well.
controls {
inet 70.85.162.231 allow {
70.85.162.231;
};
};
The rest of the configuration file is configured normally.
Next, you have to create the key for the control channel. Here are my /etc/bind/rndc.conf and /etc/bind/rndc.key files. You have to replace my IP address with your own in the former, again because we configured named to listen on our IP address--rather than localhost--for the control channel.
The file /etc/bind/rndc.key is created for you when bind
is installed. It's safer to use the one that the installation
created for you rather than mine. You need to replace the
key stanza in /etc/bind/rndc.conf with the
contents of your rndc.key file.
cron
I place my own scripts in /usr/local/etc/cron.daily, /usr/local/etc/cron.weekly, and /usr/local/etc/cron.monthly. I then add the following to /etc/crontab:
1 5 * * * root run-parts --report /usr/local/etc/cron.daily
5 5 * * 7 root run-parts --report /usr/local/etc/cron.weekly
15 7 1 * * root run-parts --report /usr/local/etc/cron.monthly
I run each of the above commands, as well as the ones that run
from /etc/cron.daily, /etc/cron.weekly, and
/etc/cron.monthly, using time(1) to see how
long each batch takes to run. Armed with this information, I can
pick starting times for each batch that do not overlap.
john
You use this package (or Crack) to ensure that your users are
using secure passwords. The patch to /etc/john-mail.conf
sets the passfile entry to
/var/local/lib/john/passwd. You must first create the
directory. I also set mailargs to root
so that I know when users are busted.
In addition, I run john with a modified cron script once a week (/usr/local/etc/cron.weekly/john) which uses additional dictionaries. It uses significant resources (for 2 hours) so I run it in the wee hours of Sunday morning.
It goes without saying (although Cathy would like me to say it)
that if you don't have any users, or your users can be trusted to
use effective passwords, then you do not have any need to run john
at all.
mailman
I
modified /etc/mailman/mm_cfg.py
to DEFAULT_EMAIL_HOST
and DEFAULT_URL_HOST to reasonable values (for me,
not for you). I also found I had to fix the value
of IMAGE_LOGOS and I also prettied up the value
of DEFAULT_URL_PATTERN. These two changes depend on
the corresponding Alias and ScriptAlias
entries I added to the end of
/etc/apache/local.conf (see package Apache).
Note that you have to specify a full address with a host part
as the administrator's address to the newlist
command. Otherwise, newlist gives you a usage
statement with no indication of what is wrong. You have been
warned.
If you rsynced the lists and archives from another machine, do
check that the ownership and permissions on all of the files and
directories are the same. Also, if the version of mailman differs,
you'll want to just rsync the mbox files rather than the entire
archive directories and run bin/arch -q
--wipe listname on them. If you know the list
databases are compatible, then you can rsync them. Or you can
simply verify that the list membership (and subscription options)
is the same on the two hosts.
nullmailer
The nullmailer package is removed when another MTA (such as postfix, below) is installed. I found that it was not removed cleanly and had to run the following to clean up the remnants:
# rm -r /etc/init.d/nullmailer /etc/nullmailer
# rm /etc/rc*.d/*20nullmailer /var/lib/dpkg/info/nullmailer.*
The copy of /etc/postfix/main.cf on your system should work with little modification. You will have to add all hostnames that will be used to send mail to your host to the mydestination variable, or set this variable to something like local-host-names and add the host names to a file of that name in the /etc/postfix directory.
The vservers sometimes interpret the value of 127.0.0.0 in the
mynetworks variable "creatively" allowing
postfix to relay mail from other vservers on the same physical
machine. The use of mynetworks_style = host
definitely prevents this from happening. This variable is ignored
if mynetworks is present, so be sure to delete the
mynetworks variable.
After you make any changes to postfix configuration files,
restart postfix with /etc/init.d/postfix restart.
Here are the spam
restrictions that I add to main.cf. I add them all to
smtpd_recipient_restrictions for simplicity. I use
warn_if_reject for those rules which may still have
more false positives than I'd like. Use your own judgement. (You
might find the script reject-check helpful to
determine this--replace my email address with your own.)
The local_recipient_maps entry bounces any mail
message that isn't addressed to a local user.
The line:
check_client_access hash:/var/lib/pop-before-smtp/hosts
is interesting. The file /var/lib/pop-before-smtp/hosts is
maintained by the pop-before-smtp package which adds hosts which
have successfully retrieved mail via POP. This rule allows you to
use your server as a mail relay from the host from which you
retrieved your mail. I found that many hosts are no longer
accepting mail from hosts on DSL and so I could no longer send
mail directly from my laptop when I was connected to such
networks.
The other spam restriction entries should be self-explanatory (and safe to use) if you look up their definitions in the manual. There is lots of good information in the URLs listed too.
You can accept mail from hosts that would ordinarily be considered spam sources by adding their IP address to /etc/postfix/access like this:
64.28.88.141 OK
If your mailing lists get repeat spammers, you can add something similar to the following to /etc/postfix/access:
bestoffersonthenet.com DISCARD
After editing /etc/postfix/access, run
postmap /etc/postfix/access
/etc/init.d/postfix restart
to make the change take effect. Alternatively, file a ticket to have repeat spammers blocked at the firewall.
Don't forget to update /etc/aliases. You want to be sure
to point postmaster to root. You then
want to point root to a real person. After that,
point MAILER-DAEMON, hostmaster,
abuse, info, spam,
support, and webmaster to either a real
person or root depending on your circumstance. I'd
suggest pointing nobody to /dev/null and all
of the system users in /etc/passwd to nobody
since most mail to them is spam. It is also common to set up
aliases in the form of first.last for each user on your
system.
sudo
I like using this package to perform actions as root for two reasons. One, it gives me a mental pause to reduce the chance of mistakes. Two, if I make a mistake, a log of root-enabled actions exists to help fix the problem.
If you want to use this package, copy the last line in
/etc/sudoers for root and replace
root with your login to give you all root privileges
with the sudo command.
tomcat4
Tomcat4 works. Calling /etc/init.d/tomcat stop
used to hang for me so that I had to kill the Java processes
manually with killall, but it no longer does. Your
mileage may vary
Moving to Acorn Hosting
This section isn't related to Debian, but if you're reading this, chances are you're in the process from moving a server of yours to Acorn Hosting. Here is a checklist I used when doing this to reduce the downtime for my users.
At least two weeks before the switch, I let my users know a move was imminent, but that if all went well, they wouldn't notice that anything had changed. I then set the TTL and other expiration times in my DNS records to 1 day. I set up bind on my host at Acorn and added it as a nameserver at my domain name provider. I then updated my IP address in the configuration files at my DNS secondaries. I set up Apache.
A couple of days before the switch, I created the user accounts and rsynced /home. I set up mailman, copied the aliases from my original server, and rsynced /var/lib/mailman/{archives,lists} and tested the lists. I sent out an email and directed the users to change their passwords, but to do nothing else as a final rsync would occur at the time of the switch. If your users were accustomed to large, green pastures, you should inform them that space comes at a premium and that they should remove any files not needed on a server (such as browser caches). Set the DNS TTL and expiration times between 10 minutes and one hour.
At the time of the switch, I first sent a quick email to tell folks not to retrieve their mail. I ensured that they couldn't by stopping sendmail, postfix, and ipop3d on my original host and on my host at Acorn. I then rsynced /var/lib/mailman/{archives,lists}. I then edited /etc/aliases to forward mail to lists and all users to my host at Acorn. I then flipped the addresses for the various service hostnames (such as www and mail) in my DNS zone file from my original host to my host at Acorn. Since I was running bind at Acorn, I had to do this in both places. I then did a final rsync of the home directories as well as /var/mail. I then started postfix on my Acorn host and sendmail on my original host. At this point, MTAs picked up the IP address for my new mail server and sent the mail off to my Acorn host. If an MTA had a cached value, it sent the mail to my old host which then forwarded it to the Acorn host. Since Apache was running at both hosts, users would see the same data whether they had a new or old IP address for www. Most folks should have your new address within 15-60 minutes, depending on how you set your expiration times. Send an email to let folks know things are back in business.
A week or two after the switch set your TTL and expiration times in your zone file to normal values. Decommission the nameserver at your original host if you wish by removing the master zone record in /etc/bind/named.conf.local at the original host and by removing its address at your domain name provider.
We've had two severe power outages in the few weeks that my domain has been hosted at Acorn, and I was fully able to relax, not worry, and have a homebrew because my domain was still available to the public even though my house was dark.
The switch was a success!
Postscript. Later, when switching hosts from a crashing
host to another, I found that in order to forward mail to the new
host from the old host, I had to comment
out mail.newt.com
in /etc/postfix/local-host-names and
use user@mail.newt.com in the aliases file on
the old host. This wasn't enough for virtual hosts, however, and I
had to append @mail.newt.com to the users on the
right-hand side in the /etc/postfix/virtual file, also on
the old host. During this switch, I found that many hosts on the
net did not get the updated records with the short TTLs. I
suspect, but I'm not sure, that this is because I did not update
the serial on the old host since I didn't want that version to be
pushed to the secondaries. But this might have kept the local
server from using it! Bumping the last digit in the serial might
have done the trick while not updating the secondary assuming that
the date in the serial is older than the date in the serial on the
new server.
Unlike CVS, you simply have to state the correct URL to your
repository. If you use file:///path/to/repository at home,
use svn+ssh://host/path/to/repository from across the
network.
CVS
It is a good idea to use ssh when using CVS over the network. To do this, set the following two environment variables:
$ export CVS_RSH=ssh
$ export CVSROOT=login@host.domain:/path/to/cvsroot
You might also read that the CVSROOT variable must
start with :ext: in this case. However, I find it is
not necessary in practice. Your mileage may vary.
|
Copyright © 2002, 2003 Bill Wohler Last modified: 2003 About photos |
Free DNS |