You know, thinking about it more, I think you're right. I've registered two OID's before, so I know the process. But if you know the ropes and want to take care of doing it, please do!
I can see that the dbmail-ldap-howto is going to be very segmented, basically explaining how to use three or four different schemas, get them set up correctly, and how to manage them. The schema that I've used was from Windows 2000 with Exchange 2000, with user id support provided by AD4UNIX. Day to day user management was done with an LDAP user manager module I wrote for TWIG. There are certainly other valid schemas out there, and while I'm still tempted to say that we should prefer something that's already an open standard (such as inetOrgPerson or some derivative of it), writing our own will certainly make it easier for users who just want to slap a schema into the ldap and go. Aaron TWIG (spiffy new website!): http://informationgateway.org AD4UNIX (apparently moved to sourceforge): http://sourceforge.net/project/showfiles.php?group_id=84224 Paul J Stevens <[EMAIL PROTECTED]> said: > > > Aaron Stone wrote: > > Would dbmail.schema be a help document, or a schema that can be loaded > > into OpenLDAP. I'm all for a help text, but I am leery of having our own > > schema. > > I really want to be based on existing standard object classes. The only > > thing I can think of that we might need a custom schema for is group > > quotas... > > For testing purposes I've adapted a custom schema file based off of the > qmail schema file. I don't see any real objection to having our own OID > space and designing a custom ldap-schema. I want to be able to tell > users of the debian packages: 'use this schema file, use this config > setup, and you're ready to rock-n-roll'. > > Of course, example setups using other, existing schemas will also be > useful and necesary, but if dbmail has it's own OID space all that would > be required to integrate with existing ldap implementations would be to > change some settings in dbmail.conf. Correct me if I'm wrong though. > > I'd be happy to know of any existing schema that will serve dbmail's > purposes. Apparently you have one :-). > > > > > > Aaron > > > > > > Paul J Stevens <[EMAIL PROTECTED]> said: > > > > > >>Thanks a lot Aaron. From your description and the authldap.c code I > >>think I can work out a test-bed installation and a dbmail.schema file. > >> > >> > >>Aaron Stone wrote: > >> > >>>Hey, > >>> > >>>Long story short, I no longer maintain an Active Directory user base, and I > >>>don't have my configs around to double check my memory. So I'll do my > >>>best... > >>>and if we get descriptive enough, let's make this thread part of the > >>>documentation project, LDAP could really use a help text! > >>> > >>>I'm pretty sure that there are Exchange2k-ism's that need to be worked out > >>>-- > >>>in particular, I'd like to be a near drop-in replacement for qmail-ldap and to > >>>function with inetOrgPerson and posixPerson accounts. Let me know if you > >>>have > >>>any trouble getting things to work! > >>> > >>>More inline... > >>> > >>>Paul J Stevens <[EMAIL PROTECTED]> said: > >>> > >>> > >>> > >>>>Hi all, and esp Aaron, > >>>> > >>>>I'm trying to test/debug the authldap layer, but I'm not exactly clear > >>>>as to how all the fields are supposed to operate. > >>>> > >>>>Could you Aaron please document the fields as allowed in the dbmail.conf > >>>>file. > >>>> > >>>>I'm all clear on these: > >>> > >>>Ok, I'll try giving a brief explanation anyways, for future posterity and > >>>those who might be new to LDAP and not recognize as many key words yet. > >>> > >>> > >>>>"BIND_DN" > >>> > >>>This is the Distinguished Name of the user who has read access to the LDAP > >>>server. It is not recommended to use an Administrator or Manager account, as a > >>>precaution in case the mail server is compromised. > >>> > >>> > >>> > >>>>"BIND_PW" > >>> > >>>The plain text password of the account above. Again, preferably not an > >>>Administrator or Manager account. > >>> > >>> > >>> > >>>>"BASE_DN" > >>> > >>>The root or starting point from which searches will be conducted. All searches > >>>use the LDAP_SCOPE_SUBTREE option to search everything in this base and below. > >>> > >>> > >>> > >>>>"PORT" > >>> > >>>The port number that the LDAP server is listerning on. By default, 389 for > >>>insecure and 636 for secure, however secure LDAP is currently unsupported. > >>> > >>> > >>> > >>>>"HOSTNAME" > >>> > >>>The hostname of the LDAP server. May be an IP address. > >>> > >>> > >>> > >>>>"OBJECTCLASS" > >>> > >>>The object class to use as a search filter, typically 'user', > >>>'inetOrgPerson' > >>>or possibly something else in more complex LDAP environments. > >>> > >>> > >>> > >>>>"FIELD_UID" > >>> > >>>The field which contains the user login name of the user. Required. > >>> > >>> > >>> > >>>>"FIELD_CID" > >>> > >>>The field which contains the group id number of the user. Not required. > >>> > >>> > >>> > >>>>"FIELD_QUOTA" > >>> > >>>The field which contains the quota, in bytes, of the user. Not required. > >>> > >>> > >>> > >>>>"FIELD_PASSWD" > >>> > >>>The field which contains the password of the user. Not implemented. > >>> > >>> > >>> > >>>>but how exactly are the following fields supposed to work/interact or > >>>>map to authsql: > >>>> > >>>>"FIELD_MAIL" > >>> > >>>The field which contains the primary email address of the user. Required. > >>> > >>> > >>> > >>>>"FIELD_MAILALT" > >>> > >>>The field which contains an alternate email address of the user. Not required. > >>> > >>> > >>> > >>>>"FIELD_NID" > >>> > >>>The field which contains the user id number of the user. Required. > >>> > >>> > >>> > >>>>"MAILALTPREFIX" > >>> > >>>A prefix which may appear on the MAILALT entry and should be ignored. MS > >>>Exchange 2000 uses the prefix 'smtp:'. Not required. > >>> > >>> > >>> > >>>>"FIELD_FORWARD" > >>> > >>>The boolean field which indicates if email should be forwarded or not. > >>> > >>> > >>> > >>>>"FIELD_FWDSAVE" > >>> > >>>The boolean field which indicates if email should also be delivered locally if > >>>it is forwarded. > >>> > >>> > >>> > >>>>"FIELD_FWDTARGET" > >>> > >>>The field which contains a destination email address for forwarding mail. > >>> > >>> > >>> > >>>>"FWDTARGETPREFIX" > >>> > >>>A prefix which may appear on the FWDTARGET entry. > >>> > >>> > >>> > >>>>"FIELD_MEMBERS" > >>> > >>>The field containing a list of DN's to users in the email distribution > >>>group. > >>> > >>> > >>> > >>>>I would much appreciate some enlightenment regarding this issue. > >>>> > >>>>thanks, > >>>> > >>>> > >>>>-- > >>>> ________________________________________________________________ > >>>> Paul Stevens [EMAIL PROTECTED] > >>>> NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > >>>> The Netherlands_______________________________________www.nfg.nl > >>>> > >>>>_______________________________________________ > >>>>Dbmail-dev mailing list > >>>>[email protected] > >>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>>> > >>> > >>> > >>> > >>> > >>-- > >> ________________________________________________________________ > >> Paul Stevens mailto:[EMAIL PROTECTED] > >> NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] > >> The Netherlands________________________________http://www.nfg.nl > >> > >>_______________________________________________ > >>Dbmail-dev mailing list > >>[email protected] > >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > > > > > > > > > -- > ________________________________________________________________ > Paul Stevens [EMAIL PROTECTED] > NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 > The Netherlands_______________________________________www.nfg.nl > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
