Deleting parameters.

[The DJ]

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


On a side-note here: My smb.conf (5) still shows this as a service only
parameter.

guest account (S)
              This is a username which will be used for access to...

The listing of parameters at the top of the file does the same.
Haven't had so much fun following technical list in a long time. ;-)

DJ
---------------------------------------------------------------------------
Universiteit Twente
---------------------------------------------------------------------------
Derk-Jan 'The DJ' Hartman
ICQnr: 10111559
Mail:  mailto:hartman at mac.com
WWW:   http://home.student.utwente.nl/d.hartman/
Goto:  http://www.student.utwente.nl/~macsatcampus