[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd-meta



It may well be that the qmail* tool returns "no such object" because that is the return code that comes from back-meta; back-meta used to have some return-code issues when something strange occurred when processing different targets. It should be cured now, but you may have found another. From your slapd.conf, you seem to be using just one target. Then, why don't you use back-ldap, which should be much more robust? For the cache problem, you don't have any proxyAttrset referred to by the proxyTemplate "(&(cn=)(objectClass=))" that contains the attribute "ldapbasedn" yourclient appears to be looking for. If you read the slapo-pcache(5) document, you'll see that only EXACT filters and attribute sets are cached and then answered.

p.

Turbo Fredriksson wrote:

I'm having a second go at trying to get slapd-meta to work...

Using the following in my slapd.conf (this is not all of it,
just the relevant parts), I can successfully search the local
server (which using database meta) with 'ldapsearch' (using
GSSAPI _and_ SIMPLE binds):

----- s n i p -----
database                meta
suffix                  "c=SE"
uri                     "ldap://master:389/c=SE";
lastmod                 off
rebind-as-user
#
overlay                 proxycache
proxyCache              bdb 1000 4 10 300
cachesize               2000
directory               /var/lib/ldap
#
proxyAttrset            0 mail mailAlternateAddress mailAlternateAddress mailForwardingAddress
proxyAttrset            0 accountStatus mailHost mailMessageStore mailQuotaSize mailQuotaCount mailSizeMax
proxyAttrset            0 deliveryProgramPath deliveryMode mailReplyText qmailDotMode objectClass
proxyAttrset            0 uid uidNumber gidNumber cn gecos homeDirectory loginShell
proxyAttrset            1 uid uidNumber gidNumber loginShell gecos homeDirectory
proxyAttrset            2 krb5PrincipalName userPassword
proxyAttrset            3 locals rcptHosts ldapBaseDN ldapObjectClass ldapRebind ldapUid ldapGid
proxyAttrset            3 ldapDefaultDotMode defaultQuotaSize defaultQuotaCount ldapLocalDelivery
proxyAttrset            3 ldapCluster dirMaker
#
proxyTemplate           (|(mail=)(mailAlternateAddress=)) 0 3600
proxyTemplate           (uid=) 1 3600
proxyTemplate           (uidNumber=) 1 3600
proxyTemplate           (gidNumber=) 1 3600
proxyTemplate           (krb5PrincipalName=) 2 43200
proxyTemplate           (&(cn=)(objectClass=)) 3 43200
#
index                   uid,uidNumber,gidNumber eq,pres
index                   objectClass,cn,sn,mail,mailAlternateAddress eq
index                   mailForwardingAddress,zoneName,relativeDomainName eq
index                   trustModel,accessTo,krb5PrincipalName,memberUid eq
index                   locals,rcptHosts eq
----- s n i p -----

However, using QmailLDAP/Controls command (qmail-ldaplookup), I do NOT get
any values:

----- s n i p -----
proxy:/var/lib/ldap# qmail-ldaplookup -m turbo@bayour.com
Searching ldap for: (|(mail=turbo@bayour.com)(mailAlternateAddress=turbo@bayour.com))
below dn:
qmail-ldaplookup: fatal: qldap_filter: no such object
----- s n i p -----

If I instead specify to use the master as LDAP server, it works fine...

Running 'slapd' with '-d -1' shows that the user I'm (QmailLDAP/Controls)
authenticates as DO get 'read access granted'. Using the same bind DN and
password with 'ldapsearch' WILL get me the desired object, with the exception

----- s n i p -----
No such object (32)
----- s n i p -----

on the very end. I've tried to look at the debug output from slapd, but I can't
find what's causing this.

On the proxy, I have 'access to * by * read' just in case (and for testing) and
on the master I'm using (correct to my knowledge) ACI's.


Also, it seems like 'slapd' isn't actually caching anyting. Using 'strings' on 'id2entry.bdb' will not get me anything and the indexes isn't created.

Looking closer at the debug output on the proxy, I see that it's binding
correctly/successfully (mech=SIMPLE ssf=0). However, the search base seems
empty!

----- s n i p -----
SRCH "" 2 0    0 0 0
[...]
conn=0 op=1 SRCH base="" scope=2 deref=0 filter="(&(cn=proxy)(objectClass=qmailControl))"
conn=0 op=1 SRCH attr=ldapbasedn
==> limits_get: conn=0 op=1 dn="<QmailLDAP/Controls bind DN>"
query template of incoming query = (&(cn=)(objectClass=))
QUERY NOT ANSWERABLE
QUERY NOT CACHEABLE
=>meta_back_getconn: conn 0 fetched
[rw] searchBase: "c=SE" -> "c=SE"
[rw] searchBase: "(&(cn=proxy)(objectclass=qmailControl))" -> "(&(cn=proxy)(objectclass=qmailControl))"
----- s n i p -----

I get the same (.*SRCH.*) lines when I use 'ldapsearch', so it seems like that's
ok... This is where I'm stuck. From first glance, I'm missing an ACL/ACI somewhere,
but I can't figure out where. Just as a quick test, I put 'access to * by * read'
on the master as well, with no change...


Oh, and the /var/lib/ldap/DB_CONFIG file looks like this (if this matters):

----- s n i p -----
set_cachesize 0 52428800 3
set_lg_regionmax 1048576
set_lg_max 10485760
set_lg_bsize 2097152
set_lg_dir /var/log/openldap
set_tmp_dir /var/tmp
----- s n i p -----







SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497