[Samba] Samba v3.0.23a BROKE my network
chris.hall at halldom.com
Wed Jan 24 21:39:33 GMT 2007
On Wed, 24 Jan 2007 you wrote
> 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 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
>>> 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?
>> 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
>> 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.
>> Even now I know the answer, I still do not see anything there that tells
>> 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
>> 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.
Chris Hall @ Home +44 (0)7970 277 383
More information about the samba