Re: Object Class Violation

On Tue, 2 Aug 2005, Mike Jackson wrote:

> Take a look at the user interface and theme. DA is not intended for an LDAP 
> guru. It's target audience is for mostly clueless help-desk personnel. Now, 
> we can certainly discuss changing the target audience. But we also have to 
> imagine how much the support load will increase if we create a complicated 
> tool, and clueless people are trying to use it...

If DA could adapt to its target environment with more robustness, it could 
adapt the the environment in which it is installed.

> BTW, for the OL fanboys on the list: This is not any more arrogant than OL 
> all of the sudden deciding to enforce structural integrity in the 2.2-> 
> series, with no method of disabling it. Something which no commercial LDAPv3 
> server does, btw. OL is the only one, in the entire world...
>
> For the record, I am not a big OL fan. And the current DA works perfectly 
> with RedHat DS/Netscape DS/Sun One DS/Fedora DS... I just made a test adding 
> groups and users, against RedHat DS on RHEL4.

The thing is, OpenLDAP is very widely deployed. As I see it, DA could take 
one of three basic strategies:

1. Continue with the status quo. DA is incompatible with OpenLDAP 2.2 with 
schema cheking on. Anyone who attempts to use it in this configuration 
will probably be frustrated and move on to use a different tool.

2. Inform users of OpenLDAP 2.2 that to use DA, they must disable schema 
checking by setting "schemacheck off". Explain the reasons why this 
needs to happen, preferably without much venom. It's just a tool, 
after all. Plenty of other projects do this in their example configuration 
files for OpenLDAP, here's two examples:

http://www.opengroup.org/messaging/G260/tech9.htm
http://www-fp.globus.org/gt2.4/replica.html

3. Adapt DA so that dealing with the person-based attributes is optional. 
It's easy enough to write a detection routine that will figure out whether 
those classes are present and combinable with the acccount objectclass. If 
they are not, just omit or disable the portions of the UI that deal with 
those attributes.

I'd prefer adopting strategy 2 immediately, and striving for 3 in the 
medium-to-long term.

  --
  Richard Bullington-McGuire, Managing Partner, PKR Internet, LLC
  Email: [email protected]  Web: http://pkrinternet.com/
  Phone: +1 (703) 271 0607  Fax: +1 (703) 271 0580
  PGP key IDs:  RSA: 0x9386230  DH/DSS: 0xDAC3028E