I/O

One of the first problems I had to resolve after installing Zimbra, was how to keep Zimbra's internal LDAP directory in sync with our Open Directory server. This problem was compounded by the fact that out of the box, all Zimbra mail boxes have to be provisioned by hand. Granted, there are command line tools and scripts that can be used to batch provision accounts but who wants to manually put together scripts to do the bulk provisioning? Authentication and GAL lookups from an external source are working beautifully so far and to me, Zimbra's lack of an auto-provisioning from an external directory feature is almost insane.

Currently there is an RFE in Zimbra's bug tracker for such a feature, but that doesn't help those of us who could use a solution now.

After a great deal of searching through the forums and bug tracker, I literally stumbled across Bug 14772 - include zmexternaldirsync in build. It's a discussion about including a Perl script called zmexternaldirsync in the Zimbra builds. From what I can tell, the team was getting it ready to include it in a build and then decided against it. I grabbed the script and documentation and fiddled around with it and got it working.

And now I'm posting it here to (hopefully) make someone else's life a little easier.

    WARNING: This script is provided as-is. The author of this blog is not responsible for any potential damage it may do to your install. The author of this blog is also not responsible for supporting this script. Be aware that any future Zimbra updates could break this script. I doubt it's supported by the Zimbra team since it isn't included in any of the available builds (AFAIK). Use it at your own risk!

With that said... I've been using it since earlier this year. So far it's auto-provisioned new mail accounts for every new user I've added to our directory server. It's made my job a lot easier than I thought it was going to be. It's survived two software updates and an OS/hardware migration. It's everything that should've been included with Zimbra to help system administrators maintain user accounts.

When I first set it up, I was running Zimbra on an Xserve running Tiger server (10.4.11). I had to install the Perl modules referenced in the spartan documentation. I also had to modify the script itself - I'll be honest, it's been so long I can't remember what I had to change and I was bad about keeping notes... I think it was a case change in three lines of the script. I've included my modified script in the zip file to save you the time and trouble. I've set the script up to pull the cn from our directory and set that value to Zimbra LDAP's displayName value... I've found it handy to have full names in the account listing screens. I just finished migrating to a newer Xserve running Leopard server (10.5.4) and haven't run into any problems with the script so far. If I do, I'll post them here.

zmexternalsync.zip (67 KB)

This one is for any other sysadmins that happen to stumble across this blog...

Our school district has the worst data management possible. We have had active email accounts for people who haven't worked for us in years.

It's that bad. Actually it's worse (although I don't know if this counts as worse)...

We have no directory services in place - For each system or application we have that requires authentication, that system or app has had it's authentication information maintained manually. It's been a nightmare to say the least.

We're finally implementing directory services (Apple's Open Directory) and we're planning on having it drive everything authentication-related. But we still have a problem with the data we get (or don't get) from our HR department. A plan has been fashioned to use a PHP/MySQL customised system to give multiple people access to the data in our directory and update it as needed. I'd go into more detail, but I'll be honest - this thing seems like it's grown to monolithic proportions and I'm at a point where I A) don't really know anything about it, B) don't even think I understand it anymore, and C) don't even have access to it.

So... my question is... is it wrong that I feel extremely hesitant (borderline refusal) to allow that much access (pretty much everyone in district - user password changes will theoretically be handled by this system) to the directory data?

Or am I just looking at it from a 'Chicken Little' point of view?

One of the projects I'm involved with at work is implementing a new email system. We're going to be moving approximately 2100 users from Squirrelmail to the Zimbra Collaboration Suite. As part of the transition we're not going to be moving user's mail, instead choosing to go the fresh slate route. All of our users will still have access to their old mail for some time to get what they really need out of their mailboxes. We're also going to be moving completely away from using mail clients, opting instead to have our users access their mail through the ZCS web UI and utilize all of it's features. We didn't make these choices lightly, but honestly our users have a habit of using their email for jokes, shopping, and more jokes - none of which I feel like moving. As for the mail client decision - anyone who's ever migrated 3GB worth of email from one computer to another can probably see where we're coming from.

In terms of the user experience, moving from Squirrelmail to Zimbra is akin to trading in a Ford Model T for a Dodge Viper. Zimbra has a beautiful AJAX UI that, while being easy on the eyes, is also extremely functional. Users essentially have all the functionality that they would expect from a locally installed client. One nice thing about Zimbra is that you're not locked into using the AJAX interface - you can choose to use a standard HTML interface which is a stripped down version of the UI, but still a million times better than what we're moving from.

One of the things I'm hoping to do with this blog is provide information on our Zimbra implementation that other admins may find useful. I've spent hours trying to find solutions to problems we've run into already (syncing Zimbra's internal LDAP server with an external OD server and auto-provisioning new email accounts for instance) and if I can save another admin the hassle, I'll be satisfied that I accomplished something.

So... a first post. A real first post.

I decided to start this blog for a few reasons. First, to document everything I'm doing at work in hopes that it can help someone else avoid the hours and hours of frustrating searches I had to go through to find the answers I needed.

The second reason is really a continuation of helping people - but instead of limiting it to my work-related projects, I'm going to try and offer up my thoughts on working with technology. Mind you, it won't necessarily be the "right way" (as if there even is such a thing!), but it will be a tried and true method I use with positive results. I'm also thinking about opening things up and taking tech questions from people - either through email or a forum system. I haven't quite decided yet, but when I do you'll read about it here.

Finally...

I just needed another "me" project.

So, coming soon, I'll be posting tech-related entries on a variety of topics. Some related to my job, some related to non-work tech stuff, possibly reviews of new stuff coming out. Really, at this point it's all up in the air. But I do know where I want it all to land.

Welcome, and I hope if you've come here looking for answers I'm able to provide them, or at least point you in the right direction.

Kicking the tires on this MT 4 installation... these templates are a bit maddening for the uninitiated.