Deleting parameters.

Sean Elble S_Elble at yahoo.com
Sun Nov 11 21:54:03 GMT 2001


You bring up a good point with the writeable/writable parameter, and it was
something that I clearly didn't think of. :-) Sometimes, maybe _I_ should go
back and read my own smb.conf every once in a while, huh?

I definitely agree with you on the respect of asking for user input for each
removal of a parameter; something like security=share might not be missed
(just a hypothetical point, not necessarily fact for those of you who use it
:-), but something like encrypted passwords=yes would be a big loss to
users, and it is those users who have to voice in their opinion, like I'm
doing right now. :-)

> > 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.

My point here was that RPM offers the capability to run a script adter the
installation; a migration script would be a perfect example for that "post
install" script. Yes, someone would have to write that (ideally not me,
since I can barely program Hello world in Perl :-), but I'm sure someone
handy with Perl could put one of them out in less than a day. Could be wrong
though, but it is definitely a capability worth investigating.

> > 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.
>
> 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.


Here's the biggest point with which I agree on with you; any broken features
have to be fixed or removed, PERIOD. No ifs, ands, or buts. And a parameter
can be removed if there is a migration path for users to get from 2.2 to 3.0
(or whatever, like the next release in the 2.2 branch). The only thing I
could disagree with you on is if there's a parameter in Samba that probably
should be removed, even if there are vocal users who object to it being
removed. What if that one parameter, like the security parameter, is holding
back Samba from becoming better as a whole (at least in the 2.2 branch)?
Users, especially large corporations, don't and can't wait another 2 years,
or however long it takes for Samba 3.0 to be released, for one feature that
could be added to 2.2 at the expense of losing a feature may be used by
many, but could be implemented in a much better way. I saw the Windows 95
point mentioned earlier, and even though you didn't think it made much
sense, I think it does. Legacy code isn't necessarily bad, but legacy code
that is bad should be dealt with, even if that means compatibility with
existing configuration files must be broken. Ever heard the phrase "amputate
the leg to save the patient"? Well try "amputate the leg to help the person
perform functions better". :-) Same basic concept, but taken a little
further to include replacing out-of-date code with improved code, even if it
does mean changing/deleting parameters. Just my (little more than) 2 cents .
. .

-----------------------------------------------
Sean P. Elble
Editor, Writer, Co-Webmaster
ReactiveLinux.com (Formerly MaximumLinux.org)
http://www.reactivelinux.com/
elbles at reactivelinux.com
-----------------------------------------------

----- Original Message -----
From: "Gerald (Jerry) Carter" <jerry at samba.org>
To: "Sean Elble" <s_elble at yahoo.com>
Cc: "Jeremy Allison" <jra at samba.org>; "Andrew Bartlett"
<abartlet at pcug.org.au>; <samba-technical at lists.samba.org>
Sent: Monday, November 12, 2001 12:23 AM
Subject: Re: Deleting parameters.


> 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.
>
> 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.
>
>
>
>
>
>
>
>
>
>
> cheers, jerry
>  ---------------------------------------------------------------------
>  www.samba.org              SAMBA  Team             jerry_at_samba.org
>  www.plainjoe.org                                jerry_at_plainjoe.org
>  http://www.hp.com        Hewlett-Packard
>  --"I never saved anything for the swim back." Ethan Hawk in Gattaca--





More information about the samba-technical mailing list