On 04/03/2012 08:08 AM, Jan Provaznik wrote:
On 03/30/2012 03:52 PM, Scott Seago wrote:
> Rather than paste in the entire text, I'm just linking to the wiki
> writeup. Please read the whole thing first and if you want to
> comment on anything specific, quote it and comment on this thread.
>
>
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_Permiss...
>
>
>
>
>
> Scott
> In "LDAP Groups" mode we won't pull in all user groups from the LDAP
> server, as there may well be many groups that aren't related to
> Conductor use, so we'll have an "Import LDAP User Group" action,
> analogous to "Create User Group" action for standalone. This will
> bring up a list of LDAP groups exposed by the LDAP server, allowing
> the admin to choose one (or more? -- not sure if we'll allow
> multiple groups at once yet) to import. The UserGroup will be created
> in conductor, with the memberships pulled into Conductor at the same
> time. Any group members that are not yet imported into the Conductor
> database as Conductor users will be pulled in at the same time.
>
"Import LDAP User Group" action implies that an admin has to manually
add a new group in conductor anytime the group is added on LDAP server?
It would be nice to have both user and group lists configurable just by
setting ldap query (in config file).
This is correct. I don't think we want to automatically pull in all LDAP
groups, since most of them will probably be not relevant for Conductor
purposes. We _could_ add a global "automatically import _every_ group
from LDAP" flag at some future point -- it wouldn't really affect much
of the design here, but we don't want that to be mandatory, so we still
need the 'import' feature.
You bring up another point -- we could possibly generate a custom query
to generate the group list. Again this would probably need to be in
addition to the manual import, and possibly not for the first version
here (unless there's a compelling need for it)
> For sync-on-use, the idea is we would store a "last sync
time" every
> time we re-sync group memberships. Any time we make a permissions
> check, the checking code would call a method on Group to refresh if
> necessary (i.e. refresh if last refresh was longer ago than
> $refresh-interval, otherwise return and do nothing).
> Group.refresh_from_ldap_if_necessary would block while checking last
> sync time and (if necessary) while performing the update using an
> ActiveRecord pessimistic lock on the "last refresh time" data element
> in order to prevent more than one web UI front end process (or
> thread) from attempting to re-sync at the same time.
>
-1 for this (+1 for doing this on background), I experienced many
situations when customer's LDAP server was responding too slow.
Typical real-life situation is: LDAP is used for SMTP auth, SMTP
server is overloaded -> LDAP responses are slow. IOW slow LDAP is much
more common then it would be expected.
We have other background tasks anyway, so there is not much additional
work to do this on background.
Jan
OK, yeah performance was my main concern with the sync-on-use. Jay was
more firmly of the opinion that the polling solution was less desirable,
but if slow LDAP server response is going to be a common occurance, I'd
prefer the background polling as well.
Scott