Hi, dbcheck tells us we have two "dangling forward links" that I am trying to get rid of. On my test domain, I have simply done ldbedit -e nano -H ./CN=CONFIGURATION,DC=SAMBA,DC=COMPANY,DC=COM to remove them. While that seems to have worked nicely, dbcheck report zero errors now, it is something that I should never have done, or do in production, according to Andrew: "We realise this is a difficult problem for you and other users, but NEVER, EVER do that." So, question: is there a SAFE way to easily get rid of those two "dangling forward links"? (they are Replica-Locations for a DC that has been removed years ago) MJ
On Mon, 16 Oct 2017 16:53:17 +0200 mj via samba <samba at lists.samba.org> wrote:> Hi, > > dbcheck tells us we have two "dangling forward links" that I am > trying to get rid of. On my test domain, I have simply done > > ldbedit -e nano -H ./CN=CONFIGURATION,DC=SAMBA,DC=COMPANY,DC=COM > > to remove them. > > While that seems to have worked nicely, dbcheck report zero errors > now, it is something that I should never have done, or do in > production, according to Andrew: > > "We realise this is a difficult problem for you and other users, but > NEVER, EVER do that." > > So, question: is there a SAFE way to easily get rid of those two > "dangling forward links"? > > (they are Replica-Locations for a DC that has been removed years ago) > > MJ >If you need to edit the NCs in sam.ldb.d, use '--cross-ncs' with the ldb command, this allows you safely change things. There have been reports of AD being destroyed by directly editing the ldb's in sam.ldb.d Rowland
On 10/16/2017 11:13 AM, Rowland Penny via samba wrote:> On Mon, 16 Oct 2017 16:53:17 +0200 > mj via samba <samba at lists.samba.org> wrote: > >> Hi, >> >> dbcheck tells us we have two "dangling forward links" that I am >> trying to get rid of. On my test domain, I have simply done >> >> ldbedit -e nano -H ./CN=CONFIGURATION,DC=SAMBA,DC=COMPANY,DC=COM >> >> to remove them. >> >> While that seems to have worked nicely, dbcheck report zero errors >> now, it is something that I should never have done, or do in >> production, according to Andrew: >> >> "We realise this is a difficult problem for you and other users, but >> NEVER, EVER do that." >> >> So, question: is there a SAFE way to easily get rid of those two >> "dangling forward links"? >> >> (they are Replica-Locations for a DC that has been removed years ago) >> >> MJ >> > If you need to edit the NCs in sam.ldb.d, use '--cross-ncs' with the > ldb command, this allows you safely change things. There have been > reports of AD being destroyed by directly editing the ldb's in sam.ldb.d > > Rowland >Mj, You should be able to safely remove those dangling forward links with #samba-tool domain tombstones expunge -- -- James
On Mon, 2017-10-16 at 16:53 +0200, mj via samba wrote:> Hi, > > dbcheck tells us we have two "dangling forward links" that I am trying > to get rid of. On my test domain, I have simply doneAre they breaking anything? If so, can you get me more detail on exactly what breaks?> ldbedit -e nano -H ./CN=CONFIGURATION,DC=SAMBA,DC=COMPANY,DC=COM > > to remove them. > > While that seems to have worked nicely, dbcheck report zero errors now, > it is something that I should never have done, or do in production, > according to Andrew: > > "We realise this is a difficult problem for you and other users, but > NEVER, EVER do that." > > So, question: is there a SAFE way to easily get rid of those two > "dangling forward links"? > > (they are Replica-Locations for a DC that has been removed years ago)Unless the link it also a deleted link (in which case I think we already remove it in dbcheck), as it has been more than the tombstone lifetime, we can't tell that this link is to something that has been long deleted, rather than pointing to an unexpectedly missing object in the directory. I've always been really nervous about removing data during dbcheck, as it can be run in --fix --yes mode. That is, links to objects marked as deleted are easily fixed, but these have been left as 'too hard' for now. I've CC'ed Tim and Garming as Tim has been working on improving our link behaviour, and with Garming we have been discussing the acceptable and un-acceptable failure modes here. 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. 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. Thanks, 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/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
Hi Rowland, On 10/16/2017 05:13 PM, Rowland Penny via samba wrote:> If you need to edit the NCs in sam.ldb.d, use '--cross-ncs' with the > ldb command, this allows you safely change things. There have been > reports of AD being destroyed by directly editing the ldb's in sam.ldb.dLooking at the man page of ldbedit, I see no reference to --cross-ncs Tried:> ldbedit --cross-ncs -e nano -H ./CN=CONFIGURATION,DC=SAMBA,DC=COMPANY,DC=COMbut that gives the ldbedit --help page. MJ