Bug 9537 - Corrupted (possibly) index after upgrade from rc6 to 4.0.0
Summary: Corrupted (possibly) index after upgrade from rc6 to 4.0.0
Status: NEW
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.0.0
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-03 21:45 UTC by Stéphane Graber
Modified: 2013-01-27 13:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane Graber 2013-01-03 21:45:14 UTC
I've been running samba 4 since around alpha17, updating from release to release.
At some point I extended the schema to include the sudo schema. Everything worked well until when I updated to 4.0.0.


Below are two ldapsearch queries, the first only for sudoUser=stgraber, properly finding the sudoers record.
The second is the same query but also looking for the sudoRule objectClass, that one returns 0 record.

My current guess is that objectClass is indexed and that index is wrong/corrupted leading to that lookup to return 0 record.

I'm getting the same result on both my samba4 servers and dbcheck seems happy:
root@samba-dc01:~# samba-tool dbcheck
Checking 277 objects
Checked 277 objects (0 errors)

Let me know if you need anything else. I'm also interested in quick workarounds as it's currently preventing me from using sudo on my network...

stgraber@castiana:~/Desktop/sssd$ ldapsearch -H ldap://samba-dc01.stgraber.net -b ou=sudoers,dc=stgraber,dc=net "sudoUser=stgraber"SASL/GSSAPI authentication started
SASL username: stgraber@STGRABER.NET
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <ou=sudoers,dc=stgraber,dc=net> with scope subtree
# filter: sudoUser=stgraber
# requesting: ALL
#

# stgraber, sudoers, stgraber.net
dn: CN=stgraber,OU=sudoers,DC=stgraber,DC=net
objectClass: top
objectClass: sudoRole
cn: stgraber
instanceType: 4
whenCreated: 20120921185401.0Z
whenChanged: 20120921185401.0Z
uSNCreated: 3757
uSNChanged: 3757
name: stgraber
objectGUID:: KOU4Zc3330aJH8QcqrJK5Q==
objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=stgraber,DC=net
sudoUser: stgraber
sudoHost: ALL
sudoCommand: ALL
sudoOption: !authenticate
distinguishedName: CN=stgraber,OU=sudoers,DC=stgraber,DC=net

# search result
search: 5
result: 0 Success

# numResponses: 2
# numEntries: 1
stgraber@castiana:~/Desktop/sssd$ ldapsearch -H ldap://samba-dc01.stgraber.net -b ou=sudoers,dc=stgraber,dc=net "(&(objectClass=sudoRule)(sudoUser=stgraber))"
SASL/GSSAPI authentication started
SASL username: stgraber@STGRABER.NET
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <ou=sudoers,dc=stgraber,dc=net> with scope subtree
# filter: (&(objectClass=sudoRule)(sudoUser=stgraber))
# requesting: ALL
#

# search result
search: 5
result: 0 Success

# numResponses: 1
Comment 1 Stéphane Graber 2013-01-11 21:42:23 UTC
Just spend a few more minutes on the problem. I tried running a reindex with dbcheck without any success, so it seems to be something worse than just a bad index, or dbcheck --reindex doesn't do its job properly :)