Hi, Why not use client auth? Java SSL X509 specification supports client authentication (keystore on client, truststore on server). There seems to be a SASL implementation for Apache Thrift (Java) [1]. Haven't used it personally but worth a shot.
Having to manually specify credentials makes dynamic service discovery completely useless. [1] https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/transport/TSaslClientTransport.java Thanks. On Mon, May 30, 2016 at 12:02 PM, Gokul Balakrishnan <[email protected]> wrote: > Hi, > > Yes, I was working on this, and the idea is to use TCP multicast to > establish connection settings. The issue however is that in order for the > connection to be fully established, the Thrift auth information is also > needed. Since this obviously shouldn't be multicast, we'll have to get the > user to manually specify the credentials after the connection parameters > for the Thrift server have been set (i.e. we won't be achieving the goal of > zero configuration). > > We could overcome this by keeping the admin/admin credentials static, but > naturally this would only cater to demo scenarios. On the other hand, we > could accomplish such kind of scenarios by simply keeping the analytics > server on a known port offset and keeping a static configuration (i.e. a > single-node demo scenario). In this respect, what would be the aim of this > functionality? For demo setups, we can more easily achieve this through > static configurations and a known port offset, and fully-fledged multi-node > setups where this would be more useful, would invariably have non-default > username/passwords which we will have to maintain a separate configuration > file to set up. > > I apologize that I was not able to start this conversation up earlier, > since we'd had to handle other priorities that had popped up, such as the > ESB Analytics release tasks. > > Thanks, > > On 30 May 2016 at 10:58, Anjana Fernando <[email protected]> wrote: > >> Hi Srinath, >> >> Yeah, we were doing some work on this, first Malith, and then Gokul. But >> due to other priorities we had with the work, we couldn't work on it much. >> And we were faced with some issues in how the configuration was done with >> it. Where we were thinking of doing some further discussions with it, on >> how practical it would be. For example, if we auto discover servers, we >> would only get the server locations, and obviously not the user credentials >> to talk with those server. We can only maybe provide default admin >> credentials we put to the server out of the box, and make the user edit a >> configuration file, which will make the concept of making the setup easier >> diminish a bit. >> >> Anyways, @Gokul, can you please give an update onto which extent we did >> this work. >> >> Cheers, >> Anjana. >> >> On Mon, May 30, 2016 at 10:48 AM, Srinath Perera <[email protected]> >> wrote: >> >>> Anjana, Have we done this? >>> >>> I think Gokul started working on this. >>> >>> --Srinath >>> >>> On Sat, Feb 20, 2016 at 6:03 PM, Nirmal Fernando <[email protected]> >>> wrote: >>> >>>> There's a library called JmDNS http://jmdns.sourceforge.net/index.html >>>> which would probably help us here. >>>> >>>> JmDNS is a Java implementation of multi-cast DNS and can be used for >>>> service registration and discovery in local area networks. JmDNS is fully >>>> compatible with Apple's Bonjour >>>> <http://developer.apple.com/macosx/rendezvous/>. >>>> >>>> The Zeroconf <http://www.zeroconf.org/> working group is working >>>> towards zero configuration IP networking. Multi-cast DNS >>>> <http://www.multicastdns.org/> and DNS service discovery >>>> <http://www.dns-sd.org/> provide a convient ways for devices and >>>> services to register themselves, and to discover other network-based >>>> services without relying on centrally administered services. >>>> >>>> Java as a language is not appropriate for low-level network >>>> configuration, but it is very useful for service registration and >>>> discovery. JmDNS provides easy-to-use pure-Java mDNS implementation that >>>> runs on most JDK1.6 compatible VMs. >>>> >>>> The code is released under the Apache 2.0 license so that it can be >>>> freely incorporated into other products and services. >>>> >>>> On Sat, Feb 20, 2016 at 10:11 AM, Sanjiva Weerawarana <[email protected] >>>> > wrote: >>>> >>>>> No no not using Hazelcast!!!! >>>>> >>>>> On Sat, Feb 20, 2016 at 10:07 AM, Srinath Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Sanjiva, >>>>>> >>>>>> I think we did though Hazelcast. AFAIK, we have not done it for DAS >>>>>> discovery yet. >>>>>> >>>>>> If we use Hazelcast, it is trivial to do. But that will add Hazelcast >>>>>> to all our products. ( or Maybe we can find and borrow that part of the >>>>>> code). >>>>>> >>>>>> --Srinath >>>>>> >>>>>> On Sat, Feb 20, 2016 at 10:00 AM, Sanjiva Weerawarana < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Guys we also need the servers to discover each other when on the >>>>>>> same machine or LAN. Have we done that yet? That's very easy to do [1] >>>>>>> and >>>>>>> IIRC we used it before for something. >>>>>>> >>>>>>> [1] https://en.wikipedia.org/wiki/Zero-configuration_networking >>>>>>> >>>>>>> On Fri, Feb 19, 2016 at 7:05 PM, Malith Dhanushka <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Feb 19, 2016 at 5:00 PM, Anjana Fernando <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Fri, Feb 19, 2016 at 4:54 PM, Srinath Perera <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Kasun, Nuwan >>>>>>>>>> >>>>>>>>>> All product needs to get DAS server location from one place. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. Do we have a place for that? Otherwise, we need something >>>>>>>>>> like conf/das-client.xml and create a component to read it and >>>>>>>>>> use it with >>>>>>>>>> API and ESB when they want to send events to DAS ( Anjana, can ESB >>>>>>>>>> analytics guys do it?) >>>>>>>>>> >>>>>>>>>> Yeah, we can check on that. As I remember, there were some >>>>>>>>> discussions on this, where a similar functionality was requested by >>>>>>>>> APIM >>>>>>>>> team as I remember. @Malith, can you please look into this. >>>>>>>>> >>>>>>>>> >>>>>>>> Noted >>>>>>>> >>>>>>>>> >>>>>>>>>> 1. >>>>>>>>>> 2. If we have a UI to specify DAS location, we should drop >>>>>>>>>> that. This is a admin UI, and in C5 we drop all admin UIs. >>>>>>>>>> 3. I think we discussed about doing a UDP broadcast, and >>>>>>>>>> automatically find the DAS server if it is in same LAN. Have we >>>>>>>>>> tried that? >>>>>>>>>> ( IMO this is post #1, but should do this ASAP) >>>>>>>>>> >>>>>>>>>> I think we just having a common configuration for pointing to a >>>>>>>>> DAS server should be enough (at least for now). UDP multicast will >>>>>>>>> not work >>>>>>>>> most often with certain network configuration, so I don't think it >>>>>>>>> would be >>>>>>>>> that useful. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Anjana. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Srinath >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ============================ >>>>>>>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>>>>>>>>> Site: http://people.apache.org/~hemapani/ >>>>>>>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>>>>>>> Phone: 0772360902 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Anjana Fernando* >>>>>>>>> Senior Technical Lead >>>>>>>>> WSO2 Inc. | http://wso2.com >>>>>>>>> lean . enterprise . middleware >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Malith Dhanushka >>>>>>>> Senior Software Engineer - Data Technologies >>>>>>>> *WSO2, Inc. : wso2.com <http://wso2.com/>* >>>>>>>> *Mobile* : +94 716 506 693 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 >>>>>>> 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 >>>>>>> 265 8311 >>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ============================ >>>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>>>>> Site: http://people.apache.org/~hemapani/ >>>>>> Photos: http://www.flickr.com/photos/hemapani/ >>>>>> Phone: 0772360902 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sanjiva Weerawarana, Ph.D. >>>>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) >>>>> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 >>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>> Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Thanks & regards, >>>> Nirmal >>>> >>>> Team Lead - WSO2 Machine Learner >>>> Associate Technical Lead - Data Technologies Team, WSO2 Inc. >>>> Mobile: +94715779733 >>>> Blog: http://nirmalfdo.blogspot.com/ >>>> >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >> >> >> >> -- >> *Anjana Fernando* >> Senior Technical Lead >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> > > > > -- > Gokul Balakrishnan > Senior Software Engineer, > WSO2, Inc. http://wso2.com > M +94 77 5935 789 | +44 7563 570502 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Akila Ravihansa Perera WSO2 Inc.; http://wso2.com/ Blog: http://ravihansa3000.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
