Hi all, We have a Samba AD DC service running on Ubuntu 16.0.4 with Samba 4.3.11. We are planning to upgrade it to a recent version, probably 4.8.3. I think that I have two options: a) Package upgrade via 3rd party repositories (Louis Van Belle's repo) by following wiki. b) A fresh install of 4.8.3 on another VM then join it to 4.3.11 as backup DC, then transfer all FSMO roles on new and finally demote older one. Since this a production environment, I have to accomplish this task transparently. Is there anyone out there who did same task before? I'll appreciate any advice regarding this. Thanks. -- Taner Tas
On Sun, 15 Jul 2018 23:27:13 +0300 Taner Tas via samba <samba at lists.samba.org> wrote:> Hi all, > > We have a Samba AD DC service running on Ubuntu 16.0.4 with Samba > 4.3.11. We are planning to upgrade it to a recent version, probably > 4.8.3. > > I think that I have two options: > > a) Package upgrade via 3rd party repositories (Louis Van Belle's repo) > by following wiki. > > b) A fresh install of 4.8.3 on another VM then join it to 4.3.11 as > backup DC, then transfer all FSMO roles on new and finally demote > older one. > > Since this a production environment, I have to accomplish this task > transparently. Is there anyone out there who did same task before? > I'll appreciate any advice regarding this. > > Thanks.I would go with option 'b', but it sounds like you only have one DC, I would also create a second DC. I would also ensure they were on different hardware, whether they are in VM's or not. Also, you should get out of calling DC's anything other than just a DC, all DC's are equal except for the FSMO roles and they can be on any DC. Rowland
> Hi all, > > We have a Samba AD DC service running on Ubuntu 16.0.4 with Samba > 4.3.11. We are planning to upgrade it to a recent version, probably > 4.8.3. > > I think that I have two options: > > a) Package upgrade via 3rd party repositories (Louis Van Belle's repo) > by following wiki. > > b) A fresh install of 4.8.3 on another VM then join it to 4.3.11 as > backup DC, then transfer all FSMO roles on new and finally demote > older one. > > Since this a production environment, I have to accomplish this task > transparently. Is there anyone out there who did same task before? > I'll appreciate any advice regarding this. > > Thanks.I would go with option 'b', but it sounds like you only have one DC, I would also create a second DC. I would also ensure they were on different hardware, whether they are in VM's or not. Also, you should get out of calling DC's anything other than just a DC, all DC's are equal except for the FSMO roles and they can be on any DC. Rowland I tried to join 4.8.2 (latest one at Louis Van Belle's repo) but I got this error: ----------------- ldc4# samba-tool domain join testdomain.org.tr DC -U"TESTDOMAIN\administrator" --dns-backend=BIND9_DLZ Finding a writeable DC for domain 'testdomain.org.tr' Found DC ldc1.testdomain.org.tr Password for [TESTDOMAIN\administrator]: workgroup is TESTDOMAIN realm is testdomain.org.tr Adding CN=LDC4,OU=Domain Controllers,DC=testdomain,DC=org,DC=tr Join failed - cleaning up ERROR(ldb): uncaught exception - LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS - <00002071: ../ldb_tdb/ldb_index.c:1216: Failed to re-index objectSid in CN=LDC4,OU=Domain Controllers,DC=testdomain,DC=org,DC=tr - ../ldb_tdb/ldb_index.c:1148: unique index violation on objectSid in CN=LDC4,OU=Domain Controllers,DC=testdomain,DC=org,DC=tr> <> File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/samba/netcmd/domain.py", line 706, in run plaintext_secrets=plaintext_secrets) File "/usr/lib/python2.7/dist-packages/samba/join.py", line 1482, in join_DC ctx.do_join() File "/usr/lib/python2.7/dist-packages/samba/join.py", line 1381, in do_join ctx.join_add_objects() File "/usr/lib/python2.7/dist-packages/samba/join.py", line 616, in join_add_objects /etc/hosts: 10.220.1.19 ldc1.testdomain.org.tr ldc1 10.220.1.20 ldc2.testdomain.org.tr ldc2 10.220.1.22 ldc4.testdomain.org.tr ldc4 /etc/hostname: ldc4 ----------------- I tested with "LDC3" hostname first, then changed hostname to "LDC4" after seeing a deleted DC record with "LDC3" name. # ldbsearch -H /var/lib/samba/private/sam.ldb --cross-ncs --show-deleted | grep LDC3 But changing hostname to "LDC4" didn't help either as can be seen above. I have same issue with 4.7.6 (Ubuntu official). I googled this "LDAP error 68 LDAP_ENTRY_ALREADY_EXISTS" error during join operation. Some people had similar problem but without a solution. --- Taner Tas
Paul Littlefield
2018-Jul-16 08:48 UTC
[Samba] Need advice on upgrading from 4.3.11 to 4.8.3
On 15/07/2018 21:27, Taner Tas via samba wrote:> We have a Samba AD DC service running on Ubuntu 16.0.4 with Samba 4.3.11. > We are planning to upgrade it to a recent version, probably 4.8.3.Yes, Penny is spot on. I have recently performed a similar task in a production environment. 1. Test the whole procedure at home with VMs, where I took a copy of the current VM, then created a new 4.8.x VM and followed through the join and demote, then tested logging on, RSAT and various Domain related tasks... lots of interesting things cropped up which I dealt with and redid it all AGAIN :) 2. Out of office hours, BACKUP the current VM just before you do it. 3. Create new VM with stable 4.8.x, join, check replication and TRANSFER roles. 4. Make sure you can logon clients, print, browse internet, etc. Check that any Windows Servers have the correct DNS and using RSAT tools check that both DCs are replicating, etc. 5. Create another same new VM with 4.8.x and join to Domain. Check replication to all 3. 6. POWER OFF the old VM and then do some more testing without it ON. 7. If you ready, start up the old VM and then demote it... check all has gone using RSAT tools (I had to manually remove _loads_ in DNS manually). 8. POWER OFF THE OLD VM, TURN OFF AUTOSTART (or check you have a backup then DELETE it from your VM environment) 9. More checks and then BACKUP both new DCs then come in early on Monday morning to be sure :) Penny, does all that sound OK? Paul
On Mon, 16 Jul 2018 08:48:45 +0000 Paul Littlefield via samba <samba at lists.samba.org> wrote:> On 15/07/2018 21:27, Taner Tas via samba wrote: > > We have a Samba AD DC service running on Ubuntu 16.0.4 with Samba > > 4.3.11. We are planning to upgrade it to a recent version, probably > > 4.8.3. > > Yes, Penny is spot on. > > I have recently performed a similar task in a production environment. > > 1. Test the whole procedure at home with VMs, where I took a copy of > the current VM, then created a new 4.8.x VM and followed through the > join and demote, then tested logging on, RSAT and various Domain > related tasks... lots of interesting things cropped up which I dealt > with and redid it all AGAIN :) > > 2. Out of office hours, BACKUP the current VM just before you do it. > > 3. Create new VM with stable 4.8.x, join, check replication and > TRANSFER roles. > > 4. Make sure you can logon clients, print, browse internet, etc. > Check that any Windows Servers have the correct DNS and using RSAT > tools check that both DCs are replicating, etc. > > 5. Create another same new VM with 4.8.x and join to Domain. Check > replication to all 3. > > 6. POWER OFF the old VM and then do some more testing without it ON. > > 7. If you ready, start up the old VM and then demote it... check all > has gone using RSAT tools (I had to manually remove _loads_ in DNS > manually). > > 8. POWER OFF THE OLD VM, TURN OFF AUTOSTART (or check you have a > backup then DELETE it from your VM environment) > > 9. More checks and then BACKUP both new DCs then come in early on > Monday morning to be sure :) > > Penny, does all that sound OK? > > Paul > >Yes Littlefield. it does ;-) Rowland
On 16.07.2018 11:48, Paul Littlefield via samba wrote:> On 15/07/2018 21:27, Taner Tas via samba wrote: >> We have a Samba AD DC service running on Ubuntu 16.0.4 with Samba >> 4.3.11. >> We are planning to upgrade it to a recent version, probably 4.8.3. > > Yes, Penny is spot on. > > I have recently performed a similar task in a production environment. > > 1. Test the whole procedure at home with VMs, where I took a copy of > the current VM, then created a new 4.8.x VM and followed through the > join and demote, then tested logging on, RSAT and various Domain > related tasks... lots of interesting things cropped up which I dealt > with and redid it all AGAIN :) > > 2. Out of office hours, BACKUP the current VM just before you do it. > > 3. Create new VM with stable 4.8.x, join, check replication and > TRANSFER roles. > > 4. Make sure you can logon clients, print, browse internet, etc. Check > that any Windows Servers have the correct DNS and using RSAT tools > check that both DCs are replicating, etc. > > 5. Create another same new VM with 4.8.x and join to Domain. Check > replication to all 3. > > 6. POWER OFF the old VM and then do some more testing without it ON. > > 7. If you ready, start up the old VM and then demote it... check all > has gone using RSAT tools (I had to manually remove _loads_ in DNS > manually). > > 8. POWER OFF THE OLD VM, TURN OFF AUTOSTART (or check you have a > backup then DELETE it from your VM environment) > > 9. More checks and then BACKUP both new DCs then come in early on > Monday morning to be sure :) > > Penny, does all that sound OK? > > PaulHave you any test procedure rather than basic operations (account setup etc) that you are following regularly? After proper dhcpd.conf setup and dns cleanup, new logons will not aware any server side update except clients remain in sleep mode at night right? Even If I keep dns service running on demoted DC's, after dns record clean-up, those clients woke up from sleep (or didn't shut down at all) would be seek previous dns records. Is there a proven solution for such conditions? Thanks. --- Taner Tas