Hello,
I am running a LDAP server on a debian system with a mySQL database as backend.
slapd-version: $OpenLDAP: slapd 2.4.11 (Jul 24 2010 08:14:20) $@murphy:/build/buildd-openldap_2.4.11-1+lenny2-i386-H5BDjb/openldap-2.4.11/debian/build/servers/slapd
mysql-version: mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2
Everything is running fine if I am searching the LDAP tree for data containing only one objectClass (inetOrgPerson). Now I have add a second auxiliary objectClass (mozillaAbPersonAlpha) to my data via ldap_entry_objclasses table in the mySQL database, but a search only results in the three inetOrgPerson fields I have set:
ldapsearch -LLL -s sub -b 'ou=contacts,ou=contacts,dc=...' 'objectclass=*' -D 'cn=USER' -w unsafe-password -x dn: ou=contacts,ou=contacts,dc=... objectClass: organizationalUnit objectClass: inetOrgPerson objectClass: mozillaAbPersonAlpha ou: contacts
dn: cn=Name Firstname,ou=contacts,ou=contacts,dc=... objectClass: inetOrgPerson cn: Name Firstname sn: Name givenName: Firstname
If I switch the dependency in the ldap_entries table from inetOrgPerson to the mozilla scheme, I get the mozilla fields but - e.g. in phpldapadmin - I can not see any data (also in my thunderbird addressbook). My opinion: mozilla scheme is not structural.
Perhaps this old mailing-list entry gives an answer but - for me myself - no solution: http://www.openldap.org/lists/openldap-software/200403/msg00303.html
Hope, someone has any idea about this problem ... !? Tanks a lot,
Andreas
My /etc/ldap/slapd.conf file (parts of it): ################################################################# include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/extension.schema include /etc/ldap/schema/mozillaAbPersonAlpha.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 256 modulepath /usr/lib/ldap moduleload back_hdb moduleload back_sql
sizelimit 500 tool-threads 1
backend hdb backend sql
database sql
suffix "ou=contacts,ou=contacts,dc=... dbname contacts dbhost localhost dbuser myuser dbpasswd mypassword lastmod off has_ldapinfo_dn_ru no upper_func "upper"
access to dn.subtree="ou=contacts,ou=contacts,dc=... by dn="cn=admin,dc=..." peername.ip=127.0.0.1 write by dn="cn=user" read by * none #################################################################
I thought about ataching my database entries but this could be too long. If there should be questions about it, please let me know.
Hello,
perhaps better title: can not read attributes of 2nd objectClass via back-sql
UPDATE: Sorry I found one error: but problem still unsolved. the ldap_entry_objclasses entry_id should NOT point to my organizationalUnit field, but to the entry (2nd, see below). SORRY
Two objectClasses: mozillaAbPersonAlpha and inetOrgPerson. Both in ldap_oc_mappings, one of them defined in ldap_entries, other one in ldap_entry_objclasses.
Problem: I get only the values from the attributes belonging to the objectClass defined in ldap_oc_mappings.
Here my new ldapsearch: (here cn,sn,givenname fields belong to inetOrgPerson)
ldapsearch -LLL -s sub -b 'ou=contacts,ou=contacts,dc=...' 'objectclass=*' -D 'cn=USER' -w PASSWORD -x
dn: ou=contacts,ou=contacts,dc=... objectClass: organizationalUnit ou: contacts
dn: cn=NAME Andreas,ou=contacts,ou=contacts,dc=... objectClass: mozillaAbPersonAlpha objectClass: inetOrgPerson c: Deutschland ou: text st: text mail: pager: title: mobile: nsAIMid: birthDay: birthYear: homePhone: birthMonth: postalCode: description: displayName: mozillaCustom1: mozillaCustom2: mozillaCustom3: mozillaCustom4: mozillaHomeUrl: mozillaWorkUrl: mozillaNickname: telephoneNumber: mozillaHomeState: mozillaHomeStreet: mozillaSecondEmail: mozillaWorkStreet2: mozillaHomePostalCode: mozillaHomeCountryName: facsimileTelephoneNumber:
Would it help to post the output from this search with "-d 65535" option? I am not sure if I have found all positions with the password is in this output. But here a small part:
ld 0x9e5a278 response count 0 ldap_chkResponseList ld 0x9e5a278 msgid 1 all 1 ldap_chkResponseList returns ld 0x9e5a278 NULL ldap_int_select read1msg: ld 0x9e5a278 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 TEXT ldap_read: want=6, got=6 TEXT ber_get_next: tag 0x30 len 12 contents: ber_dump: TEXT read1msg: ld 0x9e5a278 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: TEXT read1msg: ld 0x9e5a278 0 new referrals read1msg: mark request completed, ld 0x9e5a278 msgid 1 request done: ld 0x9e5a278 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: TEXT ber_scanf fmt (}) ber: ber_dump: buf=0x9e63d88 ptr=0x9e63d94 end=0x9e63d94 len=0
ldap_msgfree ldap_search_ext put_filter: "objectclass=*" put_filter: default put_simple_filter: "objectclass=*" ldap_build_search_req ATTRS: 2 ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber:
Sorry for second trial, thanks and greetings, Andreas
Am 16.02.2011 02:06, schrieb Andreas Härtel:
Hello,
I am running a LDAP server on a debian system with a mySQL database as backend.
slapd-version: $OpenLDAP: slapd 2.4.11 (Jul 24 2010 08:14:20) $@murphy:/build/buildd-openldap_2.4.11-1+lenny2-i386-H5BDjb/openldap-2.4.11/debian/build/servers/slapd
mysql-version: mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline 5.2
Everything is running fine if I am searching the LDAP tree for data containing only one objectClass (inetOrgPerson). Now I have add a second auxiliary objectClass (mozillaAbPersonAlpha) to my data via ldap_entry_objclasses table in the mySQL database, but a search only results in the three inetOrgPerson fields I have set:
ldapsearch -LLL -s sub -b 'ou=contacts,ou=contacts,dc=...' 'objectclass=*' -D 'cn=USER' -w unsafe-password -x dn: ou=contacts,ou=contacts,dc=... objectClass: organizationalUnit objectClass: inetOrgPerson objectClass: mozillaAbPersonAlpha ou: contacts
dn: cn=Name Firstname,ou=contacts,ou=contacts,dc=... objectClass: inetOrgPerson cn: Name Firstname sn: Name givenName: Firstname
If I switch the dependency in the ldap_entries table from inetOrgPerson to the mozilla scheme, I get the mozilla fields but - e.g. in phpldapadmin - I can not see any data (also in my thunderbird addressbook). My opinion: mozilla scheme is not structural.
Perhaps this old mailing-list entry gives an answer but - for me myself
- no solution:
http://www.openldap.org/lists/openldap-software/200403/msg00303.html
Hope, someone has any idea about this problem ... !? Tanks a lot,
Andreas
My /etc/ldap/slapd.conf file (parts of it): ################################################################# include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/extension.schema include /etc/ldap/schema/mozillaAbPersonAlpha.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel 256 modulepath /usr/lib/ldap moduleload back_hdb moduleload back_sql
sizelimit 500 tool-threads 1
backend hdb backend sql
database sql
suffix "ou=contacts,ou=contacts,dc=... dbname contacts dbhost localhost dbuser myuser dbpasswd mypassword lastmod off has_ldapinfo_dn_ru no upper_func "upper"
access to dn.subtree="ou=contacts,ou=contacts,dc=... by dn="cn=admin,dc=..." peername.ip=127.0.0.1 write by dn="cn=user" read by * none #################################################################
I thought about ataching my database entries but this could be too long. If there should be questions about it, please let me know.
openldap-technical@openldap.org