[Samba] Samba v3.0.23a BROKE my network

[Aaron Kincer]

No offense, 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.

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

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
>