You are currently viewing all posts tagged with linux.

An Ubuntu VPS on Slicehost: Mail

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Three of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Four.

Last week I moved this domain’s email to Google Apps. Slicehost has a guide to creating MX records for Google Apps. I have a couple other domains with Google Apps, along with a couple domains hosted locally with addresses that simply forward to my primary, Google hosted, email. I also need to send mail from the server. To accomplish all of this, I use Postfix.

Installing Postfix is a simple matter. Telnet is used quite a bit for testing, so I install that too:

1
$ sudo aptitude install postfix telnet mailutils

The Postfix setup will ask how it should be installed – we want the “Internet Site” option – and then ask you for your fully qualified domain name.

Done? Let’s make sure Postfix is running:

1
$ telnet localhost 25

If it’s working Postfix should return:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix (Ubuntu)

Let’s send a test message from root to the user account user (replace that with whatever your standard user is):

ehlo localhost
mail from: root@localhost
rcpt to: user@localhost
data
Subject: Test
Hi, is this thing on?
.
quit

Now, check your email as user by running mail. See the message? Good.

Open /etc/postfix/main.cf to make sure that Postfix knows what domains it’s receiving mail for. To do this, edit the mydestination variable to include all the proper domains. For me, the name of my server looks like server.mydomain.com. I want Postfix to accept mail for that domain, but not for mydomain.com (since that’s being handled by Google Apps), so mine looks like:

mydestination = server.mydomain.com, localhost.mydomain.com , localhost

Restart Postfix if you made any changes:

1
$ sudo /etc/init.d/postfix restart

Right. Now let’s send another test. Notice this time we’re using full domain names, instead of localhost:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
$ telnet server.mydomain.com 25

ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: domains!
woot... I think this works.
.
quit

Working? Good.

Let’s test from the outside. The first step is to open up the correct ports in the firewall. Assuming you have iptables configured in the way the Slicehost article suggests, open up your /etc/iptables.test.rules and add the following:

# Allow mail server connections
-A INPUT -p tcp -m state --state NEW --dport 25 -j ACCEPT

Now let’s apply the rules:

1
$ sudo iptables-restore < /etc/iptables.test.rules

Make sure everything looks dandy:

1
$ sudo iptables -L

If it meets your fancy, save the rules:

1
2
$ sudo -i
$ iptables-save > /etc/iptables.up.rules

And now, from your local computer, let’s test it out.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
$ telnet server.mydomain.com 25

ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: user@server.mydomain.com
data
Subject: remote connection test
Hello, you.
.
quit

Now check your mail on the mail server as before. Once again, everything should be working.

Now we need to setup a virtual domain. Remember, I don’t want any virtual users. I only want aliases at a virtual domain to forward to my primary email address. That makes this relatively simple. (Be very, very happy. You should have seen this guide before, when I was still hosting virtual domains with virtual users!) Open up /etc/postfix/main.cf and add the following:

virtual_alias_domains = myvirtualdomain.com
virtual_alias_maps = hash:/etc/postfix/virtual

Create the /etc/postfix/virtual file referenced above and add the aliases:

alias@myvirtualdomain.com       user@mydomain.com

Turn it into a database:

1
2
$ cd /etc/postfix
$ sudo postmap virtual

Restart Postfix:

1
$ sudo /etc/init.d/postfix restart

Attempt to send an email to the new alias at the virtual domain:

1
2
3
4
5
6
7
8
9
$ telnet server.mydomain.com 25
ehlo server.mydomain.com
mail from: root@server.mydomain.com
rcpt to: alias@myvirtualdomain.com
data
Subject: virtual domain test
I hope this works!
.
quit

The message should now be in your primary email inbox!

As long as we’re setting up forwards, let’s forward system account mail to somewhere where it’ll actually get read. To do so, create a ~/.forward file with the following contents:

user@mydomain.com

Let’s also create a /root/.forward, so that roots mail gets forwarded to my local account (where it is then forwarded to my primary email). Root’s forward would simply read:

user

Next up: install Wordpress with rewrites. (Previously, we did a basic setup and installed a web server.)

An Ubuntu VPS on Slicehost: Web Server

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Two of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Three, Part Four.

Now we’ve got a properly configured, but idle, box. Let’s do something with it.

Nginx is a small, lightweight web server that’s all the rage on some small corners of the Net. Apache is extremely overkill for a small personal web server like this and, since we’re limited to 256MB of RAM on this VPS, it quickly becomes a resource hog. Lighttpd is another small, lightweight web server, but I’m a fan of Nginx. Try it out.

First, we need to install the web server. Nginx is now in Ubuntu’s repositories:

1
$ sudo aptitude install nginx

That’s all it takes in Hardy, but if you really want a guide for it, Slicehost has you covered.

Slicehost has a few more useful guides to Nginx, including introductions to the config layout and how to get started with vhosts:

Next up, we’ll need to install MySQL and PHP, and get them working with Nginx.

Slicehost has a guide for installing MySQL and Ruby on Rails, which also includes suggestions on optimizing MySQL. I follow the MySQL part of the guide, stopping at “Ruby on Rails install”.

Now MySQL is working, lets install PHP:

1
$ sudo aptitude install php5-common php5-cgi php5-mysql php5-cli

To get PHP as FastCGI working with Nginx, we first have to spawn the fcgi process. There are a few different ways to do that. Personally, I use the spawn-fcgi app from lighttpd. To use it, we’ll compile and make lighttpd, but not install it. We’re only after one binary.

Lighttpd has a few extra requirements, so let’s install those:

1
$ sudo aptitude install libpcre3-dev libbz2-dev

Now, download the source and compile lighttpd. Then copy the spawn-fcgi binary to /usr/bin/:

1
2
3
4
5
6
$ wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.gz
$ tar xvzf lighttpd-1.4.19.tar.gz
$ cd lighttpd-1.4.19
$ ./configure
$ make
$ sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi

Then, create a script to launch spawn-fci (I call it /usr/bin/php5-fastcgi):

1
2
#!/bin/sh
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -C 2 -f /usr/bin/php5-cgi

The script tells spawn-fcgi to launch a fastcgi process, listening on 127.0.01:9000, owned by the web user, with only 2 child processes. You may want more child processes, but I’ve found 2 to be optimal.

Give the script permissions:

1
$ sudo chmod +x /usr/bin/php5-fastcgi

I then link the script filename to a version-neutral, err, version:

1
$ sudo ln -s /usr/bin/php5-fastcgi /usr/bin/php-fastcgi

Now we need an init script to start the process at boot. I use this one from HowToForge, named /etc/init.d/fastcgi:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#!/bin/bash
PHP_SCRIPT=/usr/bin/php-fastcgi
RETVAL=0
case "$1" in
    start)
        echo "Starting fastcgi"
        $PHP_SCRIPT
        RETVAL=$?
    ;;
stop)
        echo "Stopping fastcgi"
        killall -9 php5-cgi
        RETVAL=$?
    ;;
restart)
        echo "Restarting fastcgi"
        killall -9 php5-cgi
        $PHP_SCRIPT
        RETVAL=$?
    ;;
    *)
        echo "Usage: php-fastcgi {start|stop|restart}"
        exit 1
    ;;
esac      
exit $RETVAL

Give it permissions:

1
$ sudo chmod 755 /etc/init.d/fastcgi

Start it:

1
$ sudo /etc/init.d/fastcgi start

Have it start at boot:

1
$ sudo update-rc.d fastcgi defaults

Alright, now that PHP is running how we want it to, let’s tell Nginx to talk to it. To do that, add the following to your vhost server block in /etc/nginx/sites-available/mydomain.com, making sure to change the SCRIPT_FILENAME variable to match your directory structure:

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /home/user/public_html/mydomain.com/public$fastcgi_script_name;
    include        /etc/nginx/fastcgi.conf;
}

Now let’s create that /etc/nginx/fastcgi.conf file that’s being included above. As per the Nginx wiki article, mine looks like this:

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;
fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

Then restart Nginx:

1
$ sudo /etc/init.d/nginx restart

Let’s create a file named test.php in your domain’s public root to see if everything is working. Inside, do something like printing phpinfo.

Go to http://mydomain.com/test.php. See it? Good. If you get “no input file specified” or somesuch, you broke something.

If you create an index.php, and delete any index.html or index.htm you might have, you’ll notice Nginx throws a 403 Forbidden error. To fix that, find the line in your vhost config (/etc/nginx/sites-available/mydomain.com) under the location / block that reads index index.html; and change it to index index.php index.html;. Then restart Nginx.

If you want SSL with your Nginx, Slicehost has a guide for generating the certificate and another guide for installing it.

You’ll want to install OpenSSL first:

1
$ sudo aptitude install openssl

There is one bug in the second guide. In the first server module listening on port 443, which forwards www.domain1.com to domain1.com, the rewrite rule specifies the http protocol. So, in effect, what that rule does is forward you from a secure domain to unsecure: https://www.domain1.com to http://domain1.com. We want it to forward to a secure domain. Simply change the rewrite rule like thus:

rewrite ^/(.*) https://domain1.com permanent;

Next up: install a mail server. (Previously, we did a basic setup.)

An Ubuntu VPS on Slicehost: Wordpress

As mentioned previously, I’ve recently moved this domain over to Slicehost. What follows is Part Four of a guide, compiled from my notes, to setting up an Ubuntu Hardy VPS. See also Part One, Part Two, and Part Three.

I prefer to install Wordpress via Subversion, which makes updating easier. We’ll have to install Subversion on the server first:

1
$ sudo aptitude install subversion

After that, the Wordpress Codex has a guide to the rest of the install.

Nothing further is needed, unless you want fancy rewrites. In that case, we’ll have to make a change to your Nginx vhost config at /etc/nginx/sites-available/mydomain.com. Add the following to your server block under location / {:

# wordpress fancy rewrites
if (-f $request_filename) {
    break;
 }
 if (-d $request_filename) {
     break;
  }
  rewrite ^(.+)$ /index.php?q=$1 last;

While we’re here, I usually tell Nginx to cache static files by adding the following right above thelocation / { block:

# serve static files directly
location ~* ^.+\.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|css)$ {
    root  /home/user/public_html/mydomain.com/public;
    expires 7d;
    break;
}

That’ll go in the https server section, too. Now, enable rewrites in your Wordpress config. I use the following “custom” structure:

/%year%/%monthnum%/%day%/%postname%/

Then, restart Nginx:

1
$ sudo /etc/init.d/nginx restart

And there you have it! You know have a working, new web server and mail server.

(Previously, we did a basic setup, installed a web server, and installed a mail server.)

An Update

It’s been brought to my attention – repeatedly – that I neglected to post anything for the last month and a half. Oops.

I upgraded my macbook to 10.5.3 earlier tonight. Upon reboot, everything was shiny till I attempted to launch Firefox. It did one little bounce in the dock and gave up. Attempting to run it from the terminal in safe mode was no better.

Of course, OS X does its best to insulate the user from the system, so finding useful logs was out of the question. All /var/log/system.log told me was that Firefox exited with error code 1.

In a fit of desperation, I deleted my version of Firefox and downloaded Firefox 3 RC1. After the install, it launched. So now I’m running that less-than-polished software.

I’ve been running the Firefox 3 betas on my Ubuntu machine at work since February or so. Each release seems to get progressively worse: they’re all of them unstable, slow, and have an annoying new address bar. Now that I made the mistake of updating the work machine to Ubuntu 8.04, I’m stuck with using Beta 5 everyday. (Dear Canonical: Please don’t ship stable releases with beta software. Thanks.) I’ve enjoyed coming home to the stable, usable, and speedy Firefox 2.

To be fair, my Firefox 3 experience up to now was limited only to the Linux versions, and I’d not used the release candidate on any platform. So far, RC1 on OS X doesn’t seem too bad.

TrueCrypt Now Cross-Platform

TrueCrypt is finally available for OS X! Though my primary OS was Linux up till just last November, I’ve been waiting on this for a while longer. Last year I used a Mac at work, and would frequently want to decrypt TrueCrypt disks that I carry around on my flash drive.

I’m plan to donate to the project when my next paycheck comes in.

How to Own the Air

Before moving into my new place last month, I had planned on paying an ISP for internet access. But, complications arose with the company I had chosen, so I decided to cancel my order soon after it was placed. Instead, I planned to borrow internet access from my neighbors (hey, they’re pumping signals into my air-space). Trouble was, everyone had encrypted their networks with WEP. No doubt this is a good thing, and a vast improvement from the last time I had scanned down here (about 8 months ago), but I wanted in. I was able to justify cracking in to myself by recognizing that my paranoia isn’t limited just to the “others” out on the global interwebs – no, I’d be just as paranoid about the owner of whomever’s network I was breaking into watching my traffic. There was no question I’d make ample use of encryption, which, as a side benefit, meant that anything I did through his connection would be rather difficult to trace back. So, he was protected. As long as he wasn’t paying for bandwidth by the KB, he’d not be much affected by my leeching. (I use the pronoun “he” because I know now that the owner of my primary network is, in fact, a he – put a password on your routers, people!).

But there was another problem, in addition to WEP: during reconnaissance, I would rarely pick up any connected clients. Perhaps I was always trying at the wrong time of day. Or perhaps people pay for internet access and never use it. Regardless, it would have taken weeks of constant logging to gather enough IVs to crack the WEP key. So, the first step was to take the money I had saved by canceling my order with the ISP, and invest in a new wireless card that supported packet injection.

The Proxim 8470-WD (from aircrack-ng’s recommended list) caught my eye, though it took a while before I could find it a decent price. To do my initial cracking, I popped in Backtrack and followed aircrack-ng’s newbie guide. (I had upgraded my trusty old Auditor cd to Backtrack just for this occasion. It’s quite the nice distribution.) Within about 5 minutes, I had gained access to the first network. Goes to show how secure WEP is.

Though the Proxim card is plug and play in Ubuntu, the steps to crack WEP are a little different. Here’s what I do (note that I do recommend using Backtrack, instead).

First, of course, one must install aircrack:

sudo apt-get install aircrack

You may change your mac address manually, or, if you aren’t concerned with anonymity, don’t change it all. I have a preference of using the macchanger tool:

sudo apt-get install macchanger

Set your card’s MAC address randomly. In this case, the network device is at ath0:

sudo ifconfig ath0 down
sudo macchanger -r ath0
sudo ifconfig ath0 up

Put your card into monitor mode:

sudo iwconfig ath0 mode monitor

Start scanning:

sudo airodump ath0 dump 0

In this case, dump is the file prefix for airodump’s output and the 0 tells airodump to channel-hop. Now you want to pick your target network from the scan. It should have at least one client connected (displayed at the bottom of airodump’s output), the more the merrier. (Hopefully that client is transmitting data, too.)

When you pick your target, kill the first instance of airodump and start it up again, this time specifying the channel of your target:

sudo airodump ath0 targetdump 9

The targetdump is the file prefix and 9 is the channel. Optionally you can add a 1 to the end of the command, which tells airodump to only capture IVs (which is what you’re after). I normally don’t bother.

When you’ve captured somewhere in the range of 250,000 - 500,000 data packets (shown by airodump in the “Packets” column of your target client), you can start cracking:

aircrack -b 00:12:34:45:78:A3 targetdump.cap

In this case, -b is the essid of your target network. Cracking could take minutes, hours, days, weeks, months, or years. I’ve never had to wait over 20 minutes.

But what if the client is being a party-pooper and not transmitting? That’s where packet injection comes in. From aircrack’s guide:

ARP works (simplified) by broadcasting a query for an IP and the device that has this IP sends back an answer. Because WEP does not protect against replay, you can sniff a packet, send it out again and again and it is still valid. So you just have to capture and replay an ARP-request targeted at the AP to create lots of traffic (and sniff IVs).

You’ll want to keep airodump running, so that all the traffic you generate will be captured. In another terminal, start injecting:

sudo aireplay -3 -b 00:12:34:45:78:A3 -h A3:78:45:34:12:00 ath0

The -3 tells airepay you want to replay ARP requests, -b is that target network, and -h is the client. In a little bit, aireplay should inform you that it has captured 1 (or more) ARP packets. Sit back and watch airodump count up the IVs.

If that pesky client still isn’t cooperating, you can give it a little motivation. From aircrack:

Most operating systems clear the ARP cache on disconnection. If they want to send the next packet after reconnection (or just use DHCP), they have to send out ARP requests. So the idea is to disconnect a client and force it to reconnect to capture an ARP-request. A side-effect is that you can sniff the ESSID during reconnection too. This comes in handy if the ESSID of your target is hidden. ...the risk that someone recognizes this attack or at least attention is drawn to the stuff happening on the WLAN is higher than with other attacks.

Keep airodump and aireplay running, and in a new terminal give it a little kick in the butt:

sudo aireplay -0 5 -a 00:12:34:45:78:A3 -c A3:78:45:34:12:00 ath0

The first switch, -0, informs aireplay you want to force the client to be unauthenticated, -a is the target network, -c is the target client. When the client reconnects, you should start grabbing ARP requests.

After you have enough packets, crack the WEP key as before.

To manage and connect to my wireless networks, I’ve taken to using wifi-radar. It scans for networks, allows you to specify which networks you prefer and, for each network, allows you to set preferences such as the WEP key, whether to use dynamic or static addresses, and the like. What I like best is the connection commands, which allows you to set commands you want executed before wifi-radar connects to the network, and after. In the before field, I have it randomly change my mac address:

ifconfig ath0 down && macchanger -r ath0 && ifconfig ath0 up

After it connects, I restart tor:

/etc/init.d/tor restart

(As another reference for you, this site keeps turning up as a guide to cracking WEP in Ubuntu.)

Ubuntu Dapper Beta

Yesterday, I decided to give the latest Ubuntu beta a go. I first tried to upgrade using Ubuntu’s update-manager, but, alas, GUIs never work. It crashed while trying to upgrade Kino, which also left me with a broken X server. I had downloaded the new Live CD beforehand, so I just booted into that and used the installer. The partitioning tool insisted that my new swap was to be only 1K, which I wasn’t too pleased with. After killing the installer, manually setting my partitions with fstab, and then rerunning the installer, everything worked fine. By the time I rebooted, there were already 65 packages to update. After that, I had to add in some new repos and install the usual additional software.

So far, I’m happy with the release. It seems a bit faster, looks much nicer, and, of course, has a whole slew of updated software.

LinuxFest 2006

This year’s lineup for LinuxFest isn’t very impressive. It’s dissapointing. The first year I live only a few minutes away is the year that the speakers don’t interest me. I’m not sure if I’ll go.