[jira] [Created] (RANGER-1444) Do some code improvement in security admin module

[Qiang Zhang (JIRA)]

Qiang Zhang created RANGER-1444:
---

 Summary: Do some code improvement in security admin module
 Key: RANGER-1444
 URL: https://issues.apache.org/jira/browse/RANGER-1444
 Project: Ranger
  Issue Type: Bug
  Components: admin
Affects Versions: 1.0.0
Reporter: Qiang Zhang
Assignee: Qiang Zhang
 Fix For: 1.0.0


1. There are some duplicate codes in method 
mapXXPortalUserToVXPortalUserForDefaultAccount.
{code}
userProfile.setLoginId(user.getLoginId());
userProfile.setEmailAddress(user.getEmailAddress());
userProfile.setStatus(user.getStatus());
userProfile.setUserRoleList(new ArrayList());
userProfile.setId(user.getId());
userProfile.setFirstName(user.getFirstName());
userProfile.setLastName(user.getLastName());
userProfile.setPublicScreenName(user.getPublicScreenName());
userProfile.setEmailAddress(user.getEmailAddress());
{code}
We set the email address twice.
2. We have already checked if sess is null, so don't need to check it in below 
logic.
{code}
UserSessionBase sess = ContextUtil.getCurrentUserSession();
if (sess != null) {
if (sess != null && sess.isUserAdmin() || sess.isKeyAdmin()) {
return;
}
if (sess.getXXPortalUser().getId().equals(gjUser.getId())) {
return;
}
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 57496: RANGER-1440 : Improve install script to retry failing statement

[Pradeep Agrawal]

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

Review request for ranger, Ankita Sinha, Don Bosco Durai, Gautam Borad, Abhay 
Kulkarni, Madhan Neethiraj, Mehul Parikh, Ramesh Mani, Selvamohan Neethiraj, 
Sailaja Polavarapu, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

**Problem Statement:** 
Ranger installation may fail due to network latency or during parallel install 
in Ranger HA environment.
**Proposed Solution:** 
Ranger installation script can be improved to retry failed sql 
statements(specifically create/update request).
Rather calling subprocess.call() only once for all such statements execution 
wrote a function subprocessCallWithRetry() which can accept statement and retry 
2 more times if fails in first attempt.

**Other changes :**
Patch wait time is changed to 2 minute from 5 minute.

**Note:** Ranger installation script failure is still possible due to poor 
network latency of db server. 
For example: if install process of two different node read same data at 
particular timestamp but while updating the same data one node could update 
that data quickly due to better network latency and if at the same interval 
second machine got poor latency then second node process might try to update 
the old data which have already been changed by first node.


Diffs
-

  security-admin/scripts/db_setup.py 6d1a047 
  security-admin/scripts/dba_script.py 1f99328 
  security-admin/scripts/setup.sh 76bb119 
  security-admin/scripts/update_property.py 338fbf5 


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


Testing
---

**Steps performed(with patch):** Below steps have been tested for all db flavor.
1. Created Build with patch and untar the build on two node.
2. Opened install.properties and provided same db configuration in 
install.properties of both ranger-admin nodes.
3. Called setup.sh file parallelly from both hosts.

**Expected behavior :**  If same operation or sql statement is executed from 
both node then either of the node script may break and retry the script or 
sleep for some time to reduce the possibility of ranger install failure. Ranger 
admin ui should get loaded on browser whenever Ranger url is requested.

**Expected behavior :**  Ranger install worked fine. it was observed that few 
create/update sql statements failed in middle of the script execution; but the 
installation resumed and finished well. Was able to view and login to Ranger 
admin.

Tried above steps 5 times for each db flavours.


Thanks,

Pradeep Agrawal

[jira] [Commented] (RANGER-1443) Ranger binds to 127.0.0.1 after enabling ssl

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal commented on RANGER-1443:
-

[~yujie.li] Please provide more details on this and add steps to reproduce the 
case. 

> Ranger binds to 127.0.0.1 after enabling ssl
> 
>
> Key: RANGER-1443
> URL: https://issues.apache.org/jira/browse/RANGER-1443
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
>
> With http, Ranger binds with 0.0.0.0. But after enabling ssl, it only listens 
> to 127.0.0.1 (localhost). Other IPs can't access to Ranger UI.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (RANGER-1443) Ranger binds to 127.0.0.1 after enabling ssl

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal reassigned RANGER-1443:
---

Assignee: Pradeep Agrawal

> Ranger binds to 127.0.0.1 after enabling ssl
> 
>
> Key: RANGER-1443
> URL: https://issues.apache.org/jira/browse/RANGER-1443
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
>Assignee: Pradeep Agrawal
>
> With http, Ranger binds with 0.0.0.0. But after enabling ssl, it only listens 
> to 127.0.0.1 (localhost). Other IPs can't access to Ranger UI.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (RANGER-1442) https port not configurable

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal reassigned RANGER-1442:
---

Assignee: Pradeep Agrawal

> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
>Assignee: Pradeep Agrawal
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (RANGER-1442) https port not configurable

[Pradeep Agrawal (JIRA)]

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

Pradeep Agrawal commented on RANGER-1442:
-

Hi [~yujie.li] ,

Please do not mix the shutdown port with the start port. From the patch it 
seems you are proposing to assign value of property 'ranger.service.https.port' 
to shutdown port. I agree that shutdown property 'ranger.service.shutdown.port' 
is not there in ranger-admin-site.xml but its there in 
ranger-admin-default-site.xml. In Ranger 0.6 version of EmbeddedServer.java 
'ranger-admin-default-site.xml' in not being read and that's why it seems an 
issue.

To solve this issue you can add below property in your ranger-admin-site.xml 
and restart Ranger. Apart from this property other properties of 
ranger-admin-default-site.xml can be overridden in ranger-admin-site.xml file. 
If a property is available at both file then value from ranger-admin-site.xml 
shall be used.

ranger.service.shutdown.port
6185


Please note that EmbeddedServer.java code of Ranger 0.7 branch has the 
provision to read value from both config file (ranger-admin-default-site.xml 
and ranger-admin-site.xml)


> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1415) The ranger can be opened when the user enters http://localhost:6080/ in the browser address bar. But request policy from hadoop to ranger will failed after installing hd

[Qiang Zhang (JIRA)]

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

Qiang Zhang updated RANGER-1415:

Attachment: 0001-RANGER-1415-update-The-ranger-can-be-opened-when-the.patch

> The ranger can be opened when the user enters http://localhost:6080/ in the 
> browser address bar. But request policy from hadoop to ranger will failed 
> after installing hdfs plugin if we set POLICY_MGR_URL equal to 
> http://localhost:6080/.
> 
>
> Key: RANGER-1415
> URL: https://issues.apache.org/jira/browse/RANGER-1415
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.7.0
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Minor
>  Labels: patch
> Attachments: 
> 0001-RANGER-1415-update-The-ranger-can-be-opened-when-the.patch
>
>
> The ranger can be opened when the user enters http://localhost:6080/ in the 
> browser address bar. But request policy from hadoop to ranger will failed 
> after installing hdfs plugin if we set POLICY_MGR_URL equal to 
> http://localhost:6080/.The error was as following:
> 2017-02-27 21:16:42,859 ERROR 
> org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies; 
> service not found. secureMode=false, user=root (auth:SIMPLE), response=404, 
> serviceName=hadoopdev, lastKnownVersion=4, 
> lastActivationTimeInMillis=1488246663112
> 2017-02-27 21:16:42,867 ERROR org.apache.ranger.plugin.util.PolicyRefresher: 
> PolicyRefresher(serviceName=hadoopdev): failed to find service. Will clean up 
> local cache of policies (4)
> org.apache.ranger.plugin.util.RangerServiceNotFoundException: hadoopdev
>   at 
> org.apache.ranger.plugin.util.RangerServiceNotFoundException.throwExceptionIfServiceNotFound(RangerServiceNotFoundException.java:35)
>   at 
> org.apache.ranger.admin.client.RangerAdminRESTClient.getServicePoliciesIfUpdated(RangerAdminRESTClient.java:145)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicyfromPolicyAdmin(PolicyRefresher.java:257)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:201)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:170)
> Reason:
> The brower will remove the last '/' character when the user enters 
> http://localhost:6080/ in the browser address bar. The rest request address 
> will be 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev
>  when hadoop periodically requests policy from ranger. The request will fail 
> because there are two '/' character after 'Http://localhost:6080' in 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev.
>  The result is that we can't see the hdfs plugins in audit web UI.
> The program should be compatible with this situation like the browser. 
> Scenario:
> The issue can be reoccurred after we set the value of 
> ranger.plugin.hdfs.policy.rest.url to http://localhost:6080/ in 
> ../hadoop/hadoop-2.7.3/etc/hadoop/ranger-hdfs-security.xml
> Test and verify:
> I carefully tested and verified the patch before commit the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1415) The ranger can be opened when the user enters http://localhost:6080/ in the browser address bar. But request policy from hadoop to ranger will failed after installing hd

[Qiang Zhang (JIRA)]

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

Qiang Zhang updated RANGER-1415:

Attachment: (was: 
0001-RANGER-1415-The-ranger-can-be-opened-when-the-user-e.patch)

> The ranger can be opened when the user enters http://localhost:6080/ in the 
> browser address bar. But request policy from hadoop to ranger will failed 
> after installing hdfs plugin if we set POLICY_MGR_URL equal to 
> http://localhost:6080/.
> 
>
> Key: RANGER-1415
> URL: https://issues.apache.org/jira/browse/RANGER-1415
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 0.7.0
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Minor
>  Labels: patch
> Attachments: 
> 0001-RANGER-1415-update-The-ranger-can-be-opened-when-the.patch
>
>
> The ranger can be opened when the user enters http://localhost:6080/ in the 
> browser address bar. But request policy from hadoop to ranger will failed 
> after installing hdfs plugin if we set POLICY_MGR_URL equal to 
> http://localhost:6080/.The error was as following:
> 2017-02-27 21:16:42,859 ERROR 
> org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies; 
> service not found. secureMode=false, user=root (auth:SIMPLE), response=404, 
> serviceName=hadoopdev, lastKnownVersion=4, 
> lastActivationTimeInMillis=1488246663112
> 2017-02-27 21:16:42,867 ERROR org.apache.ranger.plugin.util.PolicyRefresher: 
> PolicyRefresher(serviceName=hadoopdev): failed to find service. Will clean up 
> local cache of policies (4)
> org.apache.ranger.plugin.util.RangerServiceNotFoundException: hadoopdev
>   at 
> org.apache.ranger.plugin.util.RangerServiceNotFoundException.throwExceptionIfServiceNotFound(RangerServiceNotFoundException.java:35)
>   at 
> org.apache.ranger.admin.client.RangerAdminRESTClient.getServicePoliciesIfUpdated(RangerAdminRESTClient.java:145)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicyfromPolicyAdmin(PolicyRefresher.java:257)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:201)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:170)
> Reason:
> The brower will remove the last '/' character when the user enters 
> http://localhost:6080/ in the browser address bar. The rest request address 
> will be 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev
>  when hadoop periodically requests policy from ranger. The request will fail 
> because there are two '/' character after 'Http://localhost:6080' in 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev.
>  The result is that we can't see the hdfs plugins in audit web UI.
> The program should be compatible with this situation like the browser. 
> Scenario:
> The issue can be reoccurred after we set the value of 
> ranger.plugin.hdfs.policy.rest.url to http://localhost:6080/ in 
> ../hadoop/hadoop-2.7.3/etc/hadoop/ranger-hdfs-security.xml
> Test and verify:
> I carefully tested and verified the patch before commit the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57127: The ranger can be opened when the user enters http://localhost:6080/ in the browser address bar. But request policy from hadoop to ranger will failed after installing hdfs pl

[Qiang Zhang]

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

(Updated March 10, 2017, 3:54 a.m.)


Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
hEigeartaigh, Gautam Borad, Abhay Kulkarni, Madhan Neethiraj, Ramesh Mani, 
Selvamohan Neethiraj, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

The ranger can be opened when the user enters http://localhost:6080/ in the 
browser address bar. But request policy from hadoop to ranger will failed after 
installing hdfs plugin if we set POLICY_MGR_URL equal to 
http://localhost:6080/.The error was as following:
2017-02-27 21:16:42,859 ERROR 
org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies; 
service not found. secureMode=false, user=root (auth:SIMPLE), response=404, 
serviceName=hadoopdev, lastKnownVersion=4, 
lastActivationTimeInMillis=1488246663112
2017-02-27 21:16:42,867 ERROR org.apache.ranger.plugin.util.PolicyRefresher: 
PolicyRefresher(serviceName=hadoopdev): failed to find service. Will clean up 
local cache of policies (4)
org.apache.ranger.plugin.util.RangerServiceNotFoundException: hadoopdev
at 
org.apache.ranger.plugin.util.RangerServiceNotFoundException.throwExceptionIfServiceNotFound(RangerServiceNotFoundException.java:35)
at 
org.apache.ranger.admin.client.RangerAdminRESTClient.getServicePoliciesIfUpdated(RangerAdminRESTClient.java:145)
at 
org.apache.ranger.plugin.util.PolicyRefresher.loadPolicyfromPolicyAdmin(PolicyRefresher.java:257)
at 
org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:201)
at 
org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:170)
Reason:
The brower will remove the last '/' character when the user enters 
http://localhost:6080/ in the browser address bar. The rest request address 
will be 
http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev
 when hadoop periodically requests policy from ranger. The request will fail 
because there are two '/' character after 'Http://localhost:6080' in 
http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev.
 The result is that we can't see the hdfs plugins in audit web UI.

The program should be compatible with this situation like the browser. 

Scenario:
The issue can be reoccurred after we set the value of 
ranger.plugin.hdfs.policy.rest.url to http://localhost:6080/ in 
../hadoop/hadoop-2.7.3/etc/hadoop/ranger-hdfs-security.xml

Test and verify:
I carefully tested and verified the patch before commit the issue.


Diffs (updated)
-

  
agents-common/src/main/java/org/apache/ranger/admin/client/RangerAdminRESTClient.java
 9334607 


Diff: https://reviews.apache.org/r/57127/diff/2/

Changes: https://reviews.apache.org/r/57127/diff/1-2/


Testing
---


Thanks,

Qiang Zhang

Re: Review Request 57127: The ranger can be opened when the user enters http://localhost:6080/ in the browser address bar. But request policy from hadoop to ranger will failed after installing hdfs pl

[Qiang Zhang]

> On March 9, 2017, 4:34 p.m., Colm O hEigeartaigh wrote:
> > We need to make sure that tmpUrl is not null, otherwise there will be a NPE.
> > There is an indentation problem with the = sign in: String tmpUrl   
> > = RangerConfiguration.getInstance().get(propertyPrefix + 
> > ".policy.rest.url");
> > I'm confused by the rest of the logic. Why not do something like if (tmpUrl 
> > != null && tmpUrl.trim().endsWith("/")) {} ?

You are right. I have checked whether tmpUrl is null and updated the patch. 
Thanks.


- Qiang


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


On Feb. 28, 2017, 12:07 p.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57127/
> ---
> 
> (Updated Feb. 28, 2017, 12:07 p.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Abhay Kulkarni, Madhan Neethiraj, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1415
> https://issues.apache.org/jira/browse/RANGER-1415
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The ranger can be opened when the user enters http://localhost:6080/ in the 
> browser address bar. But request policy from hadoop to ranger will failed 
> after installing hdfs plugin if we set POLICY_MGR_URL equal to 
> http://localhost:6080/.The error was as following:
> 2017-02-27 21:16:42,859 ERROR 
> org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies; 
> service not found. secureMode=false, user=root (auth:SIMPLE), response=404, 
> serviceName=hadoopdev, lastKnownVersion=4, 
> lastActivationTimeInMillis=1488246663112
> 2017-02-27 21:16:42,867 ERROR org.apache.ranger.plugin.util.PolicyRefresher: 
> PolicyRefresher(serviceName=hadoopdev): failed to find service. Will clean up 
> local cache of policies (4)
> org.apache.ranger.plugin.util.RangerServiceNotFoundException: hadoopdev
>   at 
> org.apache.ranger.plugin.util.RangerServiceNotFoundException.throwExceptionIfServiceNotFound(RangerServiceNotFoundException.java:35)
>   at 
> org.apache.ranger.admin.client.RangerAdminRESTClient.getServicePoliciesIfUpdated(RangerAdminRESTClient.java:145)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicyfromPolicyAdmin(PolicyRefresher.java:257)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:201)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:170)
> Reason:
> The brower will remove the last '/' character when the user enters 
> http://localhost:6080/ in the browser address bar. The rest request address 
> will be 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev
>  when hadoop periodically requests policy from ranger. The request will fail 
> because there are two '/' character after 'Http://localhost:6080' in 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev.
>  The result is that we can't see the hdfs plugins in audit web UI.
> 
> The program should be compatible with this situation like the browser. 
> 
> Scenario:
> The issue can be reoccurred after we set the value of 
> ranger.plugin.hdfs.policy.rest.url to http://localhost:6080/ in 
> ../hadoop/hadoop-2.7.3/etc/hadoop/ranger-hdfs-security.xml
> 
> Test and verify:
> I carefully tested and verified the patch before commit the issue.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/admin/client/RangerAdminRESTClient.java
>  9334607 
> 
> 
> Diff: https://reviews.apache.org/r/57127/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 57488: RANGER-1435: Allow different files to be specified for unix based usersync

[Velmurugan Periasamy]

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


Fix it, then Ship it!





ugsync/src/test/resources/groupFile
Lines 1 (patched)


Include this file in rat exclude list. Otherwise build will fail with 
unapproved license.



ugsync/src/test/resources/passwordFile
Lines 1 (patched)


Include this file in rat exclude list. Otherwise build will fail with 
unapproved license.


- Velmurugan Periasamy


On March 10, 2017, 1:28 a.m., Sailaja Polavarapu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57488/
> ---
> 
> (Updated March 10, 2017, 1:28 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Gautam Borad, Abhay Kulkarni, Madhan 
> Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, and Velmurugan 
> Periasamy.
> 
> 
> Bugs: RANGER-1435
> https://issues.apache.org/jira/browse/RANGER-1435
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Made code changes to read both password file and group file from the usersync 
> configuration file instead of using hardcoded values. Also added/modified 
> corresponding unit tests.
> 
> 
> Diffs
> -
> 
>   
> ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
>  2c9365d 
>   
> ugsync/src/main/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilder.java
>  f5a4c9a 
>   
> ugsync/src/test/java/org/apache/ranger/unixusersync/process/TestUnixUserGroupBuilder.java
>  831e92d 
>   ugsync/src/test/resources/groupFile PRE-CREATION 
>   ugsync/src/test/resources/passwordFile PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57488/diff/1/
> 
> 
> Testing
> ---
> 
> 1. Successfully ran unit tests.
> 2. Also verified new & existing functionality of unix sync on cluster with 
> replacing the unixusersync jar file containing the changes.
> 
> 
> Thanks,
> 
> Sailaja Polavarapu
> 
>

Re: Review Request 56912: Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS Plugin are not in the same path.

[Qiang Zhang]

> On March 9, 2017, 2:42 p.m., Colm O hEigeartaigh wrote:
> > Please remove the 'space' before COMPONENT_INSTALL_DIR_NAME.

Ok. I have removed the space before COMPONENT_INSTALL_DIR_NAME and updated the 
patch. Thanks.


- Qiang


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


On March 10, 2017, 2:44 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56912/
> ---
> 
> (Updated March 10, 2017, 2:44 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1400
> https://issues.apache.org/jira/browse/RANGER-1400
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS 
> Plugin are not in the same path.
> 1. Install hadoop-2.7.3 under /var/local/hadoop
> 2. Copy ranger-1.0.0-SNAPSHOT-hdfs-plugin.tar.gz to /usr/local
> 3. Run command: cd /usr/local
> 4. Run command: sudo tar -zxvf ranger-1.0.0-SNAPSHOT-hdfs-plugin.tar.gz
> 5. Modified install.properties according to installation guide.
> 6. Execute enable-hdfs-plugin.sh
> result:
> ERROR: Unable to find the lib directory of component [hadoop]; dir 
> [/usr/local/hadoop/lib] not found.
> 
> Reason:
> COMPONENT_INSTALL_DIR_NAME does not exist in install.properties. So the 
> HCOMPONENT_INSTALL_DIR_NAME variable is empty when execute the following 
> sentence.
> HCOMPONENT_INSTALL_DIR_NAME=$(getInstallProperty 'COMPONENT_INSTALL_DIR_NAME')
> The result is that HCOMPONENT_LIB_DIR directory doesn't exist.
> 
> We should add COMPONENT_INSTALL_DIR_NAME parameter to install.properties. The 
> error can be avoided after setting COMPONENT_INSTALL_DIR_NAME.
> 
> Test and verify:
> I carefully tested and verified the patch before commit the issue.
> 
> 
> Diffs
> -
> 
>   hdfs-agent/scripts/install.properties 1d54025 
> 
> 
> Diff: https://reviews.apache.org/r/56912/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

[jira] [Updated] (RANGER-1400) Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS Plugin are not in the same path.

[Qiang Zhang (JIRA)]

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

Qiang Zhang updated RANGER-1400:

Attachment: (was: 
0001-RANGER-1400-Enabling-Ranger-HDFS-Plugins-failed-when.patch)

> Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS 
> Plugin are not in the same path.
> 
>
> Key: RANGER-1400
> URL: https://issues.apache.org/jira/browse/RANGER-1400
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>  Labels: patch
> Attachments: 
> 0001-RANGER-1400-updte-Enabling-Ranger-HDFS-Plugins-faile.patch
>
>
> Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS 
> Plugin are not in the same path. 
> 1. Install hadoop-2.7.3 under /var/local/hadoop
> 2. Copy ranger-1.0.0-SNAPSHOT-hdfs-plugin.tar.gz to /usr/local
> 3. Run command: cd /usr/local
> 4. Run command: sudo tar -zxvf ranger-1.0.0-SNAPSHOT-hdfs-plugin.tar.gz
> 5. Modified install.properties according to installation guide.
> 6. Execute enable-hdfs-plugin.sh
> result:
> ERROR: Unable to find the lib directory of component [hadoop];  dir 
> [/usr/local/hadoop/lib] not found.
> Reason:
> COMPONENT_INSTALL_DIR_NAME does not exist in install.properties. So the 
> HCOMPONENT_INSTALL_DIR_NAME variable is empty when execute the following 
> sentence.
>  HCOMPONENT_INSTALL_DIR_NAME=$(getInstallProperty 
> 'COMPONENT_INSTALL_DIR_NAME')
> The result is that HCOMPONENT_LIB_DIR directory doesn't exist.
> We should add COMPONENT_INSTALL_DIR_NAME parameter to install.properties. The 
> error can be avoided after setting COMPONENT_INSTALL_DIR_NAME.
> Test and verify:
> I carefully tested and verified the patch before commit the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57407: There are some duplicate keys in some js files

[Qiang Zhang]

> On 三月 9, 2017, 12:08 p.m., Colm O hEigeartaigh wrote:
> > Did you test the security admin webapp after making the change?

Yes.
I have tested and verified the patch before commit the issue.


- Qiang


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


On 三月 9, 2017, 2:12 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57407/
> ---
> 
> (Updated 三月 9, 2017, 2:12 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1430
> https://issues.apache.org/jira/browse/RANGER-1430
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> the function of '_.omit(object, *keys)' is as follows: 
> for example:
> 
> _.omit({name: 'moe', age: 50, userid: 'moe1'},'userid');
> will return 
> => {name: 'moe', age: 50}
> 
> in ranger-admin Web UI, some codes are as follows:
> 
> var attrs = _.omit(this.serverSchema, 'id', 'createDate', 'updateDate', 
> "version",
>   "createDate", "updateDate", 
> "displayOption",
>   "permList", "forUserId", "status", 
> "priGrpId",
>"updatedBy","isSystem");
> 
> the keys of 'createDate' and 'updateDate' are duplicated.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/scripts/models/RangerPolicy.js f348034 
>   security-admin/src/main/webapp/scripts/models/RangerPolicyResource.js 
> 22444d1 
>   security-admin/src/main/webapp/scripts/models/RangerService.js 9d380db 
>   security-admin/src/main/webapp/scripts/models/RangerServiceDef.js 704f378 
>   security-admin/src/main/webapp/scripts/models/UserPermission.js 505abe7 
>   security-admin/src/main/webapp/scripts/models/VXAsset.js 685d7fd 
>   security-admin/src/main/webapp/scripts/models/VXAuditMap.js 92c8704 
>   security-admin/src/main/webapp/scripts/models/VXGroup.js ca13a6b 
>   security-admin/src/main/webapp/scripts/models/VXModuleDef.js 1a5edc8 
>   security-admin/src/main/webapp/scripts/models/VXPermMap.js 99cf20d 
>   security-admin/src/main/webapp/scripts/models/VXPortalUser.js 920d205 
> 
> 
> Diff: https://reviews.apache.org/r/57407/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 57438: Disable optimization for selective download of tags to components by default

[Madhan Neethiraj]

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


Ship it!




Ship It!

- Madhan Neethiraj


On March 9, 2017, 1:44 a.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57438/
> ---
> 
> (Updated March 9, 2017, 1:44 a.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1437
> https://issues.apache.org/jira/browse/RANGER-1437
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> It is useful to download tagged entities to components even when there is no 
> enabled policy for the tag; mainly for verification and auditing purpose. 
> Therefore, by default, it is advised to disable this optimization. If tag 
> downloads are found to be a performance bottleneck, then this optimization 
> may be enabled by setting 'ranger.filter.tags.for.service.plugin' 
> configuration parameter in Ranger Admin to 'true'.
> 
> 
> Diffs
> -
> 
>   
> security-admin/src/main/java/org/apache/ranger/biz/RangerTagDBRetriever.java 
> bdac0e8 
>   security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
> 053df24 
> 
> 
> Diff: https://reviews.apache.org/r/57438/diff/1/
> 
> 
> Testing
> ---
> 
> Clean compiled, and ran all unit tests.
> 
> 
> Thanks,
> 
> Abhay Kulkarni
> 
>

[jira] [Commented] (RANGER-1435) Allow different files to be specified for unix based usersync

[Sailaja Polavarapu (JIRA)]

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

Sailaja Polavarapu commented on RANGER-1435:


Review request for ranger-0.6 branch:
https://reviews.apache.org/r/57489/

> Allow different files to be specified for unix based usersync
> -
>
> Key: RANGER-1435
> URL: https://issues.apache.org/jira/browse/RANGER-1435
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.6.3
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
> Fix For: 0.6.4, 1.0.0, 0.7.1
>
> Attachments: 
> 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch, 
> 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch
>
>
> Currently there is a provision to specify a different filename for syncing 
> users for unix based sync.
> But in the backend, ranger usersync always uses /etc/password and /etc/group.
> Ranger usersync should support different files if specified in the 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 57489: RANGER-1435: Allow different files to be specified for unix based usersync - for ranger-0.6 branch

[Sailaja Polavarapu]

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

Review request for ranger, Ankita Sinha, Gautam Borad, Abhay Kulkarni, Madhan 
Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, and Velmurugan 
Periasamy.


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


Repository: ranger


Description
---

Made similar changes as in Review request 57488 for raner-0.6 branch


Diffs
-

  
ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
 eac0073 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilder.java
 c71bc90 
  
ugsync/src/test/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilderTest.java
 e4d5456 
  ugsync/src/test/resources/groupFile PRE-CREATION 
  ugsync/src/test/resources/passwordFile PRE-CREATION 


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


Testing
---

Successfully ran unit tests.


Thanks,

Sailaja Polavarapu

[jira] [Updated] (RANGER-1435) Allow different files to be specified for unix based usersync

[Sailaja Polavarapu (JIRA)]

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

Sailaja Polavarapu updated RANGER-1435:
---
Attachment: 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch

Patch file for similar changes to ranger-0.6 branch

> Allow different files to be specified for unix based usersync
> -
>
> Key: RANGER-1435
> URL: https://issues.apache.org/jira/browse/RANGER-1435
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.6.3
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
> Fix For: 0.6.4, 1.0.0, 0.7.1
>
> Attachments: 
> 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch, 
> 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch
>
>
> Currently there is a provision to specify a different filename for syncing 
> users for unix based sync.
> But in the backend, ranger usersync always uses /etc/password and /etc/group.
> Ranger usersync should support different files if specified in the 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 56700: RANGER-1386:Ranger hdfs-plugin function not revoked after execute disable-hdfs-plugin.sh which cause hadoop-hdfs authorization failed.

[Qiang Zhang]

> On 三月 9, 2017, 5:04 p.m., Colm O hEigeartaigh wrote:
> > This should be fixed for 0.7.1 as well IMO.
> > I think the changes to "dfs.permissions.enabled/dfs.permissions" also are 
> > not really necessary, just the authorizer change.

Yes,I agree with you. 
I have tested this function and updated the patch.
Thanks!


- Qiang


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


On 三月 10, 2017, 1:45 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56700/
> ---
> 
> (Updated 三月 10, 2017, 1:45 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Colm O hEigeartaigh, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1386
> https://issues.apache.org/jira/browse/RANGER-1386
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> steps:
> 1.User yuwen does't has the permission to put a.txt in hdfs Catalog /test
> [yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
> put: Permission denied: user=yuwen, access=WRITE, 
> inode="/test/a.txt._COPYING_":xiehh:supergroup:drwxr-xr-x
> 
> 2.Execute enable-hdfs-plugin.sh and Restart hadoop-hdfs, ranger authorization 
> control enabled. 
> We add policy to give permission for user yuwen to put a file in web UI.
> [yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
> [yuwen@zdh41 bin]$ ./hdfs dfs -ls /test
> Found 1 items
> -rw-r--r--   3 yuwen supergroup 15 2017-02-20 17:07 /test/a.txt
> 
> 3. Execute disable-hdfs-plugin.sh and Restart hadoop-hdfs
> user yuwen shouldn't have the permission to put a file in Catalog /test
> but he also has the rights ,ranger hdfs-plugin function not revoked
> This is a serious problem which cause hadoop-hdfs authorization failed.
> 
> 
> Diffs
> -
> 
>   hdfs-agent/disable-conf/hdfs-site-changes.cfg PRE-CREATION 
>   src/main/assembly/hdfs-agent.xml 63e426a 
> 
> 
> Diff: https://reviews.apache.org/r/56700/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 56700: RANGER-1386:Ranger hdfs-plugin function not revoked after execute disable-hdfs-plugin.sh which cause hadoop-hdfs authorization failed.

[Qiang Zhang]

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

(Updated 三月 10, 2017, 1:45 a.m.)


Review request for ranger, Don Bosco Durai, Colm O hEigeartaigh, Ramesh Mani, 
Selvamohan Neethiraj, and Velmurugan Periasamy.


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


Repository: ranger


Description
---

steps:
1.User yuwen does't has the permission to put a.txt in hdfs Catalog /test
[yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
put: Permission denied: user=yuwen, access=WRITE, 
inode="/test/a.txt._COPYING_":xiehh:supergroup:drwxr-xr-x

2.Execute enable-hdfs-plugin.sh and Restart hadoop-hdfs, ranger authorization 
control enabled. 
We add policy to give permission for user yuwen to put a file in web UI.
[yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
[yuwen@zdh41 bin]$ ./hdfs dfs -ls /test
Found 1 items
-rw-r--r--   3 yuwen supergroup 15 2017-02-20 17:07 /test/a.txt

3. Execute disable-hdfs-plugin.sh and Restart hadoop-hdfs
user yuwen shouldn't have the permission to put a file in Catalog /test
but he also has the rights ,ranger hdfs-plugin function not revoked
This is a serious problem which cause hadoop-hdfs authorization failed.


Diffs (updated)
-

  hdfs-agent/disable-conf/hdfs-site-changes.cfg PRE-CREATION 
  src/main/assembly/hdfs-agent.xml 63e426a 


Diff: https://reviews.apache.org/r/56700/diff/2/

Changes: https://reviews.apache.org/r/56700/diff/1-2/


Testing
---


Thanks,

Qiang Zhang

[jira] [Updated] (RANGER-1386) ranger hdfs-plugin function not revoked after execute disable-hdfs-plugin.sh which cause hadoop-hdfs authorization failed.

[Qiang Zhang (JIRA)]

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

Qiang Zhang updated RANGER-1386:

Attachment: 0001-RANGER-1386.patch

> ranger hdfs-plugin function not revoked after execute disable-hdfs-plugin.sh 
> which cause hadoop-hdfs authorization failed.
> --
>
> Key: RANGER-1386
> URL: https://issues.apache.org/jira/browse/RANGER-1386
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
> Attachments: 0001-RANGER-1386.patch
>
>
> steps:
> 1.User yuwen does't has the permission to put a.txt in hdfs Catalog /test
> [yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
> put: Permission denied: user=yuwen, access=WRITE, 
> inode="/test/a.txt._COPYING_":xiehh:supergroup:drwxr-xr-x
> 2.Execute enable-hdfs-plugin.sh and Restart hadoop-hdfs, ranger authorization 
> control enabled. 
> We add policy to give permission for user yuwen to put a file in web UI.
> [yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
> [yuwen@zdh41 bin]$ ./hdfs dfs -ls /test
> Found 1 items
> -rw-r--r--   3 yuwen supergroup 15 2017-02-20 17:07 /test/a.txt
> 3. Execute disable-hdfs-plugin.sh and Restart hadoop-hdfs
> user yuwen shouldn't have the permission to put a file in Catalog /test
> but he also has the rights ,ranger hdfs-plugin function not revoked
> This is a serious problem which cause hadoop-hdfs authorization failed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (RANGER-1412) Start hadoop failed after enabling ranger HDFS plugins

[Qiang Zhang (JIRA)]

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

Qiang Zhang resolved RANGER-1412.
-
   Resolution: Fixed
Fix Version/s: 1.0.0

> Start hadoop failed after enabling ranger HDFS plugins
> --
>
> Key: RANGER-1412
> URL: https://issues.apache.org/jira/browse/RANGER-1412
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 1.0.0
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Critical
>  Labels: patch
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1412-Start-hadoop-failed-after-enabling-range.patch
>
>
> Start hadoop failed after enabling ranger HDFS plugins. The error information 
> is as following:
> 2017-02-27 02:34:58,885 ERROR 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem: FSNamesystem 
> initialization failed.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
>   at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:134)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:843)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:673)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:585)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:645)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:812)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:796)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1493)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1559)
> ...
>   at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.init(RangerHdfsAuthorizer.java:64)
>   at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.(RangerHdfsAuthorizer.java:43)
>   at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown Source)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at java.lang.Class.newInstance(Class.java:383)
>   at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.init(RangerHdfsAuthorizer.java:64)
>   at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.(RangerHdfsAuthorizer.java:43)
>   at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown Source)
> 2017-02-27 02:34:58,922 INFO org.apache.hadoop.util.ExitUtil: Exiting with 
> status 1
> The cause of the issue is that the enable-hdfs-plugin.sh was done as 
> following.
> 1. Link ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-impl to 
> /var/local/hadoop/hadoop-2.7.3/lib/ranger-hdfs-plugin-impl
> 2. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
> 3. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
> lrwxrwxrwx  1 root root   72 Feb 27 02:33 ranger-hdfs-plugin-impl -> 
> /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-impl/
> lrwxrwxrwx  1 root root   91 Feb 27 02:33 
> ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar -> 
> /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
> lrwxrwxrwx  1 root root   93 Feb 27 02:33 
> ranger-plugin-classloader-1.0.0-SNAPSHOT.jar -> 
> /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
> The above link are error. The hadoop can not find dependent packages when 
> starting. They should link as following.
> 1. Link ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-impl to 
> /var/local/hadoop/hadoop-2.7.3/share/hadoop/hdfs/lib/ranger-hdfs-plugin-impl
> 2. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/share/hadoop/hdfs/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
> 3. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/share/hadoop/hdfs/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
> The program install path is as following:
> 1. Install pseudo distributions hadoop. It's path is 
> /var/local/hadoop/hadoop-2.7.3.
> 2. ranger hdfs plugin path is /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin.
> Test and verify:
> I carefully tested and verified the patch before commit the 

[jira] [Updated] (RANGER-1435) Allow different files to be specified for unix based usersync

[Sailaja Polavarapu (JIRA)]

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

Sailaja Polavarapu updated RANGER-1435:
---
Attachment: 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch

> Allow different files to be specified for unix based usersync
> -
>
> Key: RANGER-1435
> URL: https://issues.apache.org/jira/browse/RANGER-1435
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.6.3
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
> Fix For: 0.6.4, 1.0.0, 0.7.1
>
> Attachments: 
> 0001-RANGER-1435-Allow-different-files-to-be-specified-fo.patch
>
>
> Currently there is a provision to specify a different filename for syncing 
> users for unix based sync.
> But in the backend, ranger usersync always uses /etc/password and /etc/group.
> Ranger usersync should support different files if specified in the 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Review Request 57488: RANGER-1435: Allow different files to be specified for unix based usersync

[Sailaja Polavarapu]

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

Review request for ranger, Ankita Sinha, Gautam Borad, Abhay Kulkarni, Madhan 
Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, and Velmurugan 
Periasamy.


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


Repository: ranger


Description
---

Made code changes to read both password file and group file from the usersync 
configuration file instead of using hardcoded values. Also added/modified 
corresponding unit tests.


Diffs
-

  
ugsync/src/main/java/org/apache/ranger/unixusersync/config/UserGroupSyncConfig.java
 2c9365d 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/UnixUserGroupBuilder.java
 f5a4c9a 
  
ugsync/src/test/java/org/apache/ranger/unixusersync/process/TestUnixUserGroupBuilder.java
 831e92d 
  ugsync/src/test/resources/groupFile PRE-CREATION 
  ugsync/src/test/resources/passwordFile PRE-CREATION 


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


Testing
---

Successfully ran unit tests.


Thanks,

Sailaja Polavarapu

[jira] [Resolved] (RANGER-1439) Spelling error for "fileStats" in the hdfs-agent\src\main\java\org\apache\ranger\services\hdfs\client\HdfsClient.java. "fileStatus" instead of "fileStats".

[Qiang Zhang (JIRA)]

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

Qiang Zhang resolved RANGER-1439.
-
   Resolution: Fixed
Fix Version/s: 1.0.0

> Spelling error for "fileStats" in the 
> hdfs-agent\src\main\java\org\apache\ranger\services\hdfs\client\HdfsClient.java.
>  "fileStatus" instead of "fileStats".
> ---
>
> Key: RANGER-1439
> URL: https://issues.apache.org/jira/browse/RANGER-1439
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Affects Versions: 1.0.0
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1439-Spelling-error-for-fileStats-in-the-hdfs.patch
>
>
> Spelling error for "fileStats" in the 
> hdfs-agent\src\main\java\org\apache\ranger\services\hdfs\client\HdfsClient.java.
>  "fileStatus" instead of "fileStats".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (RANGER-1432) Do some code improvement in UserMgr.java

[Qiang Zhang (JIRA)]

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

Qiang Zhang resolved RANGER-1432.
-
Resolution: Fixed

> Do some code improvement in UserMgr.java
> 
>
> Key: RANGER-1432
> URL: https://issues.apache.org/jira/browse/RANGER-1432
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 1.0.0
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
> Fix For: 1.0.0
>
>
> In UserMgr.java, there are some duplicate logic.
> 1. At the beginning of method gjUserToUserProfile, we have already checked if 
> sess is null, so we don't need to check it again in below codes.
> {code}
> UserSessionBase sess = ContextUtil.getCurrentUserSession();
> if (sess == null) {
>   return;
> }
> if (sess != null) {
>   userProfile.setUserSource(sess.getAuthProvider());
> } 
> {code}
> 2. In method setUserRoles, it should be 'vStringRolesList' instead of 
> 'vString' in comment.
> {code}
> /**
>* @param userId
>* @param vStrings
>*/
>   public void setUserRoles(Long userId, List vStringRolesList)
> {code}
> 3. In method deactivateUser, it should be 'gjUser' instead of 'userId' in 
> comment.
> {code}
> /**
>* @param userId
>*/
>   public VXPortalUser deactivateUser(XXPortalUser gjUser)
> {code}
> 4. In method gjUserToUserProfile, below validation appears twice. 
> {code}
> if (sess.isUserAdmin() || sess.isKeyAdmin()
>   || 
> sess.getXXPortalUser().getId().equals(user.getId())) {
>   userProfile.setLoginId(user.getLoginId());
> }
> if (sess.isUserAdmin() || sess.isKeyAdmin()
>   || 
> sess.getXXPortalUser().getId().equals(user.getId())) {
>   userProfile.setId(user.getId());
> }
> {code}
> IMO, we can put them together.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (RANGER-1442) https port not configurable

[Jeffrey E Rodriguez (JIRA)]

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

Jeffrey E  Rodriguez edited comment on RANGER-1442 at 3/10/17 12:53 AM:


Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is used) as : 
int sslPort = 
getIntConfig("ranger.service.https.port",DEFAULT_SHUTDOWN_PORT");
int shutdownPort = getIntConfig("ranger.service.shutdown.port",sslPort 
);







was (Author: jeffreyr97):
Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is used) as : 
int shutdownPort = getIntConfig("ranger.service.shutdown.port", 
"ranger.service.https.port" )
If we do that when we may want to  get rid of DEFAULT_SHUTDOWN_PORT constant.





> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (RANGER-1442) https port not configurable

[Jeffrey E Rodriguez (JIRA)]

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

Jeffrey E  Rodriguez edited comment on RANGER-1442 at 3/10/17 12:46 AM:


Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is used) as : 
int shutdownPort = getIntConfig("ranger.service.shutdown.port", 
"ranger.service.https.port" )
If we do that when we may want to  get rid of DEFAULT_SHUTDOWN_PORT constant.






was (Author: jeffreyr97):
Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is used) as : 
int shutdownPort = getIntConfig("ranger.service.shutdown.port", 
""ranger.service.https.port"" )
If we do that when we may want to  get rid of DEFAULT_SHUTDOWN_PORT constant.





> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (RANGER-1442) https port not configurable

[Jeffrey E Rodriguez (JIRA)]

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

Jeffrey E  Rodriguez edited comment on RANGER-1442 at 3/10/17 12:41 AM:


Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is used) as : 
int shutdownPort = getIntConfig("ranger.service.shutdown.port", 
""ranger.service.https.port"" )
If we do that when we may want to  get rid of DEFAULT_SHUTDOWN_PORT constant.






was (Author: jeffreyr97):
Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is defined) as : 
int shutdownPort = getIntConfig("ranger.service.shutdown.port", 
""ranger.service.https.port"" )
If we do that when we may want to  get rid of DEFAULT_SHUTDOWN_PORT constant.





> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (RANGER-1434) Enable Group Search First causes issues when "Enable Group Sync" is disabled

[Sailaja Polavarapu (JIRA)]

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

Sailaja Polavarapu commented on RANGER-1434:


Committed to master, ranger-0.7, and ranger-0.6

> Enable Group Search First causes issues when "Enable Group Sync" is disabled
> 
>
> Key: RANGER-1434
> URL: https://issues.apache.org/jira/browse/RANGER-1434
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger, usersync
>Affects Versions: 0.7.0, 0.6.3
>Reporter: Sailaja Polavarapu
>Assignee: Sailaja Polavarapu
> Fix For: 0.6.4, 1.0.0, 0.7.1
>
> Attachments: 
> 0001-RANGER-1434-Enable-Group-Search-First-causes-issues-.patch, 
> 0001-RANGER-1434-Enable-Group-Search-First-causes-issues-.patch
>
>
> If "Enable Group Search First" = "Yes" in Ambari, this feature (group sync) 
> runs in Usersync even if "Enable Group Sync" = NO.
> Setting "Enable Group Sync" = "No" hides all values related to group search, 
> including Enable Group Search First.
> This caused me two problems:
> 1) Errors in usersync.log due to invalid values in "Group Search Base". 
> Removing this and adding a space for the value got rid of those errors.
> 2) No users synced even after fixing the errors because the group search 
> failed to find users, even though group search was disabled via "Enable Group 
> Sync" being set to No.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (RANGER-1442) https port not configurable

[Jeffrey E Rodriguez (JIRA)]

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

Jeffrey E  Rodriguez commented on RANGER-1442:
--

Hi Yu Jie,
 I wonder if instead of treating DEFAULT_SHUTDOWN_PORT as a variable which 
may be incorrect from code style point of view. If we want to set the 
shutdownPort to SSL port you could change (in the 2 places where 
DEFAULT_SHUTDOWN is defined) as : 
int shutdownPort = getIntConfig("ranger.service.shutdown.port", 
""ranger.service.https.port"" )
If we do that when we may want to also get rid of DEFAULT_SHUTDOWN_PORT.





> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1145) Policy engine optimization: convert wildcard matches into prefix and suffix match

[Abhay Kulkarni (JIRA)]

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

Abhay Kulkarni updated RANGER-1145:
---
Fix Version/s: 0.6.0

> Policy engine optimization: convert wildcard matches into prefix and suffix 
> match
> -
>
> Key: RANGER-1145
> URL: https://issues.apache.org/jira/browse/RANGER-1145
> Project: Ranger
>  Issue Type: Bug
>  Components: plugins
>Reporter: Madhan Neethiraj
>Assignee: Abhay Kulkarni
> Fix For: 0.6.0
>
>
> Ranger policies support resource values with wildcards - like test*, *.txt, 
> /finance/*. For values that have wildcards at the beginning or at the end, 
> which is likely to be most common, the match can be converted into endsWith() 
> or startsWith() - which will be more efficient than doing a wildcard match.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (RANGER-1442) https port not configurable

[Yujie Li (JIRA)]

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

Yujie Li commented on RANGER-1442:
--

this patch enables Ranger to read the value from ranger-admin-site.xml for ssl 
port.

> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1442) https port not configurable

[Yujie Li (JIRA)]

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

Yujie Li updated RANGER-1442:
-
Attachment: 0001-RANGER-1442-https-port-not-configurable.patch

> https port not configurable
> ---
>
> Key: RANGER-1442
> URL: https://issues.apache.org/jira/browse/RANGER-1442
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Affects Versions: 0.6.2
>Reporter: Yujie Li
> Fix For: 0.6.2
>
> Attachments: 0001-RANGER-1442-https-port-not-configurable.patch
>
>
> Ranger doesn't take the https port value (default 6182) from 
> ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (RANGER-1442) https port not configurable

[Yujie Li (JIRA)]

Yujie Li created RANGER-1442:


 Summary: https port not configurable
 Key: RANGER-1442
 URL: https://issues.apache.org/jira/browse/RANGER-1442
 Project: Ranger
  Issue Type: Bug
  Components: admin
Affects Versions: 0.6.2
Reporter: Yujie Li
 Fix For: 0.6.2


Ranger doesn't take the https port value (default 6182) from 
ranger-admin-site.xml and uses hardcoded value (6185) after enabling SSL



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (RANGER-1392) Hive test connection is failing even if jdbc.url configured is correct in Ranger 0.7.0

[Sailaja Polavarapu (JIRA)]

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

Sailaja Polavarapu reopened RANGER-1392:


Reverted changes from Master and ranger-0.7 branches as it is causing issues 
with ranger deployment 

> Hive test connection is failing even if jdbc.url configured is correct in 
> Ranger 0.7.0
> --
>
> Key: RANGER-1392
> URL: https://issues.apache.org/jira/browse/RANGER-1392
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Deepak Sharma
>Assignee: Sailaja Polavarapu
> Fix For: 0.7.0, 1.0.0, 0.7.1
>
> Attachments: 
> 0001-RANGER-1392-Hive-test-connection-is-failing-even-if-.patch
>
>
> even if jdbc.url is correct then also ranger hive test connection is failing.
> jdbc.url is configured to 
> jdbc:hive2://ctr-e127-1486658464320-1453-01-04.hwx.site:2181,ctr-e127-1486658464320-1453-01-03.hwx.site:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2;principal=hive/_h...@example.com;transportMode=http;httpPath=cliservice;ssl=true;sslTrustStore=/etc/security/serverKeys/hivetruststore.jks;trustStorePassword=changeit
> but during test connection it gives error:
> org.apache.ranger.plugin.client.HadoopException: Unable to connect to Hive 
> Thrift Server instance.. 
> Unable to connect to Hive Thrift Server instance.. 
> Could not establish connection to 
> jdbc:hive2://ctr-e127-1486658464320-1453-01-04.hwx.site:10001/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2;principal=hive/_h...@example.com;transportMode=http;httpPath=cliservice;ssl=true;sslTrustStore=/etc/security/serverKeys/hivetruststore.jks;trustStorePassword=changeit:
>  org.apache.hive.org.apache.http.client.ClientProtocolException. 
> org.apache.hive.org.apache.http.client.ClientProtocolException. 
> java.lang.RuntimeException: class 
> org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback not 
> org.apache.hive.org.apache.hadoop.security.GroupMappingServiceProvider. 
> class org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback not 
> org.apache.hive.org.apache.hadoop.security.GroupMappingServiceProvider. 
> problem is during test connection hiveserver2 url is used 
> dbc:hive2://ctr-e127-1486658464320-1453-01-04.hwx.site:10001/; and 
> servicediscovery mode is zookeeper,
> tried to connect manually to this url , it failed due to same error, but when 
> remove zookeeper service discovery parameter then i was able to connect using 
> beeline.
> so it seems somewhere this url is being modified.
> This happens in non WE clusters as well. Though the error is somewhat 
> different:
> 2017-02-16 00:24:23,432 [timed-executor-pool-0] INFO  
> org.apache.ranger.plugin.client.BaseClient (BaseClient.java:125) - Init 
> Lookup Login: security enabled, using lookupPrincipal/lookupKeytab
> 2017-02-16 00:24:23,436 [timed-executor-pool-0] INFO  
> apache.ranger.services.hive.client.HiveClient (HiveClient.java:67) - Secured 
> Mode: JDBC Connection done with preAuthenticated Subject
> 2017-02-16 00:24:23,481 [timed-executor-pool-0] ERROR 
> apache.ranger.services.hive.client.HiveClient (HiveClient.java:433) - Unable 
> to Connect to Hive
> org.apache.ranger.plugin.client.HadoopException: Unable to connect to Hive 
> Thrift Server instance
>   at 
> org.apache.ranger.services.hive.client.HiveClient.initConnection(HiveClient.java:549)
> As per [~rmani]: 
> Issue being this class 
> org.apache.hive.org.apache.hadoop.security.GroupMappingServiceProvider from 
> hive-jdbc-1.2.1000.2.6.0.0-*-standalone.jar is getting loaded by ranger 
> class-loader where as 
> org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback is loaded by 
> Tomcat class-loader. 
> One way to fix is to pack hive-jdbc-1.2.1000.2.6.0.0-*-standalone.jar in 
> /usr/hdp/2.6.0.0-*/ranger-admin/ews/webapp/WEB-INF/lib so the type issue will 
> be resolved.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 56700: RANGER-1386:Ranger hdfs-plugin function not revoked after execute disable-hdfs-plugin.sh which cause hadoop-hdfs authorization failed.

[Colm O hEigeartaigh]

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



This should be fixed for 0.7.1 as well IMO.
I think the changes to "dfs.permissions.enabled/dfs.permissions" also are not 
really necessary, just the authorizer change.

- Colm O hEigeartaigh


On Feb. 20, 2017, 9:06 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56700/
> ---
> 
> (Updated Feb. 20, 2017, 9:06 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Colm O hEigeartaigh, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1386
> https://issues.apache.org/jira/browse/RANGER-1386
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> steps:
> 1.User yuwen does't has the permission to put a.txt in hdfs Catalog /test
> [yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
> put: Permission denied: user=yuwen, access=WRITE, 
> inode="/test/a.txt._COPYING_":xiehh:supergroup:drwxr-xr-x
> 
> 2.Execute enable-hdfs-plugin.sh and Restart hadoop-hdfs, ranger authorization 
> control enabled. 
> We add policy to give permission for user yuwen to put a file in web UI.
> [yuwen@zdh41 bin]$ ./hdfs dfs -put /home/xiehh/a.txt /test
> [yuwen@zdh41 bin]$ ./hdfs dfs -ls /test
> Found 1 items
> -rw-r--r--   3 yuwen supergroup 15 2017-02-20 17:07 /test/a.txt
> 
> 3. Execute disable-hdfs-plugin.sh and Restart hadoop-hdfs
> user yuwen shouldn't have the permission to put a file in Catalog /test
> but he also has the rights ,ranger hdfs-plugin function not revoked
> This is a serious problem which cause hadoop-hdfs authorization failed.
> 
> 
> Diffs
> -
> 
>   hdfs-agent/disable-conf/hdfs-site-changes.cfg PRE-CREATION 
>   src/main/assembly/hdfs-agent.xml 63e426a 
> 
> 
> Diff: https://reviews.apache.org/r/56700/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 57127: The ranger can be opened when the user enters http://localhost:6080/ in the browser address bar. But request policy from hadoop to ranger will failed after installing hdfs pl

[Colm O hEigeartaigh]

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



We need to make sure that tmpUrl is not null, otherwise there will be a NPE.
There is an indentation problem with the = sign in: String tmpUrl   
= RangerConfiguration.getInstance().get(propertyPrefix + 
".policy.rest.url");
I'm confused by the rest of the logic. Why not do something like if (tmpUrl != 
null && tmpUrl.trim().endsWith("/")) {} ?

- Colm O hEigeartaigh


On Feb. 28, 2017, 12:07 p.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57127/
> ---
> 
> (Updated Feb. 28, 2017, 12:07 p.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Abhay Kulkarni, Madhan Neethiraj, Ramesh Mani, 
> Selvamohan Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1415
> https://issues.apache.org/jira/browse/RANGER-1415
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The ranger can be opened when the user enters http://localhost:6080/ in the 
> browser address bar. But request policy from hadoop to ranger will failed 
> after installing hdfs plugin if we set POLICY_MGR_URL equal to 
> http://localhost:6080/.The error was as following:
> 2017-02-27 21:16:42,859 ERROR 
> org.apache.ranger.admin.client.RangerAdminRESTClient: Error getting policies; 
> service not found. secureMode=false, user=root (auth:SIMPLE), response=404, 
> serviceName=hadoopdev, lastKnownVersion=4, 
> lastActivationTimeInMillis=1488246663112
> 2017-02-27 21:16:42,867 ERROR org.apache.ranger.plugin.util.PolicyRefresher: 
> PolicyRefresher(serviceName=hadoopdev): failed to find service. Will clean up 
> local cache of policies (4)
> org.apache.ranger.plugin.util.RangerServiceNotFoundException: hadoopdev
>   at 
> org.apache.ranger.plugin.util.RangerServiceNotFoundException.throwExceptionIfServiceNotFound(RangerServiceNotFoundException.java:35)
>   at 
> org.apache.ranger.admin.client.RangerAdminRESTClient.getServicePoliciesIfUpdated(RangerAdminRESTClient.java:145)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicyfromPolicyAdmin(PolicyRefresher.java:257)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.loadPolicy(PolicyRefresher.java:201)
>   at 
> org.apache.ranger.plugin.util.PolicyRefresher.run(PolicyRefresher.java:170)
> Reason:
> The brower will remove the last '/' character when the user enters 
> http://localhost:6080/ in the browser address bar. The rest request address 
> will be 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev
>  when hadoop periodically requests policy from ranger. The request will fail 
> because there are two '/' character after 'Http://localhost:6080' in 
> http://localhost:6080//service/plugins/policies/download/hadoopdev?lastKnownVersion=-1=0=hdfs@VBoxNodeEng-1-hadoopdev.
>  The result is that we can't see the hdfs plugins in audit web UI.
> 
> The program should be compatible with this situation like the browser. 
> 
> Scenario:
> The issue can be reoccurred after we set the value of 
> ranger.plugin.hdfs.policy.rest.url to http://localhost:6080/ in 
> ../hadoop/hadoop-2.7.3/etc/hadoop/ranger-hdfs-security.xml
> 
> Test and verify:
> I carefully tested and verified the patch before commit the issue.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/admin/client/RangerAdminRESTClient.java
>  9334607 
> 
> 
> Diff: https://reviews.apache.org/r/57127/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Review Request 57084: RANGER-1412:Start hadoop failed after enabling ranger HDFS plugins

[Colm O hEigeartaigh]

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


Ship it!




Ship It!

- Colm O hEigeartaigh


On Feb. 28, 2017, 8:37 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57084/
> ---
> 
> (Updated Feb. 28, 2017, 8:37 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1412
> https://issues.apache.org/jira/browse/RANGER-1412
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Start hadoop failed after enabling ranger HDFS plugins. The error information 
> is as following:
> 2017-02-27 02:34:58,885 ERROR 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem: FSNamesystem 
> initialization failed.
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at 
> org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:134)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:843)
> at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:673)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:585)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:645)
> at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:812)
> at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:796)
> at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1493)
> at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1559)
> ...
> at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.init(RangerHdfsAuthorizer.java:64)
> at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.(RangerHdfsAuthorizer.java:43)
> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown Source)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:383)
> at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.init(RangerHdfsAuthorizer.java:64)
> at 
> org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer.(RangerHdfsAuthorizer.java:43)
> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown Source)
> 2017-02-27 02:34:58,922 INFO org.apache.hadoop.util.ExitUtil: Exiting with 
> status 1
> 
> The cause of the issue is that the enable-hdfs-plugin.sh was done as 
> following.
> 1. Link ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-impl to 
> /var/local/hadoop/hadoop-2.7.3/lib/ranger-hdfs-plugin-impl
> 2. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
> 3. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
> 
> lrwxrwxrwx 1 root root 72 Feb 27 02:33 ranger-hdfs-plugin-impl -> 
> /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-impl/
> lrwxrwxrwx 1 root root 91 Feb 27 02:33 
> ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar -> 
> /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
> lrwxrwxrwx 1 root root 93 Feb 27 02:33 
> ranger-plugin-classloader-1.0.0-SNAPSHOT.jar -> 
> /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
> 
> The above link are error. The hadoop can not find dependent packages when 
> starting. They should link as following.
> 1. Link ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-impl to 
> /var/local/hadoop/hadoop-2.7.3/share/hadoop/hdfs/lib/ranger-hdfs-plugin-impl
> 2. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/share/hadoop/hdfs/lib/ranger-hdfs-plugin-shim-1.0.0-SNAPSHOT.jar
> 3. Link 
> ranger-1.0.0-SNAPSHOT-hdfs-plugin/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
>  to 
> /var/local/hadoop/hadoop-2.7.3/share/hadoop/hdfs/lib/ranger-plugin-classloader-1.0.0-SNAPSHOT.jar
> 
> The program install path is as following:
> 1. Install pseudo distributions hadoop. It's path is 
> /var/local/hadoop/hadoop-2.7.3.
> 2. ranger hdfs plugin path is /usr/local/ranger-1.0.0-SNAPSHOT-hdfs-plugin.
> 
> Test and verify:
> I carefully tested and verified the patch before commit the issue.
> 
> 
> Diffs
> -

Re: Review Request 56912: Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS Plugin are not in the same path.

[Colm O hEigeartaigh]

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



Please remove the 'space' before COMPONENT_INSTALL_DIR_NAME.

- Colm O hEigeartaigh


On Feb. 28, 2017, 8:39 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56912/
> ---
> 
> (Updated Feb. 28, 2017, 8:39 a.m.)
> 
> 
> Review request for ranger, Alok Lal, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1400
> https://issues.apache.org/jira/browse/RANGER-1400
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Enabling Ranger HDFS Plugins failed when hadoop program and Ranger HDFS 
> Plugin are not in the same path.
> 1. Install hadoop-2.7.3 under /var/local/hadoop
> 2. Copy ranger-1.0.0-SNAPSHOT-hdfs-plugin.tar.gz to /usr/local
> 3. Run command: cd /usr/local
> 4. Run command: sudo tar -zxvf ranger-1.0.0-SNAPSHOT-hdfs-plugin.tar.gz
> 5. Modified install.properties according to installation guide.
> 6. Execute enable-hdfs-plugin.sh
> result:
> ERROR: Unable to find the lib directory of component [hadoop]; dir 
> [/usr/local/hadoop/lib] not found.
> 
> Reason:
> COMPONENT_INSTALL_DIR_NAME does not exist in install.properties. So the 
> HCOMPONENT_INSTALL_DIR_NAME variable is empty when execute the following 
> sentence.
> HCOMPONENT_INSTALL_DIR_NAME=$(getInstallProperty 'COMPONENT_INSTALL_DIR_NAME')
> The result is that HCOMPONENT_LIB_DIR directory doesn't exist.
> 
> We should add COMPONENT_INSTALL_DIR_NAME parameter to install.properties. The 
> error can be avoided after setting COMPONENT_INSTALL_DIR_NAME.
> 
> Test and verify:
> I carefully tested and verified the patch before commit the issue.
> 
> 
> Diffs
> -
> 
>   hdfs-agent/scripts/install.properties 148d2ba 
> 
> 
> Diff: https://reviews.apache.org/r/56912/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Re: Apache Ranger & Docker

[Gautam Borad]

Hi Nigel, There is one docker available at :
https://github.com/chuyqa/dockerfiles.

Long term we should add one Dockerfile to Apache Ranger itself, and update
the wiki with instructions on how to build it. This will help new
contributors get up to speed fast! Thanks.

On Wed, Mar 8, 2017 at 11:06 PM, Nigel Jones  wrote:

> Has anyone happened to build a docker image for a ranger runtime (ie apart
> from the actual plugins). I know I could use a full HDP docker image, but
> I'm after something simpler/meaner & easily built off the current ranger
> source.
>
> I'm doing some work with Ranger currently, and looking at building a new
> plugin, and would like to easily share an example ranger environment with
> colleagues -- and have a easily repeatable environment for my own
> experimentation
>
> If not I guess I'll try to make one :-)
>
> Thanks
> nigel.
>
>


-- 
Regards,
Gautam.

Re: Request to make me contributor in Apache Ranger

[Selvamohan Neethiraj]

Hi Bhavik,

What is your JIRA identifier? If you do not have one, please create a JIRA id 
from https://issues.apache.org/jira and let me know your username in JIRA 
system.

Thanks,
Selva-


On 3/8/17, 11:45 PM, "Bhavik Patel"  wrote:

Rangers:

As I have been involved in the Apache Ranger project for a while now, Can
you please add me as a contributor to the project ?


Thanks,
Bhavik Patel

Re: Review Request 57407: There are some duplicate keys in some js files

[Colm O hEigeartaigh]

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



Did you test the security admin webapp after making the change?

- Colm O hEigeartaigh


On March 9, 2017, 2:12 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57407/
> ---
> 
> (Updated March 9, 2017, 2:12 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1430
> https://issues.apache.org/jira/browse/RANGER-1430
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> the function of '_.omit(object, *keys)' is as follows: 
> for example:
> 
> _.omit({name: 'moe', age: 50, userid: 'moe1'},'userid');
> will return 
> => {name: 'moe', age: 50}
> 
> in ranger-admin Web UI, some codes are as follows:
> 
> var attrs = _.omit(this.serverSchema, 'id', 'createDate', 'updateDate', 
> "version",
>   "createDate", "updateDate", 
> "displayOption",
>   "permList", "forUserId", "status", 
> "priGrpId",
>"updatedBy","isSystem");
> 
> the keys of 'createDate' and 'updateDate' are duplicated.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/webapp/scripts/models/RangerPolicy.js f348034 
>   security-admin/src/main/webapp/scripts/models/RangerPolicyResource.js 
> 22444d1 
>   security-admin/src/main/webapp/scripts/models/RangerService.js 9d380db 
>   security-admin/src/main/webapp/scripts/models/RangerServiceDef.js 704f378 
>   security-admin/src/main/webapp/scripts/models/UserPermission.js 505abe7 
>   security-admin/src/main/webapp/scripts/models/VXAsset.js 685d7fd 
>   security-admin/src/main/webapp/scripts/models/VXAuditMap.js 92c8704 
>   security-admin/src/main/webapp/scripts/models/VXGroup.js ca13a6b 
>   security-admin/src/main/webapp/scripts/models/VXModuleDef.js 1a5edc8 
>   security-admin/src/main/webapp/scripts/models/VXPermMap.js 99cf20d 
>   security-admin/src/main/webapp/scripts/models/VXPortalUser.js 920d205 
> 
> 
> Diff: https://reviews.apache.org/r/57407/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

Review Request 57456: RANGER-1441 - Remove MapUtils.EMPTY_MAP

[Colm O hEigeartaigh]

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

Review request for ranger.


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


Repository: ranger


Description
---

Using MapUtils.EMPTY_MAP creates generics warnings. Instead we should just use 
a parameterized Collections.emptyMap instance.


Diffs
-

  
tagsync/src/main/java/org/apache/ranger/tagsync/source/atlas/AtlasNotificationMapper.java
 922317e 


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


Testing
---


Thanks,

Colm O hEigeartaigh

[jira] [Updated] (RANGER-1441) Remove MapUtils.EMPTY_MAP

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh updated RANGER-1441:

Attachment: 0001-RANGER-1441-Remove-MapUtils.EMPTY_MAP.patch

> Remove MapUtils.EMPTY_MAP
> -
>
> Key: RANGER-1441
> URL: https://issues.apache.org/jira/browse/RANGER-1441
> Project: Ranger
>  Issue Type: Improvement
>  Components: tagsync
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: 0001-RANGER-1441-Remove-MapUtils.EMPTY_MAP.patch
>
>
> Using MapUtils.EMPTY_MAP creates generics warnings. Instead we should just 
> use a parameterized Collections.emptyMap instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (RANGER-1441) Remove MapUtils.EMPTY_MAP

[Colm O hEigeartaigh (JIRA)]

Colm O hEigeartaigh created RANGER-1441:
---

 Summary: Remove MapUtils.EMPTY_MAP
 Key: RANGER-1441
 URL: https://issues.apache.org/jira/browse/RANGER-1441
 Project: Ranger
  Issue Type: Improvement
  Components: tagsync
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Priority: Trivial
 Fix For: 1.0.0
 Attachments: 0001-RANGER-1441-Remove-MapUtils.EMPTY_MAP.patch

Using MapUtils.EMPTY_MAP creates generics warnings. Instead we should just use 
a parameterized Collections.emptyMap instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1428) In certain scenario user data contains junk email-id

[Ankita Sinha (JIRA)]

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

Ankita Sinha updated RANGER-1428:
-
Attachment: RANGER-1428.patch

> In certain scenario user data contains junk email-id
> 
>
> Key: RANGER-1428
> URL: https://issues.apache.org/jira/browse/RANGER-1428
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.0
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
> Fix For: 0.7.1
>
> Attachments: RANGER-1428.patch
>
>
> Description:
> Junk email id is displayed in some scenario
> Steps to reproduce
> When added non-existing user while creating a service, it gets created in 
> user listing without email id but when same user is deleted it shows some 
> random data in email field in “User Profile deleted” entry
> Steps to follow:
> 1. Create a service with non-existing user(user will get created in user 
> listing)
> 2. Now delete that user
> 3. Go to Audit-Admin tab and check log for "User Profile deleted", in 
> email-id field it will show some random data



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (RANGER-1428) In certain scenario user data contains junk email-id

[Ankita Sinha (JIRA)]

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

Ankita Sinha updated RANGER-1428:
-
Attachment: (was: RANGER-1428.patch)

> In certain scenario user data contains junk email-id
> 
>
> Key: RANGER-1428
> URL: https://issues.apache.org/jira/browse/RANGER-1428
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Affects Versions: 0.7.0
>Reporter: Ankita Sinha
>Assignee: Ankita Sinha
> Fix For: 0.7.1
>
>
> Description:
> Junk email id is displayed in some scenario
> Steps to reproduce
> When added non-existing user while creating a service, it gets created in 
> user listing without email id but when same user is deleted it shows some 
> random data in email field in “User Profile deleted” entry
> Steps to follow:
> 1. Create a service with non-existing user(user will get created in user 
> listing)
> 2. Now delete that user
> 3. Go to Audit-Admin tab and check log for "User Profile deleted", in 
> email-id field it will show some random data



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57373: In certain scenario user data contains junk email-id

[Ankita Sinha]

> On March 8, 2017, 6:46 a.m., Ramesh Mani wrote:
> > security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java
> > Line 2007 (original)
> > 
> >
> > Can this be 
> > vXPortalUser.setEmailAddress(vXUser.getEmailAddress());

Thanks Ramesh, this issue is fixed and patch is updated.


- Ankita


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


On March 8, 2017, 4:22 a.m., Ankita Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57373/
> ---
> 
> (Updated March 8, 2017, 4:22 a.m.)
> 
> 
> Review request for ranger, Don Bosco Durai, Gautam Borad, Abhay Kulkarni, 
> Madhan Neethiraj, Pradeep Agrawal, Ramesh Mani, Selvamohan Neethiraj, Sailaja 
> Polavarapu, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1428
> https://issues.apache.org/jira/browse/RANGER-1428
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Junk email id is displayed in some scenario
> 
> **Steps to reproduce**
> When added non-existing user while creating a service, it gets created in 
> user listing without email id but when same user is deleted it shows some 
> random data in email field in “User Profile deleted” entry
> 
> Steps to follow:
> 1. Create a service with non-existing user(user will get created in user 
> listing)
> 2. Now delete that user
> 3. Go to Audit-Admin tab and check log for "User Profile deleted", in 
> email-id field it will show some random data
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/biz/XUserMgr.java 62cffa5 
> 
> 
> Diff: https://reviews.apache.org/r/57373/diff/2/
> 
> 
> Testing
> ---
> 
> Tested on simple as well as secure cluster
> 
> 
> Thanks,
> 
> Ankita Sinha
> 
>

Re: Review Request 57447: Spelling error for "fileStats" in the hdfs-agent\src\main\java\org\apache\ranger\services\hdfs\client\HdfsClient.java. "fileStatus" instead of "fileStats".

[Colm O hEigeartaigh]

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


Ship it!




Ship It!

- Colm O hEigeartaigh


On March 9, 2017, 6:37 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57447/
> ---
> 
> (Updated March 9, 2017, 6:37 a.m.)
> 
> 
> Review request for ranger, Ankita Sinha, Don Bosco Durai, Colm O 
> hEigeartaigh, Gautam Borad, Madhan Neethiraj, Ramesh Mani, Selvamohan 
> Neethiraj, and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1439
> https://issues.apache.org/jira/browse/RANGER-1439
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Spelling error for "fileStats" in the 
> hdfs-agent\src\main\java\org\apache\ranger\services\hdfs\client\HdfsClient.java.
>  "fileStatus" instead of "fileStats".
> 
> 
> Diffs
> -
> 
>   
> hdfs-agent/src/main/java/org/apache/ranger/services/hdfs/client/HdfsClient.java
>  d712b08 
> 
> 
> Diff: https://reviews.apache.org/r/57447/diff/1/
> 
> 
> Testing
> ---
> 
> Tested it
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>

[jira] [Assigned] (RANGER-1404) Few HIVERangerAuthorizerTest UT fails with Permission denied intermittently

[Qiang Zhang (JIRA)]

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

Qiang Zhang reassigned RANGER-1404:
---

Assignee: Qiang Zhang

> Few HIVERangerAuthorizerTest UT fails with Permission denied intermittently
> ---
>
> Key: RANGER-1404
> URL: https://issues.apache.org/jira/browse/RANGER-1404
> Project: Ranger
>  Issue Type: Bug
>  Components: Ranger
>Reporter: Yesha Vora
>Assignee: Qiang Zhang
>
> Failed tests:
> * testBobAlter
> * testBobSelectOnDifferentDatabase
> * testBobSelectOnDifferentTables
> * testCreateDropFunction
> * testCreateDropMacro
> * testGrantrevoke
> * testHiveCreateDropDatabase
> * testHiveDataMasking
> * testHiveRowFilter
> * testHiveSelectAllAsAlice
> * testHiveSelectAllAsBob
> * testHiveSelectSpecificColumnAsAlice
> * testHiveUpdateAllAsBob
> * testHiveSelectSpecificColumnAsBob
> {code}
> Error Message
> Error while compiling statement: FAILED: HiveAccessControlException 
> Permission denied: user [nobody] does not have [CREATE] privilege on 
> [rangerauthz/WORDS2]{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)