[Samba] Samba v3.0.23a BROKE my network

[Chris Hall]

On Wed, 24 Jan 2007 you wrote
>No offense,

None taken.

> but making any software update or change to a production system 
>without first testing it in a test environment is an administrative 
>issue, not a software issue.

That could have reduced my users' blood pressure...

...but doesn't change my opinion that software should be written to 
avoid obscure failure caused by obvious misconfiguration -- particularly 
in the case of an upgrade which turns a previously working configuration 
into a broken one !

>It isn't terribly difficult to configure a test environment that would 
>allow you to see if everything works as expected.

Sure.  But I'm not trying to run a nuclear power station here.

Chris

>Chris Hall wrote:
>> On Wed, 24 Jan 2007 you wrote
>>
>>> On Wed, Jan 24, 2007 at 03:59:30PM +0000, Chris Hall wrote:
>>>
>>>>   * if a change is made that invalidates existing configurations
>>>>     the documentation SHOULD SAY THAT, and it SHOULD SAY WHAT CHANGES
>>>>     ARE REQUIRED.
>>>>
>>
>>
>>> I know this will not relieve you frustration, but Jerry has
>>> put a big paragraph in the file WHATSNEW.txt under the
>>> heading
>>>
>>> User and Group changes
>>> ======================
>>>
>>> We have it made very explicit that there are big changes
>>> coming with this release.
>>>
>>> Do you have any recommendation how we should this get across
>>> to our users more effectively?
>>>
>>
>> OK...
>>
>> Although I put the documentation issue first, I think it is more
>> important that the software check for this kind of configuration issue,
>> and report it clearly.
>>
>> In short, I think this is more a software than a documentation issue.
>> However, the documentation did not lead me very quickly to the solution
>> :-(
>>
>> First, I just did a "yum update" which updated samba and that broke the
>> network.  So, by the time I read the release notes the horse had already
>> bolted and I was left wondering why the stable door was off its hinges.
>>
>> Second, I was upgrading from .14 to .23a, so I had to wade through a
>> fair amount of release notes.
>>
>> Third, I could find nothing that seemed related to the symptom I had,
>> namely that users could not log in !
>>
>> Now, I agree that there's a big warning in the release notes under the
>> heading "User and Group Changes", as you say.  And yes, in the end this
>> lead me to the section in the HOWTO that says it is necessary to set up
>> groupmap entries for Domain Admins, Domain User and Domain Guests.  (But
>> not Domain Computers ?)
>>
>> I can, through a glass darkly, see that explicitly mapping ntgroups/SIDs
>> to unix groups should be useful.  Why things worked fine without such
>> mapping before is perhaps more of a puzzle than why it is required now.
>> But this is not really the point.
>>
>> I don't suppose I'm the only samba user who has never needed to worry
>> about the groupmap mechanism, and for whom it has remained a perfect
>> mystery.
>>
>> I had a configuration that worked pre .23 but now suddenly did not work.
>>
>> What I needed to know was that with .23 it is ESSENTIAL that groupmap
>> settings are made for a small number of groups.
>>
>> Even better, it would have been good to know that without those groupmap
>> settings, users would not be able to log on.
>>
>> I have read and reread the release notes.
>> (http://www.samba.org/samba/history/samba-3.0.23.html)
>>
>> Even now I know the answer, I still do not see anything there that tells
>> me:
>>
>>   From v3.0.23 onwards it is essential to map a small number of
>>   nt groups to the equivalent unix groups on the samba server.  If these
>>   mappings are not made you will find that users will not be able to
>>   log on and machine trust accounts will be unusable.
>>
>>   The nt groups that must be mapped are: Domain Admins, Domain Users and
>>   Domain Guests.  To set up the mapping you need to:
>>
>>     net groupmap add ntgroup="Domain Admins" rid=512 unixgroup=? type=d
>>     net groupmap add ntgroup="Domain Users"  rid=513 unixgroup=? type=d
>>     net groupmap add ntgroup="Domain Guests" rid=514 unixgroup=? type=d
>>
>>   where '?' is the unix group to map to in each case.  'net groupmap
>>   list' will show the current groupmap.  The groupmap is stored once it
>>   has been set up.
>>
>>   For more about group mapping see the HOWTO, Chapter 12, GROUP MAPPING:
>>   MS WINDOWS AND UNIX.
>>
>> I don't know if other bad things happen if this groupmap is not set up,
>> so this is not guaranteed to be complete.
>>
>> So, I would say:
>>
>>   1. the software should check that the configuration is complete, and
>>      make sensible noises if it is not.  The trap I fell into has no
>>      business being there in the first place.
>>
>>      Developers need to avoid constructing pitfalls, or at the very
>>      least put up some form of safety barrier.
>>
>>   2. Having to take special steps to document a pitfall is a sure sign
>>      there's something wrong with the software !
>>
>>   3. The documentation needs to be direct and from the users', not the
>>      developers', perspective.
>>
>>      I'm sure there are lots of interesting things to say about how the
>>      software now deals with groups, and how that solves various
>>      problems -- and this will make sense to people who have some idea
>>      what it is about, particularly the wizards who develop these
>>      things.
>>
>>      In general users are not interested in how the software has been
>>      improved.  Users are only interested in what a given change means
>>      to them, which can be broken into (a) description of problem,
>>      (b) resolution of problem.
>>
>>        - the description needs to be complete enough for users who have
>>          encountered (and may understand) the problem to recognise it,
>>          and enough for other users to know that it is not something
>>          they care about.
>>
>>        - the resolution needs to concentrate on the user visible effects
>>          and any action the user needs to take.
>>
>>      In this case what we have is a side effect of other improvements:
>>      some extra configuration is required.  The release notes needed to
>>      say just that.  So... following the pattern above, (a) the problem
>>      is that to get over issues with group handling it is necessary to
>>      have explicit group mappings, without which a number of bad things
>>      happen, (b) the resolution is for the user to specify a minimum set
>>      of mappings.
>>
>>      [The fact that the problem here is self-inflicted is another sure
>>      sign that the software is at fault !]
>>
>>   4. Think of the user as an intelligent person who has been asleep for
>>      two hundred years.  Now you need to teach them how to drive.  They
>>      won't need to know how a car works, just how to operate it and keep
>>      it running.  They understand the language well enough, but there's
>>      a whole new chunk of vocabulary that may mean nothing (think wing
>>      mirror) or something quite different (think bonnet or choke).
>>      Further, when you get out onto the road there's a whole slew of
>>      concepts to be mastered.
>>
>> HTH
>>
>> Chris
-- 
Chris Hall   @ Home                                         +44 (0)7970 277 383