On Mon, 2017-11-20 at 09:42 -0600, Sergei Gerasenko wrote:
> 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 ...
> root. Under than you have "suffixes", like dc=com and
> So we connect those "suffixes" with "mapping trees". Think
> 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
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”.
cn=config is special, that's why :) You should generally ignore it for
these discussions about backends and databases.
> You can really get an idea of this by looking at what's in
> If you look at:
> cd /var/lib/dirsrv/slapd-<inst>/db/userRoot
> dbscan -f id2entry.db | less
> So having your entrycache "as large or larger" than id2entry.db is
> 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?
So if you look at the entries from id2entry you'll notice that they
don't have dn's rdns. IE:
So the entries in id2entry are just the "objects". They are associated
into a tree by the parentid attribute. So for example:
So ou=People has a parent of "entry 1".
The dncache exists to cache these relation ships: because we have to
"walk up" a number of entries to work out entryid -> dn, it's better to
cache this result if we can. Again, this saves accessing id2entry,
which can be a costly operation.
So here, we'd cache entryid: 2 with a dn of ou=People,dc=example,dc=com
Does that help?
Also: do ipa services need to be stopped when using the ipa-backup
I can't answer that I have not used IPA in many years. Please ask the
freeipa-users list for help on that topic, or refer to the
documentation on access.redhat.com
(redhat IDM correlates to FreeIPA).
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
Red Hat, Australia/Brisbane