Fri, Dec 21, 2001 at 09:50:50AM -0800, sudog:
> > Basically I don't care how it's called or how it works but if I
> > cannot make the system adapt to various authentication sources
> > easily, it is certainly a big minus.  At one site, we inted to move
> > everything away from NIS and over to LDAP.  If NetBSD can't easily
> > adapt to it, it will be replaced by something that can, as easy as
> > that.  Yet one should consider that PAM is a de-facto standard now
> > (although I don't know how much the different implementations are
> > compatible with Sun's) before inventing something else that's
> > entirely incompatible.
> 
> PAM is only the de-facto standard because Linux is its bitch. And because 
> of that, I had NO END of troubles trying to re-work busy systems into an 
> actually usable state. As a former system admin of a 50,000 customer ISP, 
> PAM was one of my more onerous headaches. Recompiling everything to use 
> statically-linked auth libs and shadow passwords directly was one week of 
> hell that I'd just as soon forget.
> 
> Is there no other "nice" way to migrate to LDAP without indulging in a 
> dynamically linked frenzy?
> 
> -sudog

not that i'd use it if avoidable, but isnt this something that the
door_call() stuff (found in solaris) could deal with?  which appears
to amount to a local rpc call.  where some daemon can run with an
open door and service requests, but if the door is unavailable,
unresponsive, or otherwise fails, libs can revert to other methods?
i'm probably missing something with the way doors work.