[Samba] Samba v3.0.23a BROKE my network
Aaron Kincer
kincera at gmail.com
Wed Jan 24 19:37:51 GMT 2007
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
>
More information about the samba
mailing list