I was getting really annoyed getting these messages while anaging my Debian and Ubuntu VPSes
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Turns out the solution is simply to run these commands
export LANGUAGE=en_US.UTF-8
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
locale-gen en_US.UTF-8
apt-get install locales
dpkg-reconfigure locales
The export lines above can also be saved into either ~/.profile or ~/.bashrc or ~/.cshrc
Debian 6 i.e. “Squeeze” was released almost a month ago. Although there are still about 11 months more before Debian 5 “Lenny” is no longer supported, I figured I would upgrade one Debian Lenny Xen-based VPS hosted on a Rackspace Cloud, currently functioning as an OpenLDAP server, as a weekend project.
The upgrade steps were straightforward:
1. Edit /etc/apt/sources.list and change all instances of lenny to squeeze.
2. Run the following commands in succession in terminal
sudo apt-get update
sudo apt-get install apt dpkg aptitude
sudo apt-get dist-upgrade
Surprisingly enough the upgrade went well with Apache and even OpenLDAP migrated successfully. Just the following issues related to phpldapadmin were encountered:
1. The upgraded phpldapadmin would work until I ran
sudo apt-get purge phpldapadmin
sudo apt-get install phpldapadmin
2. I would face a screen full of “Automatically removed objectClass from template” warnings upon logging into phpldapadmin. This I resolved this by renaming the .xml files in /etc/phpldapadmin/templates/modification once again to another non- .XML suffix.
3. Every time I attempted to edit an try, I would get an annoying “Select a template to edit the entry” screen. This was resolved by renaming the files for the templates referenced in the error screen, at /etc/phpldapadmin/templates/creation, to have non- .XML suffix.
Thanks to the excellent tutorials over at Slicehost, I got an idea of some the things you need to do to secure your brand new virtual private server (VPS) straight away. To me, the main takeaways with regard to security would be:
1. create a privileged user with Sudo access
2. disable the root account login
3. use strong passwords e.g. a combination of letters in upper and lower case, numbers and other characters
4. setup iptables firewalls
I had no idea how well these steps were working though in preventing unauthorised access and I don’t really have the time to access the the system logs every day. Wouldn’t it be great if there were a way you could just receive a daily email summarising significant security-related server activities?
Well there is! You just need to setup Logwatch by following the steps in this tutorial
You won’t get any emails set to you however if your VPS hasn’t already been configured properly to send email. This excellent tutorial explains how to setup Exim4 to send emails from your VPS.
One thing I noticed about this method though is that you may not receive emails sent to your email account; apparently some email providers automatically discard emails sent from servers without proper reverse DNS records. So if you find yourself not getting emails from logwatch, you will need to set up reverse DNS on your VPS (which you usually can do in your VPS control panel – or ask your provider to help you). Alternatively, you can set your VPS to send emails via the Gmail SMTP server – which practically guarantees that sent emails reach your inbox.
The first times I received my Logwatch reports via email, I have to admit to being shocked at just how many intrusion attempts my VPS receives on a daily basis! Several thousand a day (why do so many people have so much free time?) I found out that you can tweak your iptables to limit the number of intrusion attempts. In my example below, any IP address that has more than 3 SSH login attempts over 10 minutes gets blocked for 10 minutes.
-N SSH_CHECK -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK -A SSH_CHECK -m recent --set --name SSH -A SSH_CHECK -m recent --update --seconds 600 --hitcount 4 --name SSH -j DROP -A SSH_CHECK -j ACCEPT
Note that this isn’t the most comprehensive guide to security on a VPS, but it’s a start!
There are quite a number of tutorials available on backing up to Amazon S3, which is popular due to its redundancy and low cost (15cents per gigabyte). I prefer Rackspace Cloud Files though due to its lower upload fees (8cents vs 10cents per gigabyte of bandwidth). We will use duplicity to create the backups because it is bandwidth efficient and also allows us to encrypt our backups.
We will also be setting up the cloudcity script to make it easier to automate the backup and restore process.
First set up build essential so that you can do necessary compiling later.
apt-get install build-essential
Install duplicity
Debian Lenny and Ubuntu < 10.04 come with older versions of Duplicity. We need to add additional repositories to install a newer version of duplicity from.
On Debian Lenny
nano /etc/apt/sources.list
add this line
deb http://www.backports.org/debian lenny-backports main contrib non-free
Next run the following commands in succession
apt-get update
apt-get install debian-backports-keyring
apt-get -t lenny-backports install duplicity
On Ubuntu 9.10 and earlier
sudo add-apt-repository ppa:duplicity-team/ppa
On older (pre 9.10) Ubuntu systems:
sudo nano /etc/apt/sources.list
Add the relevant Duplicity source; for Ubuntu 8.04 it would be:
deb http://ppa.launchpad.net/duplicity-team/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/duplicity-team/ppa/ubuntu hardy main
Next run these commands
sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 7A86F4A2
sudo apt-get update
sudo apt-get install duplicity
Check that the installed version is > 0.5
duplicity –version
Setup your GPG keys for encryption of your backups
gpg –gen-key
You’ll be walked through a few options for your key, select the following:
Key type – DSA and Elgamal (Default)
Key size – 2048 bits (Again, the default)
Expiration – Do not expire
Name, Comment and Email – You can enter whatever you like here
Password – Make sure you remember whatever you type, there’s no way to get it back if you forget!
When it talks about “generating entropy” to make the key, it means that the server needs to be in use in order for it to get some random numbers. Just go refresh a webpage on the server a few times, or run some commands in another terminal window.
IMPORTANT
Create backups of your keys by following the steps here:
Copy the backups to a safe and secure location – OFF this computer.
Install python-cloudfiles
Browse to http://github.com/rackspace/python-cloudfiles/downloads
Download and extract the tgz of the latest release. Then install it.
e.g.
wget http://github.com/rackspace/python-cloudfiles/tarball/1.7.2
tar xzvf rackspace-python-cloudfiles-48dd7c8.tar.gz
cd rackspace-python-cloudfiles-48dd7c8
python setup.py install
Setup cloudcity
Browse to http://github.com/jspringman/cloudcity/blob/master/cloudcity
Copy the text of the cloudcity script and edit the following lines at minimum:
# Cloud Files information you can get from https://manage.rackspacecloud.com/
export CLOUDFILES_USERNAME=your_username
export CLOUDFILES_APIKEY=your_api_key
#This is the password you typed in when creating your GPG keys earlier
export PASSPHRASE=your_gpg_passphrase
# Specify the name of the container/directory in your Cloud Files account where the backup files are to be stored
TARGET=”cf+http://cloudfiles_container_name”
# List ONLY the directories that you want to backup, for instance
INCLUDE_LIST=( “/home” “/root” “/var/www”)
Edit the other parameters as desired.
Create a file for the script
e.g.
nano cloudcity.sh
and paste the edited script contents discussed above.
Next give it permissions to run
chmod +x cloudcity.sh
Ok you’re ready to backup!
./cloudcity.sh
When completed, you will see
“Backup complete”.
You may wish to setup a cron job to call this script every night.
To view restore options
./cloudcity.sh –help
Be sure to keep a copy of cloudcity.sh!
Restoring on another computer
In the event of a catastrophic crash, the computer you are restoring your backups to will need to be set up the same way as above but with ONE difference; do not create GPG keys again, but restore your keys (that you’d backed up earlier) following the steps here
https://help.ubuntu.com/community/GnuPrivacyGuardHowto#Restoring%20your%20keys
Now use cloudcity.sh to restore your backed up files!
Note: Here is a similar tutorial on backing up your MySQL databases to Rackspace Cloud Files
http://blog.jtclark.ca/2010/02/backup-mysql-to-rackspace-cloud-files-with-duplicity/