Hi Andrew,
Thanks for the reply. Sorry if I've jumped the gun by not wanting to try
and fix "in place", sometimes it just seems easier to start again from
a
clean slate. Also, sorry for the double-email Andrew, forgot to CC the
list - this mail client is not overly list-friendly, I've had to handcraft
the reply below as it doesn't allow bottom-posting...
On Wed, 2013-12-04 at 11:08 +0000, Andrew Bartlett wrote:
> On Wed, 2013-12-04 at 10:40 +0000, Kevin Latimer wrote:
>> Hi All,
>>
>> Does anyone know if there's a Samba 4 to Samba 4 migration process?
>> Sounds weird, but it has a logical reason:
>>
>> I've a several-year-old S4 implementation, from an early Alpha (10
I
>> think?) that hasn't been in the best of shape of late - when S4
4.0.0
>> arrived, I accidentally upgraded using my normal "git
>> pull; ./configure; make; make install" procedure and instead of
>> getting 4.0 I got 4.1pre. I hastily installed the 4.0.0 tarball but I
>> think I've ended up with a broken schema because of it.
> The two trees were not that different at that point, so I don't think
> major harm came from this.
No probs, I just don't have a lot of faith in which schema I *do* have,
as I'm missing the RFC2307 / SFU things that I wanted upgradeprovision
to try to add :-)
>> It's been clunking along okay nontheless with the oddities just
>> needing a little manual intervention now and again but last night I
>> decided to install the 4.1.2 tarball.
>>
>> I wanted to do an "upgradeprovision --full" as I've been
missing the
>> SFU schema and I need to retain some UID consistency. My testing on a
>> snapshot told me you can't run upgradeprovision with more than one
DC
>> so last night, I allotted myself a maintenance window and went for it.
>> I demoted all the DC's but I had one that wouldn't demote (this
DC is
>> one of the "manual interventions"...). I've tried
samba-tool domain
>> demote, ntdsutil metadata cleanup, ADUC, ADSAS but it just won't
>> shift.
>>
>> Running out of time, I decided to upgrade to 4.1.2 on these two
>> remaining DC's anyway, do a fresh install on the other DC's and
rejoin
>> them. They upgraded just fine but I can't join any other DC's,
>> samba-tool segfaults after copying the configuration partition.
> That's unfortunate. Can you get us some information on this segfault?
Sure. I've just tried with a -d6 (a *lot* of output, much more than I
allowed for with my scrollback!) and it segfaults with the following
error at the end:
dsdb_find_nc_root: Finding a valid 'namingContexts' element in the
RootDSE failed. Using a temporary list.dsdb_find_nc_root: Finding a valid
'namingContexts' element in the RootDSE failed. Using a temporary
list.../source4/dsdb/common/util.c:3116: WARNING: domainFunctionality not setup
Segmentation fault
I've got 20k lines of scrollback I can email to you if you like? I'm
not
sure how much sensitive information might be in there for list posting...
Looking back though, these "Finding a valid 'namingContexts'
element in
the RootDSE failed" messages seem to all start around the part the sites
and
subnets start to get replicated.
>> My directory seems to be in a bit of a mess (dbcheck only shows two,
>> albeit uncorrectable errors) so I wonder if there's a procedure
(like
>> classicupgrade for S3->S4 or vampire for NT4/Windows) to get the
users
>> and computers from my current provision into a new, fresh one?
> What are the errors, and have you actually run upgradeprovision or not?
> (We are trying to avoid folks running that tool, except in the extreme
> cases such as an installation of your age, and even then we are trying
> to have dbcheck handle it as much as possible.
Haven't been able to run it, as I can't pare the domain down to a single
DC - I have a "wobbly" DC (by wobbly, I mean it identifies itself in a
"samba-tool drs showrepl" as
"0ACNF:9087250e-361c-44b6-8b11-e8cee5d48ab6"
in the server DN name) that just won't demote:
/usr/local/samba/bin/samba-tool domain demote --user=Administrator -d6
fails with:
Changing userControl and container
drsuapi_DsRemoveDSServer: struct drsuapi_DsRemoveDSServer
in: struct drsuapi_DsRemoveDSServer
bind_handle : *
bind_handle: struct policy_handle
handle_type : 0x00000000 (0)
uuid :
84b613ab-3f47-480f-8b70-27af621d5338
level : 0x00000001 (1)
req : *
req : union
drsuapi_DsRemoveDSServerRequest(case 1)
req1: struct drsuapi_DsRemoveDSServerRequest1
server_dn : *
server_dn :
'CN=HO-DC2,CN=Servers,CN=Gateshead,CN=Sites,CN=Configuration,DC=tclad,DC=tolent,DC=co,DC=uk'
domain_dn : *
domain_dn :
'DC=tclad,DC=tolent,DC=co,DC=uk'
commit : 0x00000001 (1)
../librpc/rpc/dcerpc_util.c:140: auth_pad_length 0
drsuapi_DsRemoveDSServer: struct drsuapi_DsRemoveDSServer
out: struct drsuapi_DsRemoveDSServer
level_out : *
level_out : 0x00000001 (1)
res : *
res : union
drsuapi_DsRemoveDSServerResult(case 1)
res1: struct drsuapi_DsRemoveDSServerResult1
last_dc_in_domain : 0x00000000 (0)
result : WERR_GENERAL_FAILURE
Error while demoting, re-enabling inbound replication
Sorting rpmd with attid exception 3 rDN=CN DN=CN=NTDS
Settings\0ACNF:9087250e-361c-44b6-8b11-e8cee5d48ab6,CN=HO-DC2,CN=Servers,CN=Gateshead,CN=Sites,CN=Configuration,DC=tclad,DC=tolent,DC=co,DC=uk
CN=HO-DC2,OU=Domain Controllers,DC=tclad,DC=tolent,DC=co,DC=uk
ERROR(<class 'samba.drs_utils.drsException'>): Error while sending
a removeDsServer - drsException: DsRemoveDSServer failed (31,
'WERR_GENERAL_FAILURE')
File
"/usr/local/samba/lib/python2.6/site-packages/samba/netcmd/domain.py",
line 773, in run
sendRemoveDsServer(drsuapiBind, drsuapi_handle, server_dsa_dn, domain)
File
"/usr/local/samba/lib/python2.6/site-packages/samba/drs_utils.py",
line 106, in sendRemoveDsServer
raise drsException("DsRemoveDSServer failed %s" % estr)
I've tried performing the demote with outbound replication disabled
(a trick I've used before on alpha's when the local AD has become
corrupt
in some way and I don't want to replicate the "bad" bits) but no
use :-(
>> I'm not bothered about retaining metadata like last login time or
>> password history or such, just enough information to allow users to
>> login without having to rejoin each machine? Losing GPO's
aren't the
>> end of the world either, I don't have many.
> If we really had to, we could hack something up via the classicupgrade
> code or similar, but I would really rather not.
> Let's try and fix up your directory as-is.
If you think it's worth saving, I'll start along that route then :-)
Thanks
again Andrew (and everyone else here!).