I'm currently at my friend's house, and quickly wanted to install Apache2 on his Ubuntu machine (he's asleep, and I feel like coding). apt-getting everything really wasn't a problem, in fact everything started and worked fine.

I did get a warning though:

apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

Fortunately, this can easily be fixed by editing the configuration file, usually stored at /etc/apache2/apache2.conf. The fix is simple, and you'll kick  yourself. Just add the following line to the end:

ServerName "localhost"

If you're still having problems, feel free to drop a comment, and I'll get right back to you.

The message of the day is the text that's displayed to you when you log in. At the moment, mine was just an awesome Debian symbol, with the address of my maintainers. Whilst the ascii art was awesome, it didn't really help me.

You can change your motd by sudo editing /etc/motd. It's as simple as that really.

Once you change it, it'll be system wide, meaning every user will see that message when they log on. Keeping that in mind, it's a good way to get a message around to users without having to send tonnes of emails to each of them. For instance, you could put a "Server will be down for maintanance next Tuesday" message for everyone to see. If you're the only person using the box (like I am), then you can just putting motivational messages, or a todo list.

I'm usually on my laptop, using either my college or another unsecured wireless connection which makes me a little suspected about packet sniffers. I'm not too worried since I use SCP, which is encrypted, and SSH, which is also encrypted. Pretty good encryption too.

For you paranoid types though you can tighten up your encryption by using public key encryption. To really understand why it's a better encyption method, you need to understand how encryption works and that gets a little complicated. But, because your key is 100% random, and not based on a protocol like SSH or SSL, it's even awesomely harder to crack.

You can see how to set it up correctly so you can log in using it with WinSCP and PuTTY from HowtoForge, who have a big ass four-page article. Here's my short version:

1. Nab the PuTTYgen executable.
2. Run it and click "Generate". Then you just move your mouse around the blank area, below the bar, till the bar fills. What this is doing is taking the coordinates of your mouse every few millimeters and using them as random information bits to formulate the key. Totally unguessable.
3. Change the "Key comment". I use this as a hint, since you get shown it whenever you try to log in using it. Don't make it too good a hint though, or the key'll become pointless.
4. The key passphrase is your password.
5. Save your public key, then save your private key.

That's your key generated. If you really want to, you can upload your public key; it doesn't matter if people know it. In fact, most people give it out so that people can send them encrypted messages (it's encrypted with the public key, and decrypted with the private key).

It goes without saying, but don't leave your private key lying around. I actually key mine on a flash drive, which is password protected.

Next, we need to tell your server abou the key.

Once you're logged into your server (probably for the last time without a key!), we need to make the directory ".ssh" (mkdir .ssh, so long as your on your home directory). Next, we need to make the key's file:

nano -w .ssh/authorized_keys2

Now, in the PuTTYgen window (I hope you didn't close it...) the first section gives you a chunk of text for "pasting into OpenSSH authorized_key files". Grab that, and copy it into the file we just made in nano. Save and exit nano.

Just a little bit of chmoding now.

chmod 700 .ssh

chmod 600 ~/.ssh/authorized_keys2

Now, close PuTTY and open it again. Head to Connection > SSH > Auth and put the location of you .ppk private key file. Now save that session information (head back to Session) and log in again. This time, you'll be promoted for your key phrase instead of your password.

I needed to set up an FTP server since WordPress wanted it in order to do the automatic plug-in upgrade. I've never needed one before since I've just been using SCP.

I looked around for an FTP server and was about to install FTPd, before someone told me that vsftpd was a much better daemon to get, so I did (using sudo apt-get install vsftpd).

Well, that was simple enough, but now we have to change some of the configuration file. It's actually pretty simple since it's well commented. You can nano the file /etc/vsftpd.conf to get at the options; remember to use those helpful switches!

I decided to disable anonymous access, since all I really need is to get my WordPress to update a few files, and it won't do that anonymously. Change the setting on line 23 to disable it. I want to just use local users for when I'm logging into FTP, enable that on line 26; that means that I'll use the same user name and password that I use for PuTTY to get shell access. We obviously want to write stuff when we're using FTP (instead of just reading) so make sure line 29 is uncommented.

I changed my local_umask to 022. What this does is basically makes any new file I make have the permissions of 755 (777 - 022), meaning everyone can read and execute, but only the owner can write.

Since I'm letting local users access via FTP, I want to restrict them to just their home directories, so they can't play around with files outside of their /home/username directory. That's done on line 105. Of course, I want to allow myself to access anywhere, so I uncommented line 110 and 112.

That's all the edits that I made to that file. Now though, we need to add ourselves to the list of users allowed outside their home directory. It's a simple (empty) file at /etc/vsftpd.chroot_list by default, and you just need to put your user name there.

There are a lot of switches to a lot of commands and sometimes they're just too long to remember, or you're just too lazy to type them. In cases like this, you can use aliases. They're basically shorthand for commands you use a lot.

For instance, to log onto MySQL I have to use the command:

mysql --user=dangermouse --password=letmeinplox

It gets a little boring typing that over and over again. Also, PuTTY doesn't hide the password as you're typing it which can be a little dangerous. An alias fixes both of those problems. Just do:

alias my_mysql='mysql --user=dangermouse --password=letmeinplox'

"alias" is the command, "my_mysql" is the new alias/command I'm creating, and the rest is what I want it to be. So, now I can type "my_mysql" and it'll log me into my MySQL server.

If you pick a name for your alias that already exists, the original one will just got overridden.

Unfortunately, you'll have to create this alias every time you log onto your server. You can fix that by adding it to your .bashrc file, which is in your home directory, (so, mine is /home/shamess/.bashrc). That file should already have a few aliases in it, so take a look around it for examples.

My situation: I was running www.allroundnews.co.uk fine on my shared host server, SH5 (thanks BEA Solutions ^^). Then I decided to switch to my VPS, Trinity, to run this blog. This blog is run from Trinity, but the rest of *.allroundnews.co.uk is still run from SH5. I realised that I was using up valuable space and bandwidth on SH5, when I had tonnes of both on Trinity. That's when I decided to run a virtual host for both of them. Here's how.

First, we have to fix the default Apache2 configuration, which isn't quite ready for vhosts yet. As root, edit the file /etc/apache2/sites-availiable/default. At the moment, mine and yours, if you haven't edited, looks like this, (well, I've changed the ServerAdmin, but that's about it.) We need to add the server name directive. That's just the URL that you want this vhost to be found at. I just had to add:

ServerName trinity.allroundnews.co.uk

That's fixed that. Since I'm running Trinity from a subdomain, that's all I need to add, but if you're expecting users to be able to use the www. prefix for your website, then you'll need to add a ServerAlias. If you're website is debianisawesome.com, you'd have something like the following:

ServerName debianisawesome.com

ServerAlias www.debianisawesome.com

Now that's fixed, we need to set up another VirtualHost for us to be using. In it, you need at least the ServerName and DocumentRoot directives. Remember, the ServerName is the URL Apache is "listening" for. The DocumentRoot is where it gets its files from. Try make this different from your default one, else it'll just get confusing. Here's what I've added to mine:

<VirtualHost *>

        ServerName www.allroundnews.co.uk

        ServerAlias allroundnews.co.uk *.allroundnews.co.uk

        DocumentRoot /var/www-allroundnews/

</VirtualHost>

I went ahead and created /www-allroundnews/ too, and gave myself permissions.

My new config file can be found here.

All you need to do now is copy all your files from one server to your VPS. I did that by getting them all from SH5 using FTP, then uploading them all to Trinity using WinSCP. Any better way than that; comment, please!

Then, remember to point your old DNS records to your server, and you're good to go.

Tonight's post was going to be about setting up your own DNS server, using bind. Instead, tonight's post will be about how impossible it is, and that you should stick with your domain registrar. They'll usually handle your DNS for you anyway, for free.

As always, installing bind was easy. Setting it up was a bitch though.

I wanted to run the Shamess Productions home page from this server, as a secondary nameserver. Thankfully, I know my DNS host personally so I could talk to him about finding his hashkey for RNDC, but even then it was confusing. I'd imagine it to be almost imposible to get that from GoDaddy or someone.

And even with that, I still had no idea why I wasn't synchronising.

Honestly, there's better things you can do with your server's resources than run a DNS server.

I will cover this in detail some time later though, so stay tuned. (If I get inundated with comments ask how to do this, I'll do more research and get it up faster.)

In the meantime, stick with the DNS server of whoever you registered your domain. Just ask them to point an A record for your domain to the IP address of your server.

If you're using mail functions on PHP after just installing it, you won't get any error message, even though the mail won't get sent yet. Don't worry, we'll fix that now.

Debian comes with Exim4 which is a mail server with a bunch of features. By default it's set to only send emails locally (to other users on your system). If you tried to send any emails to external users at the moment, you'll see something like "** www-data@debian R=nonlocal: Mailing to remote domains not supported" in your error logs.

We just need to reconfigure your Exim4 options, which you can do by typing the command "dpkg-reconfigure exim4-config".  Then you'll get a screen, which you'll have to answer a few options. A lot of them are easy but they can be a bit off putting.

I don't think there's much reason to split configuration files (comment if I'm wrong). Your system mail name should be your URL, including the subdomain if that's where you've pointed your VPS. For instance, mine is "trinity.allroundnews.co.uk", so all email addresses will be 'user@trinity.allroundnews.co.uk'. Let the 'listener daemon' listen to all IPs, by just leaving it blank. Say no to 'Dial-on-Demand'. The 'Root and postmaster mail recipient' is basically the user that you want mail to 'root@trinity.allroundnews.co.uk' to be redirected to (since you shouldn't stay logged in as root). So for me, that's just 'shamess'.

If you've tried to send any mail so far, you'll want to remove it from the queue (sorry if it was important). Do that by getting up the mail queue (using the mailq command). Then you can remove mail by using the command Exim -Mrm <message id>. You can put as many message ID's in the list as you like, space separated. The message ID is the weird string that looks something like ’1JOJBI-0000ag-IH'. Yup, you have to type that.

I'll talk about actually reading mail later, but at least now you can send mail with PHP!

Now we have our web server set up and you can upload your files and things securely, we need to make sure all your PHP files are being complied properly.  You'll probably be using MySQL too, so let's do that at the same time.

Start up PuTTY and connect. Installing PHP is shockingly simple. Type apt-get install php5, you'll have to be logged in as root. PHP4 is about to have its last security updates, so there's no point in getting that now. After that, I don't actually remember having to do anything other than restart Apache (/etc/init.d/apache2/ restart).

There's an article on AboutDebian about some web server stuff. That gives a few more steps in installing PHP, but I don't remember having to do those. That could be because they're using Sarge (I'm using Etch) and PHP4 (we're installing PHP5).

Now to install MySQL. This is simple too, just use apt-get again, but this time you're looking for mysql-server. If you have to, tell it to start at boot up, so that it runs automatically without you having to start it manually.

Then you'll need to install the php5-mysql package to make them work together. Then we need to let PHP know to load that module, to do that we need to edit the php.ini file. You can do that by typing (if you have the same set up):

nano /etc/php5/apache2/php.ini

Then, do a search for:

;extension mysql.so

And simply uncomment that line. Save it, and then restart Apache and everything should be up and running. Go and make a phpinfo() file and it should list MySQL as a module.

I decided I wanted get my own server so that I could run it completely; I've had shared hosting in the past but asking for my host if he could do something for me, because I didn't have access was getting old. Running your own server lets you do whatever you want.

If you want to run your own server entirely, you have three options.

First, you can build your own server. Unless you have that spare parts lying around, it may cost you a lot to make it. It's basically just a computer. You won't need to have a flashy graphics or sound card, really so if you are building your own server, don't bother getting those. There's nothing wrong with just running Apache from your own computer, but you'll have to have it on all the time and have a permanent internet connection. Your ISP might not like that you're using them as your route to the Internet though! I do know that Virgin Media don't mind you doing that.

I'm not using this option because I don't feel like managing the hardware myself. And my mum would get pissed when our 2Meg connection slowed to a crawl.

Another option is a dedicated server. Basically the same as above, but a company is looking after the hardware and they have a much faster internet connection than you'll have at home. Downside of this is that they cost around £60 a month. You get lots of hard drive space and it's really fast generally.

I didn't bothered with that because... well, mostly because I'm poor. Also because I've no idea how to manage a server. Getting something as professional as that would be silly, if I was just going to break it eventually.

So, the option I went with was a virtual server. Exactly the same as a dedicated server, except you don't get as much hard drive space or memory because it's shared with other people on the same server. Nonetheless, you have complete control over everything that happens in your "partition".

At the moment, I'm paying $10 a month (£5.14) for a server has a kinda low spec, from Redwood Virtual. It's okay for what I need it for; playing around and learning the ropes. I guess we'll see what happens if this blog ever starts getting traffic, (heaven forbid one of my articles get Dugg.)

The LVS came with Debian. I had the option of picking the distribution; Etch, Lenny, or Sid. At this point, I knew nothing about Debian, so I ran to Wikipedia to find out what they were on about. The Debian article told me that Sid was an unstable version, so I'm not entirely sure why Redwood would be offering it. Etch is the current and stable version of Debian, and Lenny is the next version that's going to be released, though it's still in an "experimental stage", which I guess means that it's in beta. I went with Etch in the end, since I know that's going to work as expected.