Björn’s Blog

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.