1) Hey kids, I'm on the list.  Don't include me in CC's.  k?


Quoting Simon J. Gerraty (sjg@crufty.net):
> Chuck Yerkes writes:
> >There.  Now who's up for coding the BSD Auth stuff and not
> >writing more mail??
> 
> The issue isn't "coding BSD Auth".
> Its what do you put in apps like login, sshd, su etc.
> So that they can use BSD Auth OR PAM, without having to code the logic
> twice in each application for each API.

I worked for a company that had a project to do something
with commercial support for which there was a need, and a
fair amount of open source versions.

They met and they planned.  They planned and they met.  They
discussed meeting to plan, and they planned to meet.  For several
months this went on.  Market requirements documents were generated
and everyone was impressed, for this was to be the most beautiful
and most functional and most elegant of products in this realm.
It was almost perfect.  They polished it and had meetings with
execs and customers and tuned their documents and their plans more.
They even started to code.  This was going to be the best EVER.
2...  3 years MAX to build this.  The Taj Mahal class of this type
of product.

After 12 or 15 months, they had lots of bits.  Maybe another year
and a half.  Then the bust came.  And a big ax came down.

And in the end we had no usable code to do other things with, we
couldn't recover and come out with a lesser version of this.

In looking back, perhaps a better model would have been to come
out with something that was OK.  No, it won't meet the needs of
our highest end customers, but then really only 1% of customers
are them and if we had something "good enough" for 30% of our customers
to start with and then generate money to pay for more development
the product could have spent 3-4 years and done perhaps 3 major
releases while paying for the developers.

You don't start building the Taj.  You build a house.  Then you add
the garden, then you add this and that.  Perhaps you end up ripping
down the original core code, but if it's working and carried us forward
to the next version, that's fine.   cause if you start building the
Taj, you often end up with a lot of expensive cuts of marble and no
way to pay the workers and get it all together.

BSD Auth:
  get the libraries working.
Run through the code that might use it (or borrow wholesale from
a project that's got it).  This effort itself will give you the abstractions
you need for authentication.  That's a huge step.

And you make BSD Auth work.

If, later, someone wants to try PAM, then the "getpwent()" routines
will have been moved in (for ex.) su(1) to a more generic "getauthinfo()"
type of routined.

Whacking PAM (or psychic biometric authentication or whatever comes next)
means redoing SOME of the work, but not all of it.


Or folks can stand around meeting and planning to meet and working out
the best way forward out of the woods and discussing it all.
Me?  I view them as being in the same crowd as telephone sanitizers
and nail salon assistants.

Peter, go!  Run.  Allez!  Do, before they staple your shoes to the floor
to have more meetings and plans for discussions of sessions as to the
best plan to think about pondering the papers needed to begin looking
at the code.


They've muttered about PAM for years and will continue to do so forever.
You're in the seventh circle.  Sartre has given you no exit.  You can
save yourself through implementation.

> An early proposal was to do a shim API, but that got shot down but the
> "I only want BSD Auth" gallery.
> Another option was do BSD Auth via PAM - also shot down by the 
> "I only want BSD Auth" gallery.  
> Another alternative may be to implement BSD Auth and PAM via nsswitch
> but I gather the "I only want BSD Auth" gallery won't like that either
> because they don't like nsswitch...
> 
> The only proposal that has been offered by the "I only want BSD Auth" 
> gallery is "just do BSD Auth and I'll be happy", but of course that doesn't
> meet the needs of the project or anyone else.
> 
> Note that all of the solutions that are likely to be acceptible to
> "the project" will involve considerably more effort that the 
> "I only want BSD Auth" gallery seem to think, since the project developers
> have made it clear that just BSD Auth isn't enough.