My first stage in the process was to get OpenLDAP set up with the right config — but when I started it, slapd complained about an error in slapd.conf. The overlay I was trying to use, it claimed, was not found. I spent the next couple of hours trying to find additional packages, trying different things, reading doco, searching Google, to no avail. The overlay I want is missing from Red Hat’s build of OpenLDAP.

So “boo hoo”, you say, “just build from source”. Well, remember how I said I was forced into RHEL? The corollary to that is that I am only allowed to use exactly what the Shadowman ships on the DVD. No build-from-source, no other OSS, is allowed.

But what does any of this have to do with Microsoft?

In my research, I found the release notes for Red Hat Enterprise Linux 5. In it was the following text (highlighting mine):

OpenLDAP Server and Red Hat Directory Server
Red Hat Directory Server is an LDAP-based server that centralizes enterprise and network data into an OS-independent, network-based registry. It is set to replace OpenLDAP server components, which will be deprecated after Red Hat Enterprise Linux 5. For more information about Red Hat Directory Server, refer to http://www.redhat.com/software/rha/directory/.

You guessed it: Red Hat Directory Server is a pay-for product. So Red Hat’s setting a direction here: server platforms comprising only the base OS, and additional function provided through extra-cost modules — now where have we seen this before?

Does this now mean that on RHEL-next, in order to run a Samba server with an LDAP IDMAP backend, companies will have to pay for RDS? That won’t fly at my work: “we already have a corporate directory, we’re not paying for another” will the customer sayeth.

“Okay”, you say, “so don’t use Red Hat”. As far as I’m allowed (this is at my employer remember) the only other choice is SLES… from Novell… that organisation that felt the need to cross-licence with Microsoft to “protect” against undisclosed and unproven patent infringement.

(Note that this post is not about Novell-Microsoft, nor is their deal a reason not to use SLES in my opinion. The thought only popped into my head because I was already thinking about Microsoft as a result of the Red Hat thing with RDS.)

So it seems like the two biggest names in corporate Linux are marching to Microsoft’s drum. Have I misread something? Am I overreacting?

Before you say ANYTHING, this is not an indication that the Crossed Wires campus is switching to the evil side.  Any experienced Linux sysadmin will tell you that working with Windows systems can’t be avoided — and in some cases, welcomed (after all it’s better to have one or two Linux boxes in a sea of Windows than no Linux boxes at all).  My main customer at work is essentially a Windows shop, but their main file servers are Linux on zSeries, which means that me as a Linux guy needs to know more than I thought I would want to know about bringing Linux and Windows together.

So they are doing a migration to Microsoft Active Directory, and the Linux systems need to be integrated into the AD setup.  To our architects, Linux Windows integration equals Samba — they never bothered to look at making use of AD’s LDAP component to create a model that Linux can handle natively, instead of the (to me) less-than-optimal Winbind (don’t get me wrong, Winbind works, it just imposes some operational issues that I’d sooner do without, like SID-[UG]ID mapping, for instance).

So I proposed that the solution be updated to utilise LDAP, through the use of Microsoft’s own Services for Unix (SFU).  I was told “yeah, dunno why it wasn’t designed that way, would be the best way to do it, but no”.  Sigh.

So I decided to stick to my guns and set up something to show that it would work exactly as I said it would.  And I have!  I’ve worked around some inaccurate information on the ‘Net, some incomplete documentation from Microsoft, and some finger-checks on my part, to be able to show The Right Way to anyone who cares…  Yep, sometimes the useless thing is just worth doing.  :)