So handle defaults like Base-DN, LDAP host, port numbers etc.

At 11:29 AM 3/25/99 -0800, Leif Hedstrom wrote: >David Zuhn wrote: > >>> This Config.pm module should make it easier to manage scripts that >>> requires >>> PerLDAP, and also help me in writing the test modules. >> >> First note: please don't call this Config.pm. Make it something much >> less generic. > >You have any suggestions? SiteLDAP.pm LDAPparam.pm how about making this namespace friendly, so that use SiteLDAP; only creates the %SiteLDAP hash, with all values being a part of the hash. Much less chance of conflict with existing identifier. use SiteLDAP (all) makes each value available via the hash, as well as a named variable at the global level. >> Secondly, this sort of thing should augment or be replaced by the >> other work Chuck B. mentioned lately (the analogue of resolv.conf for >> LDAP queries). > >Hmmm, unless he's changed his design spec, I think that was mostly for >LDAP failover (e.g. find LDAP server and port numbers). The >configuration module we wrote for Ldapp (the predecessor to PerLDAP) has >all kind of informatin related to the LDAP infrastructure. For instance: Like I said, augmentation is possible. If this ldap.conf file is present, the SiteLDAP module should read it and use those values. I should only have to make a site specific LDAP configuration chance in one place. use SiteLDAP (configile => "path/to/some/file"); should read the specified file in order to provide for multiple config files. use SiteLDAP (suffix = "o=netscape.com"); will load the appropriate values for the specified suffix (in a multi-suffix directory). >$BASE="dc=netscape,dc=com"; >$HOST = "hoth.mcom.com"; >$PORT = "389"; >$SSL_PORT = "636"; These names are entirely too generic to be in a generic LDAP module. $LDAP_BASE $LDAP_HOST (should be an array, to support failover configurations) $LDAP_PORT $LDAPS_PORT (or $LDAP_SSL_PORT) >$PEOPLE_TREE = "ou=People"; >$GROUP_TREE = "ou=Groups"; >$MAIL_TREE = "ou=MailGroups"; >$PSEUDO_TREE = "ou=PseudoAccounts"; Using a hash like $LDAP_TREE{people} make it much easier to extend the functionality without mucking too badly with the namespace. >$PEOPLE_BASE = "$PEOPLE_TREE,$BASE"; >$GROUP_BASE = "$GROUP_TREE,$BASE"; >$MAIL_BASE = "$MAIL_TREE,$BASE"; >$PSEUDO_BASE = "$PSEUDO_TREE,$BASE"; $LDAP_BASE{people} .... >$BIND_DN = "uid=ldapadmin"; >$REPL_DN = "uid=repladmin"; > >$GROUP_FILTER = >"(&(|(objectclass=mailgroup)(objectclass=groupofuniquenames))"; >$USER_FILTER = "(&(objectclass=person)"; # Prefix filter for >users. >$MAIL_RCPT_FILTER = >"(&(|(objectclass=mailgroup)(objectclass=mailrecipient))"; $LDAP_FILTER{group} ..... >and so on. The idea would be that we provide a bunch of defaults, but >the sysadmin/person will also be able to modify it (of course). During a >PerLDAP upgrade, the Makefile.PL script will check for existing default >values, and preserve them. A nice idea would be to make a tool that will scan an existing directory (as the root dn probably) and make a list of the various trees. Of course, with DS 4 we'll also have multiple top level suffixes in the tree, meaning you could provide each of these for each top level suffix, and the whole thing starts to get extremely hairy.

PerLDAP v2.0 is a dead, so closing this as wontfix, it will not go into PerLDAP 1.5.