Bug 14097 - Samba bug when running dbcheck.
Summary: Samba bug when running dbcheck.
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Build (show other bugs)
Version: 4.10.8
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-21 02:41 UTC by Zombie Ryushu
Modified: 2019-10-09 20:41 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zombie Ryushu 2019-08-21 02:41:41 UTC
hecking 312 objects
ERROR(<type 'exceptions.ValueError'>): uncaught exception - unable to parse dn string
  File "/usr/lib64/python2.7/site-packages/samba/netcmd/__init__.py", line 185, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/samba/netcmd/dbcheck.py", line 163, in run
    controls=controls, attrs=attrs)
  File "/usr/lib64/python2.7/site-packages/samba/dbchecker.py", line 254, in check_database
    error_count += self.check_object(object.dn, attrs=attrs)
  File "/usr/lib64/python2.7/site-packages/samba/dbchecker.py", line 2509, in check_object

        expected_dn = ldb.Dn(self.samdb, "RDN=RDN,%s" % (parent_dn))

This is the result of running samba-tool dbcheck.
Comment 1 Louis 2019-08-21 10:06:27 UTC
Please post your running OS and smb.conf.
Comment 2 Zombie Ryushu 2019-08-21 10:48:25 UTC
Rosa Linux 2016.1

# Global parameters
[global]
	netbios name = OLYMPIA
	realm = PUKEY
	server role = active directory domain controller
	workgroup = PUKEY-NT
	idmap_ldb:use rfc2307 = yes
	server services = s3fs, rpc, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc
	min protocol = NT1
	ntlm auth = yes
	domain logons = yes
	domain master = yes
	os level = 40
	preferred master = yes


[netlogon]
	path = /var/lib/samba/sysvol/pukey/scripts
	read only = No

[sysvol]
	path = /var/lib/samba/sysvol
	read only = No

[homes]
comment = Home Directories
read only = No
create mask = 0700
directory mask = 0700
guest ok = no


[pdf-gen]
comment = PDF Generator (only valid users)
path = /var/tmp
printable = Yes
printing = bsd
print command = /usr/share/samba/scripts/print-pdf "%s" "%H" "//%L/%u" "%m" "%I" "%J" &
lpq command = /bin/true
lprm command = lprm -P'%p' %j

[printers]
comment = All Printers
path = /var/spool/samba
create mask = 0700
guest ok = Yes
printable = Yes
browseable = No

[print$]
path = /var/lib/samba/printers
write list = @adm, root
inherit permissions = Yes
guest ok = Yes
Comment 3 Louis 2019-08-21 11:03:07 UTC
Hai. 

You smb.conf is not correct. 

These settings are for a NT4-Style PDC/BDC setup. 
    domain logons = yes
    domain master = yes
    os level = 40
    preferred master = yes

Your config shows your running an : active directory domain controller
Remove the above 4 paramters, stop and start samba. 

And try again.
Comment 4 Zombie Ryushu 2019-08-21 11:35:25 UTC
I removed the configuration parameters and restarted Samba. The result was the same. 

This problem is also preventing replication from working.
Comment 5 Louis 2019-08-21 13:41:31 UTC
This might be a resolving issue, please post: 

cat /etc/hosts 
cat /etc/resolv.conf

nslookup $(hostname -d)

nslookup -query=NS $(hostname -d) ip_of_DC
nslookup -query=_kerberos $(hostname -d) ip_of_DC
nslookup -query=_ldap $(hostname -d) ip_of_DC
Comment 6 Zombie Ryushu 2019-08-21 13:56:21 UTC
nslookup -query=NS $(hostname -d)
 $ nslookup -query=NS $(hostname -d) 192.168.0.4
Server:         192.168.0.4
Address:        192.168.0.4#53

4.0.168.192.in-addr.arpa        name = olympia.pukey.
 nslookup -query=_kerberos $(hostname -d) 192.168.0.4
unknown query type: _kerberos
4.0.168.192.in-addr.arpa        name = olympia.pukey.

$ nslookup -q=SRV _ldap._tcp.pukey
Server:         192.168.0.4
Address:        192.168.0.4#53

_ldap._tcp.pukey        service = 1 0 389 kefka.pukey.
_ldap._tcp.pukey        service = 0 0 389 olympia.pukey.

$ nslookup -q=SRV _kerberos._tcp.pukey
Server:         192.168.0.4
Address:        192.168.0.4#53

_kerberos._tcp.pukey    service = 0 0 88 olympia.pukey.
_kerberos._tcp.pukey    service = 0 0 88 kefka.pukey.
Comment 7 Louis 2019-08-21 14:20:46 UTC
it looks like your missing DNS info for the other DC. 

You forgot these : 
cat /etc/hosts 
cat /etc/resolv.conf

nslookup $(hostname -d)
i would have expected : 
 nslookup -query=NS $(hostname -d)
Server:         192.168.1.1
Address:        192.168.1.1#53

my.domain.tld     nameserver = dc1.my.domain.tld.
my.domain.tld     nameserver = dc2.my.domain.tld.


If this, olympia, is the second DC, and kefka the one with FSMO roles. 

I suggest you verify you server A PTR and NS records. 
set you resolving as followed. 

DC1 (DC with FSMO roles )
resolv.conf first resolver. 
nameserver IP_THIS_DC_WITH_FSMO
nameserver IP_OTHER_DC

And same on the second DC. 
Now reboot DC1, and wait a few min, then reboot DC2, and wait a few min. 

Now check you replication again. 
Once the replicaion is correct and in sync, then change the resolv.conf of DC2 to : 
nameserver IP_OTHER_DC
nameserver IP_THIS_DC_WITH_FSMO
Comment 8 Zombie Ryushu 2019-08-21 14:35:44 UTC
$ cat /etc/resolv.conf
# Generated by NetworkManager
search pukey
nameserver 192.168.0.4
nameserver 192.168.0.3

search pukey
127.0.0.1 localhost
192.168.0.4 olympia.pukey olympia

My DNS Setup is fine, this is a Database corruption issue.

$ nslookup -q=SRV _kerberos._tcp.pukey 192.168.0.3
Server:         192.168.0.3
Address:        192.168.0.3#53

_kerberos._tcp.pukey    service = 0 0 88 olympia.pukey.
_kerberos._tcp.pukey    service = 0 0 88 kefka.pukey.

$ nslookup -query=NS $(hostname -d) 192.168.0.3
Server:         192.168.0.4
Address:        192.168.0.4#53

3.0.168.192.in-addr.arpa        name = kefka.pukey.
Comment 9 Andrew Bartlett 2019-08-22 23:22:36 UTC
(In reply to Louis from comment #5)
samba-tool dbcheck is a local operation and is not impacted by name resolution. 

This issue is related entirely to the name parsing, which should really be improved. 

I have a patch for this issue here:
https://gitlab.com/samba-team/samba/merge_requests/289

I didn't get time to add the required tests for the second patch so this MR has not progressed.
Comment 10 Andrew Bartlett 2019-08-22 23:25:22 UTC
(In reply to Louis from comment #3)
Thankfully these are totally ignored in the AD DC, so have no impact on the server.
Comment 11 Zombie Ryushu 2019-10-08 10:31:42 UTC
I just updated to Samba 4.10.8 and this issue persists.
Comment 12 Zombie Ryushu 2019-10-09 09:58:06 UTC
Update: A patch was included in my Downstream build that fixes the dhcheck issue:

https://gitlab.com/samba-team/samba/merge_requests/289

This patch works as advertised. 

As far as I can tell, I get two different results on each AD DC.

On DC1
Checking 313 objects
Checked 313 objects (0 errors)

on DC2
Checking 312 objects
Checked 312 objects (0 errors)

Trying to find out why there is an inconsistency.

upon running samba-tool drs showrepl, I get the following result:

                DSA object GUID: a35b2245-3340-4182-aaf8-dd344725805e
                Last attempt @ Wed Oct  9 04:06:37 2019 EDT failed, result 2 (WERR_FILE_NOT_FOUND)
                16144 consecutive failure(s).
                Last success @ Wed Aug 14 01:19:23 2019 EDT

This replication error is occuring.