Deleting parameters.

[Andrew Bartlett]

"Gerald (Jerry) Carter" wrote:
> 
> On Sat, 10 Nov 2001, Andrew Tridgell wrote:
> 
> > > Of course I'm sure tridge will disagree with this.... :-) :-).
> >
> > yes, I disagree. There are some parameters that are just too evil to
> > live. A good example is the old krb4 and krb5 configure
> > parameters. They should be removed because:
> >
> > 1) they required compile time changes, which very few people do
> 
> OK.  I'll play devil's advocate here.  Have you asked ?  Or are we
> assuming?  Now I will also point out that as I did to Andrew B.
> that removing the --with-krb5 option removes certain functionality
> that I do not think can be supported in 3.0.  Namely, logons
> using Kerberos from non-win2000 clients with a non-PAM server
> (which there are many).

Yes, that problem bothers me.  I think we will end up with a new
solution that uses the new kerberos code that is complementary to the
existing design.  In intend to allow PAM (and possibly krb5-plaintext)
to be configured at runtime, rather than at compile time.  This is
actually quite practical with the new auth code.

> > 2) they only work with plaintext passwords on the wire, which means
> >    they need client hacks
> 
> So? What is the point here?  People who logon against NIS or /etc/passwd
> for convience do the same thing.

And we still allow rhosts and hostsequiv.  But how many sites:  a) have
a security policy such that they run kerberos.  b) Allow cleartext
passwords on their network.  c) Run as OS that *can't* support PAM
(installing PAM does not mandate its use for /bin/login, and FreeBSD now
supports it) and d) have made the client hacks?

> > 3) they are completely superceded by our new kerberos code
> 
> Not entirely. See above.
> 
> > Same goes for the SSL support code. It is a nasty, gross hack that
> > makes our code harder to maintain.
> 
> Again, I think that VPN's are a much better option for this, but I think
> Jeremy's initial comments was about parameters, not configure options.
> 
> > What you forget about in your view on keeping parameters is that there
> > is a tradeoff between keeping old parameters and keeping the code
> > maintained. Leaving in code that nobody actively maintains and that
> > makes the code less maintainable increases the number of bugs for
> > *everyone*, whereas keeping the parameter helps maybe one person who
> > happens to use that parameter. We do not have the resources to
> 
> The problem is that it can be very hard to determine who is actually
> using a parameter.
> 
> There are two basic issues here:
> 
>   * migration of 2.2 type parameters to 3.0 (there must be a migration
>     plan other than vi/emacs)
>   * changes in functionality (things you used to be able to do
>     and can't anymore)
> 
> > Andrew and I will be removing some of these unmaintained options from
> > the head branch. If you want to put them back in, then fine, but
> > please don't do so unless you can guarantee they will be maintained. I
> > know you don't have the time to do it yourself, so you'll have to find
> > someone willing to do it. If you can't then don't add it back in.
> 
> Please announce on samba at samba.org when you choose to remove anything
> to test the waters and explain the impact of the change.  We've gotten
> burned in the past by the perception that we develop in a vaccum. :-)

Done, and BCC'd back to samba-technical

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net