Ricardo Cerqueira wrote: > On Thu, 2002-11-21 at 16:37, Dan Melomedman wrote: > [snip] > > > At leaset these need to be prefixed: uid, mail, homeDirectory. > > Uhhh... no way :-) > The thing I like most about LDAP is that I can use it for every service > I provide, including mail, ftp, radius, or any other kind of service > requiring auth and possibly storage. > I _do_ want to use the same login attribute (uid) for all services, and > I do want to share the same homeDirectory, and cn, and userPassword, > etc...
You only want to use the same login attribute if the your LDAP-enabled services agree on the value for that attribute. What happens if they do not? There's nothing wrong with attributes which contain duplicate values if needed, and having the freedom to make them differ. You never know what kind of an LDAP-enabled application you could be running in a few months/years that will require storing _different_ values than what you already have. If an attribute is not from the standard schema, don't use it in the custom schema; make your custom object classes auxiliary to your standard object classes. This means uid, mail, homedirectory shouldn't even be in the qmailUser object class BECAUSE THEY CONFLICT WITH EXISTING SCHEMAS. Case in point: an organization has an existing directory service running where the uid attribute is populated with values such as "23415734". Uid is their naming attribute, and is not used as a username. What are you going to do? Exactly what should have been done in the first place: design qmail-ldap schema so it doesn't conflict. Convenient?
