[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 <tw@dionic.net> 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 designed systems. 


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 content.


That's exactly what one is expected to do.


If you find a solution that works reliably, I'm all ears.


RTFM?  p.

--
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano