Bug 7304 - provisioning fails with OpenLDap backend
Summary: provisioning fails with OpenLDap backend
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: x86 Windows XP
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-29 04:52 UTC by Dirk Pauli
Modified: 2010-04-08 16:00 UTC (History)
0 users

See Also:


Attachments
Proposed patch (942 bytes, patch)
2010-03-31 17:16 UTC, Endi Sukma Dewata
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Pauli 2010-03-29 04:52:55 UTC
Hi, using the latest git (commit 0dac5d2ab362c128e184e06a73364bc48f748fd2) against OpenLDap 2.4.21 on Ubuntu 9.10, provisioning a new domain (again) fails:

 sudo ./setup/provision \
> --realm=test.LOCAL --domain=test \
> --server-role='domain controller' \
> --ldap-backend-type=openldap \
> --username=samba-admin \
> --password=PWChanged \
> --adminpass=PWChanged \
> --ldapadminpass=PWChanged \
> --slapd-path='/usr/local/libexec/slapd' 
hdb_db_open: database "cn=Schema,cn=Configuration,dc=test,dc=local": db_o
pen(/usr/local/samba/private/ldap/db/schema/id2entry.bdb) failed: No such file o
r directory (2).
backend_startup_one (type=hdb, suffix="cn=Schema,cn=Configuration,dc=test
,dc=local"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR
Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi'
Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR
Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi'
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=test,DC=local
pdc_fsmo_init: no domain object present: (skip loading of domain details)

Adding configuration container
naming_fsmo_init: no partitions dn present: (skip loading of naming contexts det
ails)

Setting up sam.ldb schema
Reopening sam.ldb with new schema
naming_fsmo_init: no partitions dn present: (skip loading of naming contexts det
ails)

module schema_load initialization failed
module kludge_acl initialization failed
module operational initialization failed
module acl initialization failed
module descriptor initialization failed
module objectclass initialization failed
module asq initialization failed
module server_sort initialization failed
module paged_results initialization failed
module lazy_commit initialization failed
module rootdse initialization failed
module samba_dsdb initialization failed
Unable to load modules for /usr/local/samba/private/sam.ldb: dsdb_load_partition
_usn failed: LDAP error 34 LDAP_INVALID_DN_SYNTAX -  <invalid DN> <>
cancel called but no ldb transactions are active!
cancel called but no ldb transactions are active!
Traceback (most recent call last):
  File "./setup/provision", line 247, in <module>
    nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode,useeadb=eadb)
  File "bin/python/samba/provision.py", line 1307, in provision
    dom_for_fun_level=dom_for_fun_level)
  File "bin/python/samba/provision.py", line 1026, in setup_samdb
    samdb.transaction_cancel()
_ldb.LdbError: (1, 'dsdb_load_partition_usn failed: LDAP error 34 LDAP_INVALID_D
N_SYNTAX -  <invalid DN> <>')
A transaction is still active in ldb context [0xa1ca260] on /usr/local/samba/pri
vate/secrets.ldb
Comment 1 Andrew Bartlett 2010-03-29 05:24:17 UTC
Yeah, this looks like my changes to allow us to detect schema changes.
Comment 2 Endi Sukma Dewata 2010-03-31 17:16:47 UTC
Created attachment 5584 [details]
Proposed patch

The problem happens when the dsdb_module_load_partition_usn() tries to search for @REPLCHANGED entry and receives an Invalid DN Syntax from OpenLDAP.

With TDB backend this problem doesn't happen because the entry was created by the repl_meta_data module. With FDS backend the problem doesn't happen because FDS returns No Such Object which is handled properly by dsdb_module_load_partition_usn().

The proposed patch fixes the code so that it handles the Invalid DN Syntax as well.
Comment 3 Dirk Pauli 2010-04-08 12:57:10 UTC
after applying the proposed patch to the lastest git (8d588e96d964de5db171cfb666feb1dc2f744aad), provisioning was again possible for me.
Comment 4 Matthias Dieter Wallnöfer 2010-04-08 16:00:33 UTC
Abartlet acknowledged the patch and I've pushed it. I'm glad to see this fixed too.