Anyone that follows my Identi.ca feed will probably be aware that I recently switched away from Ubuntu and Archlinux and over to Fedora. This was mainly due to frustrations with Arch (I need a system which lets me get stuff done without too much overhead in looking after it) and my increasing feeling that Ubuntu isn’t going in the right direction for me as a power user/developer.

I recently wrote an article on Fedora 13 for our University LUG – UALUG and I thought I’d post a link for readers of this blog. The article focuses on Fedora 13 as a platform for developers and basically details my own Fedora 13 setup. It’s written with the aim of advocating Fedora for people new to Linux, but it also serves of my review of the latest Fedora release.

Anyway here’s the link: https://ualug.ece.auckland.ac.nz/archives/246.

Hopefully I should be posting some more interesting content here soon as I’ve been playing around with some interesting stuff. It’s just a matter of me finding time to write it up! Bye for now.

Is it just me or has there been an increasing amount of Apple fanboyism around recently? This is really beginning to annoy me. Principally, because I just don’t care. Apple are completely irredeemable in my eyes, they are worse than Microsoft, but no-one seems to see this, whatever they do!

This is really hacking me off in the Open Source media, particularly on podcasts (I’m looking at you Shot of Jaq!). Frankly, I don’t give a <censored> what Apple are doing, or what they might do in the future. I don’t listen to Open Source podcasts for this.

Then there’s Ubuntu, which seems to be moving closer and closer to the Mac in terms of looks (this isn’t necessarily a bad thing, but why can’t we be more inventive?). The Ubuntu community seems to be going
this way too. In a recent episode of the Ubuntu UK Podcast the words ‘the Mac just works’ were uttered. Hello! So does Ubuntu! (of course I can only speak from my experience, but I rarely if ever have problems).

As a solution to this growing epidemic, I propose a simple test which you should use if you are tempted to praise Apple in public, particularly in the Open Source media.

Simply answer the following five questions:

1. Name five pieces of Open Source software that Apple have contributed to the community.

2. Would you buy an iPhone over a Nexus One? Seriously?

3. Is the iPad even an original idea? (clue: No.)

4. If the Mac is so great, why is it so damned hard to use? Why can’t it be configured to work they way I want?

5. Do you like DRM? Apparently, neither does Steve. Slightly hypocritical, don’t you think?

If you can’t answer these simple questions in Apple’s favour, KEEP STUM!

Before I start: NO, UNLIKE EVERY OTHER ARTICLE ON THE WEB, PUBLISHED TODAY, THIS IS NOT A JOKE, K?!?

I’ve been looking for a new distro recently. I do this from time to time, principally because I get bored of what I’m currently running. Last time it was Crunchbang which I settled on. This time I wanted to go more advanced, so I started researching Arch Linux.

For those that don’t know, Arch Linux describes itself as:

…a lightweight and flexible Linux® distribution that tries to Keep It Simple.

I’d heard about Arch in the past from several sources and had heard that you basically have to install and configure everything yourself, but that the package manager (awesomely named Pacman!) manages software without having to compile from source (unless you want to!).

The following series of posts will be a record of my experiences installing and configuring Arch on my home desktop machine. This isn’t intended to be an exhaustive installation guide, more just a record of where I tripped up in order to aid those who come next. If you are searching for an installation guide, try the excellent article on the Arch Wiki.

I’ve separated the post out into days. Note: it didn’t actually take me a full day for each part, I work during the day and only really had a couple of hours each evening to spend on this.

Day 1: Backing Up

Before installing I wanted to make sure I didn’t trash my existing Ubuntu system and all my personal data, as I still need to do all the stuff I usually do with my machine. So I made a backup.

I’m not really going to go into how. Suffice to say I used LVM snapshots and rsync, I might write about this in a future post.

This took a while, as I have quite a lot of data. I thought it best to have a beer in the mean time, so I did.

Day 2: Making Space, Starting the Installation and Various Adventures with LVM

The next thing to do was to resize my existing LVM partition containing Ubuntu so that I had space for Arch. I couldn’t work out how to do this at first as none of the partition tools I tried (GParted and Cfdisk) could resize the partition. I eventually worked out how to do it.

First, on my running Ubuntu system I resized the physical volume with:

$ pvresize --setphysicalvolumesize 500G /dev/sda1

This shrank the space used by LVM down to 500GB (from about 1000GB on my machine).

I then rebooted into the Arch live CD (64-bit edition in my case), and ran:

$ fdisk /dev/sda

Now what you have to do next is slightly alarming. You actually have to delete the partition and recreate it in the new size. This works, without destroying your data, because fdisk only manipulates the partition table on the disk, it doesn’t do any formatting of partitions, etc.

I did this through fdisk so that the partition was 501GB (making it a little bigger than the PV just to make sure). I then rebooted back into Ubuntu and ran:

$ pvresize /dev/sda1

To allow it to use all the space. This probably isn’t necessary but I wanted to be safe.

Next, I proceeded to the installation. For some reason the Arch boot CD was really slow to boot and gave me loads of read errors, I think this might have something to do with my drive as I’ve been experiencing the same with other disks. Eventually it booted and dropped my at the default prompt.

From then I basically followed the installation guide for setting up the package source (CD) and the date and time.

I then set about partitioning the disks. The Arch installer uses Cfdisk, which is fine. I just added two partitions to my disk, a small (255Meg) one for my /boot partition and a large LVM one for the rest of the system (I like LVM and wanted to use it again on Arch).

This was fine, but I had some problems setting up the LVM through the installer, even though the user guide seems to think it can do it. Every time I tried, it would just fail on creating the Volume Group, weird.

I gave up for the evening and (you guessed it) went for a beer!

Day 3: Successful Installation

The next day I thought I’d try googling for LVM on Arch, luckily when I got in to work @duffkitty on identi.ca had seen one of my posts complaining about having problems and had given me a link to the LVM article on the Arch Wiki.

This advocated setting up the whole LVM setup manually (and guides you through it) and then just setting the partitions to use in the installer. It also gives you some important things to look out for when configuring the system. Following these instructions worked like a charm and I was able to format everything correctly and install the base system.

I then moved on to configuring the system, following the install guide and taking into account the instructions in the LVM article. Everything went pretty much fine here and I eventually got to installing the bootloader. Here I replaced the Ubuntu Grub version with the one installed by Arch. This left me having to add an entry for Ubuntu, which wasn’t difficult, I just copied the Arch one and changed the partition and file names.

Then it was time to ‘type reboot and pray’ as the Arch installation guide puts it.

So I did.

When I rebooted the bootloader came up with the Arch and Ubuntu entries. I selected Ubuntu just to check everything was OK.

It didn’t work.

Panicking and Swearing Ensued.

I rebooted and selected Arch.

That worked (thankfully).

When it had booted I logged in and opened up the Grub config file again. it turned out I mis-typed the name of the Ubuntu initrd file, that was easily fixed. Rebooting got me safely back to Ubuntu.

So now I have a functioning dual boot between my original Ubuntu install and a very basic Arch install, I think I might need some software there!

But first… beer.

So What’s Next???

Well, firstly I need to get my network connection up and running as I didn’t do that during the install. It’s a Wifi connection over WPA so that’s going to be fun. Then I can start installing software. I’ll probably follow the Beginners Guide on the Wiki (from Part 3). I was also recommended Yaourt by @duffkitty, so I’ll give that a try.

I’ll be continuing to play with Arch over the next few days and reporting my progress in follow up posts here. I’ll also be denting as I go along and you can follow all of these on my #archrob hash tag.

There’ll probably be beer too.

We’ll see how it goes, but eventually I hope to have a system I can use full time.

Bye for now! Happy Easter!

In the Electrical and Computer Engineering Deaprtment of the University of Auckland, where I work we have a little device, internally known as the ‘DonKey’. The purpose of this is to allow easy programming of Atmel AVR based microcontrollers via USB, rather than the simpler serial interface. We also have some internally developed software to program microcontrollers via the device, unfortunately this software is pretty much windows only (we did have a successful attempt to compile it for Linux, but this was quite a while ago, a better solution would be to use a native Linux application).

Internally the DonKey uses an FTDI based USB to UART chip (specifically the FT232R) to communicate with the microcontroller. This presents some problems as, despite being the basis of the programmer on incredibly popular Arduino boards, the main Linux programming tool (AVRdude) has no official FTDI support. I think this is largely due to the use of a bootloader on the Arduino boards, which negates the need of the programming tool to directly flash the board. If however you brick the AVR on the Arduino, you would be out of luck and would need a physical programmer (more on this below).

The DonKey in all it's glory.

In this howto I’ll cover how to get the DonKey working on Linux with AVRdude. Luckily, while researching how I might go about this I found that a large part of the work had been done for me, due to the fact that the Arduino also uses these chips. I found instructions on doswa.com on how to patch and compile AVRdude for just this purpose (so you could flash a bootloader to a new AVR).

These instructions work quite well for the DonKey, up until you get to running the ‘./configure’ command, I replaced this with:

$ ./configure --prefix=$HOME/.local

to setup the code to do a local install in my home directory (as I want this to be my primary version of AVRdude, but not to screw with things on the root filesystem).

Next I followed the instructions on modifiying the makefile and compiling AVRdude via the ‘make’ command. After ‘make’ I also typed:

$ make install

to install into the directory setup earlier. Now AVRdude is installed, the next thing to do is a bit of configuration, firstly you’ll want to make sure it’s on your $PATH so add the following to your ~/.bashrc file:

export PATH=$HOME/.local/bin:$PATH

and run the command:

$ source ~/.bashrc

to re-read the file.

The next issue is that you may wish to remove any copy of AVRdude that is otherwise installed (I found that sometimes my shell would run the wrong one – especially if you use ‘sudo’ to run it):

sudo apt-get remove --purge avrdude

Now, I just mentioned above that you might use ‘sudo’ to run AVRdude, well according to the doswa article you do need to use sudo when using the FTDI based programmers. I’m not sure why this is, but it’s not very useful if you want to be able to call AVRdude from a Makefile or the like.

I solved this by setting a ‘suid root’ on my AVRdude binary. For those that don’t know what this is, the suid bit is a Unix permission setting that makes any program with it run under it’s owning user rather than the user who called it. If the owner happens to be root, the program runs as root even if the user who calls it isn’t. This is probably really insecure if you do it a lot, but you should be OK in this case.

WARNING: Despite what I say, it might not be OK. Allowing any program unrestricted root access has the potential to hose your system and scatter all your data to the winds. FOLLOW THESE INSTRUCTIONS AT YOUR OWN RISK!!

So here we go:

$ sudo chown root:root ~/.local/bin/avrdude
$ sudo chmod u+s ~/.local/bin/avrdude

Now you should be able to successfully run AVRdude on FTDI based devices without resorting to using sudo every time.

But, what of the DonKey I hear you cry! Well all we have to do to support the DonKey is give AVRdude a little bit of configuration which tells it what the DonKey actually is. This can go in ~/.avrduderc, and looks a bit (well exactly) like this:

programmer
id = "donkey";
desc = "University of Auckland ECE DonKey";
type = ft245r;
miso = 1; # D1
sck = 2; # D2
mosi = 3; # D3
reset = 4; # D4
;

OK, now you should be able to successfully use the DonKey with AVRdude, using a command similar to this:

avrdude -c donkey -p m8 -P ft0 -U myawesomeavrproject.hex

Note: this command is for the ATMega8 as denoted by the ‘-p m8′, check the AVRdude manual page for the correct -p option if you are using a different type of AVR.

OK, well that’s pretty much it, I’ll post back soon regarding my other progress with some microcontroller stuff. Bye for now!

The following commands will resize an ext2, ext3, or ext4 filesystem running on LVM while it is mounted:

$ sudo lvresize -L +XXG <path to fs device>
$ sudo resize2fs <path to fs device>

In the above command you need to replace XX with the number of GB you want the filesystem to grow by and <path to fs device> by the device node (typically /dev/mapper/something).

An there you have it, done! Obviously there is a huge amount more you can do with the two tools above, take a look at their man pages for more info.

Hopefully this post will save me from having to work out how to do this every time!

The responder was Stephen Sharon via Twitter, he’s written a paper around some of the legal concerns over turnitin and he sent me the link. It’s good reading and confirms some of the things I had heard surrounding the site. I’d encourage everyone reading this to click through and read Stephen’s paper (it’s 38 pages, but double spaced and with much of each page containing references).

I’m not qualified to give legal comment on tunitin (I’m an Engineer not a Lawyer), but I will give my opinion. Before I do I’d like to give the following disclaimer (in true Software Freedom Law Show style):

WARNING: The following DOES NOT (in any way, shape or form) constitute legal advice, it is only my own (perhaps misguided) opinion. I would urge anyone who has any concerns over how their data may have been used by Turnitin to contact someone who actually knows what they a talking about, in this case A LAWYER!

Basically, I think Turnitin is on pretty shaky legal ground both in terms of Copyright and Privacy (certainly under US law). Here in New Zealand we have different privacy laws, but I’m sure they probably say much the same thing. The copyright issues are also concerning, I don’t want to turn over my rights to Turnitin just so I can submit my paper. What if my assignment gave technical details of an invention which I may in future have some financial interest in. Turnitin would have the right to use that information as they see fit.

Realistically I think it’s only a matter of time before Turnitin is taken to court again to face a hard examination of their user agreement, etc. This whole thing brings me back onto the subject of Free Software. I think it really is important for these tools which have such important uses to be Free (as in speech), it would be great to see a Free Network Service replace Turnitin as the dominant player in this market. I would much rather trust that to be transparent and honest than a company driven by profit and market share.

Anyway that’s just my $0.02. Before I finish I’ll encourage you all again to read Stephen’s paper.

Bye!

When I logged in I got a message warning me that it might not work, but I honestly don’t see the reason why. Shouldn’t it just be browser specific, not OS specific? I then proceeded to upload my PDF and it seemed to think it actually wasn’t a PDF! Switching to a Windows XP machine and uploading the same PDF worked fine which is the really random thing.

I don’t even see why our University has to use a third party service for this anyway, I’m sure they have the resources to do this in house. Then there is the whole copyright thing, which I’m not altogether happy with either.

Anyway, at least it seems Ubuntu isn’t alone in this, according to a friend Windows 7 also triggers the same error message (albeit without the PDF fail).

Again, sorry for the rant.

The main piece of software you will need is dnsmasq, which you can install with the command:

sudo apt-get install dnsmasq

I already had this installed as I’m using it as a DNS cache for my network (which is also pretty useful). It turns out that dnsmasq is a bit of a ‘swiss army knife’, it can do DHCP, DNS and TFTP all together and very easily. You should edit the config file:

sudo nano /etc/dnsmasq.conf

And add/uncomment/edit the following lines:

dhcp-range=192.168.1.3,192.168.1.50,12h # sets the ip address range and update frequency for the network
dhcp-boot=pxelinux.0 # set up network booting to boot the pxelinux bootloader
enable-tftp # enable built in tftp server
tftp-root=/var/tftpd # set tftp directory

Basically this sets up dnsmasq to be both the DHCP server for the network and push the PXE boot options out over the network. It also enables the built in TFTP server in dnsmasq and sets the directory to serve files from.

The next step is to get some files to serve, I got the PXE/netboot image from the Ubuntu cdimages site, and untarred the files to the correct directory:

wget http://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/netboot/netboot.tar.gz
sudo mkdir -p /var/tftp
tar -xvzf netboot.tar.gz -C /var/tftp/
chown -R nobody:nogroup /var/tftp

The tar file of course is basically just the minimal install CD, set up for netbooting, so when you install you will need to download all the packages, for a simple cli install this doesn’t take very long, and you can use a package cache or something to help with future installs.

OK, now restart dnsmasq:

sudo /etc/init.d/dnsmasq restart

…and you should be good to go (make sure that your machine is the only DHCP server on the network). For tips on booting clients see my original article – btw, since I used the new version of Ubuntu I can now boot my Eee PC 901 over the network!

If you have any questions or problems with this I’d be happy to answer them, just post them below.

Bye for now!

But it is kinda static. By this I mean it’s not particularly suited to environments where things change frequently. For example, we have a local mirror at uni, which of course it much faster than using the external Ubuntu or Debian ones, however as this is only available from internal University of Auckland IP addresses I would have to change my /etc/apt/sources.list file if I wanted to install something from home.

Today I knocked together a quick Python script to fix this, all it does is basically manipulate a symlink which points to the real /etc/apt/sources.list file, but I thought I’d share it anyway:

#!/usr/bin/env python
import sys, os
def usage():
print "Usage: %s " % (sys.argv[0],)
def main(argv):
if argv[1] != None:
sources_path = "/etc/apt/sources.list.%s" % (argv[1],)
if os.path.exists(sources_path):
os.unlink("/etc/apt/sources.list")
os.symlink(sources_path, "/etc/apt/sources.list")
print "SUCCESS: Don't for get to run 'sudo apt-get update'"
return 0
else:
print "ERROR: Unknown repository set '%s'" % (argv[1],)
usage()
else:
usage()
return 1
if __name__ == '__main__':
sys.exit(main(sys.argv))

Unfortunately wordpress screwed with my formatting there (which kinda matters in a python script) so here is the file (repo-switch.py). You’ll need to download it and put it somewhere in your $PATH. Then make it execuatable:

chmod +x repo-switch.py

The next step is to set up your lists of repositories. Each list will have a suffix which the script will use to identify it. First I copied my main repositories (for the NZ Ubuntu mirrors):

sudo cp /etc/apt/sources.list /etc/apt/sources.list.nz

Obviously replace ‘nz’ with a suffix of your choice. Then I dropped the list of repos for the local mirror into another file (in my case /etc/apt/sources.list.ece). You can set up as many different sets as you like, but I only need two.

Next step is to practice switching between them:

sudo repo-switch.py nz

…sets apt to use the file /etc/apt/sources.list.nz by changing /etc/apt.sources.list to a symlink pointing to the relevant place. Calling the script again with a different set (e.g. ‘ece’ in my case) will set it up to use one of your other sets.

Obviously, you’ll need to run ‘sudo apt-get update’ each time to make apt work with the new repos, but I added a line to the script to remind you!

Magic!

A while ago my boss came to me with an idea. He wanted to purchase a number of netbooks and install LimeSurvey on each of them to be used as a mobile survey unit, that could be taken to schools, colleges, workplaces, etc. and used to collect data for research projects. I pointed out that if we were to install LimeSurvey on all the netbooks each would need an individual webserver and MySQL server, which apart from being a lot of effort would fragment the dataset and make it much more difficult to collect the data together.

Hence, I suggested that we setup one of the machines as the server and set it’s built-in Wifi to work as an access point for the others so they could access the server. This means that no external network access is required, you carry the server with you!

Well, today the netbooks arrived (we ended up with Acer Aspire Ones in the end). So I set about configuring one to be our server. This model came with Windows XP pre-installed (not sure if you can get a Linux version), but also had a 160GB hard drive. My instinct was to install Ubuntu Server as it has an option to deploy a LAMP server out of the box (which is awesome and would have saved me loads of time). So I downloaded it from our local mirror and flashed the iso to my usbstick with Unetbootin, which I hadn’t used before. I booted from the usbstick and everything went well until I got to the ‘detect CDROM drives’ bit – which usually detects the usbstick as containing the files from the iso. Not so here, no matter what I tried it wouldn’t be convinced that the usbstick was a CDROM!

So, I fell back to what I have previously used, Isotostick, a nice little shell script thats always done this well for me. Same problem.

Turns out the problem is with the server and alternate isos of Ubuntu, which don’t contain the correct FAT driver for loading the installation packages from a usbstick. There is a workaround for this, here, but I couldn’t get it to work. So, I decided to use the Ubuntu Desktop version (thank God our mirror is internal to the university!). I realised later that this had the advantage that the server could also be used as a client and the server software would be invisible to the user.

So I installed that. Which went fine as you’d expect. When I rebooted after the install I found that the wifi didn’t work. A quick google turned up a page which gave instructions on how to install the latest madwifi driver from source, which I did, though I had to manually dig up build-essential (and dependancies) from the /pool folder on my usbstick and install them with dpkg as I couldn’t get it to recognise the usbstick as an apt repository. I wouldn’t have had this problem if I’d have had a wired connection on the machine though.

Then I set about installing the packages required to turn it into a server:

$ sudo apt-get install apache2 phpmyadmin mysql-server dhcp3-server bridge-utils

I’m not sure whether the bridge-utils package is strictly required, but I installed it anyway. It doesn’t do any harm as it’s only a few kB to download. If you are following this as a howto and are only using the Wifi as your net connection (as I was), make sure you install all of this now as later on you’ll lose your connection when we setup the Wifi to be an access point. If you’re on ethernet, you’ll be able to keep your connection (but see later).

Installing those packages took a while over the Wifi, so while it was going on I downloaded and installed LimeSurvey. I don’t really need to say how to do that as it’s all documented on their site. I unpacked it to /var/www/survey on the server and configured it as per the instructions. Once I had all the packages above installed I was able to create a database and user through phpmyadmin and run the LimeSurvey installation script. Pretty much the same as installing any other PHP app.

Next came the wifi setup, I played around for a while trying to get this working, but I think the following is probably the best course to take in setting this up. You need to start by putting the wireless adapter into access point/master mode, you do this (for the atheros card used in the Aspire One) by editing/creating the /etc/modprobe.d/madwifi file (documented here):

$ sudo nano /etc/modprobe.d/madwifi

The file contents should be:

options ath_pci autocreate=ap

Then reload the kernel module:

$ sudo modprobe ath_pci

You’re then ready to reconfigure the network interfaces, if you type iwconfig, you should see that the ath0 device now has the capability to act as an access point. To setup the access point you need to edit the network interfaces file:

$ sudo nano /etc/network/interfaces

The contents of my file were as follows:

auto lo

iface lo inet loopback

# uncomment the following two lines if you’re on ethernet and you want to still have a connection once you restart the networking!

#auto eth0

#iface eth0 inet dhcp

auto ath0

iface ath0 inet static

wireless-mode master

wireless-essid my-access-point

address 192.168.1.1

network 192.168.1.0

netmask 255.255.255.0

broadcast 192.168.1.255

This sets up the network interface acting as an access point with name ‘my-access-point’ and assigns the local machine a static address of 192.168.1.1 on the network. To reload the configuration, do this:

$ sudo /etc/init.d/networking restart

Note: at this point you will lose ‘outgoing’ wifi connectivity as your adapter is now acting as an access point!

Now, if you boot up another machine with Wifi, you should be able to see the ‘my-access-point’ network in the list of available networks. However, connecting to it won’t currently work as you won’t be able to get an IP address, this is where the DHCP server, which we installed earlier, comes in.

In order to set this up we first need to tell it to listen for DHCP requests on the correct interface, in our case ath0. We do this by editing the /etc/default/dhcp3-server file to look like this:

# Defaults for dhcp initscript

# sourced by /etc/init.d/dhcp

# installed at /etc/default/dhcp3-server by the maintainer scripts

#

# This is a POSIX shell fragment

#

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?

# Separate multiple interfaces with spaces, e.g. “eth0 eth1″.

INTERFACES=”ath0″

Next we setup the DHCP server to dish out addresses to the clients on out network, edit the file /etc/dhcp3/dhcpd.conf to have an entry like the following:

subnet 192.168.1.0 netmask 255.255.255.0 {

range 192.168.1.100 192.168.1.200;

option domain-name-servers 192.168.1.1;

option domain-name “mynetwork.local”;

option routers 192.168.1.1;

option broadcast-address 192.168.1.255;

default-lease-time 600;

max-lease-time 7200;

}

I don’t know whether all those options are definitely needed, but this configuration works. I think you could probably get away without the routers and name servers, as these won’t exist on this small standalone network.

OK, now start up the DHCP server and you should be in business:

$ sudo /etc/init.d/dhcp3 start

Assuming that works OK, try connecting to the ‘my-access-point’ network from another machine, it should work (if it doesn’t or you can’t see the network, try rebooting the server machine).

Once you’ve successfully connected you should be able to browse pages hosted on the server at http://192.168.1.1, so my LimeSurvey install would be at http://192.168.1.1/survey. Now you have a portable server that you can take round to serve web apps to machines in the vicinity! Awesome!

That just covers the server part of what I have planned for these small netbooks, my ultimate aim is to set them all up running Ubuntu with a lightweight desktop and Firefox started automatically in Kiosk mode (thanks to the R-Kiosk addon). This will give us ten little survey machines which will just ‘boot’ into Firefox and go to the LimeSurvey page. I’ll post details of that setup once I’ve done it, but for now that’s all! Bye!