Hi William, So to really answer that I should explain the LDAP data model.
You have a set of objects, in a tree database. The RootDSE (you can
search with -b '' -s base by the way with ldapsearch) is the ... well,
root. Under than you have "suffixes", like dc=com and
dc=example,dc=com.
Confirmed So we connect those "suffixes" with "mapping trees". Think "routers"
that connect a suffix to a backend of some kind.
Then that backend stories entries: that's the "userRoot". It's a
backend which is connected by a mapping tree to route queries to it.
Ok, so when issue requests for entries under dc=example,dc=com and they get translated by a mapping tree to a physical db file. I noticed that if I specify the base dn as “cn=config”, I don’t see user account data for example. When I bind under “dc=example,dc=com” however, I do! Is that because when I bind under cn=config, I don’t go through a mapping tree, but when I bind with "dc=example,dc=com” I do? I of course use our company name instead of “dc=example,dc=com”.
You can really get an idea of this by looking at what's in "userRoot".
If you look at:
cd /var/lib/dirsrv/slapd-<inst>/db/userRoot
dbscan -f id2entry.db | less
Nice So having your entrycache "as large or larger" than id2entry.db is a
great idea, because then you never need to incur the performance
penalty of accessing id2entry.
Great info again. Quick question though. There are at least two types of cache I’ve seen: the entry cache, and the dn cache. I think the entry cache corresponds to id2entry.db, right? What corresponds to the dn cache?
Also: do ipa services need to be stopped when using the ipa-backup utility?
Thanks again, Sergei |
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
