giraph-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maja Kabiljo <>
Subject Re: Review Request: GIRAPH-211: Add secure authentication to Netty IPC
Date Wed, 05 Sep 2012 09:31:46 GMT
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, 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 ;-)


On 9/5/12 2:56 AM, "Avery Ching" <> 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.
>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:
>>   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

View raw message