The problem of underscores in directory tree names

Sometimes odd little anomalies creep into NetWare service packs. Some might call them bugs, but we’re among friends here. To illustrate, I’ll just mention one case.

Now it is true that Novell recommends strongly that you follow all the LDAP standard naming rules for servers, trees, containers and leaf objects. The LDAP v3 standard (as embodied in RFC 2251 – https://www.faqs.org/rfcs/rfc2251.html) does state “These names MUST begin with a letter, and only contain ASCII letters, digit characters and hyphens.”

Many NetWare directory trees – especially those that have been around a long time – have underscores in their name (SF_MKTG, for example). Anyway, renaming a production tree is not a trivial task. It requires planning and deft execution (usually when no one else is around) to be sure that all references to the old name get changed properly. It’s a pain and, generally, serves no useful purpose except to become compliant with some “standard.”

Novell takes those standards seriously, though. The company always ensures that its products are conformant to the latest standards. Sometimes this is done at the expense of older standards or conventions.

Applying service pack 4 (SP4) to eDirectory 8.6.2 (some say this effect is observed after applying SP3) ensures that tree names with hyphens are treated properly. The same is true for most tree names with underscores. But here’s the anomaly: you will no longer be able to browse the tree over an IPX connection if your tree name begins with one, two or three characters followed by an underscore and then any number of further characters. This because the Service Advertising Protocol (SAP) number 278 becomes corrupted, so the tree is no longer advertising and your browser can no longer find it. SFCA_MKTG would still work, but SF_MKTG would disappear from your NDS “radar.”

This can be a major problem, especially when no one can log on, but it would appear to be a simple coding error on Novell’s part. Should be easy to fix, right?

Upgrading your directory service to the next Version, 8.7.1, should work. That’s the one that ships with NetWare 6.5, so an upgrade to 6.5 should solve this anomaly, right? Well, it’s true that SAP 278 is no longer “corrupt” after upgrading to NetWare 6.5/eDirectory 8.7.1. At least we don’t think so. What happens is that it simply goes away, it disappears, it’s no longer there. But at least it isn’t “corrupt” any more.

Now it’s true that not a lot of people are going to be affected by this. You need a tree named in that specific way, with the underscore coming in character position two, three or four and you also need to be working on an IPX network – no IP connections between you and the servers or among the servers. Still, this does affect more than one network. So you do begin to wonder how these “anomalies” get introduced and then never get fixed. Are service packs too big? Are they rushed into production? Is it, on the other hand, really possible to thoroughly test everything under actual real world conditions? Does your opinion change depending on whether or not the service pack you just installed appears to have crashed your network? Tell me about it.