Deleting parameters.

[Andrew Bartlett]

Jeremy Allison wrote:
> 
> On Sat, Nov 10, 2001 at 04:34:10PM -0800, Andrew Tridgell wrote:
> >
> > 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
> >
> > 2) they only work with plaintext passwords on the wire, which means
> >    they need client hacks
> >
> > 3) they are completely superceded by our new kerberos code
> 
> I would agree with these, but these are *configure* parameters,
> not runtime parameters.
> 
> > Same goes for the SSL support code. It is a nasty, gross hack that
> > makes our code harder to maintain.
> 
> Again, mainly configure params.
> 
> > 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
> > maintain such patches when so few people use them. If someone pops up
> > and (credibly) says that they will maintain and *test* the patch then
> > fine, we can keep it, but if there is nobody who will do that then we
> > must drop it.
> >
> > Having a badly maintained security option is *much worse* than not
> > having it at all.
> >
> > 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.
> 
> And you're confusing the term "parameters" to try and win
> the argument :-) :-) :-).
> 
> I don't care at all about configure params. Anyone who compiles
> from source can cope with any change we make in loadparm.

In the case of the ./configure options, the configure parameters are
going because the code they configure will be ditched.

> I care about the runtime smb.conf parameters. What prompted this
> discussion was the suggestion that we completely remove the
> "security=" parameter for 3.0. I hope you would agree that would
> be a rather too radical change :-) :-).
> 
> Jeremy.
> argument of course was the idea that we remove the "security="

Just to clear things up a little:

I am not proposing removing security=, only security=server and
security=domain, to be replaced by a much more flexible mechanism called
'auth order'.  

So users on stand alone SMB servers will see *no* difference, only users
using security=server or security=domain are affected.

I also don't mind keeping a computability entry such that 'security =
domain' implies 'auth order = guest, domain, local' (which is equivalent
to current behavior), but it will contain *loud* warnings.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Samba Team member, Build Farm maintainer        abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net