Planet Ka-Clique

26 photos from 25.08.2010 11.16 to 25.08.2010 12.10

With the Beta 3 release of Darcs 2.5 on Hackage (the Haskell library and program repository), the ipatch program I recently introduced could now be uploaded to hackage, too. If you use cabal-install, you can now install and use it with a simple run of "cabal install ipatch".

I also made the program now handle patches that add or remove files, extended the help texts a bit and added a test suite. This means that you can actually make use of ipatch as of now, to split patches into several small patches and to apply a patch interactively. Of course it needs some more testing, and you might have feature wishes – in either case, let me know.

67 photos from 11.08.2010 6.09 to 17.08.2010 18.31

12 photos from 4.08.2010 11.43 to 4.08.2010 14.52

The problem: Splitting patches

As a Debian maintainer, I often work with patches (files listing changes to text files), for example when tracking the modification I make to some software before I upload the  package to Debian. To manage these patches, quilt is a nice tool: It helps you maintain a stack of patches on top of the original code and encourages you to keep your variously modifications separate.

One use case is not supported by quilt at all: Splitting patches. One often has a large patch containing several independent changes. This might happen after you fix a few problems in the upstream code and then run dpkg-buildpackage, which will create one patch of your changes and put it in debian/patches. Before, I had to manually edit the patch and write the hunks, which are the building blocks of patches, into separate file.

Where it already works

There is no such problem when using a version control system, such as Darcs. Especially Darcs is rightly famous for its user-friendly interface and powerful hunk-selection features. You can even split a single hunk (which could be a change to one line) into two separate steps! Have a look at the HunkEditor page on the Darcs wiki to see how that works.

Let’s steal a feature

Well, it is not stealing if it is Free Software... Darcs has these nice capabilities and provides them in the context of version control systems, while we need them in the context of patch files. But Darcs is providing an API to its code, so shoudn’t it be possible to create a program that uses the Darcs code to split patch files? As a matter of fact, it is possible: You can see that program in action on this 3min Ogg Theora-Video or directly here if your browser supports HTML5:

Nice, can I use it?

The code is a working proof of concept. What you see works. You do not see how it handles patches that create or delete files, patches that do not apply cleanly or are already applied or any kind of error handling. That does not work yet. If you still want to try it, you can grab the code from the Darcs repository at http://darcs.nomeata.de/ipatch, but you need to build the latest development state of the Darcs library first.

I think ipatch could become a very useful and powerful tool with applications in areas where nobody would think of using Darcs. I definitely want some integration into quilt, replacing the splitted patch in the series by the replacing patches automatically. Maybe even a git plugin could be created? But I don’t think I can push this project far enough on my own. So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.

When I created my on-line photo album, we had the year 2001 and there was nothing wrong with publishing ones photos in the Internet. It has been almost ten years now, and things have changed. Privacy is an issue, especially when it also affects your friends and family.

The problem

So I needed to find some protection. These were my requirements:

1. I only want to protect parts of the site, as there are some pictures that I intentionally share with the public. This selection should be possible down to the individual image.
2. The solution should work without any dynamic server component besides the web server itself. This rules out any self-written CGI scripts as well.
3. One password, given to all my friends etc., is not sufficient as it might leak to unintended audience.
4. I do not want my visitors to have to register and remember yet another username and password just for my site. I also do not want to manage this user database.
5. I do not want to have do large changes to the file structure of my photo album.

This rules out most common options, e.g. protection by a .htpasswd file. Requirements 3 and 4 point to a solution based on OpenID. With OpenID, my visitors can authenticate against a service they already use (Google, Yahoo, etc.), relieving me from the burden of maintaining a user database and them from having to remember a password.

There is a mod_auth_openid module for the Apache webserver, and it is even distributed with Debian in the libapache2-mod-auth-openid package. So requirement 2 is fulfilled. The tricky part is: How do we achieve OpenID protection for some images, and not for others.

The solution

I first played around with selectively enabling or disabling mod_auth_openid based on <FileMatch> directives in the Apache configuration, but it was not elegant and would not scale well. I have more than 20.000 pictures to manage, and have already selected over 5000 pictures to be shown without protection. My solution is based on a partial copy of the whole directory tree that contains all public files. To save disk space, these are just symbolic links to the real file in the protected location. Some mod_rewrite magic then takes care of giving the user the impression that all files are in the same location. I set up a small example of my solution, which has this directory structure:

.:
drwxr-xr-x 2 root root 4096  2. Aug 12:03 images
lrwxrwxrwx 1 root root   18  1. Aug 12:05 index.html -> private/index.html
lrwxrwxrwx 1 root root   18  1. Aug 12:05 login.html -> private/login.html
drwxr-xr-x 3 root root 4096  2. Aug 12:03 private

./images:
lrwxrwxrwx 1 root root 33  2. Aug 12:00 pleaselogin.png -> ../private/images/pleaselogin.png
lrwxrwxrwx 1 root root 28  2. Aug 12:03 public.png -> ../private/images/public.png

./private:
drwxr-xr-x 2 root root 4096  2. Aug 12:00 images
-rw-r--r-- 1 root root  267  2. Aug 12:03 index.html
-rw-r--r-- 1 root root   94  2. Aug 12:01 loggedin.html
-rw-r--r-- 1 root root 2091  2. Aug 12:03 login.html
-rw-r--r-- 1 root root   10 18. Nov 2009  protected.html

./private/images:
-rw-r--r-- 1 root root 4074  2. Aug 11:58 pleaselogin.png
-rw-r--r-- 1 root root 2670  2. Aug 11:58 private.png
-rw-r--r-- 1 root root 2043  2. Aug 11:58 public.png

As you can see, real files only reside in private/, outside of that, only symbolic links exist.

The apache configuration protects the private directory and blends it into the main directory:

   <directory /var/www/nomeata.de/openid-test>
        RewriteEngine On
        # Abuse the login page as an error image
        RewriteCond %{QUERY_STRING} \.(png|jpg)
        RewriteRule ^login.html$ /openid-test/images/pleaselogin.png
        # Ship private files, if they exist, unless public files exist
        RewriteCond  $1 !^private
        RewriteCond  /var/www/nomeata.de/openid-test/$1 !-f
        RewriteCond  /var/www/nomeata.de/openid-test/private/$1 -f
        RewriteRule  ^(.+)$ /openid-test/private/$1
   </directory>
   <directory /var/www/nomeata.de/openid-test/private>
        AuthOpenIDEnabled        On
        AuthOpenIDDBLocation     /var/lib/apache2/mod_auth_openid/mod_auth_openid.db
        AuthOpenIDLoginPage      /openid-test/login.html
        AuthOpenIDTrustRoot      http://nomeata.de
        AuthOpenIDCookiePath     /
        AuthOpenIDCookieLifespan 2592000
    </directory>

A special trick handles the “login page” for protected images: If the login page is requested and the referrer indicates that the user tried to access a .png or .jpg file, apache will instead ship an image containing an error message.

For my photo album I have a small Perl script that, given a directory with a private/ directory therein and a list of rules in form of glob patterns, will symlink matching files and remove symlinks that are not allowed any more.

What’s next?

As you can see, this does not actually protect the content. It only requires the user to authenticate, then everything is visible. To select which OpenIDs are allowed to access which code, some bugs will have to be fixed in mod_auth_openid first. There was little activity there recently, I hope that the project is not dead.

Für meine Bewerbung im Studiengang Virtual Design an der FH Kaiserslautern musste ich meine künstlerische Eignung mithilfe einer Mappe und einer Hausarbeit unter Beweis stellen. Beides wurde angenommen und im folgenden könnt ihr meine Arbeiten sehen.

Die Bewerbungsmappe habe ich aus einem B1 Passepartout-Karton, Klebe-, und Scheifenband gebastelt. Die fertige Mappe und alle Arbeiten darin hatten dann das Format B2. Der Großteil der Arbeiten ist schon in meiner Schulzeit entstanden. Nur einige der gegenständlichen Zeichnung und ein paar Aktbilder, die ich beim freien Aktzeichnen des BBK Karlsruhe erstellt habe, sind extra für die Mappe entstanden. Zu sehen ist sie hier:



Für die Hausarbeit gab es die Themenvorgabe "(R)evolution". Weiter nichts, keine Vorgabe an zu verwendender Technik, nur eine Maximalgröße von A2.Ich bin über den Wortursprung (revolvere - zurückdrehen, evolvere - aufrollen) gegangen und habe zusammen mit meinem Freund eine Konstruktion gebaut mit links und rechts ner Rolle, sodass man von einem Bild zum nächsten wickeln kann. Auf den Bildern wollte ich die Entwicklung kreativer Berufe im Vergleich zu lebenserhaltenden Berufen (hier immer beispielhaft der Weizenanbau) aufzeigen.



Das erste Bild, mit Bleistift gezeichnet, spielt im 16. JH: Der brotlose Künstler, der nur Auftragsarbeit macht und die Hauptfläche des Bildes von Feldarbeit eingenommen.

Bild 2: Industrielle Revolution, in Kohle gezeichnet, im Vordergrund ein Wiener Kaffeehaus. Die Kreativen gehen nach draußen, fangen an sich in die Politik einzumischen, Wissenschaft gewinnt an Stellenwert (Benjamin Franklin rechts, der einen Drachen steigen lässt) im Hintergrund den ersten Traktor überhaupt: die Lokmobile.

Bild 3: Heute. Bleistiftzeichnung, mit Fineliner nachgezeichnet, gescannt, vektorisiert, mit GIMP coloriert und wieder ausgedruckt. Hier durchzieht die neue Technik schon alles. Im Hintergrund durch die Monitore in Fragmente zerstückelt der total automatisierte Ackerbau und der Großteil des Bildes dominiert vom Spiel in der virtuellen Welt.

Wenn man die Bilder in einer Reihe betrachtet zieht sich eine diagonale Linie durch sie.

Nach nun doch einigen Jahren der Stille hier möchte ich meinen Blog wieder aufnehmen. Einerseits weil ich nächsten Monat nach Kaiserslautern ziehen und so mehr im Kontakt mit allen aus Karlsruhe bleiben möchte, andererseits weil ich mit Virtual Design bestimmt oft schicke Sachen machen werde, die ich dann gerne rumzeigen würde. Ob ich die alten Beiträge auch wieder mit aufnehmen werde? Ich würde gerne, aber ich weiß nicht, ob ich so einfach von Serendipity importieren kann. Also lassen wir uns überraschen wie sich hier alles entwickeln wird :)