[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldapmodify crashes with long-ish input for an entry
Dameon Wagner wrote:
Dear openldap-bugs,
I've had a reasonable trawl through the archives, and not found
anything that matches the issue I'm seeing, but please point me in the
right direction if I've missed anything.
(Apologies to anyone receiving this more than once, I tried sending
this report to to openldap-bugs and openldap-its over the last few
days seen no sign of it in the archives, and not received any message
about pending moderation, so thought I would try openldap-technical
which might be more appropriate anyway.)
openldap-its is not a discussion list at all. Both lists require you to
actually submit a ticket and reference the ticket number.
We use OpenLDAP for a few directories, one of which is in the process
of being migrated to newer hardware, with OS upgrade thrown in, and
I've noticed an issue with ldapmodify that I thought was worth
reporting. The directory in question has some scripted tooling around
it to manage updates from a number of sources, which are staged in a
Postgresql database before having some LDIF generated to update the
directory itself.
During the course of my testing (we've not seen this in production,
thankfully) I've noticed that, with reasonably lengthy updates for an
entry, ldapmodify dies with an error like the following:
Define lengthy - how many bytes?
#---8<--- Command Output ----------------------------------------------
modifying entry "<DN-FOR-FAILED-ENTRY>"
ldap_result: Can't contact LDAP server (-1)
#---8<-----------------------------------------------------------------
Define crash - that doesn't look like a crash.
There are matching log-entries in the system's syslog (timestamp,
hostname and PID trimmed off to save some linewrapping) and slapd logs
(we run slapd under daemontools supervision, and capture it's
stdout/stderr):
#---8<---- SysLog Output ----------------------------------------------
local4.debug slapd: conn=1002 op=3158 MOD dn="<DN-OF-LAST-GOOD-ENTRY>"
local4.debug slapd: conn=1002 op=3158 MOD attr=member
local4.debug slapd: conn=1002 op=3158 RESULT tag=103 err=0 text=
local4.debug slapd: conn=1002 fd=13 closed (connection lost)
#---8<-----------------------------------------------------------------
#---8<---- Slapd Output -----------------------------------------------
54a2e47f conn=1002 op=3158 MOD dn="<DN-OF-LAST-GOOD-ENTRY>"
54a2e47f conn=1002 op=3158 MOD attr=member
54a2e47f conn=1002 op=3158 RESULT tag=103 err=0 text=
sb_sasl_cyrus_decode: failed to decode packet: generic failure
sb_sasl_generic_read: failed to decode packet
54a2e47f conn=1002 fd=13 closed (connection lost)
#---8<-----------------------------------------------------------------
That looks like a bug in Cyrus SASL. What SASL mechanism are you using?
The LDIF for the failed entry consists of:
#---8<-----------------------------------------------------------------
dn: <DN-FOR-FAILED-ENTRY>
changetype: modify
replace: member
member: <DN-FOR-MEMBER>
...
member: <DN-FOR-ANOTHER-MEMBER>
#---8<-----------------------------------------------------------------
where the list of members was, in this case, 9799 long. The LDIF
itself is 30097 lines long, and was happy for the first ~15000 lines.
If I prune out the modifications for the troublesome DN, the remainder
of the file also goes through happily.
As a work-around I can manually split up the list into several blocks
(tested with roughly 1000 member updates per block) with "replace:
member" for the first, to match the current behaviour, and "add:
member" for the rest. In this format, ldapmodify is happy to process
the LDIF (all in one connection, but as discreet operations). (Note:
the authenticated user has "unlimited" limits in the config)
Given that, it sounds like it could be a bug in ldapmodify (I don't
think it's on the slapd end). I've tested on both the debian stable
package (version 2.4.31-1+nmu2), and with a locally compiled build
direct from the project's download pages (also 2.4.31 to start with,
to see if it was an introduced bug).
Has anyone else on the list seen anything like this before?
2.4.31 is over 2 years old. 2.4.41 is about to be released. Debian is
known to break their packages from time to time with ill-advised
"security" patches. You should try with freshly built source.
Thanks for your time and any hints and tips.
Cheers.
Dameon.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/