date:20140328

[jira] [Commented] (HADOOP-10433) Key Management Server based on KeyProvider API

2014-03-28 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HADOOP-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950446#comment-13950446
 ] 

Hadoop QA commented on HADOOP-10433:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12637338/KMS-ALL-PATCHES.patch
  against trunk revision .

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 7 new 
or modified test files.

  {color:red}-1 javac{color}.  The applied patch generated 1504 javac 
compiler warnings (more than the trunk's current 1491 warnings).

{color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

{color:green}+1 eclipse:eclipse{color}.  The patch built with 
eclipse:eclipse.

{color:red}-1 findbugs{color}.  The patch appears to introduce 9 new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 core tests{color}.  The patch failed these unit tests in 
hadoop-assemblies hadoop-common-project/hadoop-common 
hadoop-common-project/hadoop-kms hadoop-dist:

  org.apache.hadoop.crypto.key.kms.server.TestKMSACLs
  org.apache.hadoop.crypto.key.kms.server.TestKMSServer

{color:green}+1 contrib tests{color}.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/3726//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/3726//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-kms.html
Javac warnings: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/3726//artifact/trunk/patchprocess/diffJavacWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-HADOOP-Build/3726//console

This message is automatically generated.

 Key Management Server based on KeyProvider API
 --

 Key: HADOOP-10433
 URL: https://issues.apache.org/jira/browse/HADOOP-10433
 Project: Hadoop Common
  Issue Type: Improvement
  Components: security
Affects Versions: 3.0.0
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
 Attachments: HADOOP-10433.patch, KMS-ALL-PATCHES.patch, KMS-doc.pdf


 (from HDFS-6134 proposal)
 Hadoop KMS is the gateway, for Hadoop and Hadoop clients, to the underlying 
 KMS. It provides an interface that works with existing Hadoop security 
 components (authenticatication, confidentiality).
 Hadoop KMS will be implemented leveraging the work being done in HADOOP-10141 
 and HADOOP-10177.
 Hadoop KMS will provide an additional implementation of the Hadoop 
 KeyProvider class. This implementation will be a client-server implementation.
 The client-server protocol will be secure:
 * Kerberos HTTP SPNEGO (authentication)
 * HTTPS for transport (confidentiality and integrity)
 * Hadoop ACLs (authorization)
 The Hadoop KMS implementation will not provide additional ACL to access 
 encrypted files. For sophisticated access control requirements, HDFS ACLs 
 (HDFS-4685) should be used.
 Basic key administration will be supported by the Hadoop KMS via the, already 
 available, Hadoop KeyShell command line tool
 There are minor changes that must be done in Hadoop KeyProvider functionality:
 The KeyProvider contract, and the existing implementations, must be 
 thread-safe
 KeyProvider API should have an API to generate the key material internally
 JavaKeyStoreProvider should use, if present, a password provided via 
 configuration
 KeyProvider Option and Metadata should include a label (for easier 
 cross-referencing)
 To avoid overloading the underlying KeyProvider implementation, the Hadoop 
 KMS will cache keys using a TTL policy.
 Scalability and High Availability of the Hadoop KMS can achieved by running 
 multiple instances behind a VIP/Load-Balancer. For High Availability, the 
 underlying KeyProvider implementation used by the Hadoop KMS must be High 
 Available.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HADOOP-10449) Fix the javac warnings in the security packages.

2014-03-28 Thread Haohui Mai (JIRA)


[ 
https://issues.apache.org/jira/browse/HADOOP-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950464#comment-13950464
 ] 

Haohui Mai commented on HADOOP-10449:
-

+1

 Fix the javac warnings in the security packages.
 

 Key: HADOOP-10449
 URL: https://issues.apache.org/jira/browse/HADOOP-10449
 Project: Hadoop Common
  Issue Type: Sub-task
  Components: security
Reporter: Tsz Wo Nicholas Sze
Assignee: Tsz Wo Nicholas Sze
Priority: Minor
 Attachments: c10449_20140327.patch


 The are a few minor javac warnings.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HADOOP-9923) yarn staging area on hdfs has wrong permission and is created by the wrong user

2014-03-28 Thread Sanghyun Yun (JIRA)

[
https://issues.apache.org/jira/browse/HADOOP-9923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950469#comment-13950469
]

Sanghyun Yun commented on HADOOP-9923:
--

try set users(hdfs, yarn, mapred) to the members of the same group(ex. hadoop)
and change the group of staging dir.

I think this is right usage.

yarn staging area on hdfs has wrong permission and is created by the wrong
user
---

Key: HADOOP-9923
URL: https://issues.apache.org/jira/browse/HADOOP-9923
Project: Hadoop Common
Issue Type: Bug
Affects Versions: 2.1.0-beta
Reporter: André Kelpe

I am setting up a cluster with hadoop 2.1-beta that consists of the following
components:
master: runs the namenode, the resourcemanager and the job history server.
hadoop1, hadoop2, hadoop3: run datanodes and node managers
I created 3 system users for the different components, like explained in the
docs:
hdfs: runs all things hdfs
yarn: runs all things yarn
mapred: runs the job history server
If I now boot up the cluster, I cannot submit jobs since the yarn staging
area permissions do not allow it.
What I found out is, that the job-history-server is creating the staging
directory while starting. This first of all causes it to be owned by the
wrong user (mapred) and having the wrong permision (770). The docs are not
really clear if I am supposed to start hdfs first, then create the staging
area by hand and then start the job-history-server or if this is supposed to
happen automatically by itself.
In any case, either the docs should be updated or the job-history-server
should not create the directory.

38 matches

Mail list logo