giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Reisman <initialcont...@gmail.com>
Subject Re: Review Request: GIRAPH-211: Add secure authentication to Netty IPC
Date Wed, 05 Sep 2012 18:18:08 GMT
I love the idea of the pluggable ChannelHandler, Netty is really perfectly
set up for this, nice call!


On Wed, Sep 5, 2012 at 2:31 AM, Maja Kabiljo <majakabiljo@fb.com> wrote:

> Eugene, maybe there is something wrong with the way I set up the project
> then. Here are the errors I'm getting:
> - With hadoop_2.0.0 no method TokenIdentifier.decodeIdentifier
> - With hadoop_0.23 can't find org.apache.commons.net.util.Base64, no
> method JobTokenSecretManager.checkAvailableForRead and the one from above
> What am I doing wrong?
>
> Looking forward to see the updated patch!
>
>
> Eli, I see that the confusion arises because I left
> MasterRequest.doRequest without parameters, which I did just because it's
> not used yet. But it's going to have to accept some master data once we
> have implementations of MasterRequest. The only way I see to keep only one
> doRequest signature in the end is to have some ServerData which has
> methods for accessing both master and worker stuff, and say throws an
> exception in unsupported method on each. But that seems ugly, and also
> makes us keep generics on places where we don't need them. I just have a
> feeling there should be a nice way to solve this which I'm missing because
> I'm too focused on current solution ;-)
>
> Maja
>
> On 9/5/12 2:56 AM, "Avery Ching" <aching@apache.org> wrote:
>
> >I really like this idea, so we don't need to have a separate
> >SaslNettyClient and SaslNettyServer.  It makes a lot of sense to have a
> >ChannelHandler that can be inserted if security is desired.  This should
> >be a lot cleaner.
> >
> >Avery
> >
> >On 9/4/12 11:31 AM, Eugene Koontz wrote:
> >> Thanks Maja and Eli for your comments.
> >>
> >>   I'm glad you are looking at it and discussing it! It's been a real
> >> learning experience for me too.
> >>
> >> I am working today on a new iteration of the patch which introduces a
> >> dedicated ChannelHandler dedicated to SASL- that is, a component in the
> >> pipelines of clients and servers that would be added only if SASL
> >> authentication is enabled by configuration, and is removed after
> >> authentication is completed.
> >>
> >> Adding and removing this handler can be done using
> >> ChannelPipeline.addAfter() and .remove(), respectively:
> >>
> >>
> >>
> http://docs.jboss.org/netty/3.2/api/org/jboss/netty/channel/ChannelPipeli
> >>ne.html#addFirst%28%29
> >>
> >>   I think this would better localize SASL-specific communication,
> >> touching fewer existing files, and slim down the patch. Hopefully this
> >> would also eliminate the need to pass around the ServerData object, and
> >> avoid signature changes to doRequest().
> >>
> >> With regard to -Phadoop_2.0.1, sorry about that, Maja - I will open a
> >> new JIRA to add this profile to pom.xml.
> >>
> >> The patch should work, however, with other hadoop profiles, as long as
> >> they don't have HADOOP_NON_SECURE in their munge flags.
> >>
> >> -Eugene
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message