Solaris LDAP Integration Void

Yikes, that was a harsh post title from a self-proclaimed advocate of Sun's products. I can't count the number of times I've had conversations with people about two related topics: First, how critical it is that sites begin to adopt LDAP and stop managing boxes independently. Second, how immature the administrative side of Sun's LDAP is.
It appears that Ben Rockwood, a much respected voice in the OpenSolaris community, has observed the same.

These topics each deserve a series of posts because they are complex. I mean it. Until you've tried, its hard to understand the documentation dichotomy of Sun's Directory Server Enterprise Edition. The best way I can describe it would be to imagine you have been asked to learn English given a dictionary as your only resource.

There is phenomenal depth to the documentation in form of resource guides. In other words, once you "get it" you can do anything with Sun's documentation. The number of concepts you need to master to deploy LDAP in an Enterprise is staggering, and the number of real-world cases available from Google is small. You really need a few weeks of Instructor Lead Training, but how many companies are on that track these days? Not too many. There are a few outdated books as well, but they only get you to the starting gate for a basic environment.

So now let's assume that you have learned the system and properly architected your Directory Servers. Your next challenge is managing the data. I worked on a project which integrated Oracle instances with Solaris Resource Manager (SRM). The central LDAP project ID repository allowed us to ensure no Project IDs were duplicated around the environment, and minimized the amount of management associated with application migrations. Seems simple, right?

The first issue we encountered was that there is no facility for entering records into the Directory. Don't even talk to me about the documented solution of using Sun Management Console (SMC). It's cute for local files, but it is worthless for naming services, and even Sun's solution center thinks its insane to try using it. No, really. I opened a case, and they asked my why I would ever try to use it.

There should be a set of CLI interfaces for managing this data. Period. Its a simple thing, and by now the Directory Services have been around long enough that this is sorely over due. They should follow the standard usage model that tools like useradd or usermod provide. People understand this, and the precedent should be respected.

The only other option is the Directory Editor. You pick a third party one, or a Sun one. But in the end you are responsible for reverse-engineering whether a directory attribute is a list, or a collection of attributes. This is not appropriate. For standard Solaris maps like netmasks, auto_master, hosts, etc. there should be interface dialogs which provide reasonable levels of sanity checking. I shouldn't need to scan through cryptic attributes. What's even more scary is the idea of handing over a full directory editor to say, someone on the first tier help desk who may not fully understand how terrifying it would be to make the wrong right-click.

This was a bit of a rant, but it is primarily intended to scream out in support of Ben's post. This is a huge opportunity to improve Solaris' administrative scalability and I think all too often LDAP projects get dropped during internal evaluations because the local staff has too many issues getting it working.