[jira] [Updated] (RANGER-3512) Create Java patch to update policy guid to unique value.
[ https://issues.apache.org/jira/browse/RANGER-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dineshkumar Yadav updated RANGER-3512: -- Description: This Java patch will try to find duplicate GUID in x_policy table based on service, If found then update them to a unique value. (was: This Java patch will try to find duplicate GUID in x_policy table, If found then update them to a unique value. ) > Create Java patch to update policy guid to unique value. > > > Key: RANGER-3512 > URL: https://issues.apache.org/jira/browse/RANGER-3512 > Project: Ranger > Issue Type: Sub-task > Components: Ranger >Reporter: Dineshkumar Yadav >Assignee: Dineshkumar Yadav >Priority: Major > Fix For: 2.2.0 > > > This Java patch will try to find duplicate GUID in x_policy table based on > service, If found then update them to a unique value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (RANGER-3516) Java patch 'J10045' taking more time during upgrade.
[ https://issues.apache.org/jira/browse/RANGER-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444982#comment-17444982 ] Bhavik Patel commented on RANGER-3516: -- Thanks [~Mateen.Mansoori] for the patch. Drastic change in the patch execution(run) time:). > Java patch 'J10045' taking more time during upgrade. > > > Key: RANGER-3516 > URL: https://issues.apache.org/jira/browse/RANGER-3516 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Assignee: Mateen Mansoori >Priority: Major > > J10045 patch is taking more time to apply when we upgrade -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3516) Java patch 'J10045' taking more time during upgrade.
[ https://issues.apache.org/jira/browse/RANGER-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavik Patel reassigned RANGER-3516: Assignee: Mateen Mansoori (was: Bhavik Patel) > Java patch 'J10045' taking more time during upgrade. > > > Key: RANGER-3516 > URL: https://issues.apache.org/jira/browse/RANGER-3516 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Assignee: Mateen Mansoori >Priority: Major > > J10045 patch is taking more time to apply when we upgrade -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (RANGER-3516) Java patch 'J10045' taking more time during upgrade.
[ https://issues.apache.org/jira/browse/RANGER-3516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavik Patel reassigned RANGER-3516: Assignee: Bhavik Patel > Java patch 'J10045' taking more time during upgrade. > > > Key: RANGER-3516 > URL: https://issues.apache.org/jira/browse/RANGER-3516 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Harshal Chavan >Assignee: Bhavik Patel >Priority: Major > > J10045 patch is taking more time to apply when we upgrade -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Review Request 73706: RANGER-3504 : Create framework to execute DB patch dependent on Java patch.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/73706/#review223748 --- Ship it! Ship It! - bhavik patel On Nov. 16, 2021, 1:39 p.m., Dineshkumar Yadav wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/73706/ > --- > > (Updated Nov. 16, 2021, 1:39 p.m.) > > > Review request for ranger, Ankita Sinha, Jayendra Parab, Kishor > Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep > Agrawal, Ramesh Mani, Vishal Suvagia, and Velmurugan Periasamy. > > > Bugs: RANGER-3504 > https://issues.apache.org/jira/browse/RANGER-3504 > > > Repository: ranger > > > Description > --- > > Problem Statement > Currently we have two sets of patches in Ranger (DB & Java patches). > During Ranger setup, DB patches get executed first then Java patches get > executed in an orderly manner based on their sequence. > We don't have any mechanism where we can execute Java Patch first and it's > dependent DB patch afterwards. > > Please find the below approach to handle such scenarios. > Approach: > While executing DB patches, first check if any pre java patches are present > by name starting with PatchPreSql_. > If a Pre Java patch is found then execute that java patch first. > Execute DB patch. > Check again if there are any post java patches present by name starting with > PatchPostSql_. > If Post Java patches are found, execute them. > While naming the dependent Java patches we need to follow the below > convention. > Currently we follow convention: Patch_J<5 digit sequence > number>.java > Proposed naming convention for dependent Java Patch. Patch Pre>Sql___J<5 digit sequence > number>.java > Use Case: > Suppose we have a DB patch (050-uniqueindex.sql) and there are two Java > patches one needs to execute before and another immediately after DB patch. > In that scenario we should use the following convention for naming java > patches. > Pre Java Patch : PatchPreSql_050_CleanData_J10050.java > Post Java Patch : PatchPostSql_050_UpdateData_J10051.java > > > Diffs > - > > security-admin/scripts/db_setup.py 29f074326 > > > Diff: https://reviews.apache.org/r/73706/diff/2/ > > > Testing > --- > > Tested in local setup for dependent pre and post java patch. > > > Thanks, > > Dineshkumar Yadav > >
Re: Review Request 73706: RANGER-3504 : Create framework to execute DB patch dependent on Java patch.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/73706/#review223746 --- Ship it! Ship It! - Pradeep Agrawal On Nov. 16, 2021, 1:39 p.m., Dineshkumar Yadav wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/73706/ > --- > > (Updated Nov. 16, 2021, 1:39 p.m.) > > > Review request for ranger, Ankita Sinha, Jayendra Parab, Kishor > Gollapalliwar, Abhay Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep > Agrawal, Ramesh Mani, Vishal Suvagia, and Velmurugan Periasamy. > > > Bugs: RANGER-3504 > https://issues.apache.org/jira/browse/RANGER-3504 > > > Repository: ranger > > > Description > --- > > Problem Statement > Currently we have two sets of patches in Ranger (DB & Java patches). > During Ranger setup, DB patches get executed first then Java patches get > executed in an orderly manner based on their sequence. > We don't have any mechanism where we can execute Java Patch first and it's > dependent DB patch afterwards. > > Please find the below approach to handle such scenarios. > Approach: > While executing DB patches, first check if any pre java patches are present > by name starting with PatchPreSql_. > If a Pre Java patch is found then execute that java patch first. > Execute DB patch. > Check again if there are any post java patches present by name starting with > PatchPostSql_. > If Post Java patches are found, execute them. > While naming the dependent Java patches we need to follow the below > convention. > Currently we follow convention: Patch_J<5 digit sequence > number>.java > Proposed naming convention for dependent Java Patch. Patch Pre>Sql___J<5 digit sequence > number>.java > Use Case: > Suppose we have a DB patch (050-uniqueindex.sql) and there are two Java > patches one needs to execute before and another immediately after DB patch. > In that scenario we should use the following convention for naming java > patches. > Pre Java Patch : PatchPreSql_050_CleanData_J10050.java > Post Java Patch : PatchPostSql_050_UpdateData_J10051.java > > > Diffs > - > > security-admin/scripts/db_setup.py 29f074326 > > > Diff: https://reviews.apache.org/r/73706/diff/2/ > > > Testing > --- > > Tested in local setup for dependent pre and post java patch. > > > Thanks, > > Dineshkumar Yadav > >
Re: Review Request 73707: RANGER-3511:Create Java patch to update policy resource-signature to unique value.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/73707/#review223745 --- Ship it! Ship It! - Pradeep Agrawal On Nov. 16, 2021, 2:59 p.m., Dineshkumar Yadav wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/73707/ > --- > > (Updated Nov. 16, 2021, 2:59 p.m.) > > > Review request for ranger, Jayendra Parab, Kishor Gollapalliwar, Abhay > Kulkarni, Madhan Neethiraj, Mehul Parikh, Pradeep Agrawal, Ramesh Mani, > Vishal Suvagia, and Velmurugan Periasamy. > > > Bugs: RANGER-3511 > https://issues.apache.org/jira/browse/RANGER-3511 > > > Repository: ranger > > > Description > --- > > This patch will re-calculate and update policy resource_signature for all > disabled Ranger Policies. > > > Diffs > - > > security-admin/db/mysql/optimized/current/ranger_core_db_mysql.sql > 9e2892a1c > security-admin/db/oracle/optimized/current/ranger_core_db_oracle.sql > 65f9ad2f6 > security-admin/db/postgres/optimized/current/ranger_core_db_postgres.sql > a5bcf488b > > security-admin/db/sqlanywhere/optimized/current/ranger_core_db_sqlanywhere.sql > a48f2348c > security-admin/db/sqlserver/optimized/current/ranger_core_db_sqlserver.sql > 5cbe6d5a7 > security-admin/src/main/java/org/apache/ranger/db/XXPolicyDao.java > 41ca8b2a6 > > security-admin/src/main/java/org/apache/ranger/patch/PatchPreSql_058_ForUpdateToUniqueResoureceSignature_J10053.java > PRE-CREATION > security-admin/src/main/resources/META-INF/jpa_named_queries.xml 85cadbbd5 > > > Diff: https://reviews.apache.org/r/73707/diff/5/ > > > Testing > --- > > Tested for all the disabled ranger policies. > > > Thanks, > > Dineshkumar Yadav > >
[jira] [Updated] (RANGER-3468) When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox Logout page
[ https://issues.apache.org/jira/browse/RANGER-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Polavarapu updated RANGER-3468: --- Attachment: 0001-RANGER-3468-Fixed-an-issue-where-inactivity-timeout-.patch > When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox > Logout page > > > Key: RANGER-3468 > URL: https://issues.apache.org/jira/browse/RANGER-3468 > Project: Ranger > Issue Type: Bug > Components: Ranger >Reporter: Sailaja Polavarapu >Assignee: Sailaja Polavarapu >Priority: Major > Attachments: > 0001-RANGER-3468-Fixed-an-issue-where-inactivity-timeout-.patch > > > When multiple Ranger tabs are open and session timeout happens some tabs are > not getting redirected to Knox logout page but we see new session has been > created > Steps > 1.Open 3 tabs of Ranger > 2.Wait for idle session timeout > 3.When checked all the tabs some tabs are not redirected to knox logout page. -- This message was sent by Atlassian Jira (v8.20.1#820001)
Review Request 73713: RANGER-3468: When multiple Ranger tabs are opened, Some tabs are not redirecting to Knox Logout page
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/73713/ --- Review request for ranger, Kishor Gollapalliwar, Abhay Kulkarni, Mehul Parikh, Ramesh Mani, and Velmurugan Periasamy. Bugs: RANGER-3468 https://issues.apache.org/jira/browse/RANGER-3468 Repository: ranger Description --- Fixed an issue where inactivity timeout request is not handled properly when the requested sessionid is invalid. Also added Content-Type header with value as application/x-http-headers in the logout redirect response Diffs - security-admin/src/main/java/org/apache/ranger/security/web/filter/RangerKRBAuthenticationFilter.java c0ff06ea9 Diff: https://reviews.apache.org/r/73713/diff/1/ Testing --- Patched and verified few tests for regressions. Thanks, Sailaja Polavarapu
[jira] [Commented] (RANGER-3513) locks getLatestOrCached(RangerServicePoliciesCache.java:198)
[
https://issues.apache.org/jira/browse/RANGER-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444394#comment-17444394
]
ruiliang commented on RANGER-3513:
--
As soon as the program comes in here, it's going to be like this, we have a lot
of data, it's going to last a long time, it's going to be a big problem for
us.Is there any way to fix it?
{code:java}
if(! hasProcessedAll()) {
LOG.warn("getAllPolicies(): perhaps one or more policies got updated during
retrieval. Falling back to secondary method");
ret = getAllPoliciesBySecondary();
} {code}
> locks getLatestOrCached(RangerServicePoliciesCache.java:198)
>
>
> Key: RANGER-3513
> URL: https://issues.apache.org/jira/browse/RANGER-3513
> Project: Ranger
> Issue Type: Bug
> Components: admin
>Affects Versions: 1.2.0
>Reporter: ruiliang
>Priority: Major
> Attachments: ranger_1_1115.jstack
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> add new policy ，All Ranger requests are 10s+.Print jstatck: some threads are
> locked.Does the external request lastKnownVersion not change?
> * top 61905 Threads cpu use 99.3%
> {code:java}
> KiB Swap: 0 total, 0 free, 0 used. 57020896 avail Mem
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>
>
>
> 61905 root 20 0 20.748g 4.689g 23760 R 99.3 7.6 4:32.52 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 3500 root 20 0 20.748g 4.689g 23760 S 8.3 7.6 0:00.31 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 45584 root 20 0 20.748g 4.689g 23760 S 6.3 7.6 0:02.76 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 62387 root 20 0 20.748g 4.689g 23760 S 6.3 7.6 0:02.32 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 7230 root 20 0 20.748g 4.689g 23760 S 5.3 7.6 0:00.42 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 3412 root 20 0 20.748g 4.689g 23760 S 5.0 7.6 0:00.53 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 45616 root 20 0 20.748g 4.689g 23760 S 4.3 7.6 0:03.50 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 3498 root 20 0 20.748g 4.689g 23760 S 4.3 7.6 0:00.92 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 7238 root 20 0 20.748g 4.689g 23760 S 4.3 7.6 0:00.28 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 7096 root 20 0 20.748g 4.689g 23760 S 1.3 7.6 0:00.05 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 52641 root 20 0 20.748g 4.689g 23760 S 0.3 7.6 1:33.20 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 7229 root 20 0 20.748g 4.689g 23760 S 0.3 7.6 0:00.30 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 52032 root 20 0 20.748g 4.689g 23760 S 0.0 7.6 0:00.00 java
> -Dproc_rangeradmin -XX:MetaspaceSize=512M -Xmx4024m -Xms4024m
> -Duser.timezone=UTC -Dzookeeper.sasl.client.username=zookeeper -Duser=root
> -Dhostname=fs-hiido-range+
> 52034 root 20 0 20.748g 4.689g 23760 S 0.0 7.6 0:00.84 java
> -Dproc_rangeradmin
