(ITS#6152) proxycache enhancements
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: 2.4.16
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.67.104.102)
Submitted by: hyc
Some ideas that came out of discussions at the Ubuntu Developer Summit this
week...
It would be nice for pcache to detect when connectivity to the remote server has
been lost. In that case, cache expiration should be stopped, and the cache
contents should remain intact until connectivity is restored.
Also, when connectivity is restored, pcache should explicitly refresh all the
entries it currently holds, rather than allowing them to be immediately expired.
14 years, 4 months
Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com
Andrew Bartlett wrote:
> On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote:
>> abartlet(a)samba.org wrote:
>>> Full_Name: Andrew Bartlett
>>> Version: CVS HEAD
>>> OS: Fedora 10
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (59.167.251.137)
>>>
>>>
>>> Samba4's provision and 'make test' seems to create some internal situation in
>>> OpenLDAP slapd where it will not accept any more connections over ldapi:///
>>>
>>> This is best seen by building Samba4, and running
>>>
>>> TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test
>>>
>>> The slapd does not crash, but simply stops accepting new connections. Samba4
>>> currently then crashes due to some other bug (the LDAP backend not responding is
>>> clearly untested code in Samba4).
>>>
>>> It isn't a Samba4 client bug, as ldapsearch also fails to respond.
>>>
>>> This seems very, very similar to ITS#5261
>>
>> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus
>> SASL's libsasldb2.so plugin is present. I always remove that plugin from my
>> installs, since I only use in-directory SASL secrets. That's probably why I
>> wasn't seeing the reported behavior before.
>>
>> Also a note - it's still not clear we've been talking about the same thing up
>> to this point. Even when the samba test suite hangs, I see that ldapsearch
>> still works fine against slapd. At any rate, currently all of the samba4 tests
>> pass for me.
>
> Hmm. Using that KVM image, with the libsasldb moved aside (and with it
> left in place), I still get errors.
>
> However, there is an important difference: Where previously, once it
> locked up nothing proceeded, now it proceeds - as if the failure is
> temporary now. The error has changed too - instead of a failure to
> connect, it is an inability to successfully read the rootDSE.
>
> I agree, we might be jumping at different shadows here, but your patches
> did fix something...
I see what you're describing now, with the kvm set with 2 CPUs. It appears to
be a bug caused by the recent patch for connection_hangup() processing.
Running slapd with -d15 in your test shows that a connection is closed shortly
after being established and becoming readable. The bug is (probably) that we
queued the reader but processed the hangup immediately, thus closing the
connection before the reader executes. I'm not exactly sure why this is
causing the problem on your test, since it looks like your client is closing
the socket before waiting for the reply. But certainly this is the right area.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 4 months
(ITS#6150) schema compliance checking tool
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: HEAD
OS:
URL:
Submission from: (NULL) (84.163.68.118)
masarati(a)aero.polimi.it wrote:
> Comes to mind that something like a schema compliance checking tool,
> either off- or on-line could be useful. Sort of a "slapschema" that
> checks the schema compliance of each entry (matching a filter or
> within a subtree specification) in a given database.
The result could contain the DNs of non-compliant entries each with the
diagnostic message which would have been returned to a client adding such a
non-compliant entry.
14 years, 4 months
(ITS#6149) ldapsearch is not really script-friendly (patch included)
by bugreporter＠udmvt.ru
Full_Name: Alexey
Version: 2.4.15 (LDAP library: OpenLDAP 20415)
OS: Debian GNU/Linux
URL: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch
Submission from: (NULL) (78.85.1.13)
Good day, everyone.
ldapsearch have such important (mis)feature, like output format conforming to
LDIF standard in some or other way.
You should already know, that line length in LDIF-output is limited to 76
characters and if line is larger, it is wrapped with space-padding.
Also output is sometimes base64 encoded, based on it's "printability".
Printability is tested, using single-byte functions, like isgraph(), but when
values is multibyte encoded with UTF-8, that sometimes produce random results.
That together makes ldapsearch very script-unfriendly and here is why:
to limit randomness in output's encoding, one would use -tt switch to always
write
field values to files and then use some simple script to parse the output and
substitute file urls with their contents.
But here comes to play line length limit, that will sometimes wrap urls for
fields with long names (that is common for AD).
Here is example:
msExchHomeServerName:< file:///tmp/ldapsearch-msExchHomeServerName-ZhHdx2
msExchMailboxSecurityDescriptor:< file:///tmp/ldapsearch-msExchMailboxSecurit
yDescriptor-c4gGc1
msExchUserAccountControl:< file:///tmp/ldapsearch-msExchUserAccountControl-FM
UbSZ
msExchMailboxGuid:< file:///tmp/ldapsearch-msExchMailboxGuid-6bLIxY
End of example.
That introduces extra unneeded complexity in otherwise simple script, since now
it should parse LDIF, combine whole lines from broken ones, etc. Making it no
longer an one-line script.
Since wrapping of -tt output is nonsense, but changing that may seem unfeasible
for some of you,
let me suggest additional option -ttt, that does the same as -tt, but without
line wrapping (perhaps, violating some standard).
Patch is here, as your ITS asks:
http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch
PS: manpage does not changed to reflect additional option
Thanks a lot.
14 years, 4 months
Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org
--=-0SnOgocYLpYqWd2pGoMe
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote:
> abartlet(a)samba.org wrote:
> > Full_Name: Andrew Bartlett
> > Version: CVS HEAD
> > OS: Fedora 10
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (59.167.251.137)
> >
> >
> > Samba4's provision and 'make test' seems to create some internal situat=
ion in
> > OpenLDAP slapd where it will not accept any more connections over ldapi=
:///
> >
> > This is best seen by building Samba4, and running
> >
> > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test
> >
> > The slapd does not crash, but simply stops accepting new connections. =
Samba4
> > currently then crashes due to some other bug (the LDAP backend not resp=
onding is
> > clearly untested code in Samba4).
> >
> > It isn't a Samba4 client bug, as ldapsearch also fails to respond.
> >
> > This seems very, very similar to ITS#5261
>=20
> Further testing with Andrew's kvm image shows the hang only occurs when C=
yrus=20
> SASL's libsasldb2.so plugin is present. I always remove that plugin from =
my=20
> installs, since I only use in-directory SASL secrets. That's probably why=
I=20
> wasn't seeing the reported behavior before.
>=20
> Also a note - it's still not clear we've been talking about the same thin=
g up=20
> to this point. Even when the samba test suite hangs, I see that ldapsearc=
h=20
> still works fine against slapd. At any rate, currently all of the samba4 =
tests=20
> pass for me.
Hmm. Using that KVM image, with the libsasldb moved aside (and with it
left in place), I still get errors. =20
However, there is an important difference: Where previously, once it
locked up nothing proceeded, now it proceeds - as if the failure is
temporary now. The error has changed too - instead of a failure to
connect, it is an inability to successfully read the rootDSE.=20
I agree, we might be jumping at different shadows here, but your patches
did fix something...
Andrew Bartlett
--=20
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
--=-0SnOgocYLpYqWd2pGoMe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBKHeuvz4A8Wyi0NrsRAoaGAJ9olpo9+ni006pt9kK5CkXJObYNCQCgorgP
DswBOLRtdrlhFHibmX4XrC4=
=bjw6
-----END PGP SIGNATURE-----
--=-0SnOgocYLpYqWd2pGoMe--
14 years, 4 months
Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
>Hallvard B Furuseth wrote:
>> The send_ldap_response() fix is still incomplete:
[Reversing the quoteed message]
>> Also, this:
>> rc = rs->sr_err;
>> if ( rc == SLAPD_ABANDON&& op->o_cancel )
>> rc = LDAP_CANCELLED;
>> will send a negative result code (SLAPD_ABANDON) if !o_cancel.
>
> No, it won't. That is all bypassed at the top of the function.
If so, the quoted op->o_cancel test could be skipped. But an overlay
could set rs->sr_err = SLAPD_ABANDON during slap_response_play().
Though that ought to mean o_abandon is set, so send_ldap_ber() will drop
the message. So you're right after all that it won't be sent.
>> Note, not just when the function itself sets rc = LDAP_CANCELLED,
>> since syncprov can set rs->sr_err = LDAP_CANCELLED too.
>> Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when
>> sr_ref != NULL is rather dubious. Maybe sr_ref should just
>> be ignored when sending something else than LDAP_REFERRAL.
>
> Leave the assert() in place until you have proof one way or the other.
Haven't tested with an example of an overlay setting SLAPD_ABANDON;
could check syncprov or retcode I suppose. Faked it with
nanosleep(&((struct timespec){0,2E8}), 0); /*gcc or C99 code*/
if ( op->o_abandon ) rs->sr_err = SLAPD_ABANDON;
after the op->o_callback->sc_response in slap_response_play().
Then, with this slapd.conf:
include servers/slapd/schema/core.schema
referral ldap://elsewhere/
database frontend
overlay valsort
send
Delete "cn=urgle"
<wait 0.1 second>
Abandon <previous request>
lt-slapd: result.c:479: send_ldap_response:
Assertion `rs->sr_err == 0x0a' failed.
One more detail, looking at result.c rev 1.330 send_ldap_response():
I presume the LDAP_CONNECTIONLESS branch should also ber_printf rc
rather than rs->sr_err to the response. Not sure if Cancel makes sense
in cldap (and after V2 Bind which has no extended operation at that),
but OpenLDAP does let through Cancel after a V2 Bind.
>> When rc == LDAP_CANCELLED, the function should not send sr_matched,
>> sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems
>> slap_cleanup_play() should still see them if they are not sent?
>
> Dunno what you mean.
I thought that was obvious, but since it isn't maybe I should ask
ldapext instead. Cancel does seem underspecified in this regard.
Anyway, I meant: Either an operation gets cancelled/abandoned, or it
doesn't and comletes. If these fields are set, they most likely relate
to a completed operation. Nowhere SLAPD_ABANDON gets set, are the
others set - possibly except with back-meta/back-ldap, I haven't looked
too closely. OTOH, code setting SLAPD_ABANDON rarely _clears_ those
fields, so I imagine they can convey information which would have been
removed (access controls maybe?) or updated before they were sent, if
the operation had completed.
Clearing a critical control can be a bit doubtful, I'll grant. But for
not obeying critical controls it's a choice between which error code to
return - unavailableCriticalExtension, cancelled, or something else. Or
some controls could mark the operation as "uncancellable" (another flag
needed...)
But come to think of it, an Extended Response has some of the same
problem. By the above reasoning, responseName and responseValue should
be dropped in a Cancelled response, as when sending protocolError to an
unrecognized reqest. Might be a bit extreme.
--
Hallvard
14 years, 4 months
Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com
Hallvard B Furuseth wrote:
> The send_ldap_response() fix is still incomplete:
>
> When rc == LDAP_CANCELLED, the function should not send sr_matched,
> sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems
> slap_cleanup_play() should still see them if they are not sent?
Dunno what you mean.
> Note, not just when the function itself sets rc = LDAP_CANCELLED,
> since syncprov can set rs->sr_err = LDAP_CANCELLED too.
> Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when
> sr_ref != NULL is rather dubious. Maybe sr_ref should just
> be ignored when sending something else than LDAP_REFERRAL.
Leave the assert() in place until you have proof one way or the other.
> Also, this:
> rc = rs->sr_err;
> if ( rc == SLAPD_ABANDON&& op->o_cancel )
> rc = LDAP_CANCELLED;
> will send a negative result code (SLAPD_ABANDON) if !o_cancel.
No, it won't. That is all bypassed at the top of the function.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 4 months
