Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Thrift over SSL


Copy link to this message
-
Re: Thrift over SSL
The Thrift-SSL path will be almost identical to the existing Thrift path,
and I agree it would be good for "use SSL" to be a general feature that may
be provided by any transport implementation, so I think it makes sense for
it to just be a switch to the rpc provider.  The cert management code can
be independent so it can easily be consumed by other providers later.
 Conveniently it sounds like this is also the option that minimizes the
potential conflict with your project.

Michael
On Wed, Jul 17, 2013 at 9:03 AM, Christopher <[EMAIL PROTECTED]> wrote:

> I've been holding off making progress on that ticket, because it would
> result in too many "svn mv" commands to preserve history. I was
> waiting until we switched to git to make progress. Now that we have, I
> plan on picking up where I left off, and working that, in conjunction
> with ACCUMULO-210. I think some coordination would be helpful, but I
> don't want to inhibit your progress.
>
> Essentially, what I was going to do for ACCUMULO-756 was to create an
> RPC maven module, with child modules for rpc-api, and rpc-thrift (a
> concrete implementation), and was going to push all the thrift code
> down to the rpc-thrift module. I was then hoping to specify the rpc
> implementation either in configuration (accumulo-site.xml, for now) or
> through auto-discovery of concrete implementations on the classpath,
> so one could simply swap out implementation jars.
>
> The way this might affect ACCUMULO-1009, depends on how you'd want to
> do the implementation. You could simply add configuration to control
> the provided thrift implementation to use SSL, or you could create a
> separate pluggable implementation that extends the provided one, and
> includes the necessary configuration. Another option is to make SSL a
> more generic feature for all implementations, and move the
> configuration switch up to the rpc-api module, so all other
> implementations would have both an SSL and a non-SSL option. I haven't
> played with SSL, or touched the RPC stuff in awhile, so I'm not sure
> which option is best.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, Jul 17, 2013 at 12:36 PM, Michael Berman <[EMAIL PROTECTED]>
> wrote:
> > Hi Devs,
> > I'm starting work on enabling SSL encryption over the wire
> (ACCUMULO-1009).
> > I noticed ACCUMULO-756 ("abstracting API communication mechanisms") is
> > marked as in progress by Christopher.  Should I proceed with the SSL
> changes
> > given today's thrift API code, or should I be trying to coordinate with
> the
> > grander abstraction plan?  The entrypoint to my changes should be pretty
> > focused...just a few lines of code around where we currently create
> thrift
> > servers and clients.
> >
> > I'm also open to any other advice about how SSL should be integrated if
> > others have particular requirements or solutions in mind.
> >
> > Thanks,
> > Michael
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB