3:20 a.m.
Hi,
Installed version:
OpenLDAP: slapd 2.3.30
My problem is that multi-valued attributes become single-valued
attribtues with the values as comma separated list without any
observable reason.
An entry should look like this (as it is entered into the directory):
...
mail: testing1(a)test.com
mail: testing2(a)test.com
After a while the entry suddenly looks like this:
mail: testing1(a)test.com, testing2(a)test.com
Does anybody know, what the reason of this behaviour could be? I cannot
find any cron-jobs modifying the ldap-directory, or any application with
write-permission. The modification seems to happen accidentally.
Thanks in advance,
Alex Bruckner
6:58 a.m.
Alexander Bruckner <bruckner(a)universaledition.com> writes:
Hi,
Installed version:
OpenLDAP: slapd 2.3.30
My problem is that multi-valued attributes become single-valued
attribtues with the values as comma separated list without any
observable reason.
An entry should look like this (as it is entered into the directory):
...
mail: testing1(a)test.com
mail: testing2(a)test.com
After a while the entry suddenly looks like this:
mail: testing1(a)test.com, testing2(a)test.com
What client are you using?
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
7:58 a.m.
Alexander Bruckner wrote:
An entry should look like this (as it is entered into the directory):
....
mail: testing1(a)test.com
mail: testing2(a)test.com
What does "should look like" mean? Is it really added like this? Can you
confirm that with OpenLDAP's command-line tool ldapsearch?
After a while the entry suddenly looks like this:
mail: testing1(a)test.com, testing2(a)test.com
This is not a server issue for sure. Either a client is modifying the
data or the client producing the second LDIF output is misbehaving on
multi-valued attributes. Please verify your directory content by looking
at the LDIF output generated by OpenLDAP's command-line tool ldapsearch.
I cannot find any cron-jobs modifying the ldap-directory, or any
application with write-permission. The modification seems to happen
accidentally.
If really the content of the entry changed you have to search harder... ;-)
Ciao, Michael.
8:42 a.m.
On Wednesday 23 January 2008 17:58:39 Michael Ströder wrote:
Alexander Bruckner wrote:
> I cannot find any cron-jobs modifying the ldap-directory, or
any
> application with write-permission. The modification seems to happen
> accidentally.
If really the content of the entry changed you have to search harder... ;-)
Not necessarily ... just differently, i.e. in the server's logs (after looking
at the modifyTimeStamp/entryCSN/modifiersName attributes - some of which may
be sufficient on their own).
Regards,
Buchan
12:17 a.m.
Zitat von Michael Ströder <michael(a)stroeder.com>:
Alexander Bruckner wrote:
>
> An entry should look like this (as it is entered into the directory):
> ....
> mail: testing1(a)test.com
> mail: testing2(a)test.com
What does "should look like" mean? Is it really added like this? Can
you confirm that with OpenLDAP's command-line tool ldapsearch?
The entry is initially created with ldapadd from an ldif-file with
only one mail-attribute.
The second mail-attribute is added with phpldapadmin.
ldapsearch then shows the entry as posted above (with two mail
attributes), and everthing works fine.
This is not a server issue for sure. Either a client is modifying
the data or the client producing the second LDIF output is
misbehaving on multi-valued attributes. Please verify your directory
content by looking at the LDIF output generated by OpenLDAP's
command-line tool ldapsearch.
If really the content of the entry changed you have to search harder... ;-)
I found out that the saslauthd is configured with write-access to the
ldap directory. I will now change this to anonymous bind and turn an
logging again.
Thanks for your help,
Alex Bruckner
5274
days inactive
5276
days old
openldap-software@openldap.org
4 comments
4 participants
participants (4)
-
Alexander Bruckner -
Buchan Milne -
Dieter Kluenter -
Michael Ströder