Again, I think it is appropiate to use LDAP for configuring
network services such as DHCPD , DNS , PPP, etc and to
a limited extend sendmail -- see sendmail's modification to
support user's delivery address :
http://www.stanford.edu/~bbense/Inst.html and actually
We can ask the Standford team about some of the problems mentioned
on this list to see what they think about it ;specially, if their LDAP service
is deployed ...
True LDAP (v2 or v3) does not provide record locking . Now the question is
does Novell's NDS 8 -- a native LDAP v3 -- , Oracle's Directory
Server or Microsoft Active Directory does if they do then how ?
Mantaining state information such as DNS is not a good idea as
Kurt has stated .
Again my emphasis is on configuring network services or other system services
if appropiate and to provide a HTML interface which is sufficiently rich to be
user friendly.
My little test bed project is coming along fine . My servlet which implements
my dummy html interfface, http://www.star-gate.com/dhcpd.html, is fully
operational
and it was not hard to wirite whats left is to provide error checking
and cross data validation . The mods to dhcpd to support ldap are
already in place.
Searching the LDAP database for existing DHCPD entries is also fairly
straight forward and I
do have a servlet to locate dhcpd servers which accepts regular expressions
as suppported by LDAP --- search : www* will locate all the dhcdp servers
starting with www 8)
Regards
> At 02:29 PM 7/4/99 -0700, Amancio Hasty wrote:
> >Record locking and batch requests is a bit more difficult to solve perhaps
> >someone in the list can shed light into this problem for instance does
> >LDAPv3 provide such mechanism?
>
> LDAP (v2 or v3) does not provide record locking, client/server
> transactions, nor any specific batching requests. The "L" in LDAP
> means lightweight.
>
> I think LDAP-based directory service could be used to manage
> a wide variety of system information including configuration
> information for various other network services. However, using
> LDAP directory services to manage network-services state information
> is likely not appropriate application of LDAP.
>
> For example, while it may make sense to use an LDAP directory
> service to manage the configuration and master zone information
> for a Domain Name Service, it would not be wise to use an LDAP
> directory service to maintain state information (such records
> created due to DHCP operations) of Domain Name Service.
>
> >If there any bugs in the ldap server I will probably fix them or
> >better yet the people working on openldap will fix them.
>
> OpenLDAP, like FreeBSD, is user maintained and developed. All
> users are encouraged to contribute to the project. We can
> surely use your help!
>
> Kurt
>
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message