On 10/16/2017 08:56 PM, Andrew Bartlett wrote:> Are they breaking anything?Not sure. But in another thread I reported some issues on replication, highwatermark notifications, high COU load, etc. My idea was do try several things to fix this. SO I created a virtualised isolated environment, in which I can try out all kinds of things: - upgrading the DCs to 4.7 (as suggested by you) or - add a fresh 4.7 dc, see how that works out - try the clone-dc-database But also: - try to make dbcheck complete without errors, to rule that out.> If so, can you get me more detail on exactly what breaks?So I'm not sure if there is a relation or not. :-|> If we have painted ourselves into a corner, and can no longer ignore > these dangling forward links, an improved dbcheck rule is probably the > right answer, and I would rather get you a patch than have you edit the > DB.Understood, but I'm not sure that my dangling link break anything. It's just that in case of an issue, the natural thing is: first try to make dbcheck finish without errors. :-)> Finally, for those that have already edited a backend DB, running > 'samba-tool dbcheck --reindex' on the sam.ldb is a must, to ensure the > index values are correctly re-calculated.I understand that most parts of sam.lbd are replicated between DCs, but from what I can read, some items are also non-replicated, so local-DC-only. Would I be ok to say: things that are replicated are more dangurous to edit using lbdedit than things that stay local to a specific DC? (as long as you run --reindex afterwards) MJ
On Tue, 2017-10-17 at 11:04 +0200, mj via samba wrote:> > On 10/16/2017 08:56 PM, Andrew Bartlett wrote: > > Are they breaking anything? > > Not sure. But in another thread I reported some issues on replication, > highwatermark notifications, high COU load, etc. > > My idea was do try several things to fix this. SO I created a > virtualised isolated environment, in which I can try out all kinds of > things: > > - upgrading the DCs to 4.7 (as suggested by you) > or > - add a fresh 4.7 dc, see how that works out > - try the clone-dc-database > But also: > - try to make dbcheck complete without errors, to rule that out. > > > If so, can you get me more detail on exactly what breaks? > > So I'm not sure if there is a relation or not. :-| > > > If we have painted ourselves into a corner, and can no longer ignore > > these dangling forward links, an improved dbcheck rule is probably the > > right answer, and I would rather get you a patch than have you edit the > > DB. > > Understood, but I'm not sure that my dangling link break anything. It's > just that in case of an issue, the natural thing is: first try to make > dbcheck finish without errors. :-)Can you please be less vague on what the link is exactly? A suggestion around the office from Garming was that we should: - remove more during the demote - clean up links to removed DCs more aggressively (not as likely to result in information loss). In particular, I think it would be quite safe to clean up a dangling forward link within the same partition in: - msDS-masteredBy - masteredBy - fSMORoleOwner - msDS-NC-Replica-Locations> > Finally, for those that have already edited a backend DB, running > > 'samba-tool dbcheck --reindex' on the sam.ldb is a must, to ensure the > > index values are correctly re-calculated. > > I understand that most parts of sam.lbd are replicated between DCs, but > from what I can read, some items are also non-replicated, so local-DC-only.It is some attributes.> Would I be ok to say: things that are replicated are more dangurous to > edit using lbdedit than things that stay local to a specific DC? > (as long as you run --reindex afterwards)Yes, because the replPropertMetaData is not updated during a backend edit. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
On 10/17/2017 11:22 AM, Andrew Bartlett wrote:> > Can you please be less vague on what the link is exactly? A suggestion > around the office from Garming was that we should:Oh sure! I posted that info already, I think, but this is the error:> ERROR: no target object found for GUID component for msDS-NC-Replica-Locations in object CN=84bea0a7-82dd-4237-9296-030573700698,CN=Partitions,CN=Configuration,DC=samba,DC=company,DC=com - <GUID=81a27497-bdfb-4977-9874-675bbfba490f>;<RMD_ADDTIME=130405075610000000>;<RMD_CHANGETIME=130405075610000000>;<RMD_FLAGS=0>;<RMD_INVOCID=556b2cb4-e576-48e2-bb7c-7f62caee84fc>;<RMD_LOCAL_USN=4605>;<RMD_ORIGINATING_USN=3630>;<RMD_VERSION=0>;CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samba,DC=company,DC=com> In particular, I think it would be quite safe to clean up a dangling > forward link within the same partition in: > - msDS-masteredBy > - masteredBy > - fSMORoleOwner > - msDS-NC-Replica-LocationsSo, good news :-) That's exactly what we're seeing here. So, all in all, thanks for this valuable information, I'll just go ahead and delete it! MJ