[jira] [Assigned] (RANGER-4555) Response metrics for /assets/assets API not proper
[
https://issues.apache.org/jira/browse/RANGER-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran reassigned RANGER-4555:
Assignee: Ramachandran
> Response metrics for /assets/assets API not proper
> --
>
> Key: RANGER-4555
> URL: https://issues.apache.org/jira/browse/RANGER-4555
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> When a request is made to /assets/assets API, the values like total count,
> result size in the API response is always 0.
> {code:java}
> {"startIndex": 0,"pageSize": 0,"totalCount": 0,"resultSize":
> 0,"queryTimeMS": 1700215066880,{code}
> Ideally, the total count value should reflect the total number of assets (the
> value returned by /assets/assets/count API is proper).
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4552) Response metrics for /assets/report is not proper, and pagination does not work
[
https://issues.apache.org/jira/browse/RANGER-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran reassigned RANGER-4552:
Assignee: Ramachandran
> Response metrics for /assets/report is not proper, and pagination does not
> work
> ---
>
> Key: RANGER-4552
> URL: https://issues.apache.org/jira/browse/RANGER-4552
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> When a request is made to the /assets/report API endpoint, the response
> metrics like
> result size is incorrect. Ideally, it should reflect the total number of
> objects returned
> {code:java}
> {"startIndex": 2,"pageSize": 100,"totalCount": 178,
> "resultSize": 0,"queryTimeMS": 1700217495822 {code}
> Even the pagination for the API does not work properly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4554) Response metrics for /assets/resources not proper
[
https://issues.apache.org/jira/browse/RANGER-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran reassigned RANGER-4554:
Assignee: Ramachandran
> Response metrics for /assets/resources not proper
> -
>
> Key: RANGER-4554
> URL: https://issues.apache.org/jira/browse/RANGER-4554
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> When a request is made to /assets/resources API, the values like total count,
> result size in the API response is always 0.
> {code:java}
> {"startIndex": 0,"pageSize": 0,"totalCount": 0,"resultSize":
> 0,"queryTimeMS": 1700215066880,{code}
> Ideally, the total count value should reflect the total number of resources
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4553) Response metrics for /xaudit/trx_log not proper
[
https://issues.apache.org/jira/browse/RANGER-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran reassigned RANGER-4553:
Assignee: Ramachandran
> Response metrics for /xaudit/trx_log not proper
> ---
>
> Key: RANGER-4553
> URL: https://issues.apache.org/jira/browse/RANGER-4553
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> When a request is made to /xaudit/trx_log API, the values like total count,
> result size in the API response is always 0.
> {code:java}
> {"startIndex": 0,"pageSize": 200,"totalCount": 0,
> "resultSize": 0,"queryTimeMS": 1700214070565, ...} {code}
> Ideally, the total count value should reflect the total number of logs
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4560) Ranger Roles Cache improvement to reduce DB calls to the Database
[ https://issues.apache.org/jira/browse/RANGER-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4560: - Attachment: 0001-RANGER-4560-Ranger-Roles-Cache-improvement-to-reduce.patch > Ranger Roles Cache improvement to reduce DB calls to the Database > - > > Key: RANGER-4560 > URL: https://issues.apache.org/jira/browse/RANGER-4560 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Attachments: > 0001-RANGER-4560-Ranger-Roles-Cache-improvement-to-reduce.patch > > > How Ranger uses the Roles Cache (In-Memory) > When the lastKnownRoleVersion and rangerRoleVersionInDB are equal then return > null. Because roles have not changed since the last time > otherwise, It will fetch the roles from the Database update the cache, and > then return roles to the User/Ranger Plugins > As part of Ranger Roles Cache improvement, we have added the below logic > When the rolesVersionInDB and cachedRolesVersion are equal then return cached > RangerRoles.Because RangerRoles have not changed since the last time we > fetched > How it will improve the Ranger Roles Cache > When the user/Client(Ranger Plugin) sends the lastKnownRoleVersion as -1 or > null, Ranger Roles Cache internally check whether rolesVersionInDB and > cachedRolesVersion are equal or not ?. If it equal means, it will fetch it > from the Cache rather than fetching the roles from the database update the > cache, and then return roles to the User/Ranger Plugins -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4561) Adding the mechanism to eanble/disable Ranager Access logs based on property
[ https://issues.apache.org/jira/browse/RANGER-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4561: - Attachment: 0001-RANGER-4561-Adding-the-mechanism-to-eanble-disable-R.patch > Adding the mechanism to eanble/disable Ranager Access logs based on property > - > > Key: RANGER-4561 > URL: https://issues.apache.org/jira/browse/RANGER-4561 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Attachments: > 0001-RANGER-4561-Adding-the-mechanism-to-eanble-disable-R.patch > > > In the current Ranger Admin, we have enabled Ranger access logs by default. > If any of the customers wants to disable, the Ranger access logs, it can not > be done without making code changes.So we need to leverage this use case so > that customers can disable the ranger access logs if they needed via setting > properties -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4561) Adding the mechanism to eanble/disable Ranager Access logs based on property
[ https://issues.apache.org/jira/browse/RANGER-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789767#comment-17789767 ] Ramachandran commented on RANGER-4561: -- The review is available here :[https://reviews.apache.org/r/74759/] > Adding the mechanism to eanble/disable Ranager Access logs based on property > - > > Key: RANGER-4561 > URL: https://issues.apache.org/jira/browse/RANGER-4561 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > > In the current Ranger Admin, we have enabled Ranger access logs by default. > If any of the customers wants to disable, the Ranger access logs, it can not > be done without making code changes.So we need to leverage this use case so > that customers can disable the ranger access logs if they needed via setting > properties -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4561) Adding the mechanism to eanble/disable Ranager Access logs based on property
Ramachandran created RANGER-4561: Summary: Adding the mechanism to eanble/disable Ranager Access logs based on property Key: RANGER-4561 URL: https://issues.apache.org/jira/browse/RANGER-4561 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Ramachandran Assignee: Ramachandran In the current Ranger Admin, we have enabled Ranger access logs by default. If any of the customers wants to disable, the Ranger access logs, it can not be done without making code changes.So we need to leverage this use case so that customers can disable the ranger access logs if they needed via setting properties -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4560) Ranger Roles Cache improvement to reduce DB calls to the Database
[ https://issues.apache.org/jira/browse/RANGER-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4560: - Affects Version/s: (was: 2.4.0) > Ranger Roles Cache improvement to reduce DB calls to the Database > - > > Key: RANGER-4560 > URL: https://issues.apache.org/jira/browse/RANGER-4560 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > > How Ranger uses the Roles Cache (In-Memory) > When the lastKnownRoleVersion and rangerRoleVersionInDB are equal then return > null. Because roles have not changed since the last time > otherwise, It will fetch the roles from the Database update the cache, and > then return roles to the User/Ranger Plugins > As part of Ranger Roles Cache improvement, we have added the below logic > When the rolesVersionInDB and cachedRolesVersion are equal then return cached > RangerRoles.Because RangerRoles have not changed since the last time we > fetched > How it will improve the Ranger Roles Cache > When the user/Client(Ranger Plugin) sends the lastKnownRoleVersion as -1 or > null, Ranger Roles Cache internally check whether rolesVersionInDB and > cachedRolesVersion are equal or not ?. If it equal means, it will fetch it > from the Cache rather than fetching the roles from the database update the > cache, and then return roles to the User/Ranger Plugins -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4560) Ranger Roles Cache improvement to reduce DB calls to the Database
Ramachandran created RANGER-4560: Summary: Ranger Roles Cache improvement to reduce DB calls to the Database Key: RANGER-4560 URL: https://issues.apache.org/jira/browse/RANGER-4560 Project: Ranger Issue Type: Improvement Components: Ranger Affects Versions: 2.4.0 Reporter: Ramachandran Assignee: Ramachandran How Ranger uses the Roles Cache (In-Memory) When the lastKnownRoleVersion and rangerRoleVersionInDB are equal then return null. Because roles have not changed since the last time otherwise, It will fetch the roles from the Database update the cache, and then return roles to the User/Ranger Plugins As part of Ranger Roles Cache improvement, we have added the below logic When the rolesVersionInDB and cachedRolesVersion are equal then return cached RangerRoles.Because RangerRoles have not changed since the last time we fetched How it will improve the Ranger Roles Cache When the user/Client(Ranger Plugin) sends the lastKnownRoleVersion as -1 or null, Ranger Roles Cache internally check whether rolesVersionInDB and cachedRolesVersion are equal or not ?. If it equal means, it will fetch it from the Cache rather than fetching the roles from the database update the cache, and then return roles to the User/Ranger Plugins -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4353) Purging of x_auth_sess records should purge corresponding records in x_trx_log as well
[
https://issues.apache.org/jira/browse/RANGER-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754869#comment-17754869
]
Ramachandran commented on RANGER-4353:
--
Admin Audit log is written into {{x_trx_log}} table whenever we do CUD
operations on policy/role/user/group in Ranger
We used to store the below info
Example:
{{Operation :Policy deleted }}
{{Actions:delete/create/update}}
{{Session Id:}}
{{User: }}
{{Date:}}
and some other info in {{x_trx_log}} table and this will be populated in the UI
We are seeing {{x_trx_log}} table is growing very fast. This also might affect
DB performance. We do not have any flag to disable admin audit.
This ticket will be a great initiative to address this performance issue
> Purging of x_auth_sess records should purge corresponding records in
> x_trx_log as well
> --
>
> Key: RANGER-4353
> URL: https://issues.apache.org/jira/browse/RANGER-4353
> Project: Ranger
> Issue Type: Task
> Components: Ranger
>Reporter: Madhan Neethiraj
>Assignee: Pradeep Agrawal
>Priority: Major
>
> RANGER-4255 introduced REST API to purge x_auth_sess table records that were
> created earlier than 180 days (by default). This purging should be extended
> to x_trx_log table records as well, as it can take up significant space.
> x_trx_log table track details of changes to individual attributes of
> policies/services/security-zones/users/groups/roles.
> CC: [~pradeep], [~abhay], [~vel], [~ankita], [~suchnit]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4312) Need api to reset cache of role, user. And reset policy and tag cache by service id
[ https://issues.apache.org/jira/browse/RANGER-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744320#comment-17744320 ] Ramachandran commented on RANGER-4312: -- [~madhan] We already have reset the policy and tag cache by service Name .I guess we need to support the similar kind of API's for roles,users cache > Need api to reset cache of role, user. And reset policy and tag cache by > service id > --- > > Key: RANGER-4312 > URL: https://issues.apache.org/jira/browse/RANGER-4312 > Project: Ranger > Issue Type: Task > Components: admin >Reporter: Anand Nadar >Priority: Minor > > There are cache reset apis in place for policy and tag cache. > We need similar apis for reset cache of user and role cache which are > maintained in ranger admin. > We also need apis which can reset the policy and tag cache by service id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4312) Need api to reset cache of role, user. And reset policy and tag cache by service id
[ https://issues.apache.org/jira/browse/RANGER-4312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744211#comment-17744211 ] Ramachandran commented on RANGER-4312: -- [~anandNadar] : What could be usecase for adding the reset cache of user and role cache which are maintained in ranger admin? We already have reset the policy and tag cache by service Name .Do we need the extra REST APIs for the serviceId cc >> [~mad...@apache.org] > Need api to reset cache of role, user. And reset policy and tag cache by > service id > --- > > Key: RANGER-4312 > URL: https://issues.apache.org/jira/browse/RANGER-4312 > Project: Ranger > Issue Type: Task > Components: admin >Reporter: Anand Nadar >Priority: Minor > > There are cache reset apis in place for policy and tag cache. > We need similar apis for reset cache of user and role cache which are > maintained in ranger admin. > We also need apis which can reset the policy and tag cache by service id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4264) Test Case improvement for RangerDefaultPolicyResourceMatcher
[
https://issues.apache.org/jira/browse/RANGER-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729355#comment-17729355
]
Ramachandran commented on RANGER-4264:
--
Accidentally created this ticket. This ticket is not valid and resolving now
> Test Case improvement for RangerDefaultPolicyResourceMatcher
>
>
> Key: RANGER-4264
> URL: https://issues.apache.org/jira/browse/RANGER-4264
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Attachments: image-2023-06-05-20-34-40-249.png
>
>
> As part of the test cases, we mentioned the type called
> {color:#de350b}selfAndAllDescendants{color}
> But we are not honouring this type while mapping into MatchScope of
> RangerPolicyResourceMatcher
> !image-2023-06-05-20-34-40-249.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (RANGER-4264) Test Case improvement for RangerDefaultPolicyResourceMatcher
[
https://issues.apache.org/jira/browse/RANGER-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran resolved RANGER-4264.
--
Resolution: Invalid
> Test Case improvement for RangerDefaultPolicyResourceMatcher
>
>
> Key: RANGER-4264
> URL: https://issues.apache.org/jira/browse/RANGER-4264
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Attachments: image-2023-06-05-20-34-40-249.png
>
>
> As part of the test cases, we mentioned the type called
> {color:#de350b}selfAndAllDescendants{color}
> But we are not honouring this type while mapping into MatchScope of
> RangerPolicyResourceMatcher
> !image-2023-06-05-20-34-40-249.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4264) Test Case improvement for RangerDefaultPolicyResourceMatcher
Ramachandran created RANGER-4264:
Summary: Test Case improvement for
RangerDefaultPolicyResourceMatcher
Key: RANGER-4264
URL: https://issues.apache.org/jira/browse/RANGER-4264
Project: Ranger
Issue Type: Bug
Components: Ranger
Reporter: Ramachandran
Assignee: Ramachandran
Attachments: image-2023-06-05-20-34-40-249.png
As part of the test cases, we mentioned the type called
{color:#de350b}selfAndAllDescendants{color}
But we are not honouring this type while mapping into MatchScope of
RangerPolicyResourceMatcher
!image-2023-06-05-20-33-27-419.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4264) Test Case improvement for RangerDefaultPolicyResourceMatcher
[
https://issues.apache.org/jira/browse/RANGER-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4264:
-
Attachment: image-2023-06-05-20-34-40-249.png
> Test Case improvement for RangerDefaultPolicyResourceMatcher
>
>
> Key: RANGER-4264
> URL: https://issues.apache.org/jira/browse/RANGER-4264
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Attachments: image-2023-06-05-20-34-40-249.png
>
>
> As part of the test cases, we mentioned the type called
> {color:#de350b}selfAndAllDescendants{color}
> But we are not honouring this type while mapping into MatchScope of
> RangerPolicyResourceMatcher
> !image-2023-06-05-20-34-40-249.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4264) Test Case improvement for RangerDefaultPolicyResourceMatcher
[
https://issues.apache.org/jira/browse/RANGER-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4264:
-
Description:
As part of the test cases, we mentioned the type called
{color:#de350b}selfAndAllDescendants{color}
But we are not honouring this type while mapping into MatchScope of
RangerPolicyResourceMatcher
!image-2023-06-05-20-34-40-249.png!
was:
As part of the test cases, we mentioned the type called
{color:#de350b}selfAndAllDescendants{color}
But we are not honouring this type while mapping into MatchScope of
RangerPolicyResourceMatcher
!image-2023-06-05-20-33-27-419.png!
> Test Case improvement for RangerDefaultPolicyResourceMatcher
>
>
> Key: RANGER-4264
> URL: https://issues.apache.org/jira/browse/RANGER-4264
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Attachments: image-2023-06-05-20-34-40-249.png
>
>
> As part of the test cases, we mentioned the type called
> {color:#de350b}selfAndAllDescendants{color}
> But we are not honouring this type while mapping into MatchScope of
> RangerPolicyResourceMatcher
> !image-2023-06-05-20-34-40-249.png!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name})
[ https://issues.apache.org/jira/browse/RANGER-4250 ]
Ramachandran deleted comment on RANGER-4250:
--
was (Author: JIRAUSER295265):
[^0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch]
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name})
>
>
> Key: RANGER-4250
> URL: https://issues.apache.org/jira/browse/RANGER-4250
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
>
>
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
> Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
> at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
> org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
> at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name})
[
https://issues.apache.org/jira/browse/RANGER-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4250:
-
Summary: Ranger throws BAD Request Error when we are not passing exec user
to the getRoles (/public/v2/api/roles/name/{name}) (was: Ranger throws BAD
Request Error when we are not passing exec user to the getRoles
(/public/v2/api/roles/name/{name))
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name})
>
>
> Key: RANGER-4250
> URL: https://issues.apache.org/jira/browse/RANGER-4250
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
>
>
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
> Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
> at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
> org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
> at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name})
[
https://issues.apache.org/jira/browse/RANGER-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4250:
-
Attachment: 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name})
>
>
> Key: RANGER-4250
> URL: https://issues.apache.org/jira/browse/RANGER-4250
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
>
>
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
> Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
> at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
> org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
> at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name})
[
https://issues.apache.org/jira/browse/RANGER-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4250:
-
Attachment: (was:
0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch)
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name})
>
>
> Key: RANGER-4250
> URL: https://issues.apache.org/jira/browse/RANGER-4250
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
>
>
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
> Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
> at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
> org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
> at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name)
[
https://issues.apache.org/jira/browse/RANGER-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725321#comment-17725321
]
Ramachandran commented on RANGER-4250:
--
[~mad...@apache.org] The review is available
here:[https://reviews.apache.org/r/74453/]
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> ---
>
> Key: RANGER-4250
> URL: https://issues.apache.org/jira/browse/RANGER-4250
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Attachments:
> 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
>
>
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
> Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
> at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
> org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
> at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name)
[
https://issues.apache.org/jira/browse/RANGER-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4250:
-
Attachment: 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> ---
>
> Key: RANGER-4250
> URL: https://issues.apache.org/jira/browse/RANGER-4250
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Attachments:
> 0001-RANGER-4250-Ranger-throws-BAD-Request-Error-when-we-.patch
>
>
> Ranger throws BAD Request Error when we are not passing exec user to the
> getRoles (/public/v2/api/roles/name/{name)
> getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
> Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
> at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
> org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
> org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
> at
> org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
> at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4250) Ranger throws BAD Request Error when we are not passing exec user to the getRoles (/public/v2/api/roles/name/{name)
Ramachandran created RANGER-4250:
Summary: Ranger throws BAD Request Error when we are not passing
exec user to the getRoles (/public/v2/api/roles/name/{name)
Key: RANGER-4250
URL: https://issues.apache.org/jira/browse/RANGER-4250
Project: Ranger
Issue Type: Bug
Components: Ranger
Reporter: Ramachandran
Assignee: Ramachandran
Ranger throws BAD Request Error when we are not passing exec user to the
getRoles (/public/v2/api/roles/name/{name)
getGroupsForUser('null') failed javax.ws.rs.WebApplicationException: HTTP 400
Bad Request| 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.XUserService.getXUserByUserName(XUserService.java:160)|
at org.apache.ranger.biz.XUserMgr.getXUserByUserName(XUserMgr.java:153)| at
org.apache.ranger.biz.XUserMgr.getGroupsForUser(XUserMgr.java:893)| at
org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke()|
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)|
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)|
at
org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$ab39f3cf.getGroupsForUser()|
at org.apache.ranger.rest.RoleREST.getRole(RoleREST.java:301)| at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4168) Improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719146#comment-17719146 ] Ramachandran edited comment on RANGER-4168 at 5/8/23 5:16 PM: -- [~mad...@apache.org] Can you please take a look?This This also needs to be added as part of the improvement Task which will help the developer whenever they make code changes h4. was (Author: JIRAUSER295265): [~mad...@apache.org] Can you please take a look? > Improvement :Adding Unit test cases are some of the missing classes > --- > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4190) Apache Ranger does not recover from a recoverable SQL exception
[
https://issues.apache.org/jira/browse/RANGER-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719364#comment-17719364
]
Ramachandran commented on RANGER-4190:
--
[~mad...@apache.org] Can you please take a look?
> Apache Ranger does not recover from a recoverable SQL exception
> ---
>
> Key: RANGER-4190
> URL: https://issues.apache.org/jira/browse/RANGER-4190
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4190-Apache-Ranger-does-not-recover-from-a-re.patch
>
>
> It seems the Ranger instance is not able to connect Oracle ATP. This issue
> could be the loss of network connectivity to the load balancer which will
> connect to oracle ATP.
> java.sql.SQLRecoverableException: I/O Exception: Connection reset
> Internal Exception: java.sql.SQLRecoverableException: No more data to read
> from socket
> Error Code: 17410
> This issue could happen due to the loss of connectivity to the oracle ATP
> network load balancer.
> ADB network properties -
> [https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-prepare-jdbc-thin.html#GUID-0A619DFE-5F5F-4302-BF43-B08AEDA05A6C]
>
> [https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rilin/load-balancing-of-connections-to-oracle-rac-databases.html#GUID-06B4373D-1217-44E4-BD86-DE353DA657F6]
> part of the Ranger start we need to add the below JVM parameters to disable
> the network cache by lowering its TTL to
> 0;-Djava.security.egd=[file:///dev/urandom] -Dnetworkaddress.cache.ttl=0
> -Dnetworkaddress.cache.negative.ttl=0
>
> By default, the [OpenJDK 8
> InetAddress|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/InetAddress.java#l189]
> will cache failed DNS queries, referred to as "negative caching", for 10
> seconds. It's recommended to disable both the positive and negative cache by
> setting them to 0 seconds, and rely on the DNS caching implemented inside
> OCI's DNS systems.
> {panel}
> {panel}
> |{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.ttl"{}}}{{{},
> {}}}{{{}0{}}}{{{});{}}}
> {{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.negative.ttl"{}}}{{{},
> {}}}{{{}0{}}}{{{});{}}}
> {{// (Optional) Force Java to use a specific DNS provider}}
> {{// By default it will use whatever lookup is defined in the system =>
> files,nis,dns}}
> {{// as in /etc/nsswitch.conf on linux}}
> {{{}System.setProperty({}}}{{{}"sun.net.spi.nameservice.provider.1"{}}}{{{},
> {}}}{{{}"dns,sun"{}}}{{{});{}}}|
> Or as an argument when invoking Java:
> {panel}
> {panel}
> |{{{}java -Dnetworkaddress.cache.ttl={}}}{{{}0{}}}
> {{{}-Dnetworkaddress.cache.negative.ttl={}}}{{{}0{}}} {{app.jar}}|
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4168) Improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719146#comment-17719146 ] Ramachandran commented on RANGER-4168: -- [~mad...@apache.org] Can you please take a look? > Improvement :Adding Unit test cases are some of the missing classes > --- > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4208) Recording DB Read Time while downloading policies,roles and users
[ https://issues.apache.org/jira/browse/RANGER-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716231#comment-17716231 ] Ramachandran commented on RANGER-4208: -- [~madhan] The review is available here:[https://reviews.apache.org/r/74415/] > Recording DB Read Time while downloading policies,roles and users > - > > Key: RANGER-4208 > URL: https://issues.apache.org/jira/browse/RANGER-4208 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4208-Recording-DB-Read-Time-while-downloading.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4208) Recording DB Read Time while downloading policies,roles and users
[ https://issues.apache.org/jira/browse/RANGER-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4208: - Attachment: 0001-RANGER-4208-Recording-DB-Read-Time-while-downloading.patch > Recording DB Read Time while downloading policies,roles and users > - > > Key: RANGER-4208 > URL: https://issues.apache.org/jira/browse/RANGER-4208 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4208-Recording-DB-Read-Time-while-downloading.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4208) Recording DB Read Time while downloading policies,roles and users
Ramachandran created RANGER-4208: Summary: Recording DB Read Time while downloading policies,roles and users Key: RANGER-4208 URL: https://issues.apache.org/jira/browse/RANGER-4208 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Ramachandran Assignee: Ramachandran Fix For: 3.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4168) Improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711983#comment-17711983 ] Ramachandran edited comment on RANGER-4168 at 4/20/23 4:19 PM: --- [^0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch] was (Author: JIRAUSER295265): [^0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch] > Improvement :Adding Unit test cases are some of the missing classes > --- > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4168) Improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4168: - Attachment: 0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch > Improvement :Adding Unit test cases are some of the missing classes > --- > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4168) Improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4168: - Attachment: (was: 0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch) > Improvement :Adding Unit test cases are some of the missing classes > --- > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Improvement-Adding-Unit-test-cases-are-s.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4195) Exposing the Ranger REST API is used to fetch the health check status of Ranger Admin
[
https://issues.apache.org/jira/browse/RANGER-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4195:
-
Attachment: 0001-RANGER-4195-Exposing-the-Ranger-REST-API-is-used-to-.patch
> Exposing the Ranger REST API is used to fetch the health check status of
> Ranger Admin
> -
>
> Key: RANGER-4195
> URL: https://issues.apache.org/jira/browse/RANGER-4195
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4195-Exposing-the-Ranger-REST-API-is-used-to-.patch
>
>
> Exposing the Ranger REST API is used to fetch the health check status of
> Ranger Admin
>
> RangerAdmin Health Check JSON Response look like (In the current
> implementation)
> {
> "status": "UP",
> "components": {
> "db": {
> "status": "UP",
> "details":
> { "database": "Oracle 21.3c", "validationQuery": "SELECT banner from
> v$version where rownum<2" }
> }
> }
> }
> In the future we can extend this health check API for other components like
> AuditHandler (Elastic search, Kafka,HDFS, Solr),KMS ,etc
> Another Example :
> {
> "status": "UP",
> "components": {
> "db": {
> "status": "UP",
> "details":
> { "database": "Oracle 21.3c", "validationQuery": "SELECT banner from
> v$version where rownum<2" }
> },
> "auditProvider": {
> "status": "UP",
> "details":
> { "provider": "Elastic Search", "providerHealthCheckEndpoint":
> "http://localhost:9200/_cluster/health?pretty; }
> }
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4195) Exposing the Ranger REST API is used to fetch the health check status of Ranger Admin
[
https://issues.apache.org/jira/browse/RANGER-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714544#comment-17714544
]
Ramachandran commented on RANGER-4195:
--
[~madhan] : The review is available here :https://reviews.apache.org/r/74405/
> Exposing the Ranger REST API is used to fetch the health check status of
> Ranger Admin
> -
>
> Key: RANGER-4195
> URL: https://issues.apache.org/jira/browse/RANGER-4195
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
>
> Exposing the Ranger REST API is used to fetch the health check status of
> Ranger Admin
>
> RangerAdmin Health Check JSON Response look like (In the current
> implementation)
> {
> "status": "UP",
> "components": {
> "db": {
> "status": "UP",
> "details":
> { "database": "Oracle 21.3c", "validationQuery": "SELECT banner from
> v$version where rownum<2" }
> }
> }
> }
> In the future we can extend this health check API for other components like
> AuditHandler (Elastic search, Kafka,HDFS, Solr),KMS ,etc
> Another Example :
> {
> "status": "UP",
> "components": {
> "db": {
> "status": "UP",
> "details":
> { "database": "Oracle 21.3c", "validationQuery": "SELECT banner from
> v$version where rownum<2" }
> },
> "auditProvider": {
> "status": "UP",
> "details":
> { "provider": "Elastic Search", "providerHealthCheckEndpoint":
> "http://localhost:9200/_cluster/health?pretty; }
> }
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4195) Exposing the Ranger REST API is used to fetch the health check status of Ranger Admin
[
https://issues.apache.org/jira/browse/RANGER-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4195:
-
Description:
Exposing the Ranger REST API is used to fetch the health check status of Ranger
Admin
RangerAdmin Health Check JSON Response look like (In the current implementation)
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details":
{ "database": "Oracle 21.3c", "validationQuery": "SELECT banner from v$version
where rownum<2" }
}
}
}
In the future we can extend this health check API for other components like
AuditHandler (Elastic search, Kafka,HDFS, Solr),KMS ,etc
Another Example :
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details":
{ "database": "Oracle 21.3c", "validationQuery": "SELECT banner from v$version
where rownum<2" }
},
"auditProvider": {
"status": "UP",
"details":
{ "provider": "Elastic Search", "providerHealthCheckEndpoint":
"http://localhost:9200/_cluster/health?pretty; }
}
}
}
was:
Exposing the Ranger REST API is used to fetch the health check status of Ranger
Admin
RangerAdmin Health Check JSON Response look like (In the current implementation)
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details": {
"database": "Oracle 21.3c",
"validationQuery": "SELECT banner from v$version where rownum<2"
}
}
}
}
In the future we can extend this health check API for other components like
AuditHandler (Elastic search, Kafka,HDFS, Solr),KMS ,etc
Another Example :
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details": {
"database": "Oracle 21.3c",
"validationQuery": "SELECT banner from v$version where rownum<2"
}
},
"auditProvider": {
"status": "UP",
"details": {
"provider": "Elastic Search",
"providerHealthCheckEndpoint": "http://localhost:9200/_cluster/health?pretty;
}
}
}
}
> Exposing the Ranger REST API is used to fetch the health check status of
> Ranger Admin
> -
>
> Key: RANGER-4195
> URL: https://issues.apache.org/jira/browse/RANGER-4195
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
>
> Exposing the Ranger REST API is used to fetch the health check status of
> Ranger Admin
>
> RangerAdmin Health Check JSON Response look like (In the current
> implementation)
> {
> "status": "UP",
> "components": {
> "db": {
> "status": "UP",
> "details":
> { "database": "Oracle 21.3c", "validationQuery": "SELECT banner from
> v$version where rownum<2" }
> }
> }
> }
> In the future we can extend this health check API for other components like
> AuditHandler (Elastic search, Kafka,HDFS, Solr),KMS ,etc
> Another Example :
> {
> "status": "UP",
> "components": {
> "db": {
> "status": "UP",
> "details":
> { "database": "Oracle 21.3c", "validationQuery": "SELECT banner from
> v$version where rownum<2" }
> },
> "auditProvider": {
> "status": "UP",
> "details":
> { "provider": "Elastic Search", "providerHealthCheckEndpoint":
> "http://localhost:9200/_cluster/health?pretty; }
> }
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4195) Exposing the Ranger REST API is used to fetch the health check status of Ranger Admin
Ramachandran created RANGER-4195:
Summary: Exposing the Ranger REST API is used to fetch the health
check status of Ranger Admin
Key: RANGER-4195
URL: https://issues.apache.org/jira/browse/RANGER-4195
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Ramachandran
Assignee: Ramachandran
Fix For: 3.0.0
Exposing the Ranger REST API is used to fetch the health check status of Ranger
Admin
RangerAdmin Health Check JSON Response look like (In the current implementation)
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details": {
"database": "Oracle 21.3c",
"validationQuery": "SELECT banner from v$version where rownum<2"
}
}
}
}
In the future we can extend this health check API for other components like
AuditHandler (Elastic search, Kafka,HDFS, Solr),KMS ,etc
Another Example :
{
"status": "UP",
"components": {
"db": {
"status": "UP",
"details": {
"database": "Oracle 21.3c",
"validationQuery": "SELECT banner from v$version where rownum<2"
}
},
"auditProvider": {
"status": "UP",
"details": {
"provider": "Elastic Search",
"providerHealthCheckEndpoint": "http://localhost:9200/_cluster/health?pretty;
}
}
}
}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4168) Improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4168: - Summary: Improvement :Adding Unit test cases are some of the missing classes (was: Code improvement :Adding Unit test cases are some of the missing classes) > Improvement :Adding Unit test cases are some of the missing classes > --- > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4168) Code improvement :Adding Unit test cases are some of the missing classes
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4168: - Summary: Code improvement :Adding Unit test cases are some of the missing classes (was: Unit test cases are missing for TagDBStore.java) > Code improvement :Adding Unit test cases are some of the missing classes > > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3010) Rest API 'addUsersAndGroups' issue
[ https://issues.apache.org/jira/browse/RANGER-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-3010: - Attachment: (was: 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch) > Rest API 'addUsersAndGroups' issue > -- > > Key: RANGER-3010 > URL: https://issues.apache.org/jira/browse/RANGER-3010 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: leo sun >Assignee: Ramachandran >Priority: Major > Labels: PatchAvailable > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch, Improvement > in Ranger Roles Rest API's (1).pdf > > Time Spent: 40m > Remaining Estimate: 0h > > I want to use Ranger API functions - addUsersAndGroups & removeUsersAndGroups > to manage users and groups of role. But official reference don't have > suitable example for these two APIs. And my all attempts failed. > Another point: For example, I found the input type of addUsersAndGroups is > Boolean on official web, but the input of the implement function is two > string list and one boolean. > I don't know how to use it. Could you help me with this? [~abhayk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3010) Rest API 'addUsersAndGroups' issue
[ https://issues.apache.org/jira/browse/RANGER-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-3010: - Attachment: 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch > Rest API 'addUsersAndGroups' issue > -- > > Key: RANGER-3010 > URL: https://issues.apache.org/jira/browse/RANGER-3010 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: leo sun >Assignee: Ramachandran >Priority: Major > Labels: PatchAvailable > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch, Improvement > in Ranger Roles Rest API's (1).pdf > > Time Spent: 40m > Remaining Estimate: 0h > > I want to use Ranger API functions - addUsersAndGroups & removeUsersAndGroups > to manage users and groups of role. But official reference don't have > suitable example for these two APIs. And my all attempts failed. > Another point: For example, I found the input type of addUsersAndGroups is > Boolean on official web, but the input of the implement function is two > string list and one boolean. > I don't know how to use it. Could you help me with this? [~abhayk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3010) Rest API 'addUsersAndGroups' issue
[ https://issues.apache.org/jira/browse/RANGER-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713444#comment-17713444 ] Ramachandran edited comment on RANGER-3010 at 4/18/23 7:28 AM: --- [^0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch] was (Author: JIRAUSER295265): [^Improvement in Ranger Roles Rest API's (1).pdf] > Rest API 'addUsersAndGroups' issue > -- > > Key: RANGER-3010 > URL: https://issues.apache.org/jira/browse/RANGER-3010 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: leo sun >Assignee: Ramachandran >Priority: Major > Labels: PatchAvailable > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch, Improvement > in Ranger Roles Rest API's (1).pdf > > Time Spent: 40m > Remaining Estimate: 0h > > I want to use Ranger API functions - addUsersAndGroups & removeUsersAndGroups > to manage users and groups of role. But official reference don't have > suitable example for these two APIs. And my all attempts failed. > Another point: For example, I found the input type of addUsersAndGroups is > Boolean on official web, but the input of the implement function is two > string list and one boolean. > I don't know how to use it. Could you help me with this? [~abhayk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4191) Expose the Ranger REST API to fetch all the roles that groups belong to
[ https://issues.apache.org/jira/browse/RANGER-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712673#comment-17712673 ] Ramachandran commented on RANGER-4191: -- [~mad...@apache.org] The review is available here :https://reviews.apache.org/r/74399/ > Expose the Ranger REST API to fetch all the roles that groups belong to > --- > > Key: RANGER-4191 > URL: https://issues.apache.org/jira/browse/RANGER-4191 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4191-Expose-the-Ranger-REST-API-to-fetch-all-.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4191) Expose the Ranger REST API to fetch all the roles that groups belong to
[ https://issues.apache.org/jira/browse/RANGER-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4191: - Attachment: 0001-RANGER-4191-Expose-the-Ranger-REST-API-to-fetch-all-.patch > Expose the Ranger REST API to fetch all the roles that groups belong to > --- > > Key: RANGER-4191 > URL: https://issues.apache.org/jira/browse/RANGER-4191 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4191-Expose-the-Ranger-REST-API-to-fetch-all-.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4191) Expose the Ranger REST API to fetch all the roles that groups belong to
Ramachandran created RANGER-4191: Summary: Expose the Ranger REST API to fetch all the roles that groups belong to Key: RANGER-4191 URL: https://issues.apache.org/jira/browse/RANGER-4191 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Ramachandran Assignee: Ramachandran Fix For: 3.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4190) Apache Ranger does not recover from a recoverable SQL exception
[
https://issues.apache.org/jira/browse/RANGER-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4190:
-
Attachment: 0001-RANGER-4190-Apache-Ranger-does-not-recover-from-a-re.patch
> Apache Ranger does not recover from a recoverable SQL exception
> ---
>
> Key: RANGER-4190
> URL: https://issues.apache.org/jira/browse/RANGER-4190
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4190-Apache-Ranger-does-not-recover-from-a-re.patch
>
>
> It seems the Ranger instance is not able to connect Oracle ATP. This issue
> could be the loss of network connectivity to the load balancer which will
> connect to oracle ATP.
> java.sql.SQLRecoverableException: I/O Exception: Connection reset
> Internal Exception: java.sql.SQLRecoverableException: No more data to read
> from socket
> Error Code: 17410
> This issue could happen due to the loss of connectivity to the oracle ATP
> network load balancer.
> ADB network properties -
> [https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-prepare-jdbc-thin.html#GUID-0A619DFE-5F5F-4302-BF43-B08AEDA05A6C]
>
> [https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rilin/load-balancing-of-connections-to-oracle-rac-databases.html#GUID-06B4373D-1217-44E4-BD86-DE353DA657F6]
> part of the Ranger start we need to add the below JVM parameters to disable
> the network cache by lowering its TTL to
> 0;-Djava.security.egd=[file:///dev/urandom] -Dnetworkaddress.cache.ttl=0
> -Dnetworkaddress.cache.negative.ttl=0
>
> By default, the [OpenJDK 8
> InetAddress|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/InetAddress.java#l189]
> will cache failed DNS queries, referred to as "negative caching", for 10
> seconds. It's recommended to disable both the positive and negative cache by
> setting them to 0 seconds, and rely on the DNS caching implemented inside
> OCI's DNS systems.
> {panel}
> {panel}
> |{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.ttl"{}}}{{{},
> {}}}{{{}0{}}}{{{});{}}}
> {{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.negative.ttl"{}}}{{{},
> {}}}{{{}0{}}}{{{});{}}}
> {{// (Optional) Force Java to use a specific DNS provider}}
> {{// By default it will use whatever lookup is defined in the system =>
> files,nis,dns}}
> {{// as in /etc/nsswitch.conf on linux}}
> {{{}System.setProperty({}}}{{{}"sun.net.spi.nameservice.provider.1"{}}}{{{},
> {}}}{{{}"dns,sun"{}}}{{{});{}}}|
> Or as an argument when invoking Java:
> {panel}
> {panel}
> |{{{}java -Dnetworkaddress.cache.ttl={}}}{{{}0{}}}
> {{{}-Dnetworkaddress.cache.negative.ttl={}}}{{{}0{}}} {{app.jar}}|
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4190) Apache Ranger does not recover from a recoverable SQL exception
[
https://issues.apache.org/jira/browse/RANGER-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712665#comment-17712665
]
Ramachandran commented on RANGER-4190:
--
[~mad...@apache.org] The review is available here
:https://reviews.apache.org/r/74398/
> Apache Ranger does not recover from a recoverable SQL exception
> ---
>
> Key: RANGER-4190
> URL: https://issues.apache.org/jira/browse/RANGER-4190
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
>
> It seems the Ranger instance is not able to connect Oracle ATP. This issue
> could be the loss of network connectivity to the load balancer which will
> connect to oracle ATP.
> java.sql.SQLRecoverableException: I/O Exception: Connection reset
> Internal Exception: java.sql.SQLRecoverableException: No more data to read
> from socket
> Error Code: 17410
> This issue could happen due to the loss of connectivity to the oracle ATP
> network load balancer.
> ADB network properties -
> [https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-prepare-jdbc-thin.html#GUID-0A619DFE-5F5F-4302-BF43-B08AEDA05A6C]
>
> [https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rilin/load-balancing-of-connections-to-oracle-rac-databases.html#GUID-06B4373D-1217-44E4-BD86-DE353DA657F6]
> part of the Ranger start we need to add the below JVM parameters to disable
> the network cache by lowering its TTL to
> 0;-Djava.security.egd=[file:///dev/urandom] -Dnetworkaddress.cache.ttl=0
> -Dnetworkaddress.cache.negative.ttl=0
>
> By default, the [OpenJDK 8
> InetAddress|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/InetAddress.java#l189]
> will cache failed DNS queries, referred to as "negative caching", for 10
> seconds. It's recommended to disable both the positive and negative cache by
> setting them to 0 seconds, and rely on the DNS caching implemented inside
> OCI's DNS systems.
> {panel}
> {panel}
> |{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.ttl"{}}}{{{},
> {}}}{{{}0{}}}{{{});{}}}
> {{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.negative.ttl"{}}}{{{},
> {}}}{{{}0{}}}{{{});{}}}
> {{// (Optional) Force Java to use a specific DNS provider}}
> {{// By default it will use whatever lookup is defined in the system =>
> files,nis,dns}}
> {{// as in /etc/nsswitch.conf on linux}}
> {{{}System.setProperty({}}}{{{}"sun.net.spi.nameservice.provider.1"{}}}{{{},
> {}}}{{{}"dns,sun"{}}}{{{});{}}}|
> Or as an argument when invoking Java:
> {panel}
> {panel}
> |{{{}java -Dnetworkaddress.cache.ttl={}}}{{{}0{}}}
> {{{}-Dnetworkaddress.cache.negative.ttl={}}}{{{}0{}}} {{app.jar}}|
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4190) Apache Ranger does not recover from a recoverable SQL exception
[
https://issues.apache.org/jira/browse/RANGER-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4190:
-
Description:
It seems the Ranger instance is not able to connect Oracle ATP. This issue
could be the loss of network connectivity to the load balancer which will
connect to oracle ATP.
java.sql.SQLRecoverableException: I/O Exception: Connection reset
Internal Exception: java.sql.SQLRecoverableException: No more data to read from
socket
Error Code: 17410
This issue could happen due to the loss of connectivity to the oracle ATP
network load balancer.
ADB network properties -
[https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-prepare-jdbc-thin.html#GUID-0A619DFE-5F5F-4302-BF43-B08AEDA05A6C]
[https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rilin/load-balancing-of-connections-to-oracle-rac-databases.html#GUID-06B4373D-1217-44E4-BD86-DE353DA657F6]
part of the Ranger start we need to add the below JVM parameters to disable
the network cache by lowering its TTL to
0;-Djava.security.egd=[file:///dev/urandom] -Dnetworkaddress.cache.ttl=0
-Dnetworkaddress.cache.negative.ttl=0
By default, the [OpenJDK 8
InetAddress|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/InetAddress.java#l189]
will cache failed DNS queries, referred to as "negative caching", for 10
seconds. It's recommended to disable both the positive and negative cache by
setting them to 0 seconds, and rely on the DNS caching implemented inside OCI's
DNS systems.
{panel}
{panel}
|{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.ttl"{}}}{{{},
{}}}{{{}0{}}}{{{});{}}}
{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.negative.ttl"{}}}{{{},
{}}}{{{}0{}}}{{{});{}}}
{{// (Optional) Force Java to use a specific DNS provider}}
{{// By default it will use whatever lookup is defined in the system =>
files,nis,dns}}
{{// as in /etc/nsswitch.conf on linux}}
{{{}System.setProperty({}}}{{{}"sun.net.spi.nameservice.provider.1"{}}}{{{},
{}}}{{{}"dns,sun"{}}}{{{});{}}}|
Or as an argument when invoking Java:
{panel}
{panel}
|{{{}java -Dnetworkaddress.cache.ttl={}}}{{{}0{}}}
{{{}-Dnetworkaddress.cache.negative.ttl={}}}{{{}0{}}} {{app.jar}}|
was:
It seems the Ranger instance is not able to connect Oracle ATP. This issue
could be the loss of network connectivity to the load balancer which will
connect to oracle ATP.
java.sql.SQLRecoverableException: I/O Exception: Connection reset
Internal Exception: java.sql.SQLRecoverableException: No more data to read from
socket
Error Code: 17410
As we discussed with Abhi, this issue could happen due to the loss of
connectivity to the oracle ATP network load balancer.
ADB network properties -
[https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-prepare-jdbc-thin.html#GUID-0A619DFE-5F5F-4302-BF43-B08AEDA05A6C]
[https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rilin/load-balancing-of-connections-to-oracle-rac-databases.html#GUID-06B4373D-1217-44E4-BD86-DE353DA657F6]
part of the Ranger start we need to add the below JVM parameters to disable
the network cache by lowering its TTL to
0;-Djava.security.egd=file:///dev/urandom -Dnetworkaddress.cache.ttl=0
-Dnetworkaddress.cache.negative.ttl=0
By default, the [OpenJDK 8
InetAddress|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/InetAddress.java#l189]
will cache failed DNS queries, referred to as "negative caching", for 10
seconds. It's recommended to disable both the positive and negative cache by
setting them to 0 seconds, and rely on the DNS caching implemented inside OCI's
DNS systems.
{panel}
{panel}
|{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.ttl"{}}}{{{},
{}}}{{{}0{}}}{{{});{}}}
{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.negative.ttl"{}}}{{{},
{}}}{{{}0{}}}{{{});{}}}
{{// (Optional) Force Java to use a specific DNS provider}}
{{// By default it will use whatever lookup is defined in the system =>
files,nis,dns}}
{{// as in /etc/nsswitch.conf on linux}}
{{{}System.setProperty({}}}{{{}"sun.net.spi.nameservice.provider.1"{}}}{{{},
{}}}{{{}"dns,sun"{}}}{{{});{}}}|
Or as an argument when invoking Java:
{panel}
{panel}
|{{{}java -Dnetworkaddress.cache.ttl={}}}{{{}0{}}}
{{{}-Dnetworkaddress.cache.negative.ttl={}}}{{{}0{}}} {{app.jar}}|
> Apache Ranger does not recover from a recoverable SQL exception
> ---
>
> Key: RANGER-4190
> URL: https://issues.apache.org/jira/browse/RANGER-4190
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
>
[jira] [Created] (RANGER-4190) Apache Ranger does not recover from a recoverable SQL exception
Ramachandran created RANGER-4190:
Summary: Apache Ranger does not recover from a recoverable SQL
exception
Key: RANGER-4190
URL: https://issues.apache.org/jira/browse/RANGER-4190
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Ramachandran
Assignee: Ramachandran
Fix For: 3.0.0
It seems the Ranger instance is not able to connect Oracle ATP. This issue
could be the loss of network connectivity to the load balancer which will
connect to oracle ATP.
java.sql.SQLRecoverableException: I/O Exception: Connection reset
Internal Exception: java.sql.SQLRecoverableException: No more data to read from
socket
Error Code: 17410
As we discussed with Abhi, this issue could happen due to the loss of
connectivity to the oracle ATP network load balancer.
ADB network properties -
[https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-prepare-jdbc-thin.html#GUID-0A619DFE-5F5F-4302-BF43-B08AEDA05A6C]
[https://docs.oracle.com/en/database/oracle/oracle-database/12.2/rilin/load-balancing-of-connections-to-oracle-rac-databases.html#GUID-06B4373D-1217-44E4-BD86-DE353DA657F6]
part of the Ranger start we need to add the below JVM parameters to disable
the network cache by lowering its TTL to
0;-Djava.security.egd=file:///dev/urandom -Dnetworkaddress.cache.ttl=0
-Dnetworkaddress.cache.negative.ttl=0
By default, the [OpenJDK 8
InetAddress|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/InetAddress.java#l189]
will cache failed DNS queries, referred to as "negative caching", for 10
seconds. It's recommended to disable both the positive and negative cache by
setting them to 0 seconds, and rely on the DNS caching implemented inside OCI's
DNS systems.
{panel}
{panel}
|{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.ttl"{}}}{{{},
{}}}{{{}0{}}}{{{});{}}}
{{{}java.security.Security.setProperty({}}}{{{}"networkaddress.cache.negative.ttl"{}}}{{{},
{}}}{{{}0{}}}{{{});{}}}
{{// (Optional) Force Java to use a specific DNS provider}}
{{// By default it will use whatever lookup is defined in the system =>
files,nis,dns}}
{{// as in /etc/nsswitch.conf on linux}}
{{{}System.setProperty({}}}{{{}"sun.net.spi.nameservice.provider.1"{}}}{{{},
{}}}{{{}"dns,sun"{}}}{{{});{}}}|
Or as an argument when invoking Java:
{panel}
{panel}
|{{{}java -Dnetworkaddress.cache.ttl={}}}{{{}0{}}}
{{{}-Dnetworkaddress.cache.negative.ttl={}}}{{{}0{}}} {{app.jar}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4168) Unit test cases are missing for TagDBStore.java
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4168: - Attachment: 0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch > Unit test cases are missing for TagDBStore.java > > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4168) Unit test cases are missing for TagDBStore.java
[ https://issues.apache.org/jira/browse/RANGER-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711982#comment-17711982 ] Ramachandran commented on RANGER-4168: -- [~mad...@apache.org] The review board is available here :[https://reviews.apache.org/r/74395/] > Unit test cases are missing for TagDBStore.java > > > Key: RANGER-4168 > URL: https://issues.apache.org/jira/browse/RANGER-4168 > Project: Ranger > Issue Type: Task > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4168-Unit-test-cases-are-missing-for-TagDBSto.patch > > > This also needs to be added as part of improvement Task which will help the > developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4164) Adding contributor name into ranger-site
[ https://issues.apache.org/jira/browse/RANGER-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4164: - Attachment: 0001-RANGER-4164-Adding-contributor-name-into-ranger-site.patch > Adding contributor name into ranger-site > > > Key: RANGER-4164 > URL: https://issues.apache.org/jira/browse/RANGER-4164 > Project: Ranger > Issue Type: Task > Components: documentation >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Attachments: > 0001-RANGER-4164-Adding-contributor-name-into-ranger-site.patch > > > Adding contributor name into ranger-site in > [https://github.com/apache/ranger-site] > to be visible in the [https://ranger.apache.org/team-list.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4164) Adding contributor name into ranger-site
[ https://issues.apache.org/jira/browse/RANGER-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17708504#comment-17708504 ] Ramachandran commented on RANGER-4164: -- [~mad...@apache.org] The review is available here :[https://reviews.apache.org/r/74379/] > Adding contributor name into ranger-site > > > Key: RANGER-4164 > URL: https://issues.apache.org/jira/browse/RANGER-4164 > Project: Ranger > Issue Type: Task > Components: documentation >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Attachments: > 0001-RANGER-4164-Adding-contributor-name-into-ranger-site.patch > > > Adding contributor name into ranger-site in > [https://github.com/apache/ranger-site] > to be visible in the [https://ranger.apache.org/team-list.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4168) Unit test cases are missing for TagDBStore.java
Ramachandran created RANGER-4168: Summary: Unit test cases are missing for TagDBStore.java Key: RANGER-4168 URL: https://issues.apache.org/jira/browse/RANGER-4168 Project: Ranger Issue Type: Task Components: Ranger Reporter: Ramachandran Assignee: Ramachandran Fix For: 3.0.0 This also needs to be added as part of improvement Task which will help the developer whenever they make code changes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4164) Adding contributor name into ranger-site
[ https://issues.apache.org/jira/browse/RANGER-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707352#comment-17707352 ] Ramachandran commented on RANGER-4164: -- [~mad...@apache.org] [~sneethiraj] Can you please review this PR? > Adding contributor name into ranger-site > > > Key: RANGER-4164 > URL: https://issues.apache.org/jira/browse/RANGER-4164 > Project: Ranger > Issue Type: Task > Components: documentation >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > > Adding contributor name into ranger-site in > [https://github.com/apache/ranger-site] > to be visible in the [https://ranger.apache.org/team-list.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4164) Adding contributor name into ranger-site
Ramachandran created RANGER-4164: Summary: Adding contributor name into ranger-site Key: RANGER-4164 URL: https://issues.apache.org/jira/browse/RANGER-4164 Project: Ranger Issue Type: Task Components: documentation Reporter: Ramachandran Assignee: Ramachandran Adding contributor name into ranger-site in [https://github.com/apache/ranger-site] to be visible in the [https://ranger.apache.org/team-list.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4156) Unit test cases are missing for RoleDBStore.java
[ https://issues.apache.org/jira/browse/RANGER-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4156: - Attachment: 0001-RANGER-4156-Unit-test-cases-are-missing-for-RoleDBSt.patch > Unit test cases are missing for RoleDBStore.java > > > Key: RANGER-4156 > URL: https://issues.apache.org/jira/browse/RANGER-4156 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4156-Unit-test-cases-are-missing-for-RoleDBSt.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4156) Unit test cases are missing for RoleDBStore.java
[ https://issues.apache.org/jira/browse/RANGER-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704686#comment-17704686 ] Ramachandran commented on RANGER-4156: -- [~mad...@apache.org] The review is available here :[https://reviews.apache.org/r/74363/] > Unit test cases are missing for RoleDBStore.java > > > Key: RANGER-4156 > URL: https://issues.apache.org/jira/browse/RANGER-4156 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4156-Unit-test-cases-are-missing-for-RoleDBSt.patch > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4156) Unit test cases are missing for RoleDBStore.java
Ramachandran created RANGER-4156: Summary: Unit test cases are missing for RoleDBStore.java Key: RANGER-4156 URL: https://issues.apache.org/jira/browse/RANGER-4156 Project: Ranger Issue Type: Improvement Components: Ranger Reporter: Ramachandran Assignee: Ramachandran Fix For: 3.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4056) Not able to attach a user to a group while creating it from service/xusers/users endpoint.
[
https://issues.apache.org/jira/browse/RANGER-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703431#comment-17703431
]
Ramachandran edited comment on RANGER-4056 at 3/22/23 1:16 AM:
---
[~spolavarapu], [~rmani] : Is there any reason these APIs are different?
or
shall we make it the same behavior for both ?
cc >> [~madhan]
was (Author: JIRAUSER295265):
[~spolavarapu], [~rmani] : Is there any reason these APIs are different?
or
shall we make it the same behavior for both ?
> Not able to attach a user to a group while creating it from
> service/xusers/users endpoint.
> --
>
> Key: RANGER-4056
> URL: https://issues.apache.org/jira/browse/RANGER-4056
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Kundan Kumar Jha
>Assignee: Ramachandran
>Priority: Major
>
> Problem statement:
> While creating a user from the service/xusers/users its not attaching the
> group in the groupNameList.
> Steps to reproduce:
> Create user by doing post request on service/xusers/users endpoint with
> paylload having "public" as group in it.
> Payload:
> { "name":"temp_user_abc_123", "firstName":"user1", "lastName": "user1",
> "loginId": "user1", "emailAddress" : null, "description" : "user1 desc",
> "password" : "user1Pass@123", "groupIdList":[1], "groupNameList":["public"],
> "status":1, "isVisible":1, "userRoleList": [ "ROLE_USER" ], "userSource": 0 }
>
> Response:
> { "id": 321, "createDate": "2023-01-17T06:18:58Z", "updateDate":
> "2023-01-17T06:18:58Z", "owner": "Admin", "updatedBy": "Admin",
> "name": "temp_user_abc_123", "description": "user1 desc",
> "groupIdList": [], "groupNameList": [], "status": 0, "isVisible":
> 1, "userSource": 0, "userRoleList": [ "ROLE_USER" ] }
>
> In the payload we have provided the "public" as group in groupNameList but in
> the response the groupNameList is empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4133) Improvement in Ranger Roles Rest API's
[
https://issues.apache.org/jira/browse/RANGER-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4133:
-
Attachment: 0001-RANGER-4133-Improvement-in-Ranger-Roles-Rest-API-s.patch
> Improvement in Ranger Roles Rest API's
> --
>
> Key: RANGER-4133
> URL: https://issues.apache.org/jira/browse/RANGER-4133
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
> Attachments:
> 0001-RANGER-4133-Improvement-in-Ranger-Roles-Rest-API-s.patch, Improvement in
> Ranger Roles Rest API's (1).pdf
>
>
> Apis:
> *API :addUsersAndGroups URI:/roles/roles/\{id}/addUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups, Boolean isAdmin).
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups, Boolean
> isAdmin –(RangerUsersAndGroups –Modal mentioned above to accommodate users,
> groups, isAdmin)
>
> *API :removeUsersAndGroups URI:/roles/roles/\{id}/removeUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups)
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups
> (RangerUsersAndGroups –Modal mentioned above to accommodate users,groups)
> *API :removeAdminFromUsersAndGroups
> URI:/roles/roles/\{id}/removeUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups)
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups
> (RangerUsersAndGroups –Modal mentioned above to accommodate users, groups)
> {code:java}
> package org.apache.ranger.plugin.model;import
> org.codehaus.jackson.annotate.JsonAutoDetect;
> import org.codehaus.jackson.annotate.JsonIgnoreProperties;
> import org.codehaus.jackson.map.annotate.JsonSerialize;import
> javax.xml.bind.annotation.XmlAccessType;
> import javax.xml.bind.annotation.XmlAccessorType;
> import javax.xml.bind.annotation.XmlRootElement;
> import
> java.util.List;@JsonAutoDetect(fieldVisibility=JsonAutoDetect.Visibility.ANY)
> @JsonSerialize(include=JsonSerialize.Inclusion.NON_EMPTY)
> @JsonIgnoreProperties(ignoreUnknown=true)
> @XmlRootElement
> @XmlAccessorType(XmlAccessType.FIELD)
> public class RangerUsersAndGroups implements java.io.Serializable {
> private static final long serialVersionUID = 1L;
> private List users;
> private List groups;
> private boolean isAdmin; public RangerUsersAndGroups() {
> this(null, null, false);
> } public RangerUsersAndGroups(List users, List groups,
> boolean isAdmin) {
> this.users = users;
> this.groups = groups;
> this.isAdmin = isAdmin;
> } public List getUsers() {
> return users;
> } public void setUsers(List users) {
> this.users = users;
> } public List getGroups() {
> return groups;
> } public void setGroups(List groups) {
> this.groups = groups;
> } public boolean isAdmin() {
> return isAdmin;
> } public void setAdmin(boolean admin) {
> isAdmin = admin;
> } @Override
> public String toString() {
> final StringBuilder sb = new StringBuilder("RangerUsersAndGroups{");
> sb.append("users=").append(users);
> sb.append(", groups=").append(groups);
> sb.append(", isAdmin=").append(isAdmin);
> sb.append('}');
> return sb.toString();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4056) Not able to attach a user to a group while creating it from service/xusers/users endpoint.
[
https://issues.apache.org/jira/browse/RANGER-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703431#comment-17703431
]
Ramachandran commented on RANGER-4056:
--
[~spolavarapu], [~rmani] : Is there any reason these APIs are different?
or
shall we make it the same behavior for both ?
> Not able to attach a user to a group while creating it from
> service/xusers/users endpoint.
> --
>
> Key: RANGER-4056
> URL: https://issues.apache.org/jira/browse/RANGER-4056
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Kundan Kumar Jha
>Assignee: Ramachandran
>Priority: Major
>
> Problem statement:
> While creating a user from the service/xusers/users its not attaching the
> group in the groupNameList.
> Steps to reproduce:
> Create user by doing post request on service/xusers/users endpoint with
> paylload having "public" as group in it.
> Payload:
> { "name":"temp_user_abc_123", "firstName":"user1", "lastName": "user1",
> "loginId": "user1", "emailAddress" : null, "description" : "user1 desc",
> "password" : "user1Pass@123", "groupIdList":[1], "groupNameList":["public"],
> "status":1, "isVisible":1, "userRoleList": [ "ROLE_USER" ], "userSource": 0 }
>
> Response:
> { "id": 321, "createDate": "2023-01-17T06:18:58Z", "updateDate":
> "2023-01-17T06:18:58Z", "owner": "Admin", "updatedBy": "Admin",
> "name": "temp_user_abc_123", "description": "user1 desc",
> "groupIdList": [], "groupNameList": [], "status": 0, "isVisible":
> 1, "userSource": 0, "userRoleList": [ "ROLE_USER" ] }
>
> In the payload we have provided the "public" as group in groupNameList but in
> the response the groupNameList is empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4139) DOC SITE: ranger.apache.org - revamp site's look and feel
[ https://issues.apache.org/jira/browse/RANGER-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702716#comment-17702716 ] Ramachandran commented on RANGER-4139: -- [~sneethiraj] I guess the apache contributor and committer list needs to be updated Refer: https://ranger.apache.org/team-list.html > DOC SITE: ranger.apache.org - revamp site's look and feel > -- > > Key: RANGER-4139 > URL: https://issues.apache.org/jira/browse/RANGER-4139 > Project: Ranger > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0, 2.4.0 >Reporter: Selvamohan Neethiraj >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4133) Improvement in Ranger Roles Rest API's
[
https://issues.apache.org/jira/browse/RANGER-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700738#comment-17700738
]
Ramachandran commented on RANGER-4133:
--
[~mad...@apache.org] The review is available here
:[https://reviews.apache.org/r/74349]
> Improvement in Ranger Roles Rest API's
> --
>
> Key: RANGER-4133
> URL: https://issues.apache.org/jira/browse/RANGER-4133
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: Improvement in Ranger Roles Rest API's (1).pdf
>
>
> Apis:
> *API :addUsersAndGroups URI:/roles/roles/\{id}/addUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups, Boolean isAdmin).
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups, Boolean
> isAdmin –(RangerUsersAndGroups –Modal mentioned above to accommodate users,
> groups, isAdmin)
>
> *API :removeUsersAndGroups URI:/roles/roles/\{id}/removeUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups)
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups
> (RangerUsersAndGroups –Modal mentioned above to accommodate users,groups)
> *API :removeAdminFromUsersAndGroups
> URI:/roles/roles/\{id}/removeUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups)
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups
> (RangerUsersAndGroups –Modal mentioned above to accommodate users, groups)
> {code:java}
> package org.apache.ranger.plugin.model;import
> org.codehaus.jackson.annotate.JsonAutoDetect;
> import org.codehaus.jackson.annotate.JsonIgnoreProperties;
> import org.codehaus.jackson.map.annotate.JsonSerialize;import
> javax.xml.bind.annotation.XmlAccessType;
> import javax.xml.bind.annotation.XmlAccessorType;
> import javax.xml.bind.annotation.XmlRootElement;
> import
> java.util.List;@JsonAutoDetect(fieldVisibility=JsonAutoDetect.Visibility.ANY)
> @JsonSerialize(include=JsonSerialize.Inclusion.NON_EMPTY)
> @JsonIgnoreProperties(ignoreUnknown=true)
> @XmlRootElement
> @XmlAccessorType(XmlAccessType.FIELD)
> public class RangerUsersAndGroups implements java.io.Serializable {
> private static final long serialVersionUID = 1L;
> private List users;
> private List groups;
> private boolean isAdmin; public RangerUsersAndGroups() {
> this(null, null, false);
> } public RangerUsersAndGroups(List users, List groups,
> boolean isAdmin) {
> this.users = users;
> this.groups = groups;
> this.isAdmin = isAdmin;
> } public List getUsers() {
> return users;
> } public void setUsers(List users) {
> this.users = users;
> } public List getGroups() {
> return groups;
> } public void setGroups(List groups) {
> this.groups = groups;
> } public boolean isAdmin() {
> return isAdmin;
> } public void setAdmin(boolean admin) {
> isAdmin = admin;
> } @Override
> public String toString() {
> final StringBuilder sb = new StringBuilder("RangerUsersAndGroups{");
> sb.append("users=").append(users);
> sb.append(", groups=").append(groups);
> sb.append(", isAdmin=").append(isAdmin);
> sb.append('}');
> return sb.toString();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4133) Improvement in Ranger Roles Rest API's
[
https://issues.apache.org/jira/browse/RANGER-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4133:
-
Attachment: Improvement in Ranger Roles Rest API's (1).pdf
> Improvement in Ranger Roles Rest API's
> --
>
> Key: RANGER-4133
> URL: https://issues.apache.org/jira/browse/RANGER-4133
> Project: Ranger
> Issue Type: Improvement
> Components: Ranger
>Reporter: Ramachandran
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: Improvement in Ranger Roles Rest API's (1).pdf
>
>
> Apis:
> *API :addUsersAndGroups URI:/roles/roles/\{id}/addUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups, Boolean isAdmin).
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups, Boolean
> isAdmin –(RangerUsersAndGroups –Modal mentioned above to accommodate users,
> groups, isAdmin)
>
> *API :removeUsersAndGroups URI:/roles/roles/\{id}/removeUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups)
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups
> (RangerUsersAndGroups –Modal mentioned above to accommodate users,groups)
> *API :removeAdminFromUsersAndGroups
> URI:/roles/roles/\{id}/removeUsersAndGroups*
> In the API we mentioned a couple of fields (List users, List
> groups)
> How the caller will pass the fields
> *Proposed Solution:*
> Via query Parameter (Limitation: we can not pass more characters as part of
> URI )
> Via Request payload of List users, List groups
> (RangerUsersAndGroups –Modal mentioned above to accommodate users, groups)
> {code:java}
> package org.apache.ranger.plugin.model;import
> org.codehaus.jackson.annotate.JsonAutoDetect;
> import org.codehaus.jackson.annotate.JsonIgnoreProperties;
> import org.codehaus.jackson.map.annotate.JsonSerialize;import
> javax.xml.bind.annotation.XmlAccessType;
> import javax.xml.bind.annotation.XmlAccessorType;
> import javax.xml.bind.annotation.XmlRootElement;
> import
> java.util.List;@JsonAutoDetect(fieldVisibility=JsonAutoDetect.Visibility.ANY)
> @JsonSerialize(include=JsonSerialize.Inclusion.NON_EMPTY)
> @JsonIgnoreProperties(ignoreUnknown=true)
> @XmlRootElement
> @XmlAccessorType(XmlAccessType.FIELD)
> public class RangerUsersAndGroups implements java.io.Serializable {
> private static final long serialVersionUID = 1L;
> private List users;
> private List groups;
> private boolean isAdmin; public RangerUsersAndGroups() {
> this(null, null, false);
> } public RangerUsersAndGroups(List users, List groups,
> boolean isAdmin) {
> this.users = users;
> this.groups = groups;
> this.isAdmin = isAdmin;
> } public List getUsers() {
> return users;
> } public void setUsers(List users) {
> this.users = users;
> } public List getGroups() {
> return groups;
> } public void setGroups(List groups) {
> this.groups = groups;
> } public boolean isAdmin() {
> return isAdmin;
> } public void setAdmin(boolean admin) {
> isAdmin = admin;
> } @Override
> public String toString() {
> final StringBuilder sb = new StringBuilder("RangerUsersAndGroups{");
> sb.append("users=").append(users);
> sb.append(", groups=").append(groups);
> sb.append(", isAdmin=").append(isAdmin);
> sb.append('}');
> return sb.toString();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (RANGER-4111) /service/public/v2/api/policy API should return all policies (including policies in security zones)
[
https://issues.apache.org/jira/browse/RANGER-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran resolved RANGER-4111.
--
Resolution: Fixed
> /service/public/v2/api/policy API should return all policies (including
> policies in security zones)
> ---
>
> Key: RANGER-4111
> URL: https://issues.apache.org/jira/browse/RANGER-4111
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> {color:#172b4d}When a request is made to the API endpoint
> base_url/service/public/v2/api/policy,{color}
> {color:#172b4d}only policies which are not present in security zones are
> returned.{color}
> {color:#172b4d}If a request is made to the API endpoint
> \{BASE_URL}/service/public/v2/api/policy?zoneName=\{ZONE_NAME}, the policies
> in a specific zone are returned (which is the expected behaviour).{color}
> {color:#172b4d}Ideally, query params should be used to filter the search
> results, and if no query params are used (for example, if zoneName query
> param is not used), the API should return all the policies in Ranger
> Admin{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4111) /service/public/v2/api/policy API should return all policies (including policies in security zones)
[
https://issues.apache.org/jira/browse/RANGER-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700694#comment-17700694
]
Ramachandran commented on RANGER-4111:
--
We can pass the below query parameter as part of the URI to get
{color:#172b4d}all the policies in Ranger Admin{color}
{color:#172b4d}{BASE_URL}/service/public/v2/api/policy?fetchZoneAndUnzonePolicies=true{color}
Hence Resolving this ticket
> /service/public/v2/api/policy API should return all policies (including
> policies in security zones)
> ---
>
> Key: RANGER-4111
> URL: https://issues.apache.org/jira/browse/RANGER-4111
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> {color:#172b4d}When a request is made to the API endpoint
> base_url/service/public/v2/api/policy,{color}
> {color:#172b4d}only policies which are not present in security zones are
> returned.{color}
> {color:#172b4d}If a request is made to the API endpoint
> \{BASE_URL}/service/public/v2/api/policy?zoneName=\{ZONE_NAME}, the policies
> in a specific zone are returned (which is the expected behaviour).{color}
> {color:#172b4d}Ideally, query params should be used to filter the search
> results, and if no query params are used (for example, if zoneName query
> param is not used), the API should return all the policies in Ranger
> Admin{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-4111) /service/public/v2/api/policy API should return all policies (including policies in security zones)
[
https://issues.apache.org/jira/browse/RANGER-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran reassigned RANGER-4111:
Assignee: Ramachandran
> /service/public/v2/api/policy API should return all policies (including
> policies in security zones)
> ---
>
> Key: RANGER-4111
> URL: https://issues.apache.org/jira/browse/RANGER-4111
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Assignee: Ramachandran
>Priority: Major
>
> {color:#172b4d}When a request is made to the API endpoint
> base_url/service/public/v2/api/policy,{color}
> {color:#172b4d}only policies which are not present in security zones are
> returned.{color}
> {color:#172b4d}If a request is made to the API endpoint
> \{BASE_URL}/service/public/v2/api/policy?zoneName=\{ZONE_NAME}, the policies
> in a specific zone are returned (which is the expected behaviour).{color}
> {color:#172b4d}Ideally, query params should be used to filter the search
> results, and if no query params are used (for example, if zoneName query
> param is not used), the API should return all the policies in Ranger
> Admin{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3010) Rest API 'addUsersAndGroups' issue
[ https://issues.apache.org/jira/browse/RANGER-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700641#comment-17700641 ] Ramachandran commented on RANGER-3010: -- create a separate ticket to address the improvement mentioned in attached document https://issues.apache.org/jira/browse/RANGER-4133 > Rest API 'addUsersAndGroups' issue > -- > > Key: RANGER-3010 > URL: https://issues.apache.org/jira/browse/RANGER-3010 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: leo sun >Assignee: Ramachandran >Priority: Major > Labels: PatchAvailable > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch, Improvement > in Ranger Roles Rest API's (1).pdf > > Time Spent: 40m > Remaining Estimate: 0h > > I want to use Ranger API functions - addUsersAndGroups & removeUsersAndGroups > to manage users and groups of role. But official reference don't have > suitable example for these two APIs. And my all attempts failed. > Another point: For example, I found the input type of addUsersAndGroups is > Boolean on official web, but the input of the implement function is two > string list and one boolean. > I don't know how to use it. Could you help me with this? [~abhayk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (RANGER-4133) Improvement in Ranger Roles Rest API's
Ramachandran created RANGER-4133:
Summary: Improvement in Ranger Roles Rest API's
Key: RANGER-4133
URL: https://issues.apache.org/jira/browse/RANGER-4133
Project: Ranger
Issue Type: Improvement
Components: Ranger
Reporter: Ramachandran
Assignee: Ramachandran
Fix For: 3.0.0
Apis:
*API :addUsersAndGroups URI:/roles/roles/\{id}/addUsersAndGroups*
In the API we mentioned a couple of fields (List users, List
groups, Boolean isAdmin).
How the caller will pass the fields
*Proposed Solution:*
Via query Parameter (Limitation: we can not pass more characters as part of URI
)
Via Request payload of List users, List groups, Boolean isAdmin
–(RangerUsersAndGroups –Modal mentioned above to accommodate users, groups,
isAdmin)
*API :removeUsersAndGroups URI:/roles/roles/\{id}/removeUsersAndGroups*
In the API we mentioned a couple of fields (List users, List
groups)
How the caller will pass the fields
*Proposed Solution:*
Via query Parameter (Limitation: we can not pass more characters as part of URI
)
Via Request payload of List users, List groups
(RangerUsersAndGroups –Modal mentioned above to accommodate users,groups)
*API :removeAdminFromUsersAndGroups URI:/roles/roles/\{id}/removeUsersAndGroups*
In the API we mentioned a couple of fields (List users, List
groups)
How the caller will pass the fields
*Proposed Solution:*
Via query Parameter (Limitation: we can not pass more characters as part of URI
)
Via Request payload of List users, List groups
(RangerUsersAndGroups –Modal mentioned above to accommodate users, groups)
{code:java}
package org.apache.ranger.plugin.model;import
org.codehaus.jackson.annotate.JsonAutoDetect;
import org.codehaus.jackson.annotate.JsonIgnoreProperties;
import org.codehaus.jackson.map.annotate.JsonSerialize;import
javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;
import
java.util.List;@JsonAutoDetect(fieldVisibility=JsonAutoDetect.Visibility.ANY)
@JsonSerialize(include=JsonSerialize.Inclusion.NON_EMPTY)
@JsonIgnoreProperties(ignoreUnknown=true)
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class RangerUsersAndGroups implements java.io.Serializable {
private static final long serialVersionUID = 1L;
private List users;
private List groups;
private boolean isAdmin; public RangerUsersAndGroups() {
this(null, null, false);
} public RangerUsersAndGroups(List users, List groups,
boolean isAdmin) {
this.users = users;
this.groups = groups;
this.isAdmin = isAdmin;
} public List getUsers() {
return users;
} public void setUsers(List users) {
this.users = users;
} public List getGroups() {
return groups;
} public void setGroups(List groups) {
this.groups = groups;
} public boolean isAdmin() {
return isAdmin;
} public void setAdmin(boolean admin) {
isAdmin = admin;
} @Override
public String toString() {
final StringBuilder sb = new StringBuilder("RangerUsersAndGroups{");
sb.append("users=").append(users);
sb.append(", groups=").append(groups);
sb.append(", isAdmin=").append(isAdmin);
sb.append('}');
return sb.toString();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-3010) Rest API 'addUsersAndGroups' issue
[ https://issues.apache.org/jira/browse/RANGER-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700591#comment-17700591 ] Ramachandran commented on RANGER-3010: -- We have attached the proposal document which also needs to be incorporated before merging this PR [^Improvement in Ranger Roles Rest API's (1).pdf] Let me create a separate ticket to address the improvement mentioned in this document After this fix, we will add this fix on top of the improvement mentioned in this document cc >> [~madhan] > Rest API 'addUsersAndGroups' issue > -- > > Key: RANGER-3010 > URL: https://issues.apache.org/jira/browse/RANGER-3010 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: leo sun >Assignee: Ramachandran >Priority: Major > Labels: PatchAvailable > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch, Improvement > in Ranger Roles Rest API's (1).pdf > > Time Spent: 40m > Remaining Estimate: 0h > > I want to use Ranger API functions - addUsersAndGroups & removeUsersAndGroups > to manage users and groups of role. But official reference don't have > suitable example for these two APIs. And my all attempts failed. > Another point: For example, I found the input type of addUsersAndGroups is > Boolean on official web, but the input of the implement function is two > string list and one boolean. > I don't know how to use it. Could you help me with this? [~abhayk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3010) Rest API 'addUsersAndGroups' issue
[ https://issues.apache.org/jira/browse/RANGER-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-3010: - Attachment: Improvement in Ranger Roles Rest API's (1).pdf > Rest API 'addUsersAndGroups' issue > -- > > Key: RANGER-3010 > URL: https://issues.apache.org/jira/browse/RANGER-3010 > Project: Ranger > Issue Type: Improvement > Components: Ranger >Reporter: leo sun >Assignee: Ramachandran >Priority: Major > Labels: PatchAvailable > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-3010-To-support-roleName-as-part-of-Path-para.patch, Improvement > in Ranger Roles Rest API's (1).pdf > > Time Spent: 40m > Remaining Estimate: 0h > > I want to use Ranger API functions - addUsersAndGroups & removeUsersAndGroups > to manage users and groups of role. But official reference don't have > suitable example for these two APIs. And my all attempts failed. > Another point: For example, I found the input type of addUsersAndGroups is > Boolean on official web, but the input of the implement function is two > string list and one boolean. > I don't know how to use it. Could you help me with this? [~abhayk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698165#comment-17698165 ] Ramachandran edited comment on RANGER-4126 at 3/14/23 11:39 AM: [^0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch] was (Author: JIRAUSER295265): [^0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch] > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch, Screenshot > 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4126: - Attachment: 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch, Screenshot > 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4126: - Attachment: (was: 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch) > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch, Screenshot > 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698166#comment-17698166 ] Ramachandran commented on RANGER-4126: -- [~mad...@apache.org] : The review is available here :[https://reviews.apache.org/r/74342] > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch, Screenshot > 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran reassigned RANGER-4126: Fix Version/s: 3.0.0 Assignee: Ramachandran [^0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch] > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch, Screenshot > 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4126: - Attachment: 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Priority: Major > Attachments: > 0001-RANGER-4126-Fetching-getDBVersion-in-BaseDao-class-i.patch, Screenshot > 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4126) Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4126: - Summary: Fetching getDBVersion in BaseDao class in the security-admin-web throws Exception for Oracle Database (was: getDBVersion in BaseDao class in the security-admin-web throws Exception) > Fetching getDBVersion in BaseDao class in the security-admin-web throws > Exception for Oracle Database > - > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Priority: Major > Attachments: Screenshot 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4126) getDBVersion in BaseDao class in the security-admin-web throws Exception
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698158#comment-17698158 ] Ramachandran commented on RANGER-4126: -- !Screenshot 2023-03-09 at 8.47.05 AM.png! > getDBVersion in BaseDao class in the security-admin-web throws Exception > > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Priority: Major > Attachments: Screenshot 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-4126) getDBVersion in BaseDao class in the security-admin-web throws Exception
[ https://issues.apache.org/jira/browse/RANGER-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran updated RANGER-4126: - Attachment: Screenshot 2023-03-09 at 8.47.05 AM.png > getDBVersion in BaseDao class in the security-admin-web throws Exception > > > Key: RANGER-4126 > URL: https://issues.apache.org/jira/browse/RANGER-4126 > Project: Ranger > Issue Type: Bug > Components: admin >Reporter: Arvind Rachuri >Priority: Major > Attachments: Screenshot 2023-03-09 at 8.47.05 AM.png > > > The `getDBVersion` function in `BaseDao` in the security-admin-web module > throws exception even for successful query execution for Oracle DB since it > tries to cast an Array of Objects to a String. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (RANGER-3925) Enhancing /roles/{id}/addUsersAndGroups api to add/update/replace Group to a Role.
[
https://issues.apache.org/jira/browse/RANGER-3925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-3925:
-
Fix Version/s: 3.0.0
(was: 2.4.0)
> Enhancing /roles/{id}/addUsersAndGroups api to add/update/replace Group to a
> Role.
> --
>
> Key: RANGER-3925
> URL: https://issues.apache.org/jira/browse/RANGER-3925
> Project: Ranger
> Issue Type: Bug
> Components: admin, Ranger
>Reporter: Anand Nadar
>Assignee: Ramachandran
>Priority: Major
> Fix For: 3.0.0
>
>
> Enhancing /roles/\{id}/addUsersAndGroups api to add/update/replace Group to a
> Role.
> * The current api only replaces groups of an existing role with list of
> groups coming from API. There need to be a mode to add/update Role groups as
> well.
> API will add new role user/group if it does not exists and will update if it
> exists for the role.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4111) /service/public/v2/api/policy API should return all policies (including policies in security zones)
[
https://issues.apache.org/jira/browse/RANGER-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696562#comment-17696562
]
Ramachandran commented on RANGER-4111:
--
Hi [~abhishek.patil],
Can you please confirm once from your side?
> /service/public/v2/api/policy API should return all policies (including
> policies in security zones)
> ---
>
> Key: RANGER-4111
> URL: https://issues.apache.org/jira/browse/RANGER-4111
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Priority: Major
>
> {color:#172b4d}When a request is made to the API endpoint
> base_url/service/public/v2/api/policy,{color}
> {color:#172b4d}only policies which are not present in security zones are
> returned.{color}
> {color:#172b4d}If a request is made to the API endpoint
> \{BASE_URL}/service/public/v2/api/policy?zoneName=\{ZONE_NAME}, the policies
> in a specific zone are returned (which is the expected behaviour).{color}
> {color:#172b4d}Ideally, query params should be used to filter the search
> results, and if no query params are used (for example, if zoneName query
> param is not used), the API should return all the policies in Ranger
> Admin{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4110) Upgrade to TLS to version 1.2 -Part2
[ https://issues.apache.org/jira/browse/RANGER-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695013#comment-17695013 ] Ramachandran commented on RANGER-4110: -- [~mad...@apache.org] The review is available here :[https://reviews.apache.org/r/74320/|https://reviews.apache.org/r/74320/diff/1/] > Upgrade to TLS to version 1.2 -Part2 > > > Key: RANGER-4110 > URL: https://issues.apache.org/jira/browse/RANGER-4110 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Ramachandran >Assignee: Ramachandran >Priority: Major > Fix For: 3.0.0 > > > As part of RANGER-3153 fix , we changed TLS to TLSv1.2 > Still, the following classes are using TLS > RangerRESTClient > RangerSslHelper > BaseAuditHandler > RemoteUnixLoginModule > DefaultSchemaRegistryClient > NiFiRegistryConnectionMgr > So, we need to change the above classes as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-4112) Update servicedef by name results in 400 status code while the same request works with update servicedef using id
[
https://issues.apache.org/jira/browse/RANGER-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694836#comment-17694836
]
Ramachandran commented on RANGER-4112:
--
[~pradeep]
It is a miss from our side not intentional. As part of UT, i should have added
the negative Test case to get this issue.
> Update servicedef by name results in 400 status code while the same request
> works with update servicedef using id
> -
>
> Key: RANGER-4112
> URL: https://issues.apache.org/jira/browse/RANGER-4112
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments:
> 0001-RANGER-4112-Update-servicedef-by-name-results-in-400.patch, Screenshot
> 2023-02-28 at 3.21.18 PM.png
>
>
> {color:#172b4d}If a PUT request is made to update the servicedef by id
> (BASE_URL/service/public/v2/api/servicedef/id), the request passes,{color}
> {color:#172b4d}but if the same PUT request is made to update the servicedef
> by name (BASE_URL/service/public/v2/api/servicedef/name/\{servicedef_name}),
> then it results in 400 Bad request.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (RANGER-4112) Update servicedef by name results in 400 status code while the same request works with update servicedef using id
[
https://issues.apache.org/jira/browse/RANGER-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694469#comment-17694469
]
Ramachandran edited comment on RANGER-4112 at 2/28/23 10:35 AM:
[~pradeep] My bad somehow this case i missed while doing testing
This logic needs to be changed
if(serviceDef.getId() == null)
{ serviceDef.setId(id); }
else if(!serviceDef.getId().equals(id))
{ throw
restErrorUtil.createRESTException(HttpServletResponse.SC_BAD_REQUEST ,
"serviceDef Id mismatch", true); }
into
if (serviceDef.getId() == null) {
serviceDef.setId(id);
else if(StringUtils.isBlank(serviceDef.getName()) &&
!serviceDef.getId().equals(id)) {
throw restErrorUtil.createRESTException(HttpServletResponse.SC_BAD_REQUEST ,
"serviceDef Id mismatch", true);
}
something like this
When the serviceDef contains the serviceDefName
!Screenshot 2023-02-28 at 3.21.18 PM.png!
was (Author: JIRAUSER295265):
[~pradeep] My bad somehow this case i missed while doing testing
This logic needs to be changed
if(serviceDef.getId() == null) {
serviceDef.setId(id);
} else if(!serviceDef.getId().equals(id)) {
throw
restErrorUtil.createRESTException(HttpServletResponse.SC_BAD_REQUEST ,
"serviceDef Id mismatch", true);
}
into
if (serviceDef.getId() == null) {
serviceDef.setId(id);
{color:#de350b}} else if(StringUtils.isBlank(serviceDef.getName()) &&
!serviceDef.getId().equals(id)) {{color}
throw restErrorUtil.createRESTException(HttpServletResponse.SC_BAD_REQUEST ,
"serviceDef Id mismatch", true);
}
something like this
When the serviceDef contains the serviceDefName
!Screenshot 2023-02-28 at 3.21.18 PM.png!
> Update servicedef by name results in 400 status code while the same request
> works with update servicedef using id
> -
>
> Key: RANGER-4112
> URL: https://issues.apache.org/jira/browse/RANGER-4112
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: Screenshot 2023-02-28 at 3.21.18 PM.png
>
>
> {color:#172b4d}If a PUT request is made to update the servicedef by id
> (BASE_URL/service/public/v2/api/servicedef/id), the request passes,{color}
> {color:#172b4d}but if the same PUT request is made to update the servicedef
> by name (BASE_URL/service/public/v2/api/servicedef/name/\{servicedef_name}),
> then it results in 400 Bad request.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4111) /service/public/v2/api/policy API should return all policies (including policies in security zones)
[
https://issues.apache.org/jira/browse/RANGER-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694479#comment-17694479
]
Ramachandran commented on RANGER-4111:
--
[~abhishek.patil] I guess we can pass the below query parameter as part of the
URI to get
{color:#172b4d}all the policies in Ranger Admin{color}
{color:#172b4d}{BASE_URL}/service/public/v2/api/policy?fetchZoneAndUnzonePolicies=true{color}
{color:#172b4d}cc >> [~mad...@apache.org] {color}
> /service/public/v2/api/policy API should return all policies (including
> policies in security zones)
> ---
>
> Key: RANGER-4111
> URL: https://issues.apache.org/jira/browse/RANGER-4111
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Abhishek
>Priority: Major
>
> {color:#172b4d}When a request is made to the API endpoint
> base_url/service/public/v2/api/policy,{color}
> {color:#172b4d}only policies which are not present in security zones are
> returned.{color}
> {color:#172b4d}If a request is made to the API endpoint
> \{BASE_URL}/service/public/v2/api/policy?zoneName=\{ZONE_NAME}, the policies
> in a specific zone are returned (which is the expected behaviour).{color}
> {color:#172b4d}Ideally, query params should be used to filter the search
> results, and if no query params are used (for example, if zoneName query
> param is not used), the API should return all the policies in Ranger
> Admin{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4112) Update servicedef by name results in 400 status code while the same request works with update servicedef using id
[
https://issues.apache.org/jira/browse/RANGER-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694469#comment-17694469
]
Ramachandran commented on RANGER-4112:
--
[~pradeep] My bad somehow this case i missed while doing testing
This logic needs to be changed
if(serviceDef.getId() == null) {
serviceDef.setId(id);
} else if(!serviceDef.getId().equals(id)) {
throw
restErrorUtil.createRESTException(HttpServletResponse.SC_BAD_REQUEST ,
"serviceDef Id mismatch", true);
}
into
if (serviceDef.getId() == null) {
serviceDef.setId(id);
{color:#de350b}} else if(StringUtils.isBlank(serviceDef.getName()) &&
!serviceDef.getId().equals(id)) {{color}
throw restErrorUtil.createRESTException(HttpServletResponse.SC_BAD_REQUEST ,
"serviceDef Id mismatch", true);
}
something like this
When the serviceDef contains the serviceDefName
!Screenshot 2023-02-28 at 3.21.18 PM.png!
> Update servicedef by name results in 400 status code while the same request
> works with update servicedef using id
> -
>
> Key: RANGER-4112
> URL: https://issues.apache.org/jira/browse/RANGER-4112
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: Screenshot 2023-02-28 at 3.21.18 PM.png
>
>
> {color:#172b4d}If a PUT request is made to update the servicedef by id
> (BASE_URL/service/public/v2/api/servicedef/id), the request passes,{color}
> {color:#172b4d}but if the same PUT request is made to update the servicedef
> by name (BASE_URL/service/public/v2/api/servicedef/name/\{servicedef_name}),
> then it results in 400 Bad request.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (RANGER-4112) Update servicedef by name results in 400 status code while the same request works with update servicedef using id
[
https://issues.apache.org/jira/browse/RANGER-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-4112:
-
Attachment: Screenshot 2023-02-28 at 3.21.18 PM.png
> Update servicedef by name results in 400 status code while the same request
> works with update servicedef using id
> -
>
> Key: RANGER-4112
> URL: https://issues.apache.org/jira/browse/RANGER-4112
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 3.0.0, 2.4.0
>Reporter: Abhishek
>Assignee: Pradeep Agrawal
>Priority: Major
> Fix For: 3.0.0, 2.4.0
>
> Attachments: Screenshot 2023-02-28 at 3.21.18 PM.png
>
>
> {color:#172b4d}If a PUT request is made to update the servicedef by id
> (BASE_URL/service/public/v2/api/servicedef/id), the request passes,{color}
> {color:#172b4d}but if the same PUT request is made to update the servicedef
> by name (BASE_URL/service/public/v2/api/servicedef/name/\{servicedef_name}),
> then it results in 400 Bad request.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (RANGER-4110) Upgrade to TLS to version 1.2 -Part2
Ramachandran created RANGER-4110: Summary: Upgrade to TLS to version 1.2 -Part2 Key: RANGER-4110 URL: https://issues.apache.org/jira/browse/RANGER-4110 Project: Ranger Issue Type: Bug Components: Ranger Reporter: Ramachandran Assignee: Ramachandran Fix For: 3.0.0 As part of RANGER-3153 fix , we changed TLS to TLSv1.2 Still, the following classes are using TLS RangerRESTClient RangerSslHelper BaseAuditHandler RemoteUnixLoginModule DefaultSchemaRegistryClient NiFiRegistryConnectionMgr So, we need to change the above classes as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (RANGER-3153) Upgrade to TLS to version 1.2 and above
[ https://issues.apache.org/jira/browse/RANGER-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693014#comment-17693014 ] Ramachandran edited comment on RANGER-3153 at 2/24/23 6:15 AM: --- Still, the following classes are using TLS RangerRESTClient RangerSslHelper BaseAuditHandler RemoteUnixLoginModule DefaultSchemaRegistryClient NiFiRegistryConnectionMgr So, we need to change the above classes as well cc >> [~mad...@apache.org] was (Author: JIRAUSER295265): The following classes are using TLSv1.2 after the fix RangerRESTClient RangerSslHelper BaseAuditHandler RemoteUnixLoginModule DefaultSchemaRegistryClient NiFiRegistryConnectionMgr NiFiConnectionMgr When it comes to SSL connections, we should be using TLSv1.2. Indeed, it's the default SSL protocol for Java 8. And while Java 7 supports TLSv1.2, the default is TLS v1.0, which is too weak these days. [https://www.baeldung.com/java-7-tls-v12] cc >> [~mad...@apache.org] > Upgrade to TLS to version 1.2 and above > > > Key: RANGER-3153 > URL: https://issues.apache.org/jira/browse/RANGER-3153 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3153-Updated-TLS-version-to-1.2-for-ranger.patch > > > Ranger offers a TLS v1.0 protocol to provide communications security over a > computer network. > It is recommended to switch all communications to a newer version of the > protocol (v 1.2 or 1.3) which is more secure than the older versions. > Ranger's Admin Unix Auth Service(ranger.unixauth.service.port) runs on port > 5151 which found to have TLS 1.0 enabled. > TLS1.0 needs to be disabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (RANGER-3153) Upgrade to TLS to version 1.2 and above
[ https://issues.apache.org/jira/browse/RANGER-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693014#comment-17693014 ] Ramachandran commented on RANGER-3153: -- The following classes are using TLSv1.2 after the fix RangerRESTClient RangerSslHelper BaseAuditHandler RemoteUnixLoginModule DefaultSchemaRegistryClient NiFiRegistryConnectionMgr NiFiConnectionMgr When it comes to SSL connections, we should be using TLSv1.2. Indeed, it's the default SSL protocol for Java 8. And while Java 7 supports TLSv1.2, the default is TLS v1.0, which is too weak these days. [https://www.baeldung.com/java-7-tls-v12] cc >> [~mad...@apache.org] > Upgrade to TLS to version 1.2 and above > > > Key: RANGER-3153 > URL: https://issues.apache.org/jira/browse/RANGER-3153 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: > 0001-RANGER-3153-Updated-TLS-version-to-1.2-for-ranger.patch > > > Ranger offers a TLS v1.0 protocol to provide communications security over a > computer network. > It is recommended to switch all communications to a newer version of the > protocol (v 1.2 or 1.3) which is more secure than the older versions. > Ranger's Admin Unix Auth Service(ranger.unixauth.service.port) runs on port > 5151 which found to have TLS 1.0 enabled. > TLS1.0 needs to be disabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-2738) is there limit on maximum number of ranger policies?
[ https://issues.apache.org/jira/browse/RANGER-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramachandran resolved RANGER-2738. -- Assignee: Ramachandran Resolution: Fixed > is there limit on maximum number of ranger policies? > > > Key: RANGER-2738 > URL: https://issues.apache.org/jira/browse/RANGER-2738 > Project: Ranger > Issue Type: Wish > Components: Ranger >Reporter: t oo >Assignee: Ramachandran >Priority: Major > > can i have 1 million policies or is there some hard limit? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (RANGER-3063) 404 http status response on requesting an existing policy
[
https://issues.apache.org/jira/browse/RANGER-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran resolved RANGER-3063.
--
Resolution: Fixed
> 404 http status response on requesting an existing policy
> -
>
> Key: RANGER-3063
> URL: https://issues.apache.org/jira/browse/RANGER-3063
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 2.0.0
> Environment: Cloudera, CDP (CDH) 7.1.3
> Hadoop - 3.1.1.7.1.3.0-100
> Ranger - 2.0.0.7.1.3.0-100
>Reporter: Vyacheslav Tutrinov
>Assignee: Ramachandran
>Priority: Major
>
> I caught a strange behavior of the ranger admin REST API.
> The challenge was started as I saw that the 'cm_kms' service doesn't appear
> on the UI side however it exists in the REST API response.
> Then the trying to get policies list for this service respond by the list
> that contains the single policy:
> {code:bash}
> [root@vm path]# curl -XGET -u user:** -v
> http://my-ranger-server-host:6080/service/public/v2/api/service/cm_kms/policy
> * About to connect() tomy-ranger-server-host port 6080 (#0)
> * Trying 10.6.120.140...
> * Connected to my-ranger-server-host (10.6.120.140) port 6080 (#0)
> * Server auth using Basic with user 'user'
> > GET /service/public/v2/api/service/cm_kms/policy HTTP/1.1
> > Authorization: Basic *
> > User-Agent: curl/7.29.0
> > Host: my-ranger-server-host:6080
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Set-Cookie: RANGERADMINSESSIONID=42E2616A84477202A0CB4442C9C4EA88; Path=/;
> HttpOnly
> < X-Frame-Options: DENY
> < X-XSS-Protection: 1; mode=block
> < Strict-Transport-Security: max-age=31536000; includeSubDomains
> < Content-Security-Policy: default-src 'none'; script-src 'self'
> 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self'; style-src
> 'self' 'unsafe-inline';font-src 'self'
> < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
> < Pragma: no-cache
> < Expires: 0
> < X-Content-Type-Options: nosniff
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> < Date: Thu, 29 Oct 2020 07:11:15 GMT
> < Server: Apache Ranger
> <
> [{"id":41,"guid":"52b42504-5798-4340-9da3-8e9188a3592f","isEnabled":true,"version":1,"service":"cm_kms","name":"all
> - keyname","policyType":0,"policyPriority":0,"description":"Policy for all -
> keyname","isAuditEnabled":true,"resources":{"keyname":{"values":["*"],"isExcludes":false,"isRecursive":false}},"policyItems":[{"accesses":[{"type":"create","isAllowed":true},{"type":"delete","isAllowed":true},{"type":"rollover","isAllowed":true},{"type":"setkeymaterial","isAllowed":true},{"type":"get","isAllowed":true},{"type":"getkeys","isAllowed":true},{"type":"getmetadata","isAllowed":true},{"type":"generateeek","isAllowed":true},{"type":"decrypteek","isAllowed":true}],"users":["keyadmin"],"groups":[],"roles":[],"conditions":[],"delegateAdmin":true},{"accesses":[{"type":"getmetadata","isAllowed":true},{"type":"generateeek","isAllowed":true}],"users":["hdfs"],"groups":[],"roles":[],"conditions":[],"delegateAdmin":true},{"accesses":[{"type":"getmetadata","isAllowed":true},{"type":"decrypteek","isAllowed":true}],"users":["hive"],"groups":[],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],"denyExceptions":[],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"kms","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}]
> {code}
> However the request for the specific policy by name 'all - keyname' responded
> by 404 status:
> {code:bash}
> [root@vm path]# curl -XGET -u user:** -v
> http://my-ranger-server-host:6080/service/public/v2/api/service/cm_kms/policy/all%20-%20keyname
> * About to connect() to my-ranger-server-host port 6080 (#0)
> * Trying 10.6.120.140...
> * Connected to my-ranger-server-host (10.6.120.140) port 6080 (#0)
> * Server auth using Basic with user 'user'
> > GET /service/public/v2/api/service/cm_kms/policy/all%20-%20keyname HTTP/1.1
> > Authorization: Basic ***
> > User-Agent: curl/7.29.0
> > Host: my-ranger-server-host:6080
> > Accept: */*
> >
> < HTTP/1.1 404 Not Found
> < Set-Cookie: RANGERADMINSESSIONID=2885FFB77C5B83345F5F6C0F4E7CB4D8; Path=/;
> HttpOnly
> < X-Frame-Options: DENY
> < X-XSS-Protection: 1; mode=block
> < Strict-Transport-Security: max-age=31536000; includeSubDomains
> < Content-Security-Policy: default-src 'none'; script-src 'self'
> 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self'; style-src
> 'self' 'unsafe-inline';font-src 'self'
> < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
> < Pragma: no-cache
> < Expires: 0
> < X-Content-Type-Options: nosniff
> < Content-Type: application/json
> <
[jira] [Updated] (RANGER-3899) Policy creation takes more time when there are more users,groups,roles
[
https://issues.apache.org/jira/browse/RANGER-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran updated RANGER-3899:
-
Description:
*{color:#ff}Policy Creation Steps in Apache Ranger:{color}*{color:#ff}
{color}
{code:java}
1. Get the service by Name:
RangerService service = getServiceByName(policy.getService());→ 1DB Read call
2. Get XXServiceDef by Name
XXServiceDef xServiceDef =
daoMgr.getXXServiceDef().findByName(service.getType()); → 1DB Read call
3. Get the existing XXPolicy by Name
XXPolicy existing =
daoMgr.getXXPolicy().findByNameAndServiceIdAndZoneId(policy.getName(),
service.getId(), zoneId); → 1DB Read call
4. Create a policy
policy = policyService.create(policy, true); → 1DB Write call
5. Get policy by Id
XXPolicy xCreatedPolicy = daoMgr.getXXPolicy().getById(policy.getId()); → 1DB
Read call
6. createObjectDataHistory for the newly created policy
dataHistService.createObjectDataHistory(createdPolicy,
RangerDataHistService.ACTION_CREATE); → 1DB Write call
7. createTrxLog for the newly created policy
bizUtil.createTrxLog(trxLogList); → 1DB Write call
8. Create Policy Label for the newly created policy
createOrMapLabels(xCreatedPolicy, uniquePolicyLabels); → 1DB Write call
9. Create Policy Mapping For Ref Table
policyRefUpdater.createNewPolMappingForRefTable(policy, xCreatedPolicy,
xServiceDef);
1. Getting
roleNames,groupNames,userNames,accessTypes,dataMaskTypes,conditionTypes from
each policy items of the policy
2. Getting resourceNames from the policy
3.For each resource
Getting the XXResourceDef by resource and policy.getId()
XXResourceDef xResDef =
daoMgr.getXXResourceDef().findByNameAndPolicyId(resource, policy.getId()); →
1DB Read call for each resource
populate XXPolicyRefResource
4. Create the batch of XXPolicyRefResource in DB
daoMgr.getXXPolicyRefResource().batchCreate(xPolResources); → 1DB Batch Write
call
5.For each roleNames
Getting XXRole by roleName
XXRole xRole = daoMgr.getXXRole().findByRoleName(role); → 1DB Read call for
each role
populate XXPolicyRefRole
6. Create the batch of XXPolicyRefRole in DB
daoMgr.getXXPolicyRefResource().batchCreate(xPolRoles); → 1DB Batch Write
call
7.For each groupNames
Getting the XXGroup by groupName
XXGroup xGroup = daoMgr.getXXGroup().findByGroupName(context.group.getName());→
1DB Read call for each group
populate XXPolicyRefGroup
Insert into DB
daoMgr.getXXPolicyRefGroup().create(xPolGroup);→ 1DB write call for each group
8.For each userNames
Getting XXUser by userName
XXUser xUser = daoMgr.getXXUser().findByUserName(user); → 1DB Read call for
each user
populate XXPolicyRefUser
daoMgr.getXXPolicyRefUser().create(xPolUser); → 1DB write call for each user
9.For each accessTypes
Getting the XXAccessTypeDef by accessType and xPolicy.getService()
XXAccessTypeDef xAccTypeDef =
daoMgr.getXXAccessTypeDef().findByNameAndServiceId(accessType,
xPolicy.getService()); → 1DB Read call for each accesType
populate XXAccessTypeDef
10. Create the batch of xPolAccesses in DB
daoMgr.getXXPolicyRefAccessType().batchCreate(xPolAccesses); → 1DB Batch Write
call
11.For each conditionTypes
Getting the XXPolicyConditionDef by condition and xServiceDef.getId()
XXPolicyConditionDef xPolCondDef =
daoMgr.getXXPolicyConditionDef().findByServiceDefIdAndName(xServiceDef.getId(),
condition); → 1DB Read call for each conditionType
populate XXPolicyConditionDef
12. Create the batch of xPolConds in DB
daoMgr.getXXPolicyRefCondition().batchCreate(xPolConds); → 1DB Batch Write call
{code}
*{color:#ff}A total number of DB calls involved for the below Policy
creation in Apache Ranger(Before Fix):{color}*
The Policy contains 500 users,5 access Types (permissions),12 resources
(1DB,1Table,10 columns)
||DB Write count||DB Read count||DB Batch Write count||Time is taken to create
the policy||
|504|526|3|{color:#ff}4~8 seconds{color}|
*{color:#ff}A total number of DB calls involved for the below Policy
creation in Apache Ranger(After Fix):{color}*
The policy contains 500 users,5 access Types (permissions),12 resources
(1DB,1Table,10 columns)
{color:#ff}Proposal :{color}
{color:#ff}After changing to batch create of XXPolicyRefUser instead of
calling 1 DB write XXPolicyRefUser for every user of the policy:{color}
||DB Write count||DB Read count||DB Batch Write count||Time is taken to create
the policy||
|6|526|5|{color:#ff}2.6~4 seconds{color}|
A similar will be applied for roles and groups as well.
After fixing (RANGER-3899, RANGER-2732,)
When Policy contains 500 users,5 access Types (permissions),12 resources
(1DB,1Table,10 columns)
After the Batch read the calls will be reduced into
||DB Write count||DB Read count||DB Batch Write count||Time is taken to create
the policy||
|6|27|5|<2.6 seconds |
DB read calls will be reduced to {color:#de350b}27{color} from
{color:#403294}526{color}
[jira] [Commented] (RANGER-4056) Not able to attach a user to a group while creating it from service/xusers/users endpoint.
[
https://issues.apache.org/jira/browse/RANGER-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684759#comment-17684759
]
Ramachandran commented on RANGER-4056:
--
As part of service/xusers/users endpoint for the create user is not honouring
to associate the group for the given user
[~mad...@apache.org] Is this the expected behaviour for this API?
{code:java}
public VXUser createXUserWithOutLogin(VXUser vXUser) {
checkAdminAccess();
xaBizUtil.blockAuditorRoleUser();
validatePassword(vXUser);
VXUser ret = xUserService.createXUserWithOutLogin(vXUser);
updateUserStoreVersion("createXUserWithOutLogin(" + vXUser.getName() + ")");
return ret;
}
public VXUser createXUserWithOutLogin(VXUser vxUser) {
XXUser xxUser = daoManager.getXXUser().findByUserName(vxUser.getName());
boolean userExists = true;
if (xxUser == null) {
xxUser = new XXUser();
userExists = false;
}
XXPortalUser xxPortalUser = daoManager.getXXPortalUser().findByLoginId(
vxUser.getName());
if (xxPortalUser != null
&& xxPortalUser.getUserSource() == RangerCommonEnums.USER_EXTERNAL) {
vxUser.setIsVisible(xxUser.getIsVisible());
}
xxUser = mapViewToEntityBean(vxUser, xxUser, 0);
XXPortalUser xXPortalUser =
daoManager.getXXPortalUser().getById(createdByUserId);
if (xXPortalUser != null) {
xxUser.setAddedByUserId(createdByUserId);
xxUser.setUpdatedByUserId(createdByUserId);
}
if (userExists) {
xxUser = getDao().update(xxUser);
} else {
xxUser = getDao().create(xxUser);
}
vxUser = postCreate(xxUser);
return vxUser;
}
{code}
> Not able to attach a user to a group while creating it from
> service/xusers/users endpoint.
> --
>
> Key: RANGER-4056
> URL: https://issues.apache.org/jira/browse/RANGER-4056
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Affects Versions: 2.3.0
>Reporter: Kundan Kumar Jha
>Assignee: Ramachandran
>Priority: Major
>
> Problem statement:
> While creating a user from the service/xusers/users its not attaching the
> group in the groupNameList.
> Steps to reproduce:
> Create user by doing post request on service/xusers/users endpoint with
> paylload having "public" as group in it.
> Payload:
> { "name":"temp_user_abc_123", "firstName":"user1", "lastName": "user1",
> "loginId": "user1", "emailAddress" : null, "description" : "user1 desc",
> "password" : "user1Pass@123", "groupIdList":[1], "groupNameList":["public"],
> "status":1, "isVisible":1, "userRoleList": [ "ROLE_USER" ], "userSource": 0 }
>
> Response:
> { "id": 321, "createDate": "2023-01-17T06:18:58Z", "updateDate":
> "2023-01-17T06:18:58Z", "owner": "Admin", "updatedBy": "Admin",
> "name": "temp_user_abc_123", "description": "user1 desc",
> "groupIdList": [], "groupNameList": [], "status": 0, "isVisible":
> 1, "userSource": 0, "userRoleList": [ "ROLE_USER" ] }
>
> In the payload we have provided the "public" as group in groupNameList but in
> the response the groupNameList is empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (RANGER-4056) Not able to attach a user to a group while creating it from service/xusers/users endpoint.
[
https://issues.apache.org/jira/browse/RANGER-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684685#comment-17684685
]
Ramachandran commented on RANGER-4056:
--
[~kundan.jha]
I could not succeed to reproduce this issue.
Can you please update the ticket with the Ranger version so we can able to
reproduce this issue with steps and screenshots if possible?
> Not able to attach a user to a group while creating it from
> service/xusers/users endpoint.
> --
>
> Key: RANGER-4056
> URL: https://issues.apache.org/jira/browse/RANGER-4056
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
>Reporter: Kundan Kumar Jha
>Assignee: Ramachandran
>Priority: Major
>
> Problem statement:
> While creating a user from the service/xusers/users its not attaching the
> group in the groupNameList.
> Steps to reproduce:
> Create user by doing post request on service/xusers/users endpoint with
> paylload having "public" as group in it.
> Payload:
> { "name":"temp_user_abc_123", "firstName":"user1", "lastName": "user1",
> "loginId": "user1", "emailAddress" : null, "description" : "user1 desc",
> "password" : "user1Pass@123", "groupIdList":[1], "groupNameList":["public"],
> "status":1, "isVisible":1, "userRoleList": [ "ROLE_USER" ], "userSource": 0 }
>
> Response:
> { "id": 321, "createDate": "2023-01-17T06:18:58Z", "updateDate":
> "2023-01-17T06:18:58Z", "owner": "Admin", "updatedBy": "Admin",
> "name": "temp_user_abc_123", "description": "user1 desc",
> "groupIdList": [], "groupNameList": [], "status": 0, "isVisible":
> 1, "userSource": 0, "userRoleList": [ "ROLE_USER" ] }
>
> In the payload we have provided the "public" as group in groupNameList but in
> the response the groupNameList is empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (RANGER-3063) 404 http status response on requesting an existing policy
[
https://issues.apache.org/jira/browse/RANGER-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramachandran reassigned RANGER-3063:
Assignee: Ramachandran
> 404 http status response on requesting an existing policy
> -
>
> Key: RANGER-3063
> URL: https://issues.apache.org/jira/browse/RANGER-3063
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 2.0.0
> Environment: Cloudera, CDP (CDH) 7.1.3
> Hadoop - 3.1.1.7.1.3.0-100
> Ranger - 2.0.0.7.1.3.0-100
>Reporter: Vyacheslav Tutrinov
>Assignee: Ramachandran
>Priority: Major
>
> I caught a strange behavior of the ranger admin REST API.
> The challenge was started as I saw that the 'cm_kms' service doesn't appear
> on the UI side however it exists in the REST API response.
> Then the trying to get policies list for this service respond by the list
> that contains the single policy:
> {code:bash}
> [root@vm path]# curl -XGET -u user:** -v
> http://my-ranger-server-host:6080/service/public/v2/api/service/cm_kms/policy
> * About to connect() tomy-ranger-server-host port 6080 (#0)
> * Trying 10.6.120.140...
> * Connected to my-ranger-server-host (10.6.120.140) port 6080 (#0)
> * Server auth using Basic with user 'user'
> > GET /service/public/v2/api/service/cm_kms/policy HTTP/1.1
> > Authorization: Basic *
> > User-Agent: curl/7.29.0
> > Host: my-ranger-server-host:6080
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Set-Cookie: RANGERADMINSESSIONID=42E2616A84477202A0CB4442C9C4EA88; Path=/;
> HttpOnly
> < X-Frame-Options: DENY
> < X-XSS-Protection: 1; mode=block
> < Strict-Transport-Security: max-age=31536000; includeSubDomains
> < Content-Security-Policy: default-src 'none'; script-src 'self'
> 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self'; style-src
> 'self' 'unsafe-inline';font-src 'self'
> < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
> < Pragma: no-cache
> < Expires: 0
> < X-Content-Type-Options: nosniff
> < Content-Type: application/json
> < Transfer-Encoding: chunked
> < Date: Thu, 29 Oct 2020 07:11:15 GMT
> < Server: Apache Ranger
> <
> [{"id":41,"guid":"52b42504-5798-4340-9da3-8e9188a3592f","isEnabled":true,"version":1,"service":"cm_kms","name":"all
> - keyname","policyType":0,"policyPriority":0,"description":"Policy for all -
> keyname","isAuditEnabled":true,"resources":{"keyname":{"values":["*"],"isExcludes":false,"isRecursive":false}},"policyItems":[{"accesses":[{"type":"create","isAllowed":true},{"type":"delete","isAllowed":true},{"type":"rollover","isAllowed":true},{"type":"setkeymaterial","isAllowed":true},{"type":"get","isAllowed":true},{"type":"getkeys","isAllowed":true},{"type":"getmetadata","isAllowed":true},{"type":"generateeek","isAllowed":true},{"type":"decrypteek","isAllowed":true}],"users":["keyadmin"],"groups":[],"roles":[],"conditions":[],"delegateAdmin":true},{"accesses":[{"type":"getmetadata","isAllowed":true},{"type":"generateeek","isAllowed":true}],"users":["hdfs"],"groups":[],"roles":[],"conditions":[],"delegateAdmin":true},{"accesses":[{"type":"getmetadata","isAllowed":true},{"type":"decrypteek","isAllowed":true}],"users":["hive"],"groups":[],"roles":[],"conditions":[],"delegateAdmin":true}],"denyPolicyItems":[],"allowExceptions":[],"denyExceptions":[],"dataMaskPolicyItems":[],"rowFilterPolicyItems":[],"serviceType":"kms","options":{},"validitySchedules":[],"policyLabels":[],"zoneName":"","isDenyAllElse":false}]
> {code}
> However the request for the specific policy by name 'all - keyname' responded
> by 404 status:
> {code:bash}
> [root@vm path]# curl -XGET -u user:** -v
> http://my-ranger-server-host:6080/service/public/v2/api/service/cm_kms/policy/all%20-%20keyname
> * About to connect() to my-ranger-server-host port 6080 (#0)
> * Trying 10.6.120.140...
> * Connected to my-ranger-server-host (10.6.120.140) port 6080 (#0)
> * Server auth using Basic with user 'user'
> > GET /service/public/v2/api/service/cm_kms/policy/all%20-%20keyname HTTP/1.1
> > Authorization: Basic ***
> > User-Agent: curl/7.29.0
> > Host: my-ranger-server-host:6080
> > Accept: */*
> >
> < HTTP/1.1 404 Not Found
> < Set-Cookie: RANGERADMINSESSIONID=2885FFB77C5B83345F5F6C0F4E7CB4D8; Path=/;
> HttpOnly
> < X-Frame-Options: DENY
> < X-XSS-Protection: 1; mode=block
> < Strict-Transport-Security: max-age=31536000; includeSubDomains
> < Content-Security-Policy: default-src 'none'; script-src 'self'
> 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self'; style-src
> 'self' 'unsafe-inline';font-src 'self'
> < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
> < Pragma: no-cache
> < Expires: 0
> < X-Content-Type-Options: nosniff
> < Content-Type: application/json
> <
[jira] [Comment Edited] (RANGER-2738) is there limit on maximum number of ranger policies?
[ https://issues.apache.org/jira/browse/RANGER-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683503#comment-17683503 ] Ramachandran edited comment on RANGER-2738 at 2/6/23 1:16 PM: -- [~toopt4] Do we need to keep this ticket? or close this ticket if you got the answer cc >> [~mad...@apache.org] was (Author: JIRAUSER295265): [~toopt4] Do we need to keep this ticket? or close this ticket if you got the answer > is there limit on maximum number of ranger policies? > > > Key: RANGER-2738 > URL: https://issues.apache.org/jira/browse/RANGER-2738 > Project: Ranger > Issue Type: Wish > Components: Ranger >Reporter: t oo >Priority: Major > > can i have 1 million policies or is there some hard limit? -- This message was sent by Atlassian Jira (v8.20.10#820010)
