On Mon, Jul 1, 2013 at 3:02 PM, Prabath Siriwardena <[email protected]>wrote:
> It has to maintain a order - you will authenticate a users in a chain - if > the first fails it will go to the other. why order matters? Idea of authenticating is to check whether the user is the one who claims. If the user is valid it does not matter against which store it matches. Lets say you have two user stores u1 and u2. Now user foo can be in both or one store. if that user in at least one store it will return true irrespective of order to going to check. thanks, Amila. > > Thanks & regards, > -Prabath > > > On Mon, Jul 1, 2013 at 3:01 PM, Amila Suriarachchi <[email protected]> wrote: > >> >> >> >> On Mon, Jul 1, 2013 at 2:38 PM, Prabath Siriwardena <[email protected]>wrote: >> >>> Not quite right.. >>> >>> A given user sore cannot just exist on its own.. it has to maintain the >>> order with others.. >>> >> >> Why you need to keep an order? if you authenticate the users I think it >> does not matter from which store you authenticate as far as users get >> authenticated. >> >> thanks, >> Amila. >> >> >>> That needs to be maintain at the user-mgt.xml.. >>> >>> By breaking this in to separate user-store files only make things >>> complex.. >>> >>> Thanks & regards, >>> -Prabath >>> >>> On Mon, Jul 1, 2013 at 2:27 PM, Pradeep Fernando <[email protected]>wrote: >>> >>>> Hi All, >>>> >>>> >>>> On Tue, Jun 25, 2013 at 4:00 PM, Amila Suriarachchi <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jun 25, 2013 at 3:05 PM, Pushpalanka Jayawardhana < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks all for the ideas. >>>>>> Will be moving forward with option 2. >>>>>> >>>>>> repository/conf/userstores/user-mgt.xml >>>>>> repositoty/conf/tenants/1/userstores/user-mgt.xml - configuration for >>>>>> tenant with tenant-id: 1 >>>>>> repositoty/conf/tenants/2/userstores/user-mgt.xml - configuration for >>>>>> tenant with tenant-id: 2 >>>>>> >>>>> >>>>> Technically speaking this is not correct. User-mgt.xml is used to >>>>> configure UserRealm not only the userstore. So it should be usermanager. >>>>> >>>>> But in this case what we want to dep-synch only the userstores. so my >>>>> suggestion is to put them under userstores folder with the store name. >>>>> >>>>> eg. repository/deployment/server/userstores/userstore1.xml >>>>> repository/deployment/server/userstores/userstore2.xml. >>>>> >>>>> For an example if we change one userstore there is not reason to >>>>> dep-sychn all user-mgt.xml and re initialise all user stores. >>>>> >>>> >>>> Azeez,Amila,me had a chat on the $subject. We have to follow the above >>>> approach it seems. >>>> >>>> Here the additional user-store configs are runtime artifacts and can be >>>> treated in the same way we do other runtime artifacts. User-mgt.xml is a >>>> static config file and it needs not to be dep-synched. >>>> >>>> @Prabath and Pushpalanka; >>>> >>>> Can we achieve the functionality using above method... >>>> >>>> >>>> On technical front, if we try to listen to more than one directory, >>>> things get bit complicated. Specially if you want to do dep-sync for those >>>> directories. Normally we maintain a one dep-sync thread per tenant. If we >>>> listen/dep-sync more than one directory - > two dep-sync thread per tenant. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> thanks, >>>>> Amila. >>>>> >>>>>> >>>>>> So a product will have 2 locations, inside repository/conf to be >>>>>> synced with dep-sync as, >>>>>> >>>>>> - repositoty/conf/userstores ('userstores' just to avoid syncing >>>>>> all content in conf directory) and >>>>>> - repository/conf/tenants >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Pushpalanka Jayawardhana >>>>>> >>>>>> Software Engineer >>>>>> >>>>>> WSO2 Lanka (pvt) Ltd >>>>>> [image: >>>>>> Facebook]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.facebook.com%2Fpushpalanka> >>>>>> [image: >>>>>> Twitter]<http://s.wisestamp.com/links?url=http%3A%2F%2Ftwitter.com%2FPushpalanka> >>>>>> [image: >>>>>> LinkedIn]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.linkedin.com%2Fprofile%2Fview%3Fid%3D75175642%26trk%3Dtab_pro> >>>>>> [image: >>>>>> Blogger]<http://s.wisestamp.com/links?url=http%3A%2F%2Fpushpalankajaya.blogspot.com%2F> >>>>>> [image: >>>>>> SlideShare]<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2FPushpalanka> >>>>>> Mobile: +94779716248 >>>>>> <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Dc984892c0c4ca423%26v%3D3.13.2%26t%3D1361257731639%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 25, 2013 at 11:46 AM, Dhanuka Ranasinghe < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am not much aware about carbon architecture, but have few thoughts >>>>>>> to achieve above requirements. >>>>>>> >>>>>>> 1. Having a high available singleton (HA) service (through MBeans) >>>>>>> then make sure it is active only in master node. >>>>>>> 2. When the master node down one of other member in cluster become a >>>>>>> master node and it's HA service will be activated. >>>>>>> 3. All the configurations done and read through that HA service, by >>>>>>> doing this whether it's UI or local file system change it will be synch >>>>>>> with every time with every member. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Dhanuka >>>>>>> >>>>>>> *Dhanuka Ranasinghe* >>>>>>> >>>>>>> Senior Software Engineer >>>>>>> WSO2 Inc. ; http://wso2.com >>>>>>> lean . enterprise . middleware >>>>>>> >>>>>>> phone : +94 715381915 >>>>>>> >>>>>>> >>>>>>> On Fri, May 31, 2013 at 2:41 PM, Srinath Perera <[email protected]>wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Azeez and myself was chatting, and following are some of the >>>>>>>> conflicting requirements. >>>>>>>> >>>>>>>> 1. like to edit configs from file system, and via UI avoiding two >>>>>>>> copies if possible (have to avoid case where we edit file, then we >>>>>>>> edit via >>>>>>>> UI where we lost the file updates). >>>>>>>> 2. Need a way to sync configs across the cluster >>>>>>>> 3. Make the sync model clear and consistent for both configs and >>>>>>>> artifacts (currently we use dep-sync only with artifacts) >>>>>>>> 4. Like to sync only one folder in the product with dep-sync >>>>>>>> >>>>>>> ^This will not be achieved, with the option. >>>>>> >>>>>>> 5. We should not do product folder structure before major release >>>>>>>> (C5?) >>>>>>>> >>>>>>>> We need to find the best solution out of that. >>>>>>>> >>>>>>>> --Srinath >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 30, 2013 at 9:20 PM, Senaka Fernando >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi Srinath, >>>>>>>>> >>>>>>>>> IMHO, relying on a dep-sync-based model sounds appropriate here. >>>>>>>>> We can have several strategies for dep-sync (i.e. registry, svn, >>>>>>>>> manual >>>>>>>>> etc), but the server will be driven by what's on the filesystem. IMHO, >>>>>>>>> that's very straightforward. >>>>>>>>> >>>>>>>>> And, I think we need to first of all figure out what and what's >>>>>>>>> going to be sync'ed and what's not. When it comes to some >>>>>>>>> configuration >>>>>>>>> files it might make sense to sync portions and keep some static. In >>>>>>>>> that >>>>>>>>> case, do we need to split those files in two? Also, we need to focus >>>>>>>>> on the >>>>>>>>> "things that change across environments and things that don't" for the >>>>>>>>> sever configuration as in the "CAR-based Governance Story" for ESB >>>>>>>>> configurations. >>>>>>>>> >>>>>>>>> Also, the dep-sync's notification model should work like the >>>>>>>>> hierarchical cache invalidation model that Azeez proposed, making >>>>>>>>> sure that >>>>>>>>> things will scale. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Senaka. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, May 30, 2013 at 4:46 PM, Jeewantha Dharmaparakrama < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Srinath, >>>>>>>>>> >>>>>>>>>> If the node which detects the change in its config file redeploys >>>>>>>>>> the config in every other node explicitly, we can ensure that every >>>>>>>>>> node >>>>>>>>>> sees the change since there will always be one node which is >>>>>>>>>> responsible in >>>>>>>>>> informing the others. I guess thats what depsync does IINM. >>>>>>>>>> >>>>>>>>>> If the config is stored in a central place, every node will have >>>>>>>>>> to pull the change from that place. Here if one node fails to >>>>>>>>>> redeploy the >>>>>>>>>> change, other nodes will be unaware about it so that the system will >>>>>>>>>> be >>>>>>>>>> unstable. IMHO we should prefer the former. >>>>>>>>>> >>>>>>>>>> Jeewantha >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, May 30, 2013 at 3:44 PM, Srinath Perera <[email protected] >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> We just finished a review on UI for user stores and figured we >>>>>>>>>>> are doing this in several ways. Pradeep, Prabath, and myself had a >>>>>>>>>>> chat, >>>>>>>>>>> and following are our thoughts. >>>>>>>>>>> >>>>>>>>>>> We have different types of configurations with carbon server >>>>>>>>>>> >>>>>>>>>>> 1) Some are only apply for one node (e.g. carbon.xml, >>>>>>>>>>> registry.xml ..) >>>>>>>>>>> 2) Some might be useful across a cluster, but we ask users to >>>>>>>>>>> copy it to all the nodes (e.g. data sources, xacml policies, >>>>>>>>>>> keystores ?? ) >>>>>>>>>>> 3) It is proposed that we will automatically replicate >>>>>>>>>>> user-store configurations using deployment synchronizer when it is >>>>>>>>>>> added to >>>>>>>>>>> one node. >>>>>>>>>>> >>>>>>>>>>> To share the same configurations across all nodes in the >>>>>>>>>>> cluster, we have several options. >>>>>>>>>>> >>>>>>>>>>> 1) We can have a config files, and use deployment sync to sync >>>>>>>>>>> them across the cluster (Then, I think we need to have a cluster >>>>>>>>>>> folder in >>>>>>>>>>> conf or make clear what configurations are replicated). >>>>>>>>>>> >>>>>>>>>>> 2) We have a config file, but once read, we store them in a DB >>>>>>>>>>> or in registry, since all nodes share same DB/ registry there is no >>>>>>>>>>> need to >>>>>>>>>>> replication (we can send a cluster message saying there is a >>>>>>>>>>> update). Risk >>>>>>>>>>> of this is after bring edited by UI and directly via the file, two >>>>>>>>>>> sources >>>>>>>>>>> might go out of sync and some updates can be lost when next update >>>>>>>>>>> happend. >>>>>>>>>>> >>>>>>>>>>> 3) Data sources can be added via UI (goes to registry) or via >>>>>>>>>>> file system (not replicated), which is a mix. >>>>>>>>>>> >>>>>>>>>>> I think we need to stick to one model out of #1 and #2. We >>>>>>>>>>> thought dep sync model is the best as it is clear. But then we have >>>>>>>>>>> to tell >>>>>>>>>>> which part of the configs get replicated. >>>>>>>>>>> >>>>>>>>>>> WDYT? >>>>>>>>>>> >>>>>>>>>>> --Srinath >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> ============================ >>>>>>>>>>> Srinath Perera, Ph.D. >>>>>>>>>>> Senior Software Architect, WSO2 Inc. >>>>>>>>>>> Visiting Faculty, University of Moratuwa >>>>>>>>>>> Member, Apache Software Foundation >>>>>>>>>>> Research Scientist, Lanka Software Foundation >>>>>>>>>>> Blog: http://srinathsview.blogspot.com/ >>>>>>>>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>>>>>>>> Phone: 0772360902 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jeewantha Dharmaparakrama >>>>>>>>>> Software Engineer; WSO2, Inc.; http://wso2.com/ >>>>>>>>>> Phone : (+94) 774726790 >>>>>>>>>> Skype : prasad.jeewantha >>>>>>>>>> LinkedIn : http://www.linkedin.com/in/jeewanthad >>>>>>>>>> Twitter: https://twitter.com/jeewamp >>>>>>>>>> Blog: http://jeewanthad.blogspot.com/ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Senaka Fernando* >>>>>>>>> Member - Integration Technologies Management Committee; >>>>>>>>> Technical Lead; WSO2 Inc.; http://wso2.com* >>>>>>>>> Member; Apache Software Foundation; http://apache.org >>>>>>>>> >>>>>>>>> E-mail: senaka AT wso2.com >>>>>>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>>>>>>> Linked-In: http://linkedin.com/in/senakafernando >>>>>>>>> >>>>>>>>> *Lean . Enterprise . Middleware >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ============================ >>>>>>>> Srinath Perera, Ph.D. >>>>>>>> Director, Research, WSO2 Inc. >>>>>>>> >>>>>>>> Visiting Faculty, University of Moratuwa >>>>>>>> Member, Apache Software Foundation >>>>>>>> Research Scientist, Lanka Software Foundation >>>>>>>> Blog: http://srinathsview.blogspot.com/ >>>>>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>>>>> Phone: 0772360902 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Amila Suriarachchi* >>>>> >>>>> Software Architect >>>>> >>>>> WSO2 Inc. ; http://wso2.com >>>>> lean . enterprise . middleware >>>>> >>>>> phone : +94 71 3082805 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Pradeep Fernando* >>>> Associate Technical Lead;WSO2 Inc.; http://wso2.com >>>> >>>> blog: http://pradeepfernando.blogspot.com >>>> m: +94776603662 >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> >> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://RampartFAQ.com > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
