[Date Prev][Date Next]
Re: ppolicy and rwm/relay segfaulting
On 12/04/2012 11:19 PM, Gregory Haverkamp wrote:
On Tue, Dec 4, 2012 at 2:08 PM, Tim Watts <firstname.lastname@example.org> wrote:
In my case I would have to shelve ppolicy until all my clients had been
converted - I have over 150 clients and 600 user accounts (under my
control) but LDAP is not just used by PAM/NSS (if it were it would be easy)
- there are undocumented usages in apache configs, Confluence, possibly
webapps written in all manner of languages etc etc.
It's a real mess...
I agree. It was a real mess for me.
I can give you a quick rundown of what I encountered. I feel a bit guilty
that I never submitted complete ITS reports, but I was too busy trying to
recover from software that was suddenly crashing repeatedly and predictably
once put into production.
Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.
If you consider more productive fix symptoms rather than fix the root
cause, that's your problem.
back-relay and slapo-ppolicy, as you mentioned, crashed the server.
back-ldap and slapo-rwm would cause the server to crash if a certain
malformed search filters were used (as a developer working on some code
here discovered within the first day we were up and running.)
You seem to be one of the few complaining about that. If instead of
whining you filed a report, it would have been fixed ages ago.
back-meta would cause the server to hang if there were an additional space
in a search base (our old primary naming context was "o=lawrence berkeley
laboratory,c=us" and a mail client user had
"o=lawrence[space][space]berkeley lab,c=us" in his configuration.
Back meta rewrites the way you ask it to do. If you configure it to
rewrite "o=lawrence[space]berkeley lab,c=us" don't whine if it fails to
rewrite "o=lawrence[space][space]berkeley lab,c=us". Tell it to rewrite
"o=lawrence[space]\+berkeley lab,c=us" instead, and it'll do what you
want. Machines tend to be as clever as users, seldom cleverer.
Given some of the explanation I received after posting the first bug, I
couldn't help but come to the conclusion that using any of the rewriting
infrastructure in the wild was a bad idea.
That's correct. It should be one's last resort to deal with poorly
And that's where I ended up.
So, we shortened the lifetime of our legacy naming context, wrote some
additional synchronization tools, and just cranked up a new database with
That's exactly what one is expected to do.
If you find a solution that works reliably, I'm all ears.
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano