Hi Kiran, Thanks. I've attached my server.xml and my custom EDRN schema file. Comments below:
ayyagarikiran wrote: > > As you mentioned these are not operational attributes. > Did you try using any other LDAP client( e.x Apache Directory Studio)? > If not can you try any other and see the difference > Interestingly enough Apache Directory Studio seems to work fine. That is, when I bind as Directory Studio and try to modify my entry attributes it allows me to, and AFAICT, it only allows me to edit the attributes and entries that I should be able to. PLA; however, is reporting something different. We've also instrumented PLA all over. Here is what one of our developers, Andrew Hart, made me aware of: > PLA has a class called LdapServer basically defines a buncha ways to talk > to the ldap server. There are 4 functions for getting attributes for a dn, > they are: > > * getDnSysAttrs: gets the operational attributes for a nentry... stuff > that is automatically set by ldap server.... createTimestamp, > creatorsName, etc > * getCustomDnSysAttrs: gets the 'user-defined' operational attributes for > an entry. these attributes should be treaded as internal attributes > (nsroleDN, passwordExpirationTime,passwordAllowChangeTime, etc > * getCustomDnAttrs: gets the user defined operational attributes for an > entry, these should be treated as regular attributes > * getDnAttrs: gets the attributes/values of an entry... cn sn dn etc > > The results of each of those calls is placed into its own array so its > like: > > $dnsysattrs = ldapserver->getDnSysAttrs(this->dn) > > and so on for the other 3. Then they are all merged into a single array > called attrs_vals. That array gets iterated on... each attr-val pair is > checked. Tf the current value came from the 'internal/system' array then > it should naturally be marked as readonly since you don't want users > setting their own password expiration time and so on. > > Theoretically then these 4 arrays should contain different information > (ie: the result of the sys/int array should not look like the result of > the regular attr call). In practice, thats not whats happening. The > getDnSysAttrs has information which looks great and is differrent from the > other 3. So it is not the problem, its working fine. > > The other three however have exactly the same output thus when the array > check comes around it sees that every regular attribute 'came from' the > sys/int call in PLA and thus gets marked private. > So that's a detailed description of what we are seeing via PLA. Any clue? Thanks to Andrew Hart for the detailed description. Cheers, Chris http://www.nabble.com/file/p23575980/edrn.ldif edrn.ldif http://www.nabble.com/file/p23575980/server.xml server.xml -- View this message in context: http://www.nabble.com/Help-connecting-phpldapadmin-to-ApacheDS-1.5.1-tp23570166p23575980.html Sent from the Apache Directory Project mailing list archive at Nabble.com.
