Setting up a VPS server. It was a bumpy road.
Posted Under: email,Linux,Server admin,Software,Virtualization
Introduction
These are my own notes as I set up an OpenVZ VPS server, based upon CentOS 5.6 to function as a web and mailing list server. A $36/year 128 MB RAM machine was good enough for this.
Since there’s some criticism about the hosting provider, and it looks like they’re OK after all, I’m leaving their name out for now. The main purpose of this post is to help myself getting started again, if that is ever necessary (I sure hope it will never be).
Foul #1: Mails from hosting provider marked as spam
This is the first time it happens to me that automated emails from any service providers go to Gmail’s spam box. That includes the welcome mails as I subscribed, the payment confirmation and the message telling me the server is up. And messages about support tickets. None arrived.
Spamassassin gives these mails some points (1.3 or so) as well. I’ve hardly seen anything like this from any decent automatic mail producer. I first thought this was a major blunder, but then it turns out that machine-generated emails tend to get caught by spam filters. Since email messages that are relayed by a mailing list (mailman) don’t get caught, it looks like the spam filter checks the “received” chain of headers for the first hops of the message, and tries to figure out if that’s a decent ISP there. Just a wild guess.
Workaround: Add a filter in Gmail to never send emails from *@the-hosting-provider.com to the spam box. Simple, when you know about it.
Foul #2: 12 hours from payment to server running
Even for a low-cost service, 12 hours of “pending” is a bit too much. In particular when $36 have been paid. That alone filters out most scammers, I suppose.
Foul #3: Root password not set
Maybe I was naive to expect that the root password would be set in the server, so I tried to SSH the server with the password I had assigned during the subscription, but was consistently denied.
Workaround: Enter the VPS control panel and change the password.
Foul #4: Uncertified HTTPS link
The control panel of the VPS is accessed with a link to an IP address. Which is a bit weird, but let’s leave that alone. I mean, what about buying a domain for that purpose? To make things even worse, they supply an HTTPS link as well. Which works, but makes the browser display a scare “GET ME OUT OF HERE” message.
An uncertified HTTPS link is better than HTTP, even though cryptologists will argue that in the absence of a certificate, a man-in-the-middle attack is possible. But let’s get serious. It’s not really dangerous. It’s just yet another sign that they don’t give a shit. Setting up a domain and certifying it something you would expect from any serious company, just to avoid that scary warning message. But they didn’t.
Bump #1: Lacking yum repository
Among the first thing I did after logging in (because I’m addicted):
# yum install git Loaded plugins: fastestmirror Determining fastest mirrors * base: mirror01.th.ifl.net * extras: mirror01.th.ifl.net * updates: mirror01.th.ifl.net base | 1.1 kB 00:00 base/primary | 967 kB 00:00 base 2725/2725 [ ... yada yada ... ] vz-updates/primary | 1.0 kB 00:00 vz-updates 3/3 Setting up Install Process No package git available. Nothing to do
Are you kidding me? Using
# rpm -qa --last | head
I got a list of packages installed, many of which were marked with “el5″, which isn’t surprising,
# cat /etc/redhat-release CentOS release 5.6 (Final)
since it’s a CentOS 5 distro (EL = Enterprise Linux).
The list of existing repos:
# yum repolist Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror01.th.ifl.net * extras: mirror01.th.ifl.net * updates: mirror01.th.ifl.net repo id repo name status base CentOS-5 - Base enabled: 2,725 extras CentOS-5 - Extras enabled: 286 updates CentOS-5 - Updates enabled: 1,003 vz-base vz-base enabled: 5 vz-updates vz-updates enabled: 3 repolist: 4,02
So where’s git? On Fedora 12, I checked where git was loaded from (for comparison) with
$ yumdb info 'git*' Loaded plugins: presto, refresh-packagekit git-1.7.2.3-1.fc12.x86_64 changed_by = 1010 checksum_data = 470af233244731e51076c6aac5007e1eebd2f73f23cd685db7cd8bd6fb2b3dd1 checksum_type = sha256 command_line = install git-email from_repo = updates from_repo_revision = 1291265770 from_repo_timestamp = 1291266900 reason = user releasever = 12 [ ... here comes info about git-deamon and other packages ]
So CentOS’ repository doesn’t have git? That looks odd to me. A last try:
# yum list available | less
No, git wasn’t on the list. The fix was to add Repoforge to the list of repositories on the server (following the instructions):
# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm # rpm -i rpmforge-release-0.5.2-2.el5.rf.i386.rpm
And then “yum install git” went fine.
Bump #2: Bad host name
OK, it’s partly my fault. A short host name (without a dot) isn’t good enough. At least not for sending mails. A fully-qualified host name (such as example.com, as opposed to just “example”) is needed. Or sendmail starts up very slowly and then refuses to send mails.
Bump #3: Setting up reverse DNS
For the server to be able to send emails that aren’t immediately detected as spam, its IP must have the reverse DNS set to its host name.
There is a place to edit the rDNS name in the control panel (under “Network”) but it was disabled. Contact support, it said. So I did.
Having rDNS disabled by default is somewhat understandable to at least keep an eye on spammers. On the other hand, show me a spammer paying $36 upfront.
It took support 11 hours to answer this support request, asking me to supply the rDNS record I needed for manual setting. The actual fix came an hour later, so overall this was fairly OK.
The automatic feature is simply not supported. But it’s not like decent people need to change their rDNS every day.
Bump #4: No swap
It seems like there is no way to activate a swap file on the VPS server (in particular, losetup returns with “permission denied” so there is nothing to attach the swap partition to). So there’s no choice than to make sure that the overall memory consumption doesn’t exceed the allocation of virtual RAM, which is 128 MB in my case. Or processes will just die. I can understand the commercial sense in this limitation: If users would start putting large swap files on their systems, they would buy lower-cost machines and then complain that they’re not responsive.
The figure to keep track of is the amount of free + cached memory. For example,
$ cat /proc/meminfo MemTotal: 131072 kB MemFree: 47516 kB Cached: 27156 kB [ ... ]
The free memory is 47416 + 27156 = 74672 kB, which means 131072 – 74672 = 56400 kB is used. These are the figures that appear in the Control Panel.
Installation note: Setting up sendmail
By default, sendmail doesn’t accept external connections. Edit /etc/mail/sendmail.mc, changing
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
to
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
This removes the restriction that only the local address is listened to. And also from
dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
to
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
(remove the “dnl” hence uncommenting the line).
Check with the hosting provider if they supply a mail relay server. Relaying through a well-reputed server can decrease the spam score of your mails. Besides, the hosting provider can decide to block all outgoing direct connections with mail servers out of the blue, because spams were flying out from their servers.
A line like the following should be added (possibly close to where SMART_HOST is mentioned in the file).
define(`SMART_HOST',`relay.myprovider.com')dnl
And then compile the file into sendmail.cf, and restart the server as follows:
# make -C /etc/mail # service sendmail restart
Then test the server, possibly using a script. In particular, verify that the mail server isn’t relaying (accepting messages to other domains) or the server turns into a spam machine.
Installation note: Mailman
# yum install mailman
Then customize. See instructions here and also have a look at /usr/share/doc/mailman-2.1.9/INSTALL.REDHAT. There’s a need to access the host by its domain name (as opposed to just the IP address) so the local computer’s /etc/hosts may need to be fiddled with when working on a server not yet allocated with the new address.
Note: Do not edit /usr/lib/mailman/Mailman/mm_cfg.py for changing DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST, if they happen to say
DEFAULT_URL_HOST = fqdn DEFAULT_EMAIL_HOST = fqdn
because in this case they’re set up automagically.
First, make sure that the mailman daemon is off:
# service mailman stop
To migrate a few lists from one server to another, copy the respective lists in /var/lib/mailman/{lists,archives} into the new server. Note that the “data” directory doesn’t contain any information on the lists, so therefore just adding these directories is enough.
The lists will not appear in the web interface if there was a domain switch during the list migration, as can be observed by searching for ‘web_page_url’ in the output of
# /usr/lib/mailman/bin/dumpdb config.pck
To fix this, go (for each list)
# /usr/lib/mailman/bin/withlist -l -r fix_url the-list-name
Make sure the files are owned by mailman with
# chown -R mailman:mailman ... the copied directories ...
At this point, the list should appear on the web console. Copy the entries into /etc/aliases, more or less like this:
## listname mailing list listname: "|/usr/lib/mailman/mail/mailman post listname" listname-admin: "|/usr/lib/mailman/mail/mailman admin listname" listname-bounces: "|/usr/lib/mailman/mail/mailman bounces listname" listname-confirm: "|/usr/lib/mailman/mail/mailman confirm listname" listname-join: "|/usr/lib/mailman/mail/mailman join listname" listname-leave: "|/usr/lib/mailman/mail/mailman leave listname" listname-owner: "|/usr/lib/mailman/mail/mailman owner listname" listname-request: "|/usr/lib/mailman/mail/mailman request listname" listname-subscribe: "|/usr/lib/mailman/mail/mailman subscribe listname" listname-unsubscribe: "|/usr/lib/mailman/mail/mailman unsubscribe listname"
And finally, turn the service on again:
# service mailman start
And make it a permanent service:
# chkconfig mailman on
Changing the subscription confirmation message (to tell users to look in the spam folder): Edit /usr/lib/mailman/templates/en/subscribe.html, and remove /var/lib/mailman/lists/{listname}/en/subscribe.html (if it exists, and contains nothing special for the list).
Then restart qrunner to flush cached templates:
# /usr/lib/mailman/bin/mailmanctl restart
See these two pages for more info about this (even though they’re not very accurate).