Bug 6141 - idmap ldap backend does not work; can't find idmap/ldap.so
Summary: idmap ldap backend does not work; can't find idmap/ldap.so
Status: RESOLVED DUPLICATE of bug 6286
Alias: None
Product: Samba 3.3
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.3.1
Hardware: x86 Linux
: P3 major
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-25 13:15 UTC by Patrick Diez
Modified: 2009-05-03 02:21 UTC (History)
0 users

See Also:


Attachments
Output of smbd -b (13.13 KB, text/plain)
2009-02-25 14:04 UTC, Patrick Diez
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Diez 2009-02-25 13:15:18 UTC
When built with winbind support and setting up smb.conf and an LDAP directory based on the SambaWiki article "Ldapsam Editposix" (http://wiki.samba.org/index.php/Ldapsam_Editposix) while respecting the changes made to the idmap configuration options as of 3.3 (http://us1.samba.org/samba/history/samba-3.3.0.html), provisioning the LDAP backend using "net sam provision" fails, and the log.winbindd-idmap log file describes the error with:

[<date> <time>, 3] lib/module.c:do_smb_load_module(48)
  Error loading module '/usr/lib/samba/samba/idmap/ldap.so': /usr/lib/samba/samba/idmap/ldap.so: cannot open shared object file: No such file or directory
[<date> <time>, 1] winbindd/idmap.c:idmap_alloc_init(578)
  could not find idmap alloc module ldap

This behaviour is produced in 3.3.0 and 3.3.1, and the same LDAP server was used and originally provisioned with Samba 3.2.8 without problems. The relevant portions of smb.conf are below.

[global]
workgroup = MYDOMAIN
security = user
domain logons = yes
domain master = yes
preferred master = yes
enable privileges = yes

passdb backend = ldapsam:ldap://127.0.0.1/
ldap admin dn = cn=Manager,dc=mydomain,dc=com
ldap suffix = dc=mydomain,dc=com
ldap ssl = no

ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap

ldap passwd sync = yes
ldap delete dn = yes

ldapsam:trusted = yes
ldapsam:editposix = yes

idmap backend = ldap
idmap uid = 10000-19999
idmap gid = 10000-19999

idmap config MYDOMAIN : backend = ldap
idmap config MYDOMAIN : readonly = no
idmap config MYDOMAIN : ldap_base_dn = dc=Idmap,dc=mydomain,dc=com
idmap config MYDOMAIN : ldap_user_dn = cn=Manager,dc=mydomain,dc=com
idmap config MYDOMAIN : ldap_url = ldap://127.0.0.1/

idmap alloc backend = ldap
idmap alloc config : ldap_base_dn = dc=Idmap,dc=mydomain,dc=com
idmap alloc config : ldap_user_dn = cn=Manager,dc=mydomain,dc=com
idmap alloc config : ldap_url = ldap://127.0.0.1/
Comment 1 Simo Sorce 2009-02-25 13:22:48 UTC
Can you post the output of: smbd -b ?
Comment 2 Patrick Diez 2009-02-25 14:04:13 UTC
Created attachment 3957 [details]
Output of smbd -b

This is the output of 'smbd -b' (the build options) from the Arch Linux package samba-3.3.1-1, which has the same bug and is known to be built with the idmap_ldap module.
Comment 3 Simo Sorce 2009-02-25 14:12:57 UTC
Strange, the builtin modules list shows imdap_ldap as compiled in.
Winbindd shouldn't try to open an external shared object for it ...
Comment 4 Patrick Diez 2009-02-25 16:20:07 UTC
It looks like smb_register_idmap_alloc and smb_register_idmap (in winbindd/idmap.c) aren't being called when they should be, so the alloc_backends list is empty when get_alloc_methods is called from line 567 of winbindd/idmap.c. This in turn makes idmap_alloc_ctx->methods NULL at 567, so at 570 it calls smb_probe_module, which is why it ends up looking for a shared library.
Comment 5 Karolin Seeger 2009-05-03 02:21:13 UTC

*** This bug has been marked as a duplicate of bug 6286 ***