Geek on Two Wheels

Announcing poit, a simple, single-user OpenID authentication server implementation.

This is a reworking of a even simpler server I hacked together for personal use last year.  The UI is currently very bare, and there is no documentation, but it does work, and the code is no longer terrible to work with.

It’s been tested to work on a handful of OpenID consumer sites, with only two known failures so far: Facebook and Stack Overflow.

Unsurprisingly, Facebook’s consumer implementation seems to be broken, and I won’t bother following up on that any time soon.  The failure against Stack Overflow is both unfortunate and ironic as using it was a major motivation for starting the original project.

At the moment, the UI is very crude and it doesn’t protect against all plausible bad inputs, but it is functional, and I do use it for my own needs.  Time permitting, I’m hoping to be able to cross off all the features planned for the first release in two weeks.  Some additional testing would be much appreciated.

Critiques, suggestions, and patches welcome—notification of security issues, especially.

Looks so much better without so many dead leaves and with more panda.

Took some photos at Vanier Park after today’s Critical Manners ride.

In any sane web development setup, at some point, content must be propagated from the development environment to the production one. scp and sftp are some of the favourites: git is mine.

By using the working directory of a git repository as your live website, you gain several notable advantages over manual uploading:

• The website itself doubles as your primary, authoritative repository.
• It becomes possible to apply all of git’s features on your production website. Things such as emergency roll-backs become trivial, dependencies permitting.
• No need to think about what actually needs to be uploaded and what doesn’t on an update: just git push.

Now, the last point needs some explanation. When blobs are pushed from one repository to another, by default, the working directory of the remote repository is untouched.  The reasons for this should be obvious, but, in this case, modifying the working directory is precisely the desired behaviour.  To have git update the working directory every time it receives an update, we use the post-update hook.  Here is a trivial example:

#!/bin/sh
# Update from repo
cd ..
unset GIT_DIR
exec git reset --hard

1. git runs its hooks from inside the .git directory. Not all git commands work from this location, so first we get out from it.
2. The GIT_DIR environment variable is set to “.” when executing hooks. This will cause issues as we are no longer in .git, and must be unset.
3. Finally, git reset --hard is ran to reset the working directory to match the current branch’s data in the repository.

Of course, there are tons more things you can do using the hook, as you have full shell scripting capabilities.  See git help hooks for information on all the available hooks.

As a departing note, remember to set the permission on the .git directory so that you are not leaking sensitive information.  Unless, of course, you want everybody and anybody to be able to checkout the complete revision history of your website.

I missed my Photo Friday post last week.  The week before was a rushed job, and, honestly, wasn’t up to my standard of This is Pretty Interesting.  I assure you, I had good reasons for sucking.

Now, I usually avoid meta posts about this blog, but I’ve been attempting at establishing more online presence, and missing a single post, even if just a photo, was too much of a personal let down to simply brush away.  Let me assure you that Photo Fridays will continue to be a regular feature, and I’ll try my best to stop being lame.

That said, the primary purpose of this post is not to make excuses, but to solicit some ideas.

One thing I would like to do regularly here is to write technical articles on topics within the GNU/Linux and open source software domain.  Having been involved in X.org at a capacity beyond being an average user for some time, the amount of misconceptions and misunderstandings surrounding some of the open source platforms have been both surprising and frustrating.  As much as I have tried and mostly succeeded in remedying individual cases, there’s definitely more that can be done in terms user education.

Item number one on the list of article ideas is a three-part series on video playback, specifically rendering.  Item number two may be an (simple) exposition of the state of graphics in Linux: where things have been, where things are going, and why certain things are so difficult.  Three and beyond: I haven’t a clue.

This is where you come in—what would you like to know better?

Post a comment, dent me, tweet me, or even suggest ideas in meat space.  I can’t and won’t guarantee that I will be sufficiently knowledgeable in most topics suggested or care enough to find out more about them, but I believe most of you are aware of my ability to ramble on about obscure technical trivia, and how much I seem to enjoy it.

It’s win-win, really.  You have a chance to learn about something without first having to do all the legwork (assuming you trust my competencies) and I get to explore more interesting things.

Give me your best shot.