Syndication is here!

I am just finishing up a couple issues reported by Feed Validator, otherwise, we are in business. Atom (and the various RSSes) is pretty easy to generate. You just have to be careful. And since all my current data was already in a database, generating the feed every time there's a change to the news feed is pretty much trivial.

Let's Syndicate!

Well, it's finally come time. Out with the .plan file, in with the .xml file! Out with finger, in with Atom!

I am currently working on building and testing my Atom feed. Atom seems to be the most robust of the syndication formats and only slightly "trickier" then RSS 2.0 or 0.91 so I'm trying it.

Bad update kills authentication

Well, Debian has finally punched me in the jaw. After the last few years have been so good to me, apt-get upgrade finally broke something painful. I went to run the update today and there was a new libnss-ldap package in there which has a bug in it. So, once I updated to the "latest", no auth worked. Everything was broken. Everything.

After some dicking around, I finally checked and sure enough, I still have all my old package files so I rolled-back libnss-ldap to the previous version and the system is back up.

Now, yes, I am running "testing" and not stable, but the new libnss-ldap does not work. What the heck is tested about that? That sounds like the package maintainer didn't even try it before it got moved to testing from unstable. Argh!

Well them's the breaks. We're back up and there's a couple quirks to resolve but otherwise, we're okay. Life goes on...

Crazy Media Conversion!

There's is a hella tight mod for KDE called "audiokonverter" which adds a context-menu in Konqueror to, you guessed it, konvert audio! Get it, "konvert" is "convert" only with a K! Hahahhahaha! Those KDE kids, they're so kfunny!

Okay, shenanigans aside, it's nice. It will descend recursively since we all keep our music in properly structured folders, prompts for destination folder (where it recreates the same folder structure), and then the appropriate quality level (e.g. 1-10 for Oggs but bitrate for MP3). Works great! Requires the encode/decode utilities for whatever formats you want. Even handles the tags properly (at lease for OGG and MP3 which I've tested).

Audiokonverter! It's your daddy!

IM, Just Another Unix Service

My latest adventure has been in trying to get Jive Wildfire to authenticate against PAM instead of LDAP directly. The reason for this is that this is a more manageable authentication scheme for two reasons (which any sys admin should know already):

1. The (XMPP) service does not have to be reconfigured for different environments (e.g. passwd files vs kerberos vs ldap),


2. No separate password database.

My concern re: #1 is that there is some interest in running an Instant Messaging (IM) service at work but little support for getting a kerberized service. The server (Jive Wildfire) support for it is tentative at best and client support is none (e.g. ticketed authentication) so why bother? I'd have to setup key entries for the service to talk to the KDC and basically do a lot of work whereas the Pluggable Authentication Module (PAM) system is there and ready. Heck, even if the server-side support was better, the complete lack of GSSAPI/Kerberos support on the client side is a killer.

So on to #2 which is the main reason for doing any of this at all. Managing seperate password databases means system users have to have a login and password for every service and manage their passwords seperately. Since this doesn't happen (with normal users), everyone just uses the same password for everything and they use the same password for years and years. It's bad enough with the sys admins doing the same thing for core services, but that's a whole other issue.

Anyhow, I had initially setup Jive Wildfire (then Jive Messenger) to authenticate directly against my LDAP directory specifically to avoid the problems with #2. It worked well. But now faced with managing an IM server for work, I have the same two problems. Maintaining a separate password database is going to mean zero user buy-in but if I can say "just use your IRMACS password" then it won't be a problem. So that gets us back to how to setup the auth to integrate with the Kerberos system. The answer is "I dunno" or PAM.

So, PAM, you little bastard, what's the deal? It turns out Jive Wildfire doesn't have PAM support either natively or as a proper plugin (e.g. loadable at runtime) so what we need is this Java module called Shaj. Put the Java library, the .jar file, and the platform-specific library, the .so file, into wildfire/lib. Then configure Jive to use "Native Authentication":

  <provider> 
    <auth>
      <className>org.jivesoftware.wildfire.auth.NativeAuthProvider</className> 
    </auth>
    <user> 
      <className>org.jivesoftware.wildfire.user.NativeUserProvider</className> 
    </user>
  </provider>  

And voila! Right? WRONG! I couldn't login, my client kept crashing, this "Shaj" thing was screwed. I went back and forth, back and forth, and just to get to the point where I knew what to do (above) but it ust didn't work. Something was odd since I was finally able to login to the admin interface but still nothing on the client.

It turns out that, naturally, after having been flailing around in the dark in the first place, my client had finally bit the dust. Something just got fubar between the removing and adding accounts and the server going up and down and up and down... After I stomped all my kopete config files, it worked great! Auth against PAM! Beauty!

So now I still have to test one last feature... Can I change my system password through my IM client? Does that just change my IM password (e.g. is it stored by Wildfire) or does it change my system password? Does it work at all? What about if I change my system password, is that reflected immediately in the IM login?

All I know is that "it should work (tm)"

An old argument in favour of openness rather then obscurity

A commercial, and in some respects a social doubt has been started within the last year or two, whether or not it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and know already much more than we can teach them respecting their several kinds of roguery.

Rogues knew a good deal about lock-picking long before locksmiths discussed it among themselves, as they have lately done. If a lock, let it have been made in whatever country, or by whatever maker, is not so inviolable as it has hitherto been deemed to be, surely it is to the interest of honest persons to know this fact, because the dishonest are tolerably certain to apply the knowledge practically; and the spread of the knowledge is necessary to give fair play to those who might suffer by ignorance.

It cannot be too earnestly urged that an acquaintance with real facts will, in the end, be better for all parties. Some time ago, when the reading public was alarmed at being told how London milk is adulterated, timid persons deprecated the exposure, on the plea that it would give instructions in the art of adulterating milk; a vain fear, milkmen knew all about it before, whether they practiced it or not; and the exposure only taught purchasers the necessity of a little scrutiny and caution, leaving them to obey this necessity or not, as they pleased.

-- From A.C Hobbs (Charles Tomlinson, ed.), Locks and Safes: The Construction of Locks. Published by Virtue & Co., London, 1853 (revised 1868).

How time flies...

I've been keeping busy with my project over the last month so not too much tickin' over here per se. The trick of the day is to use SSH for a SOCKS(5) proxy as per the comments here. The article is about using PuTTY to SSH to a server and open an encrypted proxy connection. As the peanut gallery says, this is even easier with ssh:

ssh -D1080 host.example.com

There, done. Tell your browser you have a SOCKS proxy at localhost:1080 and there you go! Right?

Well apparently I'm missing something cause it ain't working yet. I'll get there though, that's my goal. I'll get there...

/me mutters something about browsers