[Samba] Recommended Upgrade technique for 4.0.3 (was Re: Should I run dbcheck and sysvolreset when upgrading 4.0.0 to 4.0.3?)

[Pekka L.J. Jalkanen]

On 26.2.2013 23:53, Andrew Bartlett wrote:
> On Tue, 2013-02-26 at 13:36 +0200, Pekka L.J. Jalkanen wrote:
>> On Sat, 2013-02-16 Andrew Bartlett wrote:
>>> On Sat, 2013-02-16 at 12:55 +1100, Andrew Bartlett wrote:
>>>> On Fri, 2013-02-15 at 12:52 +1100, Andrew Bartlett wrote:
>>>>> On Thu, 2013-02-14 at 20:50 -0500, Thomas Simmons wrote:
>>>>>> Thank you, Andrew. Just to be clear, you're saying I can upgrade to 4.0.3
>>>>>> (but do nothing after make install)? If it will make things worse in any
>>>>>> way, I can stay at 4.0.0. Thanks, Thomas.
>>>>>
>>>>> It's fine to upgrade.  That protects you against the security issue we
>>>>> fixed in 4.0.1, and makes a significant number of other fixes.
>>>>
>>>> My current testing shows that:
>>>>
>>>> samba_upgradeprovision --full
>>>> dbcheck --cross-ncs [--fix [--yes]]
>>>>
>>>> Will break some ACLs on DNS, and not fix one of the ACLs on the DC's own
>>>> LDAP object.  The --full is important, without that the result is
>>>> actually worse (as far as I can tell).
>>>>
>>>> I would like to make some progress on this before I recommend it as the
>>>> final solution.
>>>>
>>>> It is however pretty close, and better than what is in the database
>>>> right now.  
>>>
>>> I retract any advise to run this tool.  I hope to have patches soon, but
>>> for the moment it treats any beta or release version as being *before*
>>> alpha9.  Essentially we have been caught out by a regex that never
>>> expected Samba to move beyond endless alphas :-)
>>>
>>> Please do not run samba_upgradeprovision under any circumstances, until
>>> I have tested patches to fix this. 
>>
>> Since the discussion on samba-technical gave somehow mixed
>> recommendations about whether it should be run or not, I had attempted
>> to run it anyway, when I upgraded my installation from 4.0.0 to 4.0.3. 
> 
> NO!

Please don't panic: like I said, I already tried it, so it's too late
for remorse now. And even if I were to lose this specific DC completely,
it would still not be a catastrophe. Extra work though, sure.

> At this point I've tried to be very clear, and I'm not sure what
> part of what I've said above was not clear. 

Everything what you wrote above was very, very clear, but perhaps I
wasn't that clear when I said that I only found about this thread after
the upgrade. In short: I upgraded before I had read what you said.

> Who suggested you should run this tool?

I think that after reading your message on samba-technical (see
https://lists.samba.org/archive/samba-technical/2013-February/090442.html)
I thought that, OK, there are some problems, but also thought that at
worst I may lose some ACLs, and I wasn't too worried about that. I also
somehow thought that I either have to run this tool, or stick with
4.0.2. I know better now, but what's done is done.

>> I
>> figured out that as I'm having some problems with my group policies
>> anyway, and am not generally using them, it shouldn't hurt too much.
>> (Back then, I had missed this thread, as I had mistakenly only followed
>> the samba-technical list.)

See above: I simply hadn't read your advise here before upgrading. So
don't feel bad here: it's my fault, not yours.

>> Here are my experiences:
>>
>> -- cut --
>>
>> Third, it finally didn't run at all, as it stated that multiple DC
>> setups aren't supported. This wasn't stated anywhere in advance. The
>> command doesn't have a manpage, and "--help" switch doesn't give any
>> clue what the command is actually supposed to do.
> 
> This is an extra safety check we added.  But the lack of clear
> documentation on this is one of the many reasons why I'm now of a mind
> to remove this tool until it meets these and many other standards. 

That would probably be a good move. At least that would be one count
less with virtually undocumented things in Samba 4 (there still would be
others left, but I guess that's another topic).

>> So in the end I didn't run it at all, as it can only be run in single DC
>> setups. But I did run the ldbadd command, and don't know how serious
>> mistake that was.
>>
>> Afterwards, I tried to run "samba-tool dbcheck --cross-ncs --fix", and
>> unlike in 4.0.0, it didn't manage to fix everything:
>>
>> -- cut --
>> Failed to correct missing instanceType on CN=RID Set,CN=W2K3DC,OU=Domain
>> Controllers,DC=mydomain,DC=site by setting instanceType=4 : (65,
>> "objectclass_attrs: at least one mandatory attribute ('rIDNextRID') on
>> entry 'CN=RID Set,CN=W2K3DC,OU=Domain Controllers,DC=mydomain,DC=site'
>> wasn't specified!")
>> -- cut --
> 
> This is a concern, and looks like it was initially due to an incorrect
> implementation of the instanceType check in the dbcheck shipped with
> 4.0.0, after your domain was imported from a Windows 2000 level domain. 
> 
> Can you give me some more detail on this history of this domain?

It's a long story, but I'll try to be brief.

It's originally a one-DC Windows 2003 R2 domain, with which I've been
trying to use S4 since beta 2 or so. But most of the time I've kept it
firewalled so that only our Windows DC and a handful of clients are
actually allowed to communicate with it; the rest of the clients are
still using the Windows DC exclusively. I've also this far been doing
all the user management on Windows DC, and have used neither Samba's own
tools nor RSAT.

The domain also previously had a two-way trust--that had already been
removed before this latest upgrade--with another domain. I know that
Samba can't trust, but the Windows DC can, and I had to use MS ADMT to
import few accounts from a separate one-DC forest. The domain functional
level had been raised from mixed mode to Windows 2000 native after
creating this trust to enable importing the accounts.

> It is more of a worry that it can't fix it - but this might be due to us
> missing some special case logic that needs to be applied around the Rid
> Set objects. 
> 
>> Don't know if I should be worried about these errors, though, or whether
>> they have anything to do with my mistaken ldbadd command.
> 
> Your ldbadd command probably just made it more difficult to ever run
> samba_upgradeprovision in the future.  It doesn't change the actual
> data, just some metadata notes in a special area outside the directory. 

Should I demote the DC, cleanup and reinstall Samba and re-promote it to
fix things? I could do this, provided that the demote works reliably
now. (At some point during the beta phase it didn't, and I had to clean
the mess in Windows with ntdsutil / metadata cleanup.)


Pekka L.J. Jalkanen