[jira] [Updated] (RANGER-1380) not able to delete group that is having special character from ranger admin

2017-02-19 Thread Mehul Parikh (JIRA)

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

Mehul Parikh updated RANGER-1380:
-
Attachment: RANGER-1380.2.patch

> not able to delete group that is having special character from ranger admin
> ---
>
> Key: RANGER-1380
> URL: https://issues.apache.org/jira/browse/RANGER-1380
> Project: Ranger
>  Issue Type: Bug
>  Components: admin, Ranger
>Affects Versions: 0.7.0
>Reporter: Deepak Sharma
>Assignee: Mehul Parikh
>Priority: Critical
> Fix For: 0.7.0
>
> Attachments: RANGER-1380.1.patch, RANGER-1380.2.patch, 
> RANGER-1380.patch
>
>
> not able to delete group that is having special character from ranger admin
> {code}org.apache.ranger.common.RESTErrorUtil (RESTErrorUtil.java:63) - 
> Request failed. loginId=admin, logMessage=groupspecial#$@& is Not Found
> javax.ws.rs.WebApplicationException
>   at 
> org.apache.ranger.common.RESTErrorUtil.createRESTException(RESTErrorUtil.java:56)
>   at 
> org.apache.ranger.common.RESTErrorUtil.createRESTException(RESTErrorUtil.java:325)
>   at 
> org.apache.ranger.service.XGroupService.getGroupByGroupName(XGroupService.java:104)
>   at 
> org.apache.ranger.rest.XUserREST.deleteGroupsByGroupName(XUserREST.java:1064)
>   at 
> org.apache.ranger.rest.XUserREST$$FastClassByCGLIB$$b2a65360.invoke()
>   at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:191)
>   at 
> org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:689)
> {code}
> problem is the input sent for special character is appended with amp after 
> the & which is causing the issue.



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


Re: Review Request 56829: Ranger-1395: LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan Zhou


> On Feb. 19, 2017, 10:34 p.m., Selvamohan Neethiraj wrote:
> > Can you please provide little more details on how the manual testing was 
> > done. This would be helpful for reviewer 

With the fix, the user sync is run ok without the exception after the removal 
of the "short user name" from the "or" logic for the group search, leaving only 
the full DN as the user name for the group search. Before the fix, the same 
search caused the InvalidNameException thrown from the LDAP server.

As stated in the Jira, apparently the problem is only with some LDAP servers. 
Using the Apache LDAP server in the Ranger automated user sync test, 
TestLdapUserGroup, the failure can't be reproduced.


- Yan


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


On Feb. 19, 2017, 10:30 p.m., Yan Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56829/
> ---
> 
> (Updated Feb. 19, 2017, 10:30 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Some LDAP servers throw exception on group search on posix user names that 
> are not full DNs.
> 
> 
> Diffs
> -
> 
>   
> ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
>  8cf6816 
>   
> ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
>  070a39b 
> 
> Diff: https://reviews.apache.org/r/56829/diff/
> 
> 
> Testing
> ---
> 
> Manual
> 
> 
> Thanks,
> 
> Yan Zhou
> 
>



Rangers: Need help to move 9 open JIRA(s) to either RESOLVED state or move out to 1.0.0 version ....

2017-02-19 Thread Selvamohan Neethiraj
Rangers:

 

As I am preparing for ranger-0.7.0  release, I still see 9 more open issues 
targeted for ranger 0.7 fix version. 

(JIRA Filter:  project = RANGER AND fixVersion = 0.7.0 AND resolution = 
Unresolved and type not in (Task) ORDER BY due ASC, priority DESC, created ASC)

Can you please review this list and move your assigned jira(s) to next release 
version 1.0.0 if you cannot resolve it in next 4 hours?  If it is not moved out 
(or resolved), I will have to move them to 1.0.0 release before sending the 
release for VOTE.

 

Just another FYI:  I have disabled the build.apache.org Jenkin Job that was 
publishing our 0.7.0-SNAPSHOT libraries to Apache (since we have changed the 
version to 0.7.0 and the release is not yet approved).

 

Thanks,

Selva-



[jira] [Commented] (RANGER-1391) Error occurred when use EndDate as Search Filter in Audit Access WebPage

2017-02-19 Thread Selvamohan Neethiraj (JIRA)

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

Selvamohan Neethiraj commented on RANGER-1391:
--

+1 for the patch
Patch committed - 06005ca39b12bde4042804bf538ab855507c983f

> Error occurred when use EndDate as Search Filter in Audit Access WebPage
> 
>
> Key: RANGER-1391
> URL: https://issues.apache.org/jira/browse/RANGER-1391
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>  Labels: patch
> Fix For: 0.7.0
>
> Attachments: 
> 0001-RANGER-1391-Error-occurred-when-use-EndDate-as-Searc.patch, 
> solrEndDateError.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> RangerAdmin use solr to store audit data,
> then open the WebPage Audit Access of RangerAdmin,
> and use only EndDate as Search Filter without StartDate,
> there is error occurred with message "Unable to connect to Audit store!!",
> please refer screenshot 
> [solrEndDateError.png|https://issues.apache.org/jira/secure/attachment/12853228/solrEndDateError.png]
>  for more detail,
> check ranger_admin.log to find error log:
> {noformat}
> 2017-02-17 06:28:36,113 [http-bio-6080-exec-5] ERROR 
> org.apache.ranger.solr.SolrUtil (SolrUtil.java:159) - Error running query. 
> query=q=*:*&fq=null:[*+TO+2017-02-17T15:59:59Z]&sort=evtTime+desc&start=0&rows=25,
>  response=null
> 2017-02-17 06:28:36,113 [http-bio-6080-exec-5] INFO  
> org.apache.ranger.common.RESTErrorUtil (RESTErrorUtil.java:63) - Request 
> failed. loginId=admin, logMessage=Error running query
> {noformat}



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


[jira] [Updated] (RANGER-1391) Error occurred when use EndDate as Search Filter in Audit Access WebPage

2017-02-19 Thread Selvamohan Neethiraj (JIRA)

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

Selvamohan Neethiraj updated RANGER-1391:
-
Fix Version/s: 0.7.0

> Error occurred when use EndDate as Search Filter in Audit Access WebPage
> 
>
> Key: RANGER-1391
> URL: https://issues.apache.org/jira/browse/RANGER-1391
> Project: Ranger
>  Issue Type: Bug
>  Components: admin
>Reporter: Qiang Zhang
>Assignee: Qiang Zhang
>  Labels: patch
> Fix For: 0.7.0
>
> Attachments: 
> 0001-RANGER-1391-Error-occurred-when-use-EndDate-as-Searc.patch, 
> solrEndDateError.png
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> RangerAdmin use solr to store audit data,
> then open the WebPage Audit Access of RangerAdmin,
> and use only EndDate as Search Filter without StartDate,
> there is error occurred with message "Unable to connect to Audit store!!",
> please refer screenshot 
> [solrEndDateError.png|https://issues.apache.org/jira/secure/attachment/12853228/solrEndDateError.png]
>  for more detail,
> check ranger_admin.log to find error log:
> {noformat}
> 2017-02-17 06:28:36,113 [http-bio-6080-exec-5] ERROR 
> org.apache.ranger.solr.SolrUtil (SolrUtil.java:159) - Error running query. 
> query=q=*:*&fq=null:[*+TO+2017-02-17T15:59:59Z]&sort=evtTime+desc&start=0&rows=25,
>  response=null
> 2017-02-17 06:28:36,113 [http-bio-6080-exec-5] INFO  
> org.apache.ranger.common.RESTErrorUtil (RESTErrorUtil.java:63) - Request 
> failed. loginId=admin, logMessage=Error running query
> {noformat}



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


[jira] [Commented] (RANGER-1347) The AtlasClient should fall back to the plain password if the password decryption fails

2017-02-19 Thread Selvamohan Neethiraj (JIRA)

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

Selvamohan Neethiraj commented on RANGER-1347:
--

+1 for the patch
committed to ranger-0.7 branch 5eb030ada419c4b1aaff4474ac98b6680667efb0


> The AtlasClient should fall back to the plain password if the password 
> decryption fails
> ---
>
> Key: RANGER-1347
> URL: https://issues.apache.org/jira/browse/RANGER-1347
> Project: Ranger
>  Issue Type: Improvement
>  Components: plugins
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 0.7.0
>
> Attachments: 
> 0001-RANGER-1347-The-AtlasClient-should-fall-back-to-the-.patch
>
>
> The AtlasClient should fall back to the plain password if the password 
> decryption fails. Otherwise trying to Test the Connection when creating a new 
> service fails for me. The KnoxClient also follows this approach.
> Review request: https://reviews.apache.org/r/56280/



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


Re: Review Request 56280: RANGER-1347 - The AtlasClient should fall back to the plain password if the password decryption fails

2017-02-19 Thread Selvamohan Neethiraj

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


Ship it!




Ship It!

- Selvamohan Neethiraj


On Feb. 3, 2017, 10:52 a.m., Colm O hEigeartaigh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56280/
> ---
> 
> (Updated Feb. 3, 2017, 10:52 a.m.)
> 
> 
> Review request for ranger.
> 
> 
> Bugs: RANGER-1347
> https://issues.apache.org/jira/browse/RANGER-1347
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> The AtlasClient should fall back to the plain password if the password 
> decryption fails. Otherwise trying to Test the Connection when creating a new 
> service fails for me. The KnoxClient also follows this approach.
> 
> 
> Diffs
> -
> 
>   
> plugin-atlas/src/main/java/org/apache/ranger/services/atlas/client/AtlasClient.java
>  4f90469 
> 
> Diff: https://reviews.apache.org/r/56280/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Colm O hEigeartaigh
> 
>



Re: Review Request 56780: RANGER-1391:Error occurred when use EndDate as Search Filter in Audit Access WebPage

2017-02-19 Thread Selvamohan Neethiraj

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


Ship it!




Ship It!

- Selvamohan Neethiraj


On Feb. 17, 2017, 2:54 a.m., Qiang Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56780/
> ---
> 
> (Updated Feb. 17, 2017, 2:54 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-1391
> https://issues.apache.org/jira/browse/RANGER-1391
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> #Solution:
> Add dateFieldName when use EndDate to query solr.
> 
> 
> Diffs
> -
> 
>   security-admin/src/main/java/org/apache/ranger/solr/SolrUtil.java e0ab372 
> 
> Diff: https://reviews.apache.org/r/56780/diff/
> 
> 
> Testing
> ---
> 
> #Test Result:
> 1.Start Ranger-Admin success
> 2.Search success to use EndDate as Search Filter in Audit Access WebPage
> 
> 
> Thanks,
> 
> Qiang Zhang
> 
>



Re: Review Request 56640: Support for using resource-matcher for filtering policies within a service if service-resource is provided in the filter

2017-02-19 Thread Madhan Neethiraj

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




agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerServiceDefHelper.java
 (line 51)


Consider renaming: "getServiceDefForNonrecursivePathResourceMatchers" ==> 
"cloneServiceDefForResourceFiltering"



agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerDefaultPolicyResourceMatcher.java
 (line 370)


Qhy should serviceDef be given as argument to this method? Shouldn't the 
serviceDef be set for the resource-matcher via init(). How is the serviceDef in 
this method parameter different from the one given in init()?

It will help to add examples/usecases for match being attempted here. 
Especially details of exits from the 'for' loop at line #370.. value of { 
matchType, ret } at each iteration and at exit.



security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java (line 
2151)


Consider abstracting the details of updating resourceName in a method like: 
updateResourceForFilter(filterResources, serviceDef)



security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java (line 
2161)


Instead of hardcoding resource names ("path" and "queue") and delimiters 
(".", "/"), consider reading these from serviceDef.resources.


- Madhan Neethiraj


On Feb. 16, 2017, 10:45 p.m., Abhay Kulkarni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56640/
> ---
> 
> (Updated Feb. 16, 2017, 10:45 p.m.)
> 
> 
> Review request for ranger, Madhan Neethiraj and Velmurugan Periasamy.
> 
> 
> Bugs: RANGER-1383
> https://issues.apache.org/jira/browse/RANGER-1383
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Ranger admin's REST API support retrieving and filtering policies for 
> resource specified in the provided filter. Currently, a simple string-match 
> and wildcard-match is used to filter policies. It is desirable to provide an 
> option to use, for filtering purpose, the same resource-matching algorithm 
> that is used by the policy engine to search policies that need to be 
> evaluated for access determination in the component.
> 
> A new option ("resourceMatchScope") will be supported for filtering policies 
> in a service. If it is required to filter policies based on
> the resources, then, with this option, Ranger will use resource-matchers for 
> filtering policies.
> 
> The values supported for "resourceMatchScope" option are:
> 
> "self" -> Search for exact match
> "ancestor" -> Search for policies which partially match specified resource. 
> If resource is incompletely specified (for example, if
> service-type supports multiple resourcedefs - hive supports database, table, 
> column; hbase supports database, column-family, column),
> then unspecified resourcedefs will be considered to have value of "*", which 
> matches any value.
> "self_or_ancestor" -> Search for policies which match as "self" or "ancestor"
> 
> If resourceMatchScope is specified, but its value is not one of "self", 
> "ancestor" or "self_or_ancestor", then value is set to
> "self_or_ancestor".
> 
> An example curl command is as follows:
> 
> curl -u admin:admin -H "Accept: application/json" -H "Content-Type: 
> application/json" -X GET 
> 'http://localhost:6080/service/plugins/policies/service/name/cl1_hadoop?policyType=0&resource:path=/demo&resourceMatchScope=self_or_ancestor'
> 
> This will return all access policies for cl1_hadoop service which match path 
> '/demo' or any path that starts with '/demo/'
> 
> Similarly, a command
> 
> curl -u admin:admin -H "Accept: application/json" -H "Content-Type: 
> application/json" -X GET 
> 'http://localhost:6080/service/plugins/policies/service/name/cl1_hive?policyType=0&resource:udf=demo&resource:database=tmp&resourceMatchScope=self
> 
> will return only policies which have both database=tmp and udf=demo as one of 
> their policy values.
> 
> 
> Diffs
> -
> 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/model/validation/RangerServiceDefHelper.java
>  3cdf40b 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerDefaultPolicyResourceMatcher.java
>  fa2b940 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/policyresourcematcher/RangerPolicyResourceMatcher.java
>  8a784b4 
>   
> agents-common/src/main/java/org/apache/ranger/plugin/store/AbstractPredicateUtil.java
>  36a9a27 
>   agents-common/src/main/java/org/apache/ranger/p

Re: Review Request 56829: Ranger-1395: LDAP group sync fails with InvalidNameException

2017-02-19 Thread Selvamohan Neethiraj

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



Can you please provide little more details on how the manual testing was done. 
This would be helpful for reviewer 

- Selvamohan Neethiraj


On Feb. 19, 2017, 5:30 p.m., Yan Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/56829/
> ---
> 
> (Updated Feb. 19, 2017, 5:30 p.m.)
> 
> 
> Review request for ranger.
> 
> 
> Repository: ranger
> 
> 
> Description
> ---
> 
> Some LDAP servers throw exception on group search on posix user names that 
> are not full DNs.
> 
> 
> Diffs
> -
> 
>   
> ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
>  8cf6816 
>   
> ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
>  070a39b 
> 
> Diff: https://reviews.apache.org/r/56829/diff/
> 
> 
> Testing
> ---
> 
> Manual
> 
> 
> Thanks,
> 
> Yan Zhou
> 
>



[jira] [Updated] (RANGER-1395) LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan (JIRA)

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

Yan updated RANGER-1395:

Attachment: ldap_2.patch

> LDAP group sync fails with InvalidNameException
> ---
>
> Key: RANGER-1395
> URL: https://issues.apache.org/jira/browse/RANGER-1395
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.6.0, 0.7.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 1.0.0
>Reporter: Yan
> Fix For: 1.0.0
>
> Attachments: ldap_2.patch
>
>
> Some LDAP servers throw exception on group search on posix user names that 
> are not full DNs. 



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


[jira] [Commented] (RANGER-1395) LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan (JIRA)

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

Yan commented on RANGER-1395:
-

Please review a patch at https://reviews.apache.org/r/56829/

> LDAP group sync fails with InvalidNameException
> ---
>
> Key: RANGER-1395
> URL: https://issues.apache.org/jira/browse/RANGER-1395
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.6.0, 0.7.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 1.0.0
>Reporter: Yan
> Fix For: 1.0.0
>
>
> Some LDAP servers throw exception on group search on posix user names that 
> are not full DNs. 



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


Review Request 56829: Ranger-1395: LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan Zhou

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

Review request for ranger.


Repository: ranger


Description
---

Some LDAP servers throw exception on group search on posix user names that are 
not full DNs.


Diffs
-

  
ugsync/src/main/java/org/apache/ranger/ldapusersync/process/LdapUserGroupBuilder.java
 8cf6816 
  
ugsync/src/main/java/org/apache/ranger/unixusersync/process/PolicyMgrUserGroupBuilder.java
 070a39b 

Diff: https://reviews.apache.org/r/56829/diff/


Testing
---

Manual


Thanks,

Yan Zhou



[jira] [Commented] (RANGER-1395) LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan (JIRA)

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

Yan commented on RANGER-1395:
-

The result is that the LDAP groups are not synced to Ranger at all.

> LDAP group sync fails with InvalidNameException
> ---
>
> Key: RANGER-1395
> URL: https://issues.apache.org/jira/browse/RANGER-1395
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.6.0, 0.7.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 1.0.0
>Reporter: Yan
>
> Some LDAP servers throw exception on group search on posix user names that 
> are not full DNs. 



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


[jira] [Commented] (RANGER-1395) LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan (JIRA)

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

Yan commented on RANGER-1395:
-

The problem was introduced with Ranger-893 when a short user name is added in 
searching for groups of the user, in addition to the full DN. 

> LDAP group sync fails with InvalidNameException
> ---
>
> Key: RANGER-1395
> URL: https://issues.apache.org/jira/browse/RANGER-1395
> Project: Ranger
>  Issue Type: Bug
>  Components: usersync
>Affects Versions: 0.6.0, 0.7.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 1.0.0
>Reporter: Yan
>
> Some LDAP servers throw exception on group search on posix user names that 
> are not full DNs. 



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


[jira] [Created] (RANGER-1395) LDAP group sync fails with InvalidNameException

2017-02-19 Thread Yan (JIRA)
Yan created RANGER-1395:
---

 Summary: LDAP group sync fails with InvalidNameException
 Key: RANGER-1395
 URL: https://issues.apache.org/jira/browse/RANGER-1395
 Project: Ranger
  Issue Type: Bug
  Components: usersync
Affects Versions: 0.6.3, 0.6.2, 0.6.1, 0.6.0, 0.7.0, 0.6.4, 1.0.0
Reporter: Yan


Some LDAP servers throw exception on group search on posix user names that are 
not full DNs. 



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


[jira] [Updated] (RANGER-1394) Ranger Release of 0.7.0

2017-02-19 Thread Selvamohan Neethiraj (JIRA)

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

Selvamohan Neethiraj updated RANGER-1394:
-
Priority: Blocker  (was: Major)

> Ranger Release of 0.7.0
> ---
>
> Key: RANGER-1394
> URL: https://issues.apache.org/jira/browse/RANGER-1394
> Project: Ranger
>  Issue Type: Task
>  Components: Ranger
>Reporter: Selvamohan Neethiraj
>Assignee: Selvamohan Neethiraj
>Priority: Blocker
> Fix For: 0.7.0
>
>
> Track all Release related activities



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


[jira] [Created] (RANGER-1394) Ranger Release of 0.7.0

2017-02-19 Thread Selvamohan Neethiraj (JIRA)
Selvamohan Neethiraj created RANGER-1394:


 Summary: Ranger Release of 0.7.0
 Key: RANGER-1394
 URL: https://issues.apache.org/jira/browse/RANGER-1394
 Project: Ranger
  Issue Type: Task
  Components: Ranger
Reporter: Selvamohan Neethiraj
Assignee: Selvamohan Neethiraj
 Fix For: 0.7.0


Track all Release related activities



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


Review Request 56827: [RANGER-1393] Fix generic types in RangerAuditFields

2017-02-19 Thread Zsombor Gegesy

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

Review request for ranger.


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


Repository: ranger


Description
---

Changing the class level generic parameter to method level, in this way lot of 
class cast can be eliminated


Diffs
-

  security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java 
15f205a3b5a3bb1ce984647c87c45feeae05ae94 
  security-admin/src/main/java/org/apache/ranger/biz/TagDBStore.java 
fa97bc96ad364fb06df478c1be6bdd8ef7ddb655 
  security-admin/src/main/java/org/apache/ranger/service/RangerAuditFields.java 
7223f109c93a3123e1ae13446dd9f121ae2ca7f7 
  
security-admin/src/main/java/org/apache/ranger/service/RangerServiceDefServiceBase.java
 aacf398663d2d71be0236f83e8e293c9cf9fa72b 
  
security-admin/src/main/java/org/apache/ranger/service/RangerTagDefServiceBase.java
 b85197ccc2073a1570b4a4cd9bdd7ec83420b7ab 
  
security-admin/src/main/java/org/apache/ranger/service/RangerTagServiceBase.java
 63050998313b2f40d879cbb1681ed908a32cb1cc 
  security-admin/src/test/java/org/apache/ranger/biz/TestServiceDBStore.java 
2b773dac7c7b9c3076d604f61c12ca3fd008877f 
  security-admin/src/test/java/org/apache/ranger/rest/TestServiceREST.java 
c54674727ac29b7a8ff70e214370e93b6faf7b27 
  
security-admin/src/test/java/org/apache/ranger/service/TestRangerPolicyServiceBase.java
 7910cbd8552125ea3ba821ab7433e6a2c2d0803b 
  
security-admin/src/test/java/org/apache/ranger/service/TestRangerServiceDefServiceBase.java
 b73a629a5429c35dde65575f068fa4947c34dde4 
  
security-admin/src/test/java/org/apache/ranger/service/TestRangerTagDefServiceBase.java
 803191e23753b13277b78fba7051c18fd5eb 

Diff: https://reviews.apache.org/r/56827/diff/


Testing
---


Thanks,

Zsombor Gegesy



[jira] [Updated] (RANGER-1393) RangerAuditFields generic type is incorrectly specified

2017-02-19 Thread Zsombor Gegesy (JIRA)

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

Zsombor Gegesy updated RANGER-1393:
---
Attachment: 0001-RANGER-1393-Fix-generic-types-in-RangerAuditFields.patch

> RangerAuditFields generic type is incorrectly specified
> ---
>
> Key: RANGER-1393
> URL: https://issues.apache.org/jira/browse/RANGER-1393
> Project: Ranger
>  Issue Type: Improvement
>  Components: Ranger
>Reporter: Zsombor Gegesy
>Assignee: Zsombor Gegesy
>Priority: Minor
>  Labels: code-cleanup
> Fix For: 1.0.0
>
> Attachments: 
> 0001-RANGER-1393-Fix-generic-types-in-RangerAuditFields.patch
>
>
> RangerAuditFields has a class level generic parameter instead of a method 
> level generic parameter. Because this, otherwise unnecessary casts are needs 
> to be written



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


[jira] [Created] (RANGER-1393) RangerAuditFields generic type is incorrectly specified

2017-02-19 Thread Zsombor Gegesy (JIRA)
Zsombor Gegesy created RANGER-1393:
--

 Summary: RangerAuditFields generic type is incorrectly specified
 Key: RANGER-1393
 URL: https://issues.apache.org/jira/browse/RANGER-1393
 Project: Ranger
  Issue Type: Improvement
  Components: Ranger
Reporter: Zsombor Gegesy
Assignee: Zsombor Gegesy
Priority: Minor
 Fix For: 1.0.0


RangerAuditFields has a class level generic parameter instead of a method level 
generic parameter. Because this, otherwise unnecessary casts are needs to be 
written



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