Zimbra Crossing

A perfect mail server setup is a holy grail for systems departments in any organisation, whatever maybe it's size.

Whether to host the mail server locally, or outsource the hosting ? Will the data be safe ? Will the service be secure ? Will my provider be stable and is 1Mbps enough for my mails and internet access ? What solution do we adopt ? What will be the ROI/TCO/TLA ?

These and a zillion other questions arise in the minds of the systems, finance and other top management guys. In our company, we've been advising, deploying and maintaining a number of email servers for small organisations to large organisations with users ranging from only a couple to hundreds. Initially, we deployed custom home grown solutions using Postfix, Courier, Squirrelmail, OpenLDAP, MySQL, Spamassassin, ClamAV, Amavis along with a user management module, we wrote in PHP.

The installations were (are, in some cases) very robust, stable, scaling and had been extended extensively beyond the initial requirements (For eg, integrating with PureFTPd). Though we and our clients were very happy with these, we always felt the need for more features - to manage mail queues, better analysis and statistics amongst others.

In the meantime, there was a product which was making news as a featureful but open source email system - Zimbra. I took a look at the Zimbra, and was elated by the fact that Zimbra used the same open source components that we used to build our own system. Then, I was taken aback when I discovered most of the frontend was written in Java. Also, their complete IMAP/POP/Mailbox implementations are in Java - specific to Zimbra. Actually, I don't have anything against Java. In a couple of projects, I used to even enjoy the breaks I got while java code got compiled :-P. But nevertheless Zimbra wasn't for me. Yet!!

After a couple of months, when a customer asked for some very particular features. We discovered that it would take us aeons to implement that same features and integrate, given our limited resources. We finally bit the bullet and worked on deploying Zimbra for the client. Basing it on Debian GNU/Linux Sarge, we had a wonderful learning experience with Zimbra. We wrote several tools and utilities using which we migrated the users seamlessly and efficiently. Zimbra took off.

But, later we came across several bloopers with Zimbra - the distribution list didn't work, (btw, Zimbra's console management client works well), the number of new mails were misleading. Since the code was in java, we couldn't take the code, repair the same in a shorttime.

Recently, we upgraded Zimbra from 3.1.2 to a fairly large project Zimbra-4.5. It was such a wonderful experience - stage-by-stage application upgrade, it is very rarely used elsewhere.

... To be continued!!

Debian/Ubuntu, NSS, LDAP and Udev

We have a home brewn Single Sign-On implementation in our office which uses account information stored in OpenLDAP, exports home directories (NFS mounts) for clients using Automount. Our desktops run either Ubuntu Dapper or Debian Etch.

During the initial days when we deployed and provisioned the system, I faced a problem in which the desktops wouldn't boot.

udevd[1005]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
udevd[1005]: nss_ldap: could not search LDAP server - Can't contact LDAP server
udevd[1005]: lookup_group: error resolving group 'nvram': Illegal seek

I originally thought since udevd starts up before networking in rc2.d, it isn't able to seek the LDAP server and hence is causing some problem. So, I changed the priority of networking from S40 to S02 and that appeared to solve the problem. But there were those udevd messages that still persisted.

Cut, six months later when Ubuntu Feisty Fawn was released and we installed the same. We still used to get the same problem. But no amount of changing the priorities helped this time. This made me take a hard look at the logs and it was then that I observed the last line in each set of logs.

udevd[1005]: lookup_group: error resolving group 'nvram': Illegal seek

Now, udev is set to create the device nvram at boot time and change group ownership of the device to nvram.
But we've setup the NSS service to lookup LDAP (in /etc/nsswitch.conf) for passwd, group and shadow. So, everytime udev wanted the group called nvram, a search for the group nvram was done in the local /etc/groups file and not finding it there, an LDAP seek was done (wow, PAM!!!) and either it couldn't contact the LDAP server (because network isn't brought up yet) or when contacted (as in our Dapper case) it couldn't find the group called nvram in LDAP.

Hence the solution would be to give udev what it seeks; The group "nvram"!

# addgroup --system nvram

Once that is done. A reboot confirmed this indeed was the solution!!! The moral of the story is that people creating udevd rules should take into account non-existant users/groups. And create them if not found. Also, a framework for the whole SSO solution is missing in the open source world, which is why Micro$oft is able to shove it's products to corporates. Let me know if any effort exists which does try to address the situation.

Good Will Hunting!

Thanks to sachin, saw this movie a week or so back. I would rate this one as one of the best dramas ever I've experienced. The best thing about the movie are the dialogues. Sample this:



Though out of context, it might not make much sense. Watching the entire movie really gets one thinking. It got me! Reflecting!!