Deleting parameters.

[Andrew Bartlett]

"Gerald (Jerry) Carter" wrote:
> 
> On Sat, 10 Nov 2001, Sean Elble wrote:
> 
> > Maybe Tridge would disagree with you, but I'm with him
> > on this one. :-) There will always be unused/stupid,
> > and even dangerous options in a program, and it is up
> > to the both the users and developers to realize that.
> > Options that aren't done right should be done right,
> > and users should _know_ what options in _their_
> > configuration files do what. My recommendation would
> 
> I think that certain things like "read only", "writeable"
> and "writable" are candidates for reduction (to a single parameter.
> But only after significant warning.  And only after
> examining the consequences.
> 
> Think this out for a second.  Suppose we want to do away with
> "writeable" and "writable" in Samba 3.0.  We must flag these
> as deprecated beginning in the next 2.2.x release.
> No consider what would happen if an admin still contained
> 
>         writeable = yes
> 
> in a service after upgrading to 3.0? In this case, since
> all shares are read only by default, there is no
> security problem.  However, this is not the case.
> 
> If a feature, or parameter is to be removed, it must be
> announced to samba at samba.org to solict feedback.  None of this
> "developers perogative" stuff.  Then a reasonable plan
> must be made for its removal.
> 
> > be to add some text to the change logs, in which you
> > could write about the removal/addition of any config
> > options. Many Samba users compile their own binaries,
> 
> Over 50% of the downloads for 2.2.0 from samba.org were binary
> packages.  This does not include those which installed
> Samba form a vendor's distro of course, so the number
> is probably higher.
> 
> > and those who do generally read the change logs. Those
> > who obtain binaries from the Samba team, and other
> > vendors, should be informed during the installation,
> > if possible, as it is with RPMs. And, yes, I do
> 
> The only management app we have really is SWAT.  Its too easy to
> hand wave and go "we'll do this or do that during the upgrade".
> Someone has to write those migration tools.  I have not seen
> many if all proposals for migrating existing installations.
> 
> The exception to this was the "encrypt passwords = yes"
> default debate a few months ago.  And I will push to delay
> a 3.0 release until this tool is included.
> 
> > support a couple production Samba systems; I almost
> > always study the differences between each version of
> > Samba, using both the change logs, and e-mails from
> > the mailing lists. We can't "dumb down" Samba for
> > users who aren't willing to learn the _major_
> > differences between different versions. After all, you
> > don't see any config.sys files on any Windows 2000
> > machines, do you? :-) Just my 2 cents . . .
> 
> "dumb down" is a bad term here I think.  The problem
> is that I've seen proposals for changing things that resulted
> in a loss of functionality.  "Samba 2.2 would do this, but
> Samba 3.0 won't do XXX".  This is an example of course, but
> please consider this possibility.

Yes, and I beleive that some loss of functionality is required in some
places.  We can't maitain all funcionality for ever.  But we do need to
consult with users, and to attempt to provide workarounds.

However, where some 'functionality' gets in my way, is in my area, and
nobody steps up to maintain it I'll have to ask as to its future.

> Now as a side rule, if a feature is broken in 2.2, it should
> be fixed or removed.  A parameter can be removed IIF there exists
> a migration path for sysadmins to get from here to there.

Thats the situation for lp_guestaccount() as a share-level paramater,
its broken in 2.2 in every case except share level security.  Only the
global defintion functions, the local one will be almost compleatly
ignored.

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