OpenSolaris

Printable Version Enter a New Search
Bug ID 5035244
Synopsis Make ldapaddent a standalone tool
State 10-Fix Delivered (Fix available in build)
Category:Subcategory ldap:tools
Keywords ITCTO | duckwater | dwp0
Responsible Engineer Tomas Heran
Reported Against 5.9
Duplicate Of
Introduced In solaris_9
Commit to Fix snv_93
Fixed In snv_93
Release Fixed solaris_nevada(snv_93)
Related Bugs 6681320 , 6711290 , 6712098
Submit Date 21-April-2004
Last Update Date 3-July-2008
Description
Currently if you wish to perform any naming services migration, then you are  going to want to migrate naming information. The ldapaddent(1M) command was added in the Solaris 9 Operating Systems to provide a simple and quick way to populate the Sun Java Directory (LDAP) tree with data. However, there are several prerequisites to using the ldapaddent.  

- Firstly, the ldapaddent(1M) command must be run from an already configured Secured LDAP Naming Services Client. This is because ldapaddent(1M) uses the libsldap interfaces to perform it's job, which means that libsldap _must_ be configured. This is the same thing as configuring a Secured LDAP client.  This obviously means that ldapaddent(1) is not completely a stand-alone utility. You may have also noticed (or will do!) that ldapaddent(1M) does not have an option to specify which server the data should be loaded from. This would be something like the -h option that ldapmodify and ldapdelete have, but which is missing from ldapaddent(1M). In addition, ldapaddent has to access the configuration data from an already setup client in order to talk to a server. 

It is a very desirable feature to make ldapaddent(1M) a standalone utility. Being forced to have already configured an exisiting Secured LDAP Client imposes a limitation that will make it less likely for our customers to use. 

Please also see the following RFE: 4877152 that I filed. This is related to ldapaddent(1M) and it's performance.
Work Around
N/A
Comments
N/A