We currently set an upper bounds of 512k max for a buffer. Internally the system can handle more, but we physically cap it to prevent other problems like DoS. The decision to cap it was the result of security reviews.
At the moment that cap is fixed, but considerably larger than the pre-sparks physical limit of 8k. The plan it to eventually add a SMF configuration value to nscd so admins can change the hard coded value to a value that can be updated upon reboot [due to POSIX restrictions]. This will take some additional development in nscd and possibly SMF, that is still TBD. Doug. Nicolas Williams wrote: > On Mon, Sep 29, 2008 at 04:30:17PM -0400, HUGE | Rob Terhaar wrote: >> Hello all, >> >> Appologies if this has been discussed already, but we're having problems >> doing ldap lookups via ldap client to a group in AD with a lot of members. >> We're seeing the following error message in the logs: >> >> Sep 29 16:11:37 nynas1 idmap[320]: [ID 869372 daemon.warning] >> ns_lookup_byname: getgrnam_r(huge-group) failed (Result too large). >> Sep 29 16:11:37 nynas1 smbd[492]: [ID 118120 daemon.error] smb_token_create: >> idmap failed >> >> Is there a way to push this limit up, or increase the cache size? > > Another question for Doug :) Doug? > > Doug, > > idmapd is using getgrnam_r() here as part of name-based ID mapping. > It's looking up the GID of a Unix group that's actually an AD group > being access via nss_ldap w/ schema mapping to the AD SFU schema. > > Evidently the number of members in that group is... too large for > nss_ldap. Is there a workaround? > > Nico > -- _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
