Björn’s Blog

I finally got WPA2 to work on my old Mac Mini G4, which is running Ubuntu Linux 10.04 server edition for PowerPC (Update: WLAN worked for a while, but it seems to be very unstable. Could be the location where it sits, or the software – Update2: running it at another location, it seems to work fine and stable).

I wanted to use the old Mini as a homeserver for a long time, but my girl-friend had complained about the (faint) noise it makes. Without a wireless connection, I had to place it next to the router, which in turn is placed next to her room.

Now with wireless I put it on the fridge in the kitchen, which is already quite noisy. Unfortunately, my girl-friend still complains. But I hope she’ll either get used to it, or I can still find a better place. With WLAN, there are more options.

Since I have installed Ubuntu Server and Samba for serving Windows shares months ago, I have forgotten the steps and can not talk about them now. I remember that the Ubuntu installation was really simple. Also I had apparently already configured the driver for the Mini’s wireless card, so I am not sure how I got that working. For a long time, I was unable to get wireless to actually work, especially not with WPA_SUPPLICANT providing access to my WPA2 encrypted network.

Hopefully information for installing the correct drivers for the Mac Mini wireless card can be found reasonably easy, as I can not retrace the steps anymore. My Mini required the b43 drivers, which requires download of the firmware by installing the b43-fwcutter package (sudo aptitude install b43-fwcutter).

So assuming your driver is working, I eventually found WPAHowTo for an old version of Ubuntu that describes most of the steps for configuring WPA2 (I only read the WPA_SUPPLICANT parts of that HowTo). All the newer how-tos seem to assume a graphical user interface and only describe how to use network-manager.

All instructions say to shut down eth0 before trying to start wlan0 (that’s how they are called on my system). So I grudgingly connected the Mini to a monitor and a keyboard again to complete the configuration. I also tested wlan without encryption, which worked.

Next install wpa_supplicant if not already done (sudo aptitude install wpasupplicant).

My wlan network uses a preshared key, so I used wpa_passphrase to generate the basis for a config file:

wpa_passphrase NetworkEssid passphrase


(replace NetworkEssid and passphrase according to your network’s setttings).

which resulted in output like

network={
ssid="NetworkEssid"
#psk="TextPassphrase"
psk=somerandomnumbersandletters
}


Then create or edit /etc/wpa_supplicant.conf (on my system the file did not exist yet). Since it needs the output of wpa_passphrase, I actually piped the output of wpa_passphrase into a file and copied it to /etc/wpa_supplicant.conf (somehow piping there directly didn’t work). (all operations in /etc require root privileges, so sudo accordingly). Also change owner and group of the conf file back to root in case by copying it or creating it it became owned by your “normal” user (chgrp root thefile and chown root thefile).

After some searching around, I found an example wpa_supplicant.conf for a WPA2 WLAN network using a preshared key and CCMP/AES encryption here They say they need a weird “double configuration” for it to work, but actually it also worked for me when I removed the TKIP stuff. So my final wpa_supplicant.conf file looks like this:

network={
ssid="dummy"
proto=WPA2
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
#psk="dummydummy"
psk=somerandomnumbersandletters
}


(Except of course other values for dummy and psk). It is probably save to delete the line with the clear text password, too.

Now the instructions from the WPAHowTo said to test wpa_supplicant like this (already with my parameters, not the ones from the HowTo):

sudo wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -Dwext

(Omitting the -w parameter from the HowTo, doesn’t seem to exist anymore)

The problem here was the -D parameter, as here you are supposed to state the correct driver (also, apparently, instead of wlan0 your wlan might have a different device name). At the Homepage of the linux driver for the b43 I found the information that “wext” should be used for wpa_supplicant.

So, again following the old HowTo, I put the following into my /etc/networks/interfaces:

auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf


Now if I power up the server, it automatically connects to my WPA2-encrypted WLAN. I was very happy about this and put the server on the fridge. However, while I started writing up this summary, I experienced several connection losses. Now I feel like giving up on connecting the server via WLAN and try one of those Powerline networking things instead, which enable networking through the electric power lines (like this one).. On the other hand, I just moved the Mac Mini server into my room to connect it to the monitor again, and here WLAN seems to work fine. So maybe it was just the location on top of the fridge that doesn’t work – it is closer to the router, but at another angle and with different walls in between. I might try some other places for the server yet.

One candidate might be the bathroom, but I am bit worried about the occasional high humidity.

There are yet more issues to be solved before my home server is ready. Backups, what kind of file systems to share, iTunes server (?) or something else?

One small thing I also haven’t yet found a solution for yet: it would be nice if the Mini would shutdown if I press the power button. At the moment the power button simply seems to be ignored by the Ubuntu Server installtion. I could not yet find a solution for this – in the net there are some instructions for making the power button initiate the shutdown sequence, but they are all for normal PCs, not for PowerPC Minis. If anybody knows of a solution, please let me know!

That way, my girl-friend could also power the server on and off without having to learn about ssh and linux shells, and it wouldn’t have to run all the time.

Valentine’s day is upon us, and like many other special days throughout the year a pesky aspect of the internet rears it’s head again: e-cards.

For one thing, spammers jump on the opportunity and send around intriguing e-card announcements of the form “somebody sent you an e-card” or “n people want to meet you on network x”. It’s a good idea to never click on those links in emails, as most likely they’ll just link to a scam.

So that is one reason not to send e-cards: it endangers the recipient, because he is getting used to clicking on e-card links, which might be hazardous. The better e-card sites are capable of including the senders name in the email (“xyz sent you an e-card”), but even that is no guarantee that the e-card is legitimate. It is easy to harvest the names of a person’s friends from various social networks (Facebook and others) and simply pretend to send e-cards in their name.

One way to at least send a reasonably safe e-card would be to use a very well known and trustworthy company, like Yahoo, Google or Amazon (and that list is probably the complete list, I can’t think of any other well known sites). But even then it is still rude: by sending somebody an e-card, you are giving away that person’s private information, namely their email-address. Chances are high that in addition to your lovingly selected e-card, that person will also receive a never ending amount of spam mails for the rest of their lives.

If you absolutely want to send a greeting card by mail, just attach a regular JPEG image to an email you sent from your normal email program. Otherwise, why not invest in a real postcard? I know there are a lot of funny flash movies available for special occasions, but really JPEG is preferred. The chances for security holes in JPEG viewers are very small (although not impossible), and the same can not be said for most other formats like flash or Power Point.

That said, I admit that the occasional e-card from a friend has given me a warm fuzzy feeling. I don’t really expect most people to understand the issues with e-cards, or with giving my email address to a 3rd party. But I’d prefer it if they did, hence this article.

Whether they loved it or hated it, all reviewers of the iPad agreed that usability of “normal” PCs for average users is atrocious. And I have to agree: whenever I take a look at the PC of a friend or relative who is not a “computer freak”, they are always riddled with spyware and malware or at least ladden with useless software that draws away time and energy of the user (examples are “Toolbars” like the Google Toolbar or the Yahoo Toolbar). This is not only because they might have downloaded or installed bad software from questionable sources, but because even vendors or seemingly trustworthy businesses have no qualms to sell their customers. Usually a new PC is already messed up by the software the vendor has preinstalled. If not that, then the new gadget (camera, navigation system, whatever) might come with crappy software.

But I don’t want to rant about the various ways today’s PC software and hardware vendors mess up the PC experience. The point is, by many reviewers the iPad has been hailed as the savior from this hell of malware and overly complicated software. What I want to mention is that the “geeks” (computer savvy people) have actually been aware of this problem for a long time, and they have invented a solution long before Apple’s App Store. It is called APT.

APT is a front end to the package managers of some Linux distributions, most notably Debian and it’s derivative Ubuntu. By using it you can install software from a trusted repository of open source applications (trusted because it is open to peer review). It is not the only way to install software on these Linux systems, but usually if you opt to install software from another source, you end up feeling slightly icky and dirty, as you should.

To avoid icky spyware, malware and so on, just stick to the official repositories of your Linux distribution. It is as simple as that – no debilitating iPad required.

Now I have to go ahead and admit that I am not even that well versed with Linux and apt. I know how to find, install and remove programs, and some other internals that are not really important. But isn’t that kind of the point: you can use Linux and apt even if you are NOT a “computer freak”. There are simple front ends that enable you to use it without using the command line. The main difference to Apple’s App Store is that it is still open – using apt is entirely optional, but recommended.

Of course, things on Linux don’t always run as smoothly as with a Mac (although I have whole lot of things to complain about with Macs, too). Not all the software in the repositories is very polished or even bug free. But neither is software in the app store.

As for stability, it helps to look at the hardware Apple has on offer: presumably they only actually sell three or four different kinds of computers (a laptop, which includes the iMac and the Mac Mini which are also based on laptop internals, the Mac Pro, and the iPhone/iPad). Most Linux distributions try to support a far wider range of hardware and therefore are less optimized for any specific piece of hardware. But it would be possible even today to launch computers with a Linux distribution optimized just for these computers. They should have no troubles achieving adequate stability.

Anyway, maybe you get the idea, maybe you don’t, all I want to say is this: the App store model is NOT our only salvation.

I finally managed to set up a git repository on my debian server that can be accessed via http WebDAV. Since there were a few stumbling blocks I could not find any information on, I thought I should blog a quick note. This won’t be interesting to many visitors of my blog, but perhaps it can save some people a bit of time if they run into the same problems as I did.

First I have to say that I don’t know very much about the ins and outs of git yet (and the same goes for WebDAV). I merely tried to follow some tutorials for setting up a central git repository. I am not even sure if access via http is a very good idea. But I am sharing the server and before git we used subversion via WebDAV, so it seemed like the most consistent way to go the same route for git.

For the most part I followed the instructions found in this “git server over http tutorial” on kernel.org

This almost worked, but left out issues with https and a strange command named “git update-server info” that needs to be run on the server after each commit. Luckily it will be run automatically eventually, but the first time it has to be run by hand (or so it seems).

Since the tutorial at kernel.org covers most steps, I’ll describe the problems I had first and then try to give a very brief summary of all steps in at the end of the article.

git update-server-info, file ownerships and update hooks

One issue I ran into was that after trying to push to the server, git push would end with

Updating remote server info
PUT error: curl result=22, HTTP code=403


And after that I could still not pull the changes from the server into another clone.

I could not find any info on this on the net. It turned out that there were some files in the git repository that were not owned by www-data (the apache2 user). I suspect it happened when I executed

git update-server-info

on the server, which I was supposed to do once in the beginning (according to a website I unfortunately can’t find anymore now). So making www-data the owner of all files by executing

chown -R www-data /path/to/git-repo

fixed that.

As for the initial call of git update-server-info, I am not sure. Maybe it would not have been necessary had the “hook” worked from the beginning. But in case there are problems, it is probably worth executing.

git update-server-info


in the root directory of the git repository once. After that, check again that all file permissions are correct (www-data should be the owner of all files).

It seems in subsequent git push calls git triggers the update-server-info hook automatically.

Frankly it makes me feel a bit uneasy – it seems WebDAV allows writing to the git repository and executing files – could it overwrite the executable and then execute it? A bit more than what I would like to allow guest users. But WebDAV and git where implemented by smart people, so for now I’ll assume that it is going to be OK (and I don’t have guests on there yet anyway).

HTTPS, self-signed root certificates and curl+ssl on OS X with MacPorts

The other problem I had was that I wanted to allow HTTPS access only. Our apache server uses a self signed root certificate that somehow had to be made known to git. Otherwise git operations would fail because it could not validate the certificate. The tutorial on kernel.org writes that you can disable the validation, but that is a temporary solution at best.

Apparently git uses libcurl, so making the certificate known to curl fixed the problem. However, by default curl on OS X does not even have ssl support built in if it is installed via MacPorts. I found a blog article on enabling https support which explains that the remedy is to install curl with options as follows:

sudo port install curl +ssl


First the old version has to be uninstalled, though (or MacPorts has to be convinced in some other way to do the upgrade – Update: via Twitter @MacPorts told me to use “sudo port -fn upgrade curl +ssl”). This turned out to be very complicated for someone who does not know MacPorts very well. Simple port uninstall commands would fail because of dependencies, and even

sudo port uninstall --follow-dependents curl


Would fail because sometimes there would still be multiple versions of packages around and MacPorts would then not know which ones to uninstall (yeah right, because I want to keep the outdated package??).

After a bit of Yahoogling I found that I could purge all the outdated packages with the command

sudo port -f uninstall inactive


The -f is for force, however, so it uninstalls even if there might be some dependencies. I have not yet checked if any other packages have stopped working. Also, for the future I know to run “port -u upgrade” instead of “port upgrade”, as the -u flag is supposed to tell MacPorts to uninstall the outdated versions right away.

With that cleared up, I could uninstall and reinstall curl and curl +ssl. One more thing to do about the certificates problem: make it known to curl. Our certificate was already in PEM format, so all there was to it was to add the text from the PEM certificate to /usr/share/curl/curl-ca-bundle.crt and git stopped complaining about the certificates. curl will name the location of it’s ca-bundle, in case it is located elsewhere on your system. I really added the certificate manually by opening curl-ca-bundle.crt in a text editor and copy+pasting the root certificate text (UPDATE: I just realized that MacPorts replaced that file when updating curl+ssl – looking for workaround). There are tutorials for importing the certificates from Firefox, but I don’t think they necessarily work for OS X. However, Firefox might provide an easy way to convert certificates to PEM, as it lets you choose the format for exporting certificates (in “Preferences”->”Advanced”->”View Certificates”).

Update: on Ubuntu 9.04 I also had problems to let curl know about the certificate. What worked where the instructions found at help.ubuntu.com for “Importing a Certificate into the System-Wide Certificate Authority Database”.

However, somehow git on Ubuntu does not ask me for a password and just fails with error code 22 (unauthorized). As a workaround for the time being I tried to hardcode my password into the remote URL (username:password@url), but that led to an error message (same as this one). Putting my login information into ~/.netrc as follows worked:

machine domain.name
login foo
password bar


I am not very happy with that, though, as it puts my password into a file in clear text.

quick steps summary (on Debian Linux)

Create directory for repository, either below apache2 DocumentRoot (usually /var/www) or some other lcoation you deem suitable

mkdir myproject.git

Init git repository with –bare option (apparently to make sure it never gets into unclean state – it should not be used the same way a local git repo is being used). Make accessible to www-data (apache user).

cd myproject.git
git --bare init
git update-server-info
chown -R www-data.www-data .


(note: install git with apt-get install git-core, the package “git” seems to be something else). Enable WebDAV (it seems I did not need the dav_fs as suggested in the kernel.org tutorial)

a2enmod dav

Configure apache for allowing WebDAV to the git repository. I also require SSL – however I won’t go into this. The infrastructure already existed on my server and I don’t want to search for tutorials now. There should be plenty of tutorials on setting up SSL for apache2. The same goes for setting up BasicAuth. Also I did not add my changes to /etc/apache2/httpd.conf but to the respective VirtualHost config file for my domain in /etc/apache2/sites-available (as our apache2 serves multiple domains).

My config looked something like this:

Alias /git/myproject /path/to/git/repo/on/server

<Location /git/myproject>
SSLRequireSSL
DAV on
AuthType Basic
AuthName "yourDomainForBasicAuth"
AuthUserFile /etc/apache2/path/to/password-file
Require user username-in-passwordfile
</Location>


Restart apache2 with /etc/init.d/apache2 restart and things should be ready to go. As described at kernel.org, configure the remote location for your local git repo as follows

git config remote.upload.url https://<username>@<servername>/git/myproject/


I suppose “upload” is actually an arbitrary name you can choose. The trailing “/” is important. From then on you can just

git push upload master

to the repository. (If the project is not yet in git, execute “git init” in the top level directory of the project first).

On the other hand, to check out the project from the server into a new working directory (let’s call it “my-project-dir”), I did

git clone https://<username>@<servername>/git/myproject/ my-project-dir


Not sure actually if that is the best way – git has so many variations. But when I had done it like that, the way to push changes to the server would be

git push origin master

I suppose because I pulled the project from the server, the server repo is now known as “origin”, no need to configure anything else. There is a certain logic to it apparently.

I have not yet set up passwords via .netrc as described in the kernel.org tutorial, so that step is optional.