Bug 5278 - Build system: Dependencies on external libs (here e.g. libldb)
Summary: Build system: Dependencies on external libs (here e.g. libldb)
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Andrew Bartlett
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-24 19:58 UTC by Steve Roylance
Modified: 2008-09-10 11:14 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 Steve Roylance 2008-02-24 19:58:49 UTC
ubuntu server 7.10 with libldb installed caused provision to fail like this:
#
root@# bin/smbpython setup/provision --realm=xxx --domain=xxx ==adminpassword=xxx -server-role='domain controller'
#
set DOMAIN SID: S-1-5-21-2679737394-905568146-2647156769
#
Provisioning for xxx in realm xxx
#
Using administrator password: xxx
#
Setting up smb.conf
#
Setting up share.ldb
#
Setting up secrets.ldb
#
Setting up the registry
#
Setting up templates db
#
Setting up idmap db
#
schema_fsmo_init: no schema dn present: (skip schema loading)
#
naming_fsmo_init: no partitions dn present: (skip loading of naming contexts details)
#
pdc_fsmo_init: no domain dn present: (skip loading of domain details)
#
Setting up sam.ldb attributes
#
Setting up sam.ldb rootDSE
#
schema_fsmo_init: no schema head present: (skip schema loading)
#
naming_fsmo_init: no partitions dn present: (skip loading of naming contexts details)
#
pdc_fsmo_init: no domain object present: (skip loading of domain details)
#
Pre-loading the Samba 4 and AD schema
#
schema_fsmo_init: no schema head present: (skip schema loading)
#
naming_fsmo_init: no partitions dn present: (skip loading of naming contexts details)
#
pdc_fsmo_init: no domain object present: (skip loading of domain details)
#
Adding DomainDN: DC=bits (permitted to fail)
#
Modifying DomainDN: DC=bits
#
Adding configuration container (permitted to fail)
#
Modifying configuration container
#
Adding schema container (permitted to fail)
#
Modifying schema container
#
Setting up sam.ldb Samba4 schema
#
Setting up sam.ldb AD schema
#
Setting up sam.ldb configuration data
#
Setting up display specifiers
#
Adding users container (permitted to fail)
#
Modifying users container
#
Adding computers container (permitted to fail)
#
Modifying computers container
#
Setting up sam.ldb data
#
Setting up sam.ldb users and groups
#
Traceback (most recent call last):
#
  File "setup/provision", line 161, in <module>
#
    ldap_backend_type=opts.ldap_backend_type)
#
  File "bin/../scripting/python/samba/provision.py", line 883, in provision
#
    ldap_backend_type=ldap_backend_type, sitename=sitename)
#
  File "bin/../scripting/python/samba/provision.py", line 694, in setup_samdb
#
    "KRBTGTPASS_B64": b64encode(krbtgtpass),
#
  File "bin/../scripting/python/samba/provision.py", line 135, in setup_add_ldif
#
    ldb.add_ldif(data)
#
  File "bin/../scripting/python/samba/__init__.py", line 170, in add_ldif
#
    self.add(msg)
#
_ldb.LdbError: (1, 'Operations error')
#

un-installing libldb resovled the problem
Comment 1 Matthias Dieter Wallnöfer 2008-04-22 16:18:07 UTC
This is due to the fact, that the system providen libldb is older than the one shipped with SAMBA 4.
A solution would be to check the version number in the provision script.
Comment 2 Matthias Dieter Wallnöfer 2008-06-07 12:40:05 UTC
Andrew, what do you think about my proposition?
Comment 3 Matthias Dieter Wallnöfer 2008-08-08 15:07:25 UTC
Okay, this is a bit a nasty issue. I propose the following:
- When you use a SAMBA 4 packaged version, then the dependencies should be checked by her (incl. "libldb" version). When e.g. "libldb" is too old, you simply aren't able to install the package like it is mostly the case.
- When you use a source version, you should control this yourself, since most of this users should be more comfortable with handling such faults. Another possibility would be a control done by the "configure" script.

If there is some interest to help changing something (e.g. modifying "configure"), please answer! Otherwise I'll close this bug due to lack of participation.
Comment 4 Matthias Dieter Wallnöfer 2008-08-08 15:10:41 UTC
Maybe also Jelmer is interested in following this case.
Comment 5 Andrew Bartlett 2008-08-08 23:04:37 UTC
Yes, we should do some more configure checks.
Comment 6 Matthias Dieter Wallnöfer 2008-09-10 11:14:10 UTC
Seems to be fixed now!