Hello All, I was modifying the value of an attribute, automountInformation in this instance. The modify works as expected, but when I use ldapsearch to dump the entry containing the new value it seems to truncate it at 78 characters, that is (attribute name + attribute value). The remainder of the value is on the next line, which has caused some scripts to not work as expected. The manpage for ldapsearch did not reveal any clues or switches to get around this length limit. Could it be a server limit? Interesting also is that db2ldif produces the same behavior. Ideas on what I could do to get the value retruned back on one line? STRANGE EXAMPLE OUTPUT: ==============automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768 fs001:/raid/facst aff/faharris ============== EXPECTED OUTPUT: ==============automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768 fs001:/raid/facstaff/faharris ============== The above examples may not be clear due to email wrapping, but in the first one ldapsearch truncates at the "t" and in the second there is not truncating. TIA -- Jim Summers School of Computer Science-University of Oklahoma -------------------------------------------------
Jim Summers wrote:> Hello All, > > I was modifying the value of an attribute, automountInformation in this > instance. The modify works as expected, but when I use ldapsearch to > dump the entry containing the new value it seems to truncate it at 78 > characters, that is (attribute name + attribute value). The remainder > of the value is on the next line, which has caused some scripts to not > work as expected.Line wrapping is defined in the LDIF RFC (2849); this is not a bug, it''s a feature. You can get around it when writing a script with e.g. perl-ldap (Net::LDAP). BR, Mike -- http://www.netauth.com - LDAP Directory Consulting
Jim Summers wrote:> Hello All, > > I was modifying the value of an attribute, automountInformation in > this instance. The modify works as expected, but when I use > ldapsearch to dump the entry containing the new value it seems to > truncate it at 78 characters, that is (attribute name + attribute > value). The remainder of the value is on the next line, which has > caused some scripts to not work as expected. > > The manpage for ldapsearch did not reveal any clues or switches to get > around this length limit. Could it be a server limit? > > Interesting also is that db2ldif produces the same behavior.This is part of the LDIF standard. You can refer RFC 2849 for details on the LDIF syntax.> > Ideas on what I could do to get the value retruned back on one line?The "-U" option to db2ldif will tell it to not fold lines. The "-T" option to ldapsearch will do the same. -NGK> > STRANGE EXAMPLE OUTPUT: > ==============> automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768 > fs001:/raid/facst > aff/faharris > ==============> > EXPECTED OUTPUT: > ==============> automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768 > fs001:/raid/facstaff/faharris > ==============> > The above examples may not be clear due to email wrapping, but in the > first one ldapsearch truncates at the "t" and in the second there is > not truncating. > > TIA
Richard Megginson
2006-Mar-09 18:03 UTC
Re: [Fedora-directory-users] LdapSearch Field Length
Jim Summers wrote:> Hello All, > > I was modifying the value of an attribute, automountInformation in > this instance. The modify works as expected, but when I use > ldapsearch to dump the entry containing the new value it seems to > truncate it at 78 characters, that is (attribute name + attribute > value). The remainder of the value is on the next line, which has > caused some scripts to not work as expected. > > The manpage for ldapsearch did not reveal any clues or switches to get > around this length limit. Could it be a server limit?No. This is standard LDAP LDIF behavior. If you''re using perl, I suggest using either perldap or Net::LDAP - they both have LDIF parsers that handle this nicely. If you''re using python, I think python-ldap also handles this. If you''re using sh, see below.> > Interesting also is that db2ldif produces the same behavior. > > Ideas on what I could do to get the value retruned back on one line?I''m not sure if /usr/bin/ldapsearch supports this, but /opt/fedora-ds/shared/bin/ldapsearch has the -T option: -T don''t fold (wrap) long lines (default is to fold)> > STRANGE EXAMPLE OUTPUT: > ==============> automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768 > fs001:/raid/facst > aff/faharris > ==============> > EXPECTED OUTPUT: > ==============> automountInformation: -rw,actimeo=30,rsize=32768,wsize=32768 > fs001:/raid/facstaff/faharris > ==============> > The above examples may not be clear due to email wrapping, but in the > first one ldapsearch truncates at the "t" and in the second there is > not truncating. > > TIA
Richard Megginson wrote:> > If you''re using perl, I suggest using either perldap or Net::LDAP - they > both have LDIF parsers that handle this nicely. If you''re using python, > I think python-ldap also handles this. If you''re using sh, see below.Many thanks to all who replied on this. A quick modification using the Net::LDAP fixed all. I will also get ahold of the 2849 rfc for future reference.> >> >> Interesting also is that db2ldif produces the same behavior. >> >> Ideas on what I could do to get the value retruned back on one line? > > I''m not sure if /usr/bin/ldapsearch supports this, butI checked the /usr/bin/ldapsearch and it does not support the -T. Interestingly it doesn''t fail on bad switch / parameter but it yields kinda unpredictable behavior. Kinda like getopts in perl with an unexpected parameter. Thanks again.> /opt/fedora-ds/shared/bin/ldapsearch has the -T option: > -T don''t fold (wrap) long lines (default is to fold) > >>-- Jim Summers School of Computer Science-University of Oklahoma -------------------------------------------------