Re: Using back-ldap as a client-side proxy/cache

[Ryan Steele <ryans@aweber.com>]

Howard Chu wrote:
> Ryan Steele wrote:
>> Hey folks,
>>
>> In order to provide stability to my OpenLDAP clients in the event of a
>> network outage, I would like to implement some client-side caching. 
>> I've done some research, and have concluded that nscd is evil and 
>> should be avoided at all costs,
> 
> It's not necesarily evil, it just doesn't work...
>

Well, to me it's one and the same if it affects my service availability.  :)

>> and thus eventually settled on using back-ldap as a proxy and caching
>> mechanism on the clients.
> 
> And just to be clear, back-ldap is only a proxy. For caching support you
> must add the pcache overlay.
> 
>> Ideally, clients would query a local cache first, and if the 
>> information was not available, back-ldap would then forward the 
>> connection on to my root OpenLDAP  server(s).
> 
> That's exactly what back-ldap+pcache will do.
> 

Yeah, I think I've settled on using libnss-ldapd/nslcd + back-ldap + pcache.  I would like to get nssov involved too,
but it's not clear to me from the available documentation whether nssov is to be used in conjunction with pcache or
instead of pcache.  It almost seemed like nssov would be most suitable on the server side of things, whereas pcache was
geared more towards client-side back-ldap setups.  Am I misinterpreting anything there?  If not, would anybody care to
expound on that subject a little to provide some framing context?

>> However, I didn't see much information in the admin guide with respect 
>> to such configurations other than a reference to the back-ldap man page,
>> and given that I've got no real experience with setting up back-ldap, I
>> was wondering if somebody who did/does would have some recommendations,
>> advice, or knew of a good documentation source describing this sort of 
>> setup?
> 
> Generally there's not much to set up. back-ldap needs whatever
> information any client would need to communicate successfully with the
> remote LDAP server.
>

That's what I was starting to gather, but I'm still trying to figure out exactly what's supported since it's only a
proxy.  In particular, there doesn't seem to be many examples of folks using ACL's in their back-ldap configs, so I
still want to make sure that the contents of the client-side cache are subject to the same visibility restrictions
imposed on the server.  To that end, if someone could confirm that the ACL syntax available in fully-fleshed out
back-hdb slapd installations is available (in its entirety) in back-ldap configurations, I would be most appreciative.

>> The other question I have is that it seems most people use back-ldap with
>> a slapd.conf-style configuration, versus a cn=config type of setup. In
>> this sort of circumstance, where one is not configuring a full-on 
>> OpenLDAP server/replica, that seems like it might be a good thing in the
>> interest of keeping the client configurations simple. Nonetheless, I
>> wanted to verify that it was the recommended way, since slapd.conf (in
>> the context of a fully fleshed-out OpenLDAP server) is deprecated.
> 
> It only seems that most are using slapd.conf because cn=config is new
> and most sites with existing slapd.conf deployments haven't migrated to
> cn=config yet. For new installs, just use cn=config.
> 

Gotcha, thanks for clarifying, Howard.


Respectfully,
Ryan