Software

posted 02/23/08 by Rick Webb

The Barbarian Group makes software for any of four reasons:
  1. First, because we thought of something we could do that would be really awesome and cool, and it just so transpired that we actually knew how to build the awesome thing, we actually had the time to do it, so we went ahead and built said awesome thing.
  2. Second, because we wanted to learn how to do something that we didn’t know how to do before, and figured we’d try to get something out of it. This happens far, far more often than one might glean from this website, because most of the time we try to do this, we do not, in fact, produce a useful piece of software along the way. We do generally manage to learn something, though, so that’s nice.
  3. Third, because we thought it might be of use to our clients in the future, and we are prototyping it for R&D or demo’s sake. We are endeavoring to further explore how technology and interactive marketing might mix. We have a whole philosophy about it. We’ll tell you about it some day. If we were better at marketing ourselves, we would list this as number one on this list because, in fact, it’s the driving reason behind all of this. At least that’s what we tell our accountant.
  4. And, lastly, we perhaps came up with a nifty little app during the course of our lives doing design, technology and marketing work and figured we’d share it with the community. No point re-inventing the wheel and whatnot.

You’ll notice that none of these four reasons is directly related to “making lots of money.” We should probably fix that. We’ll add that to the “to do” list.

Here are some recent posts from our employees about Software:

AIM's Dominance Diminishing

So, Adium – a multi-protocol IM client for the mac – released v 1.3 this week that now includes integrated Facebook chat, along with several other protocols:
They’ve released new versions before which have integrated the IM protocol of specific social networking sites, most recently MySpace, as well as, previously, Livejournal. Both of those were mildly exciting, but never really caught on. The facebook one seems different, though, and got me thinking about how well Facebook integrated chat into the actual web app before they launched their IM protocol out to the public. So last night, when I ran my Adium upgrade and added my Facebook account details, I instantly saw something like 50 new friends in my buddy list, many of whom I didn’t have an IM screen name for before. It’s been fun chatting with random other people. Nice breath of fresh air.
The other thing I realized is that this sort of completes a trend I’ve been noticing for a while. Adium, you see, shows a little icon for each buddy in your buddy list, specifying which IM service they were on. For years, the list was basically non-stop AIM icons. Over the years, though, new icons have popped up in there, as people have adopted other services. Jabber and GTalk were the big ones, those really mixed up my list nicely. But today, with Facebook chat, it looks like the Aim icon has finally fallen below 50%:

And this doesn’t even show my Bonjour) buddies from within the office.
However, this is just volume of usernames, not actual chat time. And it’s slightly skewed by our internal Jabber network.
Still, though, I think it’s an interesting milestone. AIM is not the only go-to anymore. Gtalk contributed a lot to this, but I have a hunch, in time, Facebook will as well. This was a well-executed play for them.

First O'Reilly InsideRIA Blog Post

Doing some writing for O’Reilly. My first post is on the rad SproutCore framework.
Now go submit some patches to their SCM to get TableView support finished!

Migrating Users from a Tiger server to a clean Leopard server

In a previous post I mentioned that we’ve been testing a new mail server solution. So far so good! I really like Kerio.
Only problem is that our internal authentication setup wasn’t really up to snuff, so I migrated everything over from our current Tiger server to a clean Leopard server. It was kind of a muddled process, and I figure other people might want to do the same thing, so here we go! steps!
What we’ll have at the end of this is a clean Leopard server running as an OD master, with kerberos rockin’ and all of our old users AND their passwords.
First things first, get you Leopard server box up and running, update it, get Open Directory running and set it to Open Directory Master. BE CAREFUL HERE. If you set your search base wrong or your kerberos realm wrong YOU WILL HAVE PROBLEMS LATER. Search base really could be anything, but I highly suggest you keep it as simple as possible, or if you can keep it the same as the search base on your old Tiger server.
Once you have Open Directory running, make damn sure that kerberos is also running before you do ANYTHING else. If its not, check your DNS, you should be able to resolve your server from its hostname AND ip address. If you need help, email me.
Now we need to export our users with their passwords, cause they are important and stuff. So on your old Tiger box get terminal buzzing cause everything we need to do is done there. Oh yeah, and this won’t harm your production server at all, so you can keep everything running live.
Lets export your users into an ldif file, like so:
sudo slapcat -l /path/to/users.ldif
While we’re here lets make a directory to put our passwords in and then grab our password db, like so:
mkdir /path/to/tiger_passwd_db<br />sudo mkpassdb -backupdb /path/to/tiger_passwd_db
Now you’ve got a flat file with all of your users and a folder with your password database files, but wait, you can’t just go and import this stuff whilly nilly into your clean install. The install is clean, and your old user db is DIRTY.
So lets clean it up! The first thing you’ll want to remove from the ldif file is anything that already exists in your clean Leopard install, so things like the root user and the old diradmin account need to get trashed. These entries will look similar to this:
dn: uid=diradmin,cn=users,dc=barbariangroup,dc=com
uid: diradmin
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
objectClass: organizationalPerson
objectClass: top
objectClass: person
sn: 99
structuralObjectClass: inetOrgPerson
entryUUID: 5355461a-cb28-102b-8468-c17ea9eda937
creatorsName: uid=root,cn=users,dc=barbariangroup,dc=com
createTimestamp: 20070720161633Z
gidNumber: 20
uidNumber: 1000
authAuthority: (bunch of junk here)
userPassword::(bunch of junk here)
loginShell: /bin/bash
apple-generateduid: (blahblah more junk)
homeDirectory: /Users/diradmin
cn: Directory Administrator
entryCSN: 20070720161633Z#00000e#00#000000
modifiersName: uid=diradmin,cn=users,dc=barbariangroup,dc=com
modifyTimestamp: 20070720161633Z
Now hopefully you’re asking yourself, “how the hell do i know what to get rid of?” What I did was go to my Leopard server and exported the user database to an ldif file just like I did to the Tiger server and then compared the two, anything that already existed in the Leopard ldif file, I trashed from the Tiger ldif file.
But wait! Still not done cleaning that file up. You’ll need to search and replace your old LDAP search base with the new one for the Leopard server because this gets written to every user record. Annoying right? So for instance, on your Tiger server your search base was dc=server,dc=domain,dc=com and on your new Leopard server you’ve simplified things to just dc=domain,dc=com you’ll need to find/replace the dc=server in the Tiger ldif to match the NEW search string.
Cool, so that’s done, now you’re got a (nearly) perfect ldif file will all of your old user data. hooray! Lets get the Leopard server ready for the transition. Now since you’ve already set up Open Directory and made it the master, you will have already created a diradmin account. Since we don’t want to lose that password, we’ll first export your Leopard password database then import all your Tiger users, and then merge the two password databases.
So lets export that Leopard password database, open up terminal and run:
sudo mkdir passwords_from_leopard_server<br />sudo mkpassdb -backupdb passwords_from_leopard_server
You’ll notice that’s exactly what we did before to export our passwords from Tiger. Now we need the public key from the Leopard server, grab that by running:
mkpassdb -dump
You’re looking for a section titled “Public Key.” It’ll start with a 1024 and end with root@yourdomain.com. Hang onto that and head back to your Tiger ldif file, we’ve got some more find/replace-ing to do. The part you’re looking for is the “authAuthority” its a part of every user section of your ldif file and will look something like this:
authAuthority: ;ApplePasswordServer;0×46a0rewe95q184c10000000a0000000a,1024 35
1656695931665909934885529650807878698902444799687544911514204277892750444560
40005936512372916582789463659890238498589238402348023840210107069530617774018
50577252081327366279005303145695496695847004346878374632327359789719986361946
35779287349872349872349872349872347676758484746738357768598768767876313084048
91 root@server.com:ipaddress
You need to replace the string that starts with 1024 and ends with root@server.com:ipaddress with the string from the leopard server that starts and ends similarly. Make sense? good.
Now you’re done with that good ol’ ldif file, it should be perfect. Phew! That was a lot of finding and replacing eh? Take a break and get yourself a soda, you deserve it.
Alright lets get those users imported now! Send that Tiger ldif file over to your Leopard server. Since you’ve got Open Directory running already you’ve gotta kill slapd before you can import anything. Like so:
sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
Then import the Tiger ldif file:
sudo slapadd -c -l users.ldif
and then reload slapd
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Now you can launch Workgroup Manager on your Leopard server and make sure all your users made it over, lovely they’re all there! Now time for the passwords, send that whole directory we created earlier from the Tiger server over to the leopard server. Then merge the databases:
sudo mkpassdb -mergeparent /path/to/tiger_passwd_db /path/to/passwords_from_leopard_server
And now for the moment of truth, try and authenticate yourself against the new server with the same password you had on the old server. If that goes well, hooray! If not, you’ll need to demote the server to stand-alone and then back to master and repeat everything, mega burn.
If all went well though, and you’re able to authenticate your users just fine, you’ll wanna go ahead and kerberize your server, like so:
sudo mkpassdb -kerberize
and you’re done! you now have a fresh clean Leopard server that is running Kerberos fine, and has all your old user data and passwords imported. Sit back, relax, then get back to work sorting out the rest of your network!
Other tips:
  • Check out the inspiration for this post here actually most of these steps are taken straight from there, though this is more Leopard centric in that you need to kill slapd before importing users. Credit to Ian for finding that article in the first place, AFP548.com is a great resource for any Apple sysadmin.
  • Have a fellow IT guy/gal near at hand for those frustrating moments, it helps to have someone to bounce ideas off of.
  • Take your time. You will fail at least once, everyone does!

Mail Servers

Hey look at that! We’re growing! It’s really awesome because we get to meet and hang out with all these new fun people! but being the IT guy I of course see the stress adding all these people into the mix puts on our network.
Our current mail server/calendar solution just isn’t working anymore.
We rely on iCal pretty heavily for meeting scheduling, and let me tell you, since the last Leopard update it is BROKEN. We don’t use Apple’s CalDAV server, don’t even get me started on that, so the method we’ve adopted is one of subscription/updating flat files on a sever. Which works alright if you have like 30 people in the company all downloading and uploading their flat calendar files all at the same time. but if you double that number, well, you’re just asking for trouble buddy.
So the new thing we’re looking at is this Kerio Mail Server solution, which is just software, but it’ll run on Windows/Linux/Mac OS. Which is pretty awesome if you ask me, course I’m a sucker for flexible software. The best part about this software though is that it’s exchange-esque without having to bow to the whims of Microsoft.

Plainview 1.0.151

Last night we released a new version of Plainview. The biggest changes in this version are the addition of a custom user agent string, to help some web apps which use questionable detection methods, some new keyboard shortcuts in response to user feedback, and a few new features for kiosk mode.
Kiosk mode is a way to easily lock users into Plainview, making it a good choice for kiosks where you want to show web (or flash) content, but don’t want the user to have full access to the system. When you enter kiosk mode, you’re asked for an administrator password and then you’re locked in. No menus, no cmd-tab, no bookmarks or location panels, nothing except where the currently loaded site will take you. To this we’ve added a few new bells and whistles. In the preferences, you can now set some options to hide the mouse, and have the app automatically load in kiosk mode.

Pages Feedback

Pages Feedback

iTunes Feedback

itunes feedback

Searching for Safari, a Kick in the Eye

Soon after the release of Plainview, we starting hearing about issues viewing pages that employ browser sniffing to look for compatible browsers, sites like abc.com where Safari is allowed, but Plainview is blocked. There was even suspicion that we were using an custom user-agent string which was causing trouble. Well, we weren’t, but we are now. Turns out that the sites mentioned, and many others it seems, are looking for “Safari” in the user-agent string, and WebKit does not identify itself as Safari out-of-the-box so these sites would believe Plainview to be incompatible. This is bad mojo. Apple recommends looking for “AppleWebKit” not “Safari” to ensure compatibility with WebKit powered browsers, and even offers some code to help out.
However, I hardly expect abc.com and their ilk to switch detect scripts overnight. So the next build of Plainview will include a tweaked user-agent string to identify itself as “Plainview (like Safari)” which seems to fix the issues with abc.com and hopefully others as well.