On Tue, 2015-03-17 at 14:06 +0100, Jakub Hrozek wrote:
On Tue, Mar 17, 2015 at 02:02:08PM +0100, Jakub Hrozek wrote:
> On Mon, Mar 16, 2015 at 06:15:07PM -0700, Paul B. Henson wrote:
> > On Mon, Mar 16, 2015 at 09:14:26AM +0100, Jakub Hrozek wrote:
> > > SSSD would download whatever autofs would tell it to..if you increase
> > > debugging in the autofs responder and the domain section you'd see
> > > queries coming from automounter to the autofs responder in the responder
> > > log and the LDAP searches in the domain log.
> > Hmm, I'm not sure how to interpret that.
> What I meant is that sssd only performs LDAP lookups based on what
> queries it receives through the automounter deamon.
> > While we haven't tested with
> > the latest sssd, only the one shipping with RHEL6, I don't see any
> > commits or code changes that would result in different behavior.
> Right, the autofs code is mostly stable.
> > Specifically, the behavior I see is that on startup, sssd tries to
> > download *every* entry in a map. autofs is configured to look at files,
> > then sssd, and the file /etc/auto.master contains:
> > /user auto_user -fstype=nfs4,sec=krb5p,noresvport
> > Here are the queries sssd makes:
> > -----
> > Mar 13 19:04:16 shelley slapd: conn=1333352 op=2 SRCH
> > base="ou=automount,
> > ou=service,dc=csupomona,dc=edu" scope=2 deref=3
> > filter="(&(ou=auto_user)(objectClass=organizationalUnit))"
> > Mar 13 19:04:16 shelley slapd: conn=1333352 op=2 SEARCH RESULT
> > tag=101 err=0 nentries=1 text=
> > -----
> > First, it looks for, and finds, the auto_user map in ldap.
> > -----
> > Mar 13 19:04:16 shelley slapd: conn=1333352 op=3 SRCH
> > base="ou=auto_user,
> > ou=automount,ou=service,dc=csupomona,dc=edu" scope=2 deref=3
> > filter="(&(uid=*)(objectClass=top))"
> > Mar 13 19:04:16 shelley slapd: conn=1333352 op=3 SEARCH RESULT
> > tag=101 err=4 nentries=100 text=
> > -----
> > Next, it tries to download *every* entry in that map. The connection
> > from sssd to ldap is resource restricted, so it only gets the first 100
> > (of the 120000) entries. This is further demonstrated by the sssd log:
> > (Thu Mar 12 18:12:42 2015) [sssd[autofs]] [sysdb_autofs_entries_by_map]
> > (0x2000): found 100 entries for map auto_user
> > At this point, trying to access /user/<username>, where <username>
> > one of the 100 results returned, works fine. Where <username> was not
> > one of the first 100 fails utterly with not found errors.
> > Am I missing something? The behavior I would expect is that a given
> > automount key would be searched for when access was attempted to that
> > directory, ie on demand. That is the behavior autofs exhibits when
> > pointed directly at ldap rather than at sssd. If I try to access
> > /user/fred, an ldap search is made for uid=fred. /user/bob, a search for
> > uid=bob. autofs pointed directly at ldap *never* does a search for
> > uid=*.
> Sorry, I had to go and re-read the autofs LDAP code since we haven't
> touched it in years. Indeed it seems that we download all the keys at
> once. I don't remember why we did that and I didn't realize the plain
> automounter driver does this differently. Maybe we were trying to reduce
> the number of round-trips, I no longer remember that.
> Ian, do you think it would make sense to only fetch keys as they are
> requested by either _sss_getautomntent_r() or _sss_getautomntbyname_r()
> as opposed to fetching them all when _sss_setautomntent() is called?
> Is that how the 'native' ldap integration works?
If an indirect map has the "browse" (or ghost) option the entire map
must be read so the keys are known and can be used to pre-create the
mount point directories. Otherwise autofs tries to only read the map
entry upon lookup and update the entry entry if needed.
Direct maps must always be read completely because the direct mount
triggers must be created for each map entry at startup and refresh.
Direct maps are only updated upon receiving a HUP signal.
What we do now to read an sss autofs map is call setautomntent() and
repeatedly call getautomntent_r() until we get an ENOENT to signify we
have the entire map.
I think we discussed this at the time and, given the cases, decided it
was best for sss to read the entire map and cache it since it might need
to be able to supply the entire map and can't know if that will be the