[Samba] Samba v3.0.23a BROKE my network

Aaron Kincer kincera at gmail.com
Wed Jan 24 21:55:02 GMT 2007

Not that I don't understand your frustration. I do. I guess it boils 
down to whether I would prefer the developers concentrate on fixing bugs 
and improving functionality or for them to expend energy on helping 
prevent me from doing something bad that goes against best practices. I 
overwhelmingly prefer the former.

If someone out there has the wherewithal to write some kind of upgrade 
checker that has the functionality you desire, I hope they come forward 
and do so. Otherwise, I'm content for the developers to keep doing what 
they are doing and focus on getting Samba 4 ready for prime time. But 
that's just me and I can't speak for anyone else.

Chris Hall wrote:
> 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 
>>> 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

More information about the samba mailing list