I'm using samba 4.17 and bind 9.18 on debian bookworm. Everything is working fine, except changing/editing dns records. If I create static record with "DNS editor" in RSAT, I can see it in "samba-tool", but not with bind. Registered machines are in both (samba-tool and bind). With lsof I can see, that: * running samba processes are working with ldb files /var/lib/samba/private/sam.ldb and directory /var/lib/samba/private/sam.ldb.d/ * running bind is working with /var/lib/samba/bind-dns/dns/sam.ldb files in directory /var/lib/samba/bind-dns/dns/sam.ldb.d/ So DNS records added with RSAT or samba-tool are not visible for bind and DNS records added with bind are not visible for RSAT and samba-tool. There is configuration option "binddns dir", but it has suitable only to bind_DLZ module. Regardless to configuration bind_DLZ use databases in "dns" subdirectory from this configuration. I don't know, if it is only "debian specific", or samba method, or only my mistake. Why there are 2 different databases? Is it safe to use only one (with symlinks and correct rights)? Are database location hardcoded in samba, or is possible to change them? Thanks, Petr
We have a hard-linked copy of the database in the bind-dns/dns directory to have as restrictive access as possible while allowing two separate users. This is not a solution that we deeply love, but it mostly works. Is it possible your databases became un-hard-linked? Perhaps via some back-up/restore process? If you `ls -l` both sam.ldb.d directories, you should see a "2" in the second column for the DNS partition files: -rw------- 2 ... 'DC=FORESTDNSZONES,...ldb' -rw------- 2 ... 'DC=DOMAINDNSZONES,...ldb' Something like `find /var/lib/samba/ -samefile /var/lib/samba/bind-dns/dns/sam.ldb.d/DC=DOMAINDNSZONES*` will tell you whether the hardlinks link the correct files. See https://bugzilla.samba.org/show_bug.cgi?id=12957 and/or source4/scripting/bin/samba_upgradedns for some context. > Are database location hardcoded in samba, or is possible to change them? I think it is possible to change them at compile time using ./configure --with-bind-dns-dir`, but that probably won't help.
You shouldn't have two databases, bind should use the DNS records in AD, what do you think bind_dlz is for ? If you have the AD dns domains in the bind configuration i.e. in flatfiles, I suggest you remove them. I would also suggest you update to Samba from bookworm-backports, this will get you a Samba supported version.
Hi, thank you. So the correct state is hardlink all files between sam.ldb.d directories? Files sam.ldb are different without hardlink? I can't find this in documentation. I think that Douglas is right and my state is from some backup/restore process. Actual state (with -i is inode number, files are different): # ls -li /var/lib/samba/{private,bind-dns/dns}/sam.ldb 9715777 -rw-rw---- 1 root bind 7942144 Jan 27 2023 /var/lib/samba/bind-dns/dns/sam.ldb 9715795 -rw------- 1 root root 4247552 Jan 18 2023 /var/lib/samba/private/sam.ldb # ls -li /var/lib/samba/{private,bind-dns/dns}/sam.ldb.d/*FORE* 9715782 -rw-rw---- 1 root bind 4247552 Jan 27 2023 /var/lib/samba/bind-dns/dns/sam.ldb.d/DC%3DFORESTDNSZONES%2CDC%3DXXX%2CDC%3DSAMBA.ldb 9715806 -rw-rw---- 1 root bind 4247552 Jan 27 2023 /var/lib/samba/private/sam.ldb.d/DC%3DFORESTDNSZONES%2CDC%3DXXX%2CDC%3DSAMBA.ldb I don't have flatfiles in bind configuration, private domain is only with bind_dlz. Regards, Petr
To get it right you need to link just those two partition files and "metadata.tdb" (plus lock files if you use the lmdb backend). The point is to not let bind see the non-DNS stuff which has more secrets. This is the function that does it, in which you can see the os.link() calls: https://gitlab.com/samba-team/samba/-/blob/master/python/samba/provision/sambadns.py?ref_type=heads#L830 It *should* be possible to use samba_upgradedns to fix things -- probably it is best to move away the /var/lib/samba/bind-dns/ directory first. This will lose any DNS updates that have been done via DNS (as opposed to RPC, LDAP, etc). It will be possible to retrieve these changes from the removed ldb files, but likely not worth the effort. Sorry for the lack of documentation.
(In reply to Douglas Bagnall from comment #4) Hi, thanks for explanation. I'll repair hardlinks (all files in sam.ldb.d directory), some records will be lost, but this is our fault. Regards, Petr
(In reply to Petr Jurasek from comment #5) It sounds like there is something seriously going wrong here, how did the hardlinks get broken ? There is some mention of backup/restore, how was this done ? Was an individual DC backed up and then restored ? Something That shouldn't be done. I personally think the easiest way out of this is to join a new DC and then demote and remove the old one.
(In reply to Rowland Penny from comment #6) Hi, I found that there was an migration with rsync, but I don't have logs. It was few years ago and probably without rsync switch --hard-links :-(. So it's not bug in samba, only our bad process few years ago.