Posts Tagged Ubuntu

Ubuntu Home Server (UHS)

I've recently set up a home server using Ubuntu. I thought it might be useful for me to record my experience and any problems / pitfalls / useful tidbits of information I found along the way. It's not been a particularly arduous process, but hopefully this might help someone out in the future.

The hardware I used was a semi-home build; I bought the Intel D525MW motherboard, which has an integrated dual-core Atom 1.66GHz processor, and fitted it into a case along with some RAM and a hard drive. The processing power on the motherboard should be more than enough for what we're asking it to do (see below), and it's low power so that means we can leave it on all the time, and it's passively cooled too. The other advantage is that it's mini-ITX, so nice and small to fit under the stairs where it's going to live. I fitted the board into a cheap no-name mini-ITX case which actually turned out to be decent quality, and added 2Gb Kingston RAM. The hard drive is a Western Digital Caviar Green (low power) 1Tb from a previous NAS setup. There's no DVD drive (what's the point nowadays, really?), and I'm using onboard video and sound.

My mini-ITX home server, prior to being shoved into the cupboard. Copyright Haydn Williams 2011

My mini-ITX home server, prior to being shoved into the cupboard. Copyright Haydn Williams 2011

The software I installed was obviously customised to fit our needs / requirements. I chose Ubuntu as the operating system, because a Mac was too expensive, a Hackintosh was too complicated in terms of finding 100% compatible hardware, and Windows Home Server was discounted for reasons I can't remember right now, but were definitely valid and unresolved. I have a little bit of experience with Linux, but never in an admin role and I've never used Ubuntu before. I have used the Terminal in Mac OS and Linux before, so have some basic competence in that area. I certainly wouldn't class myself as a 'guru' though, so if you're not a Linux whizz then don't worry – if I can manage it, I'm sure you can!

In terms of applications installed, we needed the server to carry out a number of roles:

  • File server (including Bonjour for Macs on the network)
  • DLNA server
  • NTP
  • Web server (including WordPress)
  • Repository / eventually CruiseControl
  • Time Machine backups

I've therefore split the software section up into a number of posts on this blog, all starting with the letters 'UHS':

  1. Installing and Updating Ubuntu
  2. Admin tools
  3. Hardware monitoring
  4. Samba file server
  5. Apache, MySQL, PHP (LAMP) web server + WordPress
  6. SSH and Subversion (SVN)
  7. DLNA media server
  8. Time Machine backups
  9. Network Time Protocol (NTP) server
  10. Calendar (iCal) server

Tags: , , , , , , , , , , , , , , , ,

UHS1 – Installing and updating Ubuntu

Installing Ubuntu was pretty painless. I was using v11.04, Natty Narwhal. My server doesn't have an optical drive, so I wanted to install from a USB stick. I also wanted Ubuntu Standard, AKA Desktop, rather than Server. The main difference seems to be that Server doesn't come with a GUI (Unity is standard on Desktop, although GNOME is also present), but does include things like LAMP. Multiple places say that you can install whatever packages you need if it turns out you've chosen the wrong version, so I don't think there's any inherent deep differences that should cause any major problems. As our machine will be used for internet browsing, playing music, etc, as well as server duties, Desktop seemed the way forward. (I appreciate you shouldn't mix desktop and server roles but to be honest, it's not a proper 'server' is it?). The steps I took were:

  1. Visit the Standard download page
  2. Download the installation .iso
  3. Run the Universal USB Installer tool to create the installation flash drive
  4. Plug the flash drive in, and boot from it
  5. Select the "install" option
  6. Create partitions as appropriate
  7. Marvel at the wonder of Ubuntu

Partitioning my single 1Tb WD hard drive was a bit of a gamble, since I don't really know Linux and didn't want to get it wrong. I read a lot of useless information from the internerd and eventually decided on the following scheme:

  • /tmp – 8Gb – Temporary files
  • /var – 8Gb – Variable files. Recommended to be a different partition from root – if a program goes crazy and fills the partition containing /var with, for example, log files, it doesn't fill the one holding your OS and it'll be easier to fix.
  • /home – 10Gb - Files belonging to individual users. Given the server nature of this box, ours will mostly be held in one big partition somewhere else that everyone (and other networked devices in the house) can access, so this didn't need to be too big.
  • /data – ~900Gb - The massive partition that will hold most of our data.
  • / – 50Gb – Root partition, containing Ubuntu amongst other things. I made it much bigger than I ever anticipated using (Ubuntu is about 4.5Gb I think), just in case.
  • /swp – 4.5Gb – Swap partition. Used to supplement RAM when it gets full. General concensus seems to be that it should be double the amount of RAM you have. I've got 2Gb so – again being over-cautious – made this a bit bigger than 4Gb.

The first five were all logical partitions in one extended partition. There's more information about how and why you should name your partitions on the Filesystem Hierarchy Standard site, although the Wikipedia entry is a bit more digestible. I'd recommend flicking through it, although I unfortunately only found it once I'd already decided on my partitions. I'm certain that this whole concept is a bit of a black art, which doubtless gets easier the more you work with Unix. I'm hoping this will suffice for now. If you want to view your partitioning once installation is complete, you can do so using the "Disk Utility" program.

Partition scheme viewed in Ubunty's "Disk Utility"

Partition scheme viewed in Ubunty's "Disk Utility"

During installation you'll be asked to choose a username; this account is created with Admin privileges so I chose a generic admin name for this. Once it was up and running I created our standard user accounts for everyday use (known as a "Desktop user" in Ubuntu parlance). This can be done using the "Users and Groups" application in the "System" category.

Now is also the time to decide on a name for your server – if you're indecisive like me then start thinking early! Most networks have names grouped around a theme; my old computer chemistry lab had machines named after greek gods. While some of these were very clever (Romulus and Remus for two servers which were mirrors, for example) on a home network there's possibly less scope for wittiness. Should you decide to change the name, just edit /etc/hostname to reflect your new choice. You should then also update /etc/hosts in a similar manner too (if you forget to do this, you may get a message the system is "unable to resolve host" at various points).

xkcd: Permanence

xkcd: Permanence

Once that's all done, I'd recommend running the apt-get command to ensure that all of the software installed by default is up-to-date. apt-get is the tool used to carry out, according to the official Ubuntu Documentation, "installation of new software packages" along with "upgrade of existing software packages". The commands you'll need to do the latter are:

[code lang="bash"]sudo apt-get update
sudo apt-get dist-upgrade[/code]

This ensures the list of programs is up-to-date, and then uses that list to ensure everything you have installed is also up-to-date. There's a bit more detailed info on Wikipedia.

You may also want to set up a Manual (i.e. static) IP address, particularly if you're running some kind of basic server. I did look at loads of options for doing this via the command line, but in the end I just gave up and went into "Network Connections" (which lives in the "Themes and Tweaks" section of "Applications", rather bizarrely). Select the relevant network connection (you may only have one), then select the "IPv4 Settings" tab. Change the "Method" from "Automatic (DHCP)" to "Manual" and then add the desired IP address in the "Addresses" section. Don't forget to add your DNS server(s) and then click "Save".

Setting a manual IP address in "Network Connections"

Setting a manual IP address in "Network Connections"

Finally, a word about sudo and su. There's a subtle difference between the commands sudo and gksudo – the former is fine for command-line programs but shouldn't be used for anything with a GUI (in which case, the latter should be used). psychocats has a great explanation of why you should use them properly. You'll also find that the 'root' account is disabled by default on Ubuntu, so you can't log in as root, and you can't use su to run a terminal as root either. Hence all the examples here prefix their commands with sudo. More in the Community Ubuntu Documentation.

Tags: , , , , , , , , , , , , , , , , , , ,

UHS6 – SSH & Subversion (SVN)

SSH

SSH lets you remotely access your computer, or other computers, using a command-line interface. Installing SSH really is a breeze:

sudo apt-get install ssh

It was so quick and easy I even had to check it had actually been done!

>which ssh

The binary did exist and I was able to log into the machine without any problems. Almost too simple! You'll probably want to increase the security of your setup a bit by using hosts.allow and hosts.deny files. These live in /etc and consist of rules that determine which hosts should be allowed to connect to certain services on your machine. My hosts.deny has the following:

ALL: ALL

and my hosts.allow has this:

127.0.0.1
SSHD: 192.168.1.23

This results in all connections from all IP addresses being denied, except for SSH from one specific machine on the local network. Note that the hosts.* files will only work on services started as daemons, not standalone, and these services must support TCP Wrappers (which are what make hosts.* work). This page, and another, revealed the following command to determine whether a particular daemon has support for TCP Wrappers; it basically checks whether the daemon depends on the relevant library, libwrap.so.0:

ldd /usr/sbin/smbd | grep wrap

Running the above command doesn't give any result, so smbd – the Samba server daemon – isn't affected by hosts.* (see my other post for rudimentary details on securing Samba). There are plenty of pages which delve into more detail about more complex rules for hosts.*, or you could just:

man hosts.allow
man hosts.deny

 

Subversion

Subversion (SVN) was no more difficult:

sudo apt-get install subversion subversion-tools

The first chance I got to test SVN as a client was when installing WordPress, which is covered in a different post. To test the server side of things, I just created a repository:

sudo svnadmin create /var/svn

Everything went swimmingly, so further setup will take place at a later date. There are a number of good guides online that will take you further with Subversion, which is beyond the scope of this post.

Tags: , , , , , , , , , , ,