[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
>>> 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
More information about the samba
mailing list