Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue

[masarati@aero.polimi.it]

Let me first explain one thing.  If you have one problem and you don't
have time to rebuild from source, then it's very likely you'll have to
live with your problem.  The only difference between you and me is that if
I find a solution, I can commit the fix.  For the rest, your time is
valuable exactly as mine, and I probably get paid less than you get paid,
but to fix my problems, not yours.  It just happened that tracking
someone's issue, upgrading just solved it (ITS#6537, which ended up being
a duplicate of another, already solved issue).  In order to save the very
scarce, unpaid manpower we can dedicate to fixing others' issues, our
policy is to avoid tracking issues in old releases, because we don't
backport fixes so, in the best case, the issue will be solved in the next
one, and you'll have to upgrade anyway.

After this lengthy preamble, thanks to your prompt response I already
figured out myself how to reproduce the issue you're having, so you don't
need to rebuild yet.  You'll have to as soon as the issue is fixed.

p.

> It is also bears mentioning that test022-ppolicy has not changed at all
> since 2.4.18, and so would never detect this
> problem, even using the most recent stable version.  As I mentioned,
> ldapsearch does not trigger any errors - only
> slapcat does (and of course, starting slapd, which fails as is detailed
> above).
>
>
> If you really want to test this, you must restart the server on which the
> chaining configuration from test022-ppolicy
> has been added, and then run slapcat.  I am not the only one to run in to
> this; for example, this individual has the
> exact same issue, with no resolution:
> http://www.openldap.org/lists/openldap-software/200907/msg00118.html
>
>
> I'd be more than happy to patch the source, if such a patch existed.  But
> since nothing seems to have changed in the
> relevant bits of code that would affect this behavior, and no
> corresponding ITS exists, that would lead me to believe it
> is thusly undocumented, except for similar on-list complaints.  If you can
> show me where in the back-ldap code you
> believe I've missed said patch or refactoring, I've got no problem
> admitting I missed it, but I don't see any such
> modification(s).
>
>
> I'm sure not everybody has the time to build from completely new source
> every time a bug is unearthed, and while I do
> not object to doing that as soon as I can, right now I have a slapd server
> that is down because of this, so top priority
> is to evaluate the code to figure out where this bug is stemming from and
> fix it so I can restart slapd.  Next priority
> is building and testing new packages.  I mean no disrespect by this, but
> dropping everything to do this and work out any
> new issues, bugs, and compatibility problems and separate those from this
> pre-existing buggy behavior, seems hasty at
> best, especially when there's no concretely identified reason for doing so
> (i.e., this revision had change X, which
> fixes problem Y).
>
>
> I'm still reviewing the relevant code (which AFAICT hasn't changed) to
> figure out what's going on here and put out the
> immediate fire so that I can at least restore services, at which point I
> will obviously have to make the time to
> completely upgrade it all.
>
> Thanks
>
>
>
>