[Building Sakai] adding provided users as local users

[John Bush]

That is an interesting idea, keep that is the back of my mind for other things.

We are going the persistent cache in the provider route, with some
warming done at init time.  For us a failover ldap isn't cheaper,
although we talked about it.  That would quickly lead to us hosting
many different flavors of ldap and learning how to manage all of them.
 We don't want to be in the ldap hosting business.

On Wed, Sep 29, 2010 at 10:02 PM, Casey Dunn <caseyd.stan at gmail.com> wrote:
> Use a quartz job to call a webservice on each member of the server pool.
> Pretty brute force...
> By scanning ur event table u cld even build a population of heavy users and
> tune ur cache pop.
> Wldnt failover in ldap be cheaper?
>
> - sent from my android device
>
> On Sep 29, 2010 1:16 PM, "John Bush" <john.bush at rsmart.com> wrote:
>> yeah, I've been thinking about this. The one issue is that the
>> cache's occur on every app server, so you can use quartz to do this
>> b/c there isn't a way to get a job to run on every app server in a
>> reoccurring way. But I think there are other ways, worth thinking
>> about some more. Basically a persistent cache would do it.
>>
>> On Wed, Sep 29, 2010 at 1:08 PM, Aaron Zeckoski <azeckoski at unicon.net>
>> wrote:
>>> If you have the user ids in Sakai already then you can prime the cache
>>> by calling getUser() for every valid membership in the system (or
>>> every userId in the user ID-EID mapping file if you want to keep it a
>>> little simpler). This won't do you any good if the users never were
>>> entered in the system somehow but that's probably unlikely for many
>>> Sakai installs.
>>>
>>> -AZ
>>>
>>>
>>> On Wed, Sep 29, 2010 at 2:54 PM, John Bush <john.bush at rsmart.com> wrote:
>>>> funny you say that, as that is our backup idea.  The one thing I'm
>>>> worried about with that solution is that users that haven't
>>>> authenticated or accessed via a getUser(s) call wouldn't exist.  I'm
>>>> not sure how bad a problem that is, I'm worried there might be bits of
>>>> code that might not like users suddenly disappearing.
>>>>
>>>> On Wed, Sep 29, 2010 at 12:47 PM, Jim Eng <jimeng at umich.edu> wrote:
>>>>> John,
>>>>>
>>>>> If you want a backup in case LDAP system is unavailable, one approach
>>>>> would be to add a table under the control of your provider.  Each time sakai
>>>>> calls the provider about a user, your provider would update the entry in the
>>>>> table.  Then if LDAP failed, it would just use the info from that table.
>>>>>  Just an idea.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>> On Sep 29, 2010, at 3:43 PM, John Bush wrote:
>>>>>
>>>>>> I'm exploring ways to add provided users as local users in order to
>>>>>> provide a failover in the case of say an ldap system being down.  But
>>>>>> if you try to add a user that is provided, you'll get a
>>>>>> UserAlreadyDefinedException.  If you try to edit a provided user
>>>>>> you'll get a UserNotDefinedException.  Does anyone else do this?  If
>>>>>> the users were created locally first this wouldn't be an issue, but I
>>>>>> can't assure that will be that case.
>>>>>>
>>>>>> --
>>>>>> John Bush
>>>>>> 602-490-0470
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to
>>>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>>>> "unsubscribe"
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> John Bush
>>>> 602-490-0470
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>> "unsubscribe"
>>>>
>>>
>>>
>>>
>>> --
>>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>>>
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>



-- 
John Bush
602-490-0470