Review Request 72000: RANGER-2702:Upgrade Kafka Version in Ranger to 2.4

2020-01-14 Thread Ramesh Mani 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/72000/
---

Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, Selvamohan Neethiraj, Sailaja 
Polavarapu, and Velmurugan Periasamy.


Bugs: RANGER-2702
https://issues.apache.org/jira/browse/RANGER-2702


Repository: ranger


Description
---

RANGER-2702:Upgrade Kafka Version in Ranger to 2.4


Diffs
-

  
plugin-kafka/src/main/java/org/apache/ranger/services/kafka/client/ServiceKafkaClient.java
 6929257 
  
plugin-kafka/src/main/java/org/apache/ranger/services/kafka/client/ServiceKafkaConnectionMgr.java
 9e0d6b4 
  
plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerGSSTest.java
 43e88b5 
  
plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerSASLSSLTest.java
 88a3e02 
  
plugin-kafka/src/test/java/org/apache/ranger/authorization/kafka/authorizer/KafkaRangerAuthorizerTest.java
 8d2f0a4 
  pom.xml f53c54d 


Diff: https://reviews.apache.org/r/72000/diff/1/


Testing
---

Testing done in local vm


Thanks,

Ramesh Mani

[jira] [Updated] (RANGER-2697) Retrieve additional user/group attributes from AD/LDAP and rest API to download this information

2020-01-14 Thread Sailaja Polavarapu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Polavarapu updated RANGER-2697:
---
Attachment: 0001-RANGER-2697-Usersync-and-Ranger-admin-changes-to-sup.patch

> Retrieve additional user/group attributes from AD/LDAP and rest API to 
> download this information 
> -
>
> Key: RANGER-2697
> URL: https://issues.apache.org/jira/browse/RANGER-2697
> Project: Ranger
>  Issue Type: New Feature
>  Components: Ranger, usersync
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
>Priority: Major
> Attachments: 
> 0001-RANGER-2697-Usersync-and-Ranger-admin-changes-to-sup.patch
>
>
> Enhance Usersync to retrieve additional attributes for users and groups from 
> AD/LDAP and update Ranger admin. Provide Ranger admin REST API to download 
> user and group attributes. This is extension to 
> https://jira.apache.org/jira/browse/RANGER-2632



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Review Request 71999: RANGER-2697: Usersync and Ranger admin changes to support retriving additional user/group attributes from LDAP/AD

2020-01-14 Thread Sailaja Polavarapu 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/71999/
---

Review request for ranger.


Bugs: RANGER-2697
https://issues.apache.org/jira/browse/RANGER-2697


Repository: ranger


Description
---

Modified Usersync code to retrieve configurable user and group attributes from 
AD/LDAP. Also added rest API support in ranger admin to dowmload user and group 
information including these additional attributes.


Diffs
-

  agents-common/src/main/java/org/apache/ranger/plugin/model/GroupInfo.java 
PRE-CREATION 
  
agents-common/src/main/java/org/apache/ranger/plugin/model/RangerPluginInfo.java
 90367fe04 
  agents-common/src/main/java/org/apache/ranger/plugin/model/UserInfo.java 
PRE-CREATION 
  
agents-common/src/main/java/org/apache/ranger/plugin/util/RangerUserStore.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/biz/AssetMgr.java 0f4488861 
  security-admin/src/main/java/org/apache/ranger/biz/RoleDBStore.java 04596dc65 
  security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
ccda6abb0 
  security-admin/src/main/java/org/apache/ranger/biz/UserMgr.java 3045eaf9a 
  security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 037c591e8 
  
security-admin/src/main/java/org/apache/ranger/common/RangerUserStoreCache.java 
PRE-CREATION 
  security-admin/src/main/java/org/apache/ranger/db/XXGlobalStateDao.java 
2e462bd3a 
  security-admin/src/main/java/org/apache/ranger/rest/XUserREST.java 1e8a09379 
  security-admin/src/main/java/org/apache/ranger/service/XGroupServiceBase.java 
1a701bbfb 
  security-admin/src/main/java/org/apache/ranger/service/XUserServiceBase.java 
1004952a9 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapDeltaUserGroupBuilder.java
 ca50f098a 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapPolicyMgrUserGroupBuilder.java
 b469e9245 
  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
 8efa1613a 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
 1d4e37fcf 
  ugsync/src/main/java/org/apache/ranger/unixusersync/model/MUserInfo.java 
841bac64a 
  ugsync/src/main/java/org/apache/ranger/unixusersync/model/XGroupInfo.java 
cbe0eb02b 
  ugsync/src/main/java/org/apache/ranger/unixusersync/model/XUserInfo.java 
e2f36b2c5 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
 f08c5117b 
  ugsync/src/main/java/org/apache/ranger/usergroupsync/UserGroupSink.java 
77bd016fd 
  
ugsync/src/test/java/org/apache/ranger/usergroupsync/LdapPolicyMgrUserGroupBuilderTest.java
 99bc2b44e 
  
ugsync/src/test/java/org/apache/ranger/usergroupsync/PolicyMgrUserGroupBuilderTest.java
 2bc395180 


Diff: https://reviews.apache.org/r/71999/diff/1/


Testing
---

1. Verified all the existing unit tests are run successfully.
2. Patched a cluster and ran tests to sync various user/group attributes from 
test AD
3. Also verified new rest API to download user and group information with 
addition attributes.


Thanks,

Sailaja Polavarapu

[jira] [Comment Edited] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is often blocked

2020-01-14 Thread Jiayi Liu (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015574#comment-17015574
 ] 

Jiayi Liu edited comment on RANGER-2700 at 1/15/20 2:54 AM:


Hi, [~vel]. Thank you for your reply, I create a review request in 
https://reviews.apache.org/r/71998/, can you please help review?


was (Author: liujiayi771):
Hi, [~vel]. Thank you for your reply, I create a review request in 
https://reviews.apache.org/r/71998/

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> often blocked
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (RANGER-2667) Running the disable-presto-plugin.sh script will always get stuck

2020-01-14 Thread Jiayi Liu (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015579#comment-17015579
 ] 

Jiayi Liu commented on RANGER-2667:
---

Hi, [~mehul], can you please help review?

> Running the disable-presto-plugin.sh script will always get stuck
> -
>
> Key: RANGER-2667
> URL: https://issues.apache.org/jira/browse/RANGER-2667
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 2.0.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2667.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Running the disable-presto-plugin.sh script will always get stuck. Because 
> the script sets the 
> controlName to an empty string and passes it to the function 
> addOrUpdatePropertyToFile when disable the presto plugin. If controlName is 
> an empty string, addOrUpdatePropertyToFile will ignore this parameter and let 
> fn to be the second parameter. So $3 passed to checkPropertyInFile will be 
> empty. In checkPropertyInFile, if the second parameter is empty, the sed 
> command will never return, and the disable-presto-plugin.sh script will 
> always get stuck.
> We should pass the default value of access-control.name and set controlName 
> to be allow-all when disable presto plugin. 
> The default value of access-control.name can be seen here: 
> https://prestodb.io/docs/current/security/built-in-system-access-control.html
> The pull request: https://github.com/apache/ranger/pull/45



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is often blocked

2020-01-14 Thread Jiayi Liu (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015574#comment-17015574
 ] 

Jiayi Liu commented on RANGER-2700:
---

Hi, [~vel]. Thank you for your reply, I create a review request in 
https://reviews.apache.org/r/71998/

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> often blocked
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Review Request 71998: RANGER-2700: Use SecureRandom.getInstance(NativePRNGNonBlocking) to get random string

2020-01-14 Thread Jiayi Liu 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/71998/
---

Review request for ranger, Ankita Sinha, bhavik patel, Gautam Borad, Abhay 
Kulkarni, Madhan Neethiraj, Mehul Parikh, Nikhil P, Nitin Galave, Ramesh Mani, 
Sailaja Polavarapu, and Velmurugan Periasamy.


Bugs: RANGER-2700
https://issues.apache.org/jira/browse/RANGER-2700


Repository: ranger


Description
---

In Ranger-2.0.0, the request that creating new service often stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block.

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will not 
be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random and 
/dev/urandom use the same pool of randomness under the hood, and they are 
equally secure.


Diffs
-

  agents-common/src/main/java/org/apache/ranger/plugin/util/PasswordUtils.java 
c08f55d6e 


Diff: https://reviews.apache.org/r/71998/diff/1/


Testing
---


Thanks,

Jiayi Liu

[jira] [Created] (RANGER-2702) Upgrade Kafka Version in Ranger to 2.4

2020-01-14 Thread Ramesh Mani (Jira) 
Ramesh Mani created RANGER-2702:
---

 Summary: Upgrade Kafka Version in Ranger to 2.4
 Key: RANGER-2702
 URL: https://issues.apache.org/jira/browse/RANGER-2702
 Project: Ranger
  Issue Type: Bug
  Components: Ranger
Affects Versions: 2.1.0
Reporter: Ramesh Mani


Upgrade Kafka Version in Ranger to 2.4.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (RANGER-2702) Upgrade Kafka Version in Ranger to 2.4

2020-01-14 Thread Ramesh Mani (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramesh Mani reassigned RANGER-2702:
---

Assignee: Ramesh Mani

> Upgrade Kafka Version in Ranger to 2.4
> --
>
> Key: RANGER-2702
> URL: https://issues.apache.org/jira/browse/RANGER-2702
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 2.1.0
>Reporter: Ramesh Mani
>Assignee: Ramesh Mani
>Priority: Major
>
> Upgrade Kafka Version in Ranger to 2.4.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Review Request 71954: RANGER-2684: Add Kudu service definition

2020-01-14 Thread Abhay Kulkarni 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/71954/#review219257
---




agents-common/src/main/resources/service-defs/ranger-servicedef-kudu.json
Lines 100 (patched)


"label": "DELETE",


- Abhay Kulkarni


On Jan. 6, 2020, 10:43 p.m., Hao Hao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/71954/
> ---
> 
> (Updated Jan. 6, 2020, 10:43 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> RANGER-2684: Add Kudu service definition
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/store/EmbeddedServiceDefsUtil.java
>  e96f881ac6798725a53ff4b44ef27330a3832fe9 
>   agents-common/src/main/resources/service-defs/ranger-servicedef-kudu.json 
> PRE-CREATION 
>   plugin-kudu/.gitignore PRE-CREATION 
>   plugin-kudu/pom.xml PRE-CREATION 
>   
> plugin-kudu/src/main/java/org/apache/ranger/services/kudu/RangerServiceKudu.java
>  PRE-CREATION 
>   pom.xml abe8b751cb15ae86b1cb119d8aea9e919580cede 
>   src/main/assembly/admin-web.xml 4658f87cf10529697a214b5766de555f9cd9ca14 
> 
> 
> Diff: https://reviews.apache.org/r/71954/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hao Hao
> 
>

Re: Review Request 71992: RANGER-2695: Default displayName for ServiceDef

2020-01-14 Thread Kishor Gollapalliwar 


> On Jan. 14, 2020, 12:29 p.m., Abhay Kulkarni wrote:
> > agents-common/src/main/java/org/apache/ranger/plugin/store/EmbeddedServiceDefsUtil.java
> > Lines 304 (patched)
> > 
> >
> > Is there any specific reason to use Objects.noNull(ret) construct? 
> > Would the following be easier to read?
> > 
> > if (ret != null && StringUtils.isBlank(ret.getDisplayName())) {
> > ret.setDisplayName(ret.getName());
> > }

Objects.noNull(ret) construct is similar to 
StringUtils.isBlank(ret.getDisplayName()). 
We are already using StringUtils.isBlank(ret.getDisplayName()) style construct.
Hence for consistency and readability I have used it.


- Kishor


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/71992/#review219253
---


On Jan. 14, 2020, 10:38 a.m., Kishor Gollapalliwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/71992/
> ---
> 
> (Updated Jan. 14, 2020, 10:38 a.m.)
> 
> 
> Review request for ranger, Jayendra Parab, Abhay Kulkarni, Madhan Neethiraj, 
> Mehul Parikh, Pradeep Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2695
> https://issues.apache.org/jira/browse/RANGER-2695
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Ranger creates ServiceDef(s) as part of initial setup. While creating these 
> ServiceDef(s) it refers respective JSON file. If display name for a 
> ServiceDef is not provided OR it is empty, ServiceDef's name should be used 
> as DEFAULT displayName for that ServiceDef.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/store/EmbeddedServiceDefsUtil.java
>  e96f881ac 
> 
> 
> Diff: https://reviews.apache.org/r/71992/diff/2/
> 
> 
> Testing
> ---
> 
> Setup Ranger using following scenarios:
>  1. No displayName attribute in JSON file.
>  2. displayName attribute with empty string.
>  3. displayName attribute with string other than name.
> 
> 
> Thanks,
> 
> Kishor Gollapalliwar
> 
>

Re: Request to add me as contributor

2020-01-14 Thread Dineshkumar Yadav 
My github and apache jira user Id :  dineshkumar-yadav


From: Dineshkumar Yadav 
Sent: Tuesday, January 14, 2020 6:46 PM
To: dev@ranger.apache.org 
Subject: Request to add me as contributor

Hi Team,

I would like to contribute to ranger community, Please add me as contributor.

--
Thanks & Regards,
Dineshkumar Yadav

[jira] [Updated] (RANGER-2701) Improve Logging mechanism for Ranger KMS

2020-01-14 Thread Dhaval B. SHAH (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhaval B. SHAH updated RANGER-2701:
---
Attachment: RANGER-2701-01.patch

> Improve Logging mechanism for Ranger KMS
> 
>
> Key: RANGER-2701
> URL: https://issues.apache.org/jira/browse/RANGER-2701
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Dhaval B. SHAH
>Assignee: Dhaval B. SHAH
>Priority: Major
> Attachments: RANGER-2701-01.patch
>
>
>  Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.
> E.G. 
> {code:java}
> // code placeholder
> 2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
> 2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}
> This logs are useful while debugging the issue.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2701) Improve Logging mechanism for Ranger KMS

2020-01-14 Thread Dhaval B. SHAH (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhaval B. SHAH updated RANGER-2701:
---
Attachment: (was: RANGER-2701.patch)

> Improve Logging mechanism for Ranger KMS
> 
>
> Key: RANGER-2701
> URL: https://issues.apache.org/jira/browse/RANGER-2701
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Dhaval B. SHAH
>Assignee: Dhaval B. SHAH
>Priority: Major
>
>  Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.
> E.G. 
> {code:java}
> // code placeholder
> 2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
> 2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}
> This logs are useful while debugging the issue.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is often blocked

2020-01-14 Thread Velmurugan Periasamy (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015106#comment-17015106
 ] 

Velmurugan Periasamy commented on RANGER-2700:
--

Thanks [~liujiayi771]. Can you please post the patch in the review board? 

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> often blocked
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is often blocked

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Summary: creating service sometimes fails because 
SecureRandom.getInstanceStrong() is often blocked  (was: creating service 
sometimes fails because SecureRandom.getInstanceStrong() is blocked)

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> often blocked
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is very slow

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Attachment: 0001-RANGER-2700.patch

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> very slow
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is blocked

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Summary: creating service sometimes fails because 
SecureRandom.getInstanceStrong() is blocked  (was: creating service sometimes 
fails because SecureRandom.getInstanceStrong() is very slow)

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> blocked
> 
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is very slow

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Description: 
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will not 
be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random and 
/dev/urandom use the same pool of randomness under the hood, and they are 
equally secure. 

  was:
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

Can we use /dev/urandom by replacing 
SecureRandom.getInstanceStrong().nextBytes(iv) with new 
SecureRandom().nextBytes(iv)? /dev/random and /dev/urandom use the same pool of 
randomness under the hood, and they are equally secure. 


> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> very slow
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Request to add me as contributor

2020-01-14 Thread Velmurugan Periasamy 
Hi - welcome to Ranger community. Thanks for your interest in contributing to 
Ranger. I have added your user id (dineshkumar-yadav) as a contributor. 

On Tue, Jan 14, 2020 at 8:17 AM Dineshkumar Yadav 
 wrote:
Hi Team,

I would like to contribute to ranger community, Please add me as contributor.

--
Thanks & Regards,
Dineshkumar Yadav

[jira] [Updated] (RANGER-2701) Improve Logging mechanism for Ranger KMS

2020-01-14 Thread Dhaval B. SHAH (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhaval B. SHAH updated RANGER-2701:
---
Description: 
 Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.

E.G. 
{code:java}
// code placeholder
2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}
This logs are useful while debugging the issue.

 

  was:
 

 

Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.

E.G. 
{code:java}
// code placeholder
2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}

This logs are useful while debugging the issue.

 


> Improve Logging mechanism for Ranger KMS
> 
>
> Key: RANGER-2701
> URL: https://issues.apache.org/jira/browse/RANGER-2701
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Dhaval B. SHAH
>Assignee: Dhaval B. SHAH
>Priority: Major
> Attachments: RANGER-2701.patch
>
>
>  Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.
> E.G. 
> {code:java}
> // code placeholder
> 2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
> 2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}
> This logs are useful while debugging the issue.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2701) Improve Logging mechanism for Ranger KMS

2020-01-14 Thread Dhaval B. SHAH (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dhaval B. SHAH updated RANGER-2701:
---
Attachment: RANGER-2701.patch

> Improve Logging mechanism for Ranger KMS
> 
>
> Key: RANGER-2701
> URL: https://issues.apache.org/jira/browse/RANGER-2701
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Dhaval B. SHAH
>Assignee: Dhaval B. SHAH
>Priority: Major
> Attachments: RANGER-2701.patch
>
>
>  
>  
> Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.
> E.G. 
> {code:java}
> // code placeholder
> 2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
> 2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}
> This logs are useful while debugging the issue.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Request to add me as contributor

2020-01-14 Thread Dineshkumar Yadav 
Hi Team,

I would like to contribute to ranger community, Please add me as contributor.

--
Thanks & Regards,
Dineshkumar Yadav

Re: Review Request 71992: RANGER-2695: Default displayName for ServiceDef

2020-01-14 Thread Abhay Kulkarni 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/71992/#review219253
---




agents-common/src/main/java/org/apache/ranger/plugin/store/EmbeddedServiceDefsUtil.java
Lines 304 (patched)


Is there any specific reason to use Objects.noNull(ret) construct? Would 
the following be easier to read?

if (ret != null && StringUtils.isBlank(ret.getDisplayName())) {
ret.setDisplayName(ret.getName());
}


- Abhay Kulkarni


On Jan. 14, 2020, 10:38 a.m., Kishor Gollapalliwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/71992/
> ---
> 
> (Updated Jan. 14, 2020, 10:38 a.m.)
> 
> 
> Review request for ranger, Jayendra Parab, Abhay Kulkarni, Madhan Neethiraj, 
> Mehul Parikh, Pradeep Agrawal, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-2695
> https://issues.apache.org/jira/browse/RANGER-2695
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Ranger creates ServiceDef(s) as part of initial setup. While creating these 
> ServiceDef(s) it refers respective JSON file. If display name for a 
> ServiceDef is not provided OR it is empty, ServiceDef's name should be used 
> as DEFAULT displayName for that ServiceDef.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/store/EmbeddedServiceDefsUtil.java
>  e96f881ac 
> 
> 
> Diff: https://reviews.apache.org/r/71992/diff/2/
> 
> 
> Testing
> ---
> 
> Setup Ranger using following scenarios:
>  1. No displayName attribute in JSON file.
>  2. displayName attribute with empty string.
>  3. displayName attribute with string other than name.
> 
> 
> Thanks,
> 
> Kishor Gollapalliwar
> 
>

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is very slow

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Description: 
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

Can we use /dev/urandom by replacing 
SecureRandom.getInstanceStrong().nextBytes(iv) with new 
SecureRandom().nextBytes(iv)? /dev/random and /dev/urandom use the same pool of 
randomness under the hood, and they are equally secure. 

  was:
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

Can we use /dev/urandom by replacing 
ecureRandom.getInstanceStrong().nextBytes(iv) to new 
SecureRandom().nextBytes(iv)? /dev/random and /dev/urandom use the same pool of 
randomness under the hood, and they are equally secure. 


> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> very slow
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> Can we use /dev/urandom by replacing 
> SecureRandom.getInstanceStrong().nextBytes(iv) with new 
> SecureRandom().nextBytes(iv)? /dev/random and /dev/urandom use the same pool 
> of randomness under the hood, and they are equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is very slow

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Description: 
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

Can we use /dev/urandom by replacing 
ecureRandom.getInstanceStrong().nextBytes(iv) to new 
SecureRandom().nextBytes(iv)? /dev/random and /dev/urandom use the same pool of 
randomness under the hood, and they are equally secure. 

  was:
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom by 
replacing ecureRandom.getInstanceStrong() to 
SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and /dev/urandom 
use the same pool of randomness under the hood, and they are equally secure. 


> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> very slow
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> Can we use /dev/urandom by replacing 
> ecureRandom.getInstanceStrong().nextBytes(iv) to new 
> SecureRandom().nextBytes(iv)? /dev/random and /dev/urandom use the same pool 
> of randomness under the hood, and they are equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (RANGER-2695) Default displayName for ServiceDef

2020-01-14 Thread Kishor Gollapalliwar (Jira) 


[ 
https://issues.apache.org/jira/browse/RANGER-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17014998#comment-17014998
 ] 

Kishor Gollapalliwar commented on RANGER-2695:
--

RR : https://reviews.apache.org/r/71992/

> Default displayName for ServiceDef
> --
>
> Key: RANGER-2695
> URL: https://issues.apache.org/jira/browse/RANGER-2695
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Kishor Gollapalliwar
>Assignee: Kishor Gollapalliwar
>Priority: Major
>
> Ranger creates ServiceDef(s) as part of initial setup. While creating these 
> ServiceDef(s) it refers respective JSON file. If display name for a 
> ServiceDef is not provided OR it is empty, ServiceDef's name should be used 
> as DEFAULT displayName for that ServiceDef.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (RANGER-2701) Improve Logging mechanism for Ranger KMS

2020-01-14 Thread Dhaval B. SHAH (Jira) 
Dhaval B. SHAH created RANGER-2701:
--

 Summary: Improve Logging mechanism for Ranger KMS
 Key: RANGER-2701
 URL: https://issues.apache.org/jira/browse/RANGER-2701
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Dhaval B. SHAH
Assignee: Dhaval B. SHAH


 

 

Change the logging level from INFO to DEBUG of certain logs in Ranger KMS.

E.G. 
{code:java}
// code placeholder
2019-12-13 14:45:25,844 INFO KMS - Entering decryptEncryptedKey method.
2019-12-13 14:45:25,866 INFO KMS - Exiting handleEncryptedKeyOp method.{code}

This logs are useful while debugging the issue.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is very slow

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Description: 
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random string. We can find a lot of 
information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom by 
replacing ecureRandom.getInstanceStrong() to 
SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and /dev/urandom 
use the same pool of randomness under the hood, and they are equally secure. 

  was:
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random byte array. We can find a 
lot of information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom by 
replacing ecureRandom.getInstanceStrong() to 
SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and /dev/urandom 
use the same pool of randomness under the hood, and they are equally secure. 


> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> very slow
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom 
> by replacing ecureRandom.getInstanceStrong() to 
> SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and 
> /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (RANGER-2700) creating service sometimes fails because SecureRandom.getInstanceStrong() is very slow

2020-01-14 Thread Jiayi Liu (Jira) 


 [ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiayi Liu updated RANGER-2700:
--
Description: 
I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
service in Ranger WebUI, when I click the Add button, I keep stuck in the 
Please waiting state for a long time, and finally get an error that 
createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random byte array. We can find a 
lot of information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom by 
replacing ecureRandom.getInstanceStrong() to 
SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and /dev/urandom 
use the same pool of randomness under the hood, and they are equally secure. 

  was:
I try to install ranger-2.0.0 on my cluster, however when I try to create a new 
service in WebUI, I often get an error that createService failed.

 I try to debug through the source code, and found that it stuck on 
generateBase64EncodedIV() in PasswordUtils.java. It uses 
SecureRandom.getInstanceStrong() to get the random byte array. We can find a 
lot of information showing that this function often blocks and is very slow. 
SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
thread if there isn't enough randomness available, but /dev/urandom will never 
block. 

SecureRandom.getInstanceStrong() is equivalent to 
SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom by 
replacing ecureRandom.getInstanceStrong() to 
SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and /dev/urandom 
use the same pool of randomness under the hood, and they are equally secure. 


> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> very slow
> --
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
>  Issue Type: Improvement
>  Components: admin
>Affects Versions: ranger-2.0
>Reporter: Jiayi Liu
>Priority: Major
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random byte array. We can find a 
> lot of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), and we can use /dev/urandom 
> by replacing ecureRandom.getInstanceStrong() to 
> SecureRandom.getInstance("NativePRNGNonBlocking"). /dev/random and 
> /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)