Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: adding node(s) to Hadoop cluster
From: Rainer Toebbicke <rtb@pclella.cern.ch>
In-Reply-To: <D461CB96-0CE7-4574-89DE-09FE93F11B6B@hortonworks.com>
Date: Thu, 11 Dec 2014 10:13:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <0542CBB8-E970-429E-9401-0765E76DF53F@pclella.cern.ch>
References: <5A6D749C-C448-46B7-806E-FC376B318688@pclella.cern.ch>
 <D461CB96-0CE7-4574-89DE-09FE93F11B6B@hortonworks.com>
To: <user@hadoop.apache.org>


Le 10 d=E9c. 2014 =E0 20:08, Vinod Kumar Vavilapalli =
<vinodkv@hortonworks.com> a =E9crit :

> You don't need patterns for host-names, did you see the support for =
_HOST in the principle names? You can specify the datanode principle to =
be say datanodeUser@_HOST@realm, and Hadoop libraries interpret and =
replace _HOST on each machine with the real host-name.

Thanks, I may be mistaken, but I suspect you missed the point:

for me, auth_to_local's role is to protect the server(s). For example,  =
somebody on an untrusted "client" can disguise as hdfs/nodename@REALM =
and hence take over hdfs through a careless principal->id translation. A =
well-configured auth_to_local will deflect that rogue "hdfs" to "nobody" =
or something, so a malicious client cannot do a "hdfs dfs -chown ..." =
for example.

The _HOST construct makes using the same config files throughout the =
cluster easier indeed, but as far as I see it mainly applies to the =
"client".

On the server, I see no way other than auth_to_local with a list/pattern =
of trusted node names (on namenode and every datanode in the hdfs case) =
to prevent the scenario above. Would there be?

Thanks, Rainer=