We would not be geeks if we did not maintain our own server. The machine that currently hosts this site is fairly complicated. Recently I asked Ryder to help us out with some admin task for the mail server that we host. And I felt like I need to give him a foundation on how the current server works.

The current machine "kungfu" is running 5 virtual servers and some services on the host os.

Host OS

The Ubuntu Server os on the kungfu machine is running a few things natively: Bind for DNS, Apache2, Tomcat with Coccon, and firehol for firewall and port forwarding.

Apache2 listens to port 80 and responds directly to geekspeak.org and some of troxell.com and all non-coccon web requests are redirected using mod-proxy to either port 8080, port 5080 or port 300? which are different virtual servers running Apache2 or, in the case of the rails apps, Mongrel.

Firehol redirects ports 25, 143 and 993 to 7025, 7143 and 7993 respectively. Those ports are the public ports for the mail virtual. The mail virtual thinks that is is being accessed by 10.0.2.2 on ports 25, 143 and 993. As you can see this gets fairly complicated. I find that you have to use 7025 to telnet from the machine or from the virtuals. telnet 10.0.2.2 7025 works from the web virtual.

So, the firewall rules must be a little messed up. I think that port 25 redirects to 7025 but only for eth0, Miles and I want to set up the virtules as a subnet and then use NAT. It would be a virtual sub-net, but it would probably make more sense to all of us. This would mean that the host machine would think it had an eth1 as well as it's public eth0. We have new hardware on which we will be trying this out.

Virtual Servers

We have 5 virtual servers running using QEMU:

• mail.corkdog.com , 7000 range
• lamp.corkdog.com, 5000 range
• db.corkdog.com, 2000 range
• web.corkdog.com, 8000 range
• rails.corkdog.com, 3000 range

These virtuals are all runing on the host machine under a non-privlaged user with a command something like

qemu -hda web-fu_tb20070204.virtual.qcow -boot c -nographic -redir tcp:8022::22 -redir tcp:8000::80

This basically starts a virtual Ubuntu Server and takes the host port, 8022 and directs it to the virtual's port 22. So, to ssh into the web.corkdog.com virtual you would need to use this command:

ssh -p 8022 user@mail.corkdog.com

Greylisting

We have Greylisting enabled on the mail server. Grey listing records "to, from and from ip-address" of every email message that comes in and saves it for a month, refreshing the date for every new message. If a message comes in that has a new "to, from and from ip" then postfix responds with, service busy try again later. And forces a one minute delay. This seems to kill most spam as spam agents do not seem to try again using the same "to, from and from ip address". If, in a minute or more later, the sending smtp server trys to deliver the message again then greylisting looks it up, sees a match and accepts and delivers the message normally.

Problems with our current setup.

Each virtuals thinks of all traffic as coming from 10.0.2.2 which is the host machine. Actually I am not sure if this is true, it could be that any traffic coming from the host, or other virtulas, as being 10.0.2.2. Outside traffic might look like it is coming from the remote hosts. In any case, if the lamp.corkdog.com virtual wants to send mail it has to have it's own smtp server, which it does, because without that the mail virtual will greylist it and treat it as non-trusted. I hesitate to tell the mail.corkdog.com postfix to trust 10.0.2.2 because I am not sure if that will make all traffic trusted. A side effect of the virtuals not being trusted by the mail virtual is that they can only send email to local mail hosted accounts, because our mail server does not do relaying.

I just tested. Outside traffic looks like it is coming from the remote host. So we should be able to tell postfix on the mail virtual to trust 10.0.2.2. But we will want to test this.

And that was a week ago.

Server administration is time consuming, and getting help from Ryder, Alex, Dedi, Miles and hardware help from Sean makes this site and our email keep working. Thank you all.