DOCUNEXT

I upgraded my Lenovo g555 laptop to Ubuntu Oneric Ocelot on Friday and it was a little rocky, but now its working really well.

I have setup a few new / different items:

• I’m using the ATI proprietary driver, much to my chagrin solely because it gets less hot than the open source one. As far as performance goes, I don’t notice a difference, but no doubt - KMS is awesome. The raw terminals look magnificient. Specifically, using this makes all the difference:

amdconfig --px-igpu

• I am now using ext4 for the /home directory. I was hesitant to use ext4 because ext3 is so reliable, but then I read about some basic performance factors - like extents specifically, so I’m giving it a go.
• While I’m using OpenVZ extensively these days, I’m now checking out LXC for a development environment on my laptop. I actually just setup another user account “app” that I ssh into (yes, ssh’ing to the same machine - for ssh forwarding), and that’s working OK because I’ve got Ruby installed with rbenv, but I want to encapsulate mysql, and I don’t want it polluting my base workstation OS.
• I’m also using libnss-extrausers because it is awesome - I’d rather use something like puppet or csync2 to manage hard files instead of using ldap - maybe even something like git-annex for that, or maybe just plain git.

I’m still doing plenty the same:

• Gnome + Awesome
• Still using rbenv, homesick, and major dotfiles in my home directories (which is why I split my laptop user with the development user)
• Still using jEdit, sorta.

I’m no longer using:

• Picasa3 - see ya! I’m tired of Wine, and realized I can manage my images better than Picasa can.
• No longer bothering with the default folders in my home

Other stuff catching my attention:

• Fuse BindFS
• mbr
• mr (not related)
• caspar ( see this)

Probably going to stick with csync2, maybe? Actually I’m liking the idea of simply using git more and more. There are actually plenty of folks doing this, and here’s the best example I found:

• http://git.rot13.org/?p=bak-git.git;a=blob;f=bak-git-server.pl;hb=HEAD

I’ve been working more git lately, covering at least the following items:

• Gitolite
• Git enrypt
• Git annex
• Bup

Here are my notes on each component:

Gitolite

I’ve been using Gitosis for awhile, and its fine. I decided to try Gitolite because it supports git-annex-shell, and I’ve been seriously getting into git annex after realizing it supports bup.

I was able to set it up and got it working well, but then I came to realize that git-annex-shell is not compatible with bup:

“git-annex-shell does not support bup, due to the wacky way that bup starts its server. So, to use bup, you need full shell access to the server.”

So much for reading the manual! :-)

Now I’ve got both gitosis and gitolite setup. I’m only actively using gitosis right now - I won’t switch anytime soon - probably when I have another hankering to use git-annex-shell!

UPDATE: It looks like this isn’t a show stopper, because apparently git annex repositories can still stored in gitosis or gitolite servers, its just that the annexed contents, cannot. That’s fine though, in my opinion. I’ll try it out.

Git encrypt

Git encrypt is a really nice script for using git smudge and clean to pretty much transparently encrypt / decrypt git repository data while allowing git to still do its thing.

I’ve been tinkering with it today while working with homesick - a ruby gem that allows cloning and symlinking dotfiles for home directory configuration. Its really awesome, but I have some additions I’d like to make, such as the ability to symlink dotfiles within dotfolders, like the .ssh or .config folders.

Anyway, back to git encrypt - given that some dotfiles have some relatively sensitive data (like .s3cfg and the .ssh folder items) - its a perfect combo with homesick.

I’ve gotten the two to work together, but getting it to work is a very manual process, since the passphrase must be entered before the repository is checked out. Maybe when I have some free time, I’ll try smoothing it out.

Git annex

This is such an awesome project.

Other All Stars

• bindfs
• mkisofs + fuseiso
• mr

I’ve been wrestling with Gnome Keyring during the transition to Gnome 3 on Debian, and Ubuntu 11 (all with Awesome WM).

One interesting snag was the relocation of /usr/lib/gnome-keyring/gnome-keyring-pkcs11.so to /usr/lib/pkcs11/gnome-keyring-pkcs11.so.

root@asee-mm-02:/usr/lib/gnome-keyring# ln -s /usr/lib/pkcs11/gnome-keyring-pkcs11.so ./

I don’t like to do these types of workarounds, but a softlink isn’t too bad.

I got fed up with gnome keyring sufficiently that I again installed keychain. Perhaps its what’s caused this?

Yikes! My dsa public keys stopped working today, and I found this murky error message in /var/log/auth.log:

gnome-keyring-daemon[1907]: unsupported key algorithm in certificate: 1.2.840.10045.2.1

Hmmm… apparently gnome-keyring-daemon doesn’t like my key! I tried upgrading gnutls in hopes it would pull in some certificates, but that didn’t work.

I searched the web for some clues, and came up with some bug reports, but no clear solution:

• https://bugzilla.redhat.com/show_bug.cgi?id=694954
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552723

Now I’m doing a bold upgrade of gnome-keyring, which is updating a slew of other debian packages.

FYI - I’m running Debian Wheezy.

UPDATE: I never did figure this one out; instead I just created a new key.