I have cc'd the sparks-discuss alias so others can participate in this discussion as well.
As I read this thread, this is a request to extend naming services to provide a configurable on-disk cache of naming service data. I say configurable, because we have had a couple of requests for an on-disk cache to provide better response to naming data when the network services are down, but this is the first we have seen of a request to potentially download an entire LDAP DIT for mobile caching and to enable disconnected activity of this sort. This request of course has the potential of caching & managing (literally) gigabytes of data and 100,000's of entries (at least in large configurations that we are aware of) on a mobile box. With the delivery of the sparks project, we now have the potential in naming services to deliver an on disk cache but we have not scoped out the effort at this time. Beyond the basics of caching the contents of obvious name lookup data there are the login amd pam considerations that are not easily addressed. In sparks per-user mode, pam_krb is required, implying the need to have an active kerberos kdc etc. in order to login, and potentially that kdc might require a directory server. Likewise, if pam_ldap is deployed login authentication is done in the directory server not on the client, so no amount of caching of the directory data will enable a login in a disconnected environment, unless the mobile environment is, for instance, running the directory server in a zone on the box. Running a local directory server may be more suitable for your needs and it requires no additional modification of Solaris (Nevada or s10u4) today. I current have a toshiba m5 running SNV_65 on my desk that is configured with: the global zone running in a files only mode, using NWAM & punchin to allow me to switch between my wireless or LAN connection & run either on my home LAN or on Sun's internal VPN. I also have: 1 zone running a JES DS 6.0 DS server that I can boot as needed 1 zone setup as an LDAP client used for testing various LDAP environments and I create/destroy other zones for NIS, NIS+ or other testing as needed. Currently my DS 6.0 server has a minimal testing DIT, but it could if I chose (and IT agreed) :) be configured to be a replica of a much larger environment. IE in theory I could configure the DS to replicate the entire Sun naming service DIT or some subtree needed for mobile use downloading the entire naming environment or some subportion as desired. When needed, I either boot the needed zones for LDAP usage and/or potentially I could configure global zone to use the local DS for naming lookups. Since JES DS has a pretty sophisticated replication environment, I'm sure it can be configured to synchronize with the DS master when the mobile unit decides to do a pull type operation (by manual intervention) or at some periodic interval when a connection to the master can be made. The machines LDAP configuration could be set up to either use the master DS as the primary and the local DS as the fallback or the reverse depending on the desires of the situation. Thereby making the local DS either a secondary service or a local cache. I defer the to TX team about how/if such a configuration could be enabled when TX is enabled, because I know zones in TX are behaviorally different than zones out of TX, but I suspect with some thought and potentially a whole lot less work, this solution might deliver what is needed today, versus at some point in the future when we might be able to complete an on-disk DB cache solution in naming. I hope that helps, Doug. This message posted from opensolaris.org
