On Mon, 2017-11-20 at 09:42 -0600, Sergei Gerasenko wrote: > 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”. 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 > > "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? So if you look at the entries from id2entry you'll notice that they don't have dn's rdns. IE: uid=william Rather than: uid=william,ou=People,.... So the entries in id2entry are just the "objects". They are associated into a tree by the parentid attribute. So for example: dc=example,dc=com entryid: 1 ou=People parentid: 1 entryid: 2 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 > utility? 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). > > Thanks again, > Sergei > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o > rg -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
