[jira] [Comment Edited] (AMBARI-19621) Mpack Based Operations Model - Mpack v2
[ https://issues.apache.org/jira/browse/AMBARI-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460539#comment-16460539 ] Keta Patel edited comment on AMBARI-19621 at 5/2/18 5:38 AM: - Hello [~jluniya], We are developing a custom service and would like to understand how the new mpacks (v2) must be built from Ambari 3.0 onwards.Is there a spec doc available for us to understand this? Will the older mpacks (v1) still be supported in Ambari 3.0? Thank you, Keta Patel was (Author: patel...@us.ibm.com): Hello Jayush, We are developing a custom service and would like to understand how the new mpacks (v2) must be built from Ambari 3.0 onwards.Is there a spec doc available for us to understand this? Will the older mpacks (v1) still be supported in Ambari 3.0? Thank you, Keta Patel > Mpack Based Operations Model - Mpack v2 > --- > > Key: AMBARI-19621 > URL: https://issues.apache.org/jira/browse/AMBARI-19621 > Project: Ambari > Issue Type: Epic > Components: ambari-agent, ambari-server, ambari-web >Affects Versions: 2.5.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-19621) Mpack Based Operations Model - Mpack v2
[ https://issues.apache.org/jira/browse/AMBARI-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460539#comment-16460539 ] Keta Patel commented on AMBARI-19621: - Hello Jayush, We are developing a custom service and would like to understand how the new mpacks (v2) must be built from Ambari 3.0 onwards.Is there a spec doc available for us to understand this? Will the older mpacks (v1) still be supported in Ambari 3.0? Thank you, Keta Patel > Mpack Based Operations Model - Mpack v2 > --- > > Key: AMBARI-19621 > URL: https://issues.apache.org/jira/browse/AMBARI-19621 > Project: Ambari > Issue Type: Epic > Components: ambari-agent, ambari-server, ambari-web >Affects Versions: 2.5.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMBARI-21145) allow wildcard for log directory folder in the path component of Logfeeder input
[ https://issues.apache.org/jira/browse/AMBARI-21145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1604#comment-1604 ] Keta Patel commented on AMBARI-21145: - Hello Oliver, While processing the *_"path"_* of _*"input"*_ parameter from a -logsearch-conf.xml file, is it possible to select multiple files matching the regex provided in the "path" or just the first match from the many options matching the regex gets selected for Logfeeder input? In my analysis only the 1st match from the "path" regex gets picked up. There is existing logic to check for wildcards, but this code is executed only for those files in the "notReadyList" of the InputManager class. Files in this list are put when no matching file is found for the "path" regex during config loading stage. However, for a regex that matches with at least one of the files in the location, the 1st match gets added to the "inputList" of InputManager class. Please share your input on my understanding of how this logic works. Thank you, Keta > allow wildcard for log directory folder in the path component of Logfeeder > input > > > Key: AMBARI-21145 > URL: https://issues.apache.org/jira/browse/AMBARI-21145 > Project: Ambari > Issue Type: Improvement > Components: logsearch >Affects Versions: 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel >Priority: Minor > > The wildcard processing in Logfeeder is carried out only for the last file > component in the log path. For a few services, where there are multiple log > folders and log files from each of the folders is desired to be parsed in > Logsearch UI, the lack of a wildcard processing for the previous portions > becomes an issue. Hence, introducing wildcard processing for the log > directory part of the "path" in the Logfeeder's input for the service will > help resolve this issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (AMBARI-21145) allow wildcard for log directory folder in the path component of Logfeeder input
Keta Patel created AMBARI-21145: --- Summary: allow wildcard for log directory folder in the path component of Logfeeder input Key: AMBARI-21145 URL: https://issues.apache.org/jira/browse/AMBARI-21145 Project: Ambari Issue Type: Improvement Components: logsearch Affects Versions: 2.5.0 Reporter: Keta Patel Assignee: Keta Patel Priority: Minor The wildcard processing in Logfeeder is carried out only for the last file component in the log path. For a few services, where there are multiple log folders and log files from each of the folders is desired to be parsed in Logsearch UI, the lack of a wildcard processing for the previous portions becomes an issue. Hence, introducing wildcard processing for the log directory part of the "path" in the Logfeeder's input for the service will help resolve this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026628#comment-16026628 ] Keta Patel commented on AMBARI-20769: - Hello Robert, Please find attached the screenshots of the code snippets where the Cluster Operator user is not allowed to perform the recommission operation (cluster_operator_1_recommission.png, cluster_operator_2_recommission.png). image-1 shows the place where the uri is matched for All Cluster Apis and then a further check is made for the roles of Cluster User and Cluster Administrator. Image-2 shows where the error is thrown for this. The RequestResourceProvider.java does get called before this, but there is no check made for roles there. Kindly please help me investigate this issue further. > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png, cluster_operator_1_recommission.png, > cluster_operator_2_recommission.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Attachment: cluster_operator_2_recommission.png cluster_operator_1_recommission.png > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png, cluster_operator_1_recommission.png, > cluster_operator_2_recommission.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Attachment: (was: cluster_operator_1_recommission.png) > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Attachment: (was: cluster_operator_2_recommission.png) > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Attachment: cluster_operator_2_recommission.png cluster_operator_1_recommission.png > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16001078#comment-16001078 ] Keta Patel commented on AMBARI-20769: - Hello Robert, I kindly request you to please share your input on this issue of Recommission of nodes. I have the following question about the authorization granted to CLUSTER.ADMINISTRATOR and CLUSTER.USER in the class AmbariAuthorizationFilter (ambari-server/src/main/java/org/apache/ambari/server/security/authorization/AmbariAuthorizationFilter.java). The URI used in the recommission request is "/api/v1/clusters//requests". Please refer to the image attached as "AMBARI-20769-codeSnippet.png". The 2 red boxes show why the Ambari Admins and users with Cluster Administrator roles are authorized to Recommission nodes. For all the other roles, the response returned is "403. You do not have permissions to access this resource.". Please refer to the screenshot of the code attached as "AMBARI-20769-codeSnippet-for-error.png". As per the services that various roles are authorized to perform, CLUSTER.OPERATOR, SERVICE.ADMINISTRATOR and SERVICE.OPERATOR are must also be allowed to perform recommission. 1. Then why does the code allow only CLUSTER.ADMINISTRATOR and CLUSTER.USER roles? Why is CLUSTER.OPERATOR not included in the list to access API_CLUSTERS_ALL_PATTERN uri? 2. How should we handle the accessibility for SERVICE.ADMINISTRATOR and SERVICE.OPERATOR roles? Will it be correct to check for these roles under the API_CLUSTERS_ALL_PATTERN uri umbrella? Kindly please share your thoughts on my investigation. Thank you, Keta > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Attachment: AMBARI-20769-codeSnippet-for-error.png > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet-for-error.png, > AMBARI-20769-codeSnippet.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Attachment: AMBARI-20769-codeSnippet.png > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-20769-codeSnippet.png > > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20839) When HTTPS is enabled, Log search authenication does not work for non log search admin users
[ https://issues.apache.org/jira/browse/AMBARI-20839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15996154#comment-15996154 ] Keta Patel commented on AMBARI-20839: - Hello Oliver, yes, I had added the ambari-server certificate into the Logsearch truststore and the Logsearch certificate into the ambari-server truststore, I updated the Logsearch UI protocol to "https" also. With this setting, Hosts->Logs tab in the Ambari UI fails to load. Also the Logsearch UI fails to load. But on changing the Logsearch UI protocol back to "http", Hosts->Logs tab loads correctly. Also the Logsearch UI loads, but only the Logsearch admin user is able to login, all the other ambari users having access to the Logsearch UI fail to login. > When HTTPS is enabled, Log search authenication does not work for non log > search admin users > -- > > Key: AMBARI-20839 > URL: https://issues.apache.org/jira/browse/AMBARI-20839 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: 2.4.0 >Reporter: Tuong Truong >Assignee: Keta Patel > > When HTTPS is enabled, only the configured Log Search admin user can log > into Log Search UI. All others users are not able to log into Log Search UI > regardless of how Log Search is configured with respect to role permission.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20839) When HTTPS is enabled, Log search authenication does not work for non log search admin users
[ https://issues.apache.org/jira/browse/AMBARI-20839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993157#comment-15993157 ] Keta Patel commented on AMBARI-20839: - Hello Oliver, I would like to have your input on this defect. I have used the tried and tested steps while configuring HTTPS for ambari-server: 1. enable HTTPS using **ambari-server setup-security** option#1 2. Setup TrustStore for ambari-server using option#4 3. Import the self-signed certificate using option#5 When using HTTPS enabled ambari-server with Logsearch, which still uses HTTP protocol, I am able to see the logs in the Host->Logs tab, and the Logsearch UI succressfully loads the login page. At this point, the issue mentioned in the description of this Jira, i.e. only the Logsearch admin is able to successfully log into the Logsearch UI, can be seen. For all the other ambari users, invalid user/password error is displayed. The error happens when the LogsearchAuthenticationProvider tests the username/password using the **EXTERNAL_AUTH** method. In this case, it fails to make a successful ExternalServerClient.sendGETRequest() call. I suspect that the SSLUtil class fails to load the SSLContext because of which the subsequent calls fail to connect to the ambari-server successfully. Is it necessary to enable Logsearch SSL for this? I tried enabling SSL for Logsearch-portal, Logsearch-logfeeder, but when I update the Logsearch protocol to **https**, the Host->Logs tab won't show any logs and even the Logsearch UI fails to load. I used the following links to setup SSL for Logsearch: https://community.hortonworks.com/articles/90621/log-search-and-ssl.html https://community.hortonworks.com/articles/75476/how-to-enable-ssl-for-logsearch-and-update-logsera.html It would be helpful if you could share your view on this issue. Thank you, Keta Patel > When HTTPS is enabled, Log search authenication does not work for non log > search admin users > -- > > Key: AMBARI-20839 > URL: https://issues.apache.org/jira/browse/AMBARI-20839 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: 2.4.0 >Reporter: Tuong Truong >Assignee: Keta Patel > > When HTTPS is enabled, only the configured Log Search admin user can log > into Log Search UI. All others users are not able to log into Log Search UI > regardless of how Log Search is configured with respect to role permission.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Description: A local Ambari user with no cluster roles assigned to it can successfully log into the Logsearch UI. Logsearch service exercises restriction on who can access its UI using a property "logsearch.roles.allowed". This property is a comma-separated list of roles to be allowed access to Logsearch UI. This defect deals with the following issue: 1. If Logsearch service requires that only certain roles be allowed to access its UI, then a local Ambari user with no roles must not be allowed to access the UI. DESIRED BEHAVIOR: = 1. A local user with no role assigned to it, must not be able to access Logsearch UI. Note: The description has been updated by removing the aspect of correcting the behavior for Ambari Administrator role for the Logsearch UI. was: A local Ambari user with no cluster roles assigned to it can successfully log into the Logsearch UI. Logsearch service exercises restriction on who can access its UI using a property "logsearch.roles.allowed". This property is a comma-separated list of roles to be allowed access to Logsearch UI. This defect deals with the following 2 issues: 1. If Logsearch service requires that only certain roles be allowed to access its UI, then a local Ambari user with no roles must not be allowed to access the UI. 2. If some user with privilege to edit the config properties, updates "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from its list, then the Ambari Admins will not be able to access the Logsearch UI. This violates the Ambari Administrator privilege which must be able to access all frames of Ambari UI as well as perform all UI operations. DESIRED BEHAVIOR: = 1. A local user with no role assigned to it, must not be able to access Logsearch UI. 2. Ambari Administrators must be always be allowed to access the Logsearch UI. No user is allowed to revoke this access right of Ambari Administrator for the Logsearch UI. > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, > AMBARI-20768_branch-2.5.0.patch, AMBARI-20768_branch-2.5_updated.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following issue: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > Note: The description has been updated by removing the aspect of correcting > the behavior for Ambari Administrator role for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Status: Patch Available (was: Open) > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, > AMBARI-20768_branch-2.5.0.patch, AMBARI-20768_branch-2.5_updated.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976108#comment-15976108 ] Keta Patel commented on AMBARI-20768: - Have attached updated patch "AMBARI-20768_branch-2.5_updated.patch" after applying changes as mentioned in the ReviewBoard comments. This patch is created for "branch-2.5.0", so the Hadoop QA may fail to apply it on trunk. > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, > AMBARI-20768_branch-2.5.0.patch, AMBARI-20768_branch-2.5_updated.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Attachment: AMBARI-20768_branch-2.5_updated.patch > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, > AMBARI-20768_branch-2.5.0.patch, AMBARI-20768_branch-2.5_updated.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Status: Open (was: Patch Available) > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, AMBARI-20768_branch-2.5.0.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972140#comment-15972140 ] Keta Patel edited comment on AMBARI-20768 at 4/18/17 5:33 AM: -- The patch **AMBARI-20768_branch-2.5.0.patch** contains the fix for this issue. The fix involves correction in 2 places in the LogsearchExternalServerAuthenticationProvider class. 1. In order to prevent a local user with no cluster roles assigned to it from logging into Logsearch UI, we return **false**. 2. We implicitly check whether the user is an Ambari Administrator or not, thus removing the requirement of having "AMBARI.ADMINISTRATOR" role in the "logsearch.roles.allowed" property on the UI. Now, even if some user removes the "AMBARI.ADMINISTRATOR" property from the UI, it will not affect the Ambari admin's accessibility to the Logsearch UI. Ambari Admins will always be allowed to login. The results of the logsearch tests are shown in the screenshot "all_tests_successful.png" screenshot after applying the patch. was (Author: patel...@us.ibm.com): The patch **AMBARI-20768.patch** contains the fix for this issue. The fix involves correction in 2 places in the LogsearchExternalServerAuthenticationProvider class. 1. In order to prevent a local user with no cluster roles assigned to it from logging into Logsearch UI, we return **false**. 2. We implicitly check whether the user is an Ambari Administrator or not, thus removing the requirement of having "AMBARI.ADMINISTRATOR" role in the "logsearch.roles.allowed" property on the UI. Now, even if some user removes the "AMBARI.ADMINISTRATOR" property from the UI, it will not affect the Ambari admin's accessibility to the Logsearch UI. Ambari Admins will always be allowed to login. The results of the logsearch tests are shown in the screenshot "all_tests_successful.png" screenshot after applying the patch. > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, AMBARI-20768_branch-2.5.0.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Attachment: AMBARI-20768_branch-2.5.0.patch > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, AMBARI-20768_branch-2.5.0.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Attachment: (was: AMBARI-20768.patch) > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Status: Patch Available (was: In Progress) The patch is created for branch-2.5.0. > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, AMBARI-20768.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972140#comment-15972140 ] Keta Patel commented on AMBARI-20768: - The patch **AMBARI-20768.patch** contains the fix for this issue. The fix involves correction in 2 places in the LogsearchExternalServerAuthenticationProvider class. 1. In order to prevent a local user with no cluster roles assigned to it from logging into Logsearch UI, we return **false**. 2. We implicitly check whether the user is an Ambari Administrator or not, thus removing the requirement of having "AMBARI.ADMINISTRATOR" role in the "logsearch.roles.allowed" property on the UI. Now, even if some user removes the "AMBARI.ADMINISTRATOR" property from the UI, it will not affect the Ambari admin's accessibility to the Logsearch UI. Ambari Admins will always be allowed to login. The results of the logsearch tests are shown in the screenshot "all_tests_successful.png" screenshot after applying the patch. > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, AMBARI-20768.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Attachment: AMBARI-20768.patch > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png, AMBARI-20768.patch > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Attachment: all_tests_successful.png > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: all_tests_successful.png > > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Description: A local Ambari user with no cluster roles assigned to it can successfully log into the Logsearch UI. Logsearch service exercises restriction on who can access its UI using a property "logsearch.roles.allowed". This property is a comma-separated list of roles to be allowed access to Logsearch UI. This defect deals with the following 2 issues: 1. If Logsearch service requires that only certain roles be allowed to access its UI, then a local Ambari user with no roles must not be allowed to access the UI. 2. If some user with privilege to edit the config properties, updates "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from its list, then the Ambari Admins will not be able to access the Logsearch UI. This violates the Ambari Administrator privilege which must be able to access all frames of Ambari UI as well as perform all UI operations. DESIRED BEHAVIOR: = 1. A local user with no role assigned to it, must not be able to access Logsearch UI. 2. Ambari Administrators must be always be allowed to access the Logsearch UI. No user is allowed to revoke this access right of Ambari Administrator for the Logsearch UI. was: Ambari admin and local Ambari user with no cluster roles assigned to it are able to successfully log into Logsearch UI. However, when the local user is assigned some cluster role, that user is not able to log into Logsearch UI. As a fix to access the Logsearch UI by the cluster roles, the property "logsearch.roles.allowed" is added under Log Search->configs->Advanced->Custom logsearch-properties. This value of this property is a comma-separated list of the cluster roles allowed to log into Logsearch UI. As a result of this, the local ambari users having the corresponding roles are now able to log into Logsearch UI, but Ambari admins show unsuccessful login. On removing the "logsearch.roles.allowed" property, all Ambari admins, local users with NO roles assigned are able to successfully log into Logsearch UI, but users with some cluster roles assigned to them are not allowed to login. The following behavior is what is required: - Ambari Admins must be able to successfully log into Logsearch UI regardless of whether the "logsearch.roles.allowed" property has been added or not. - All local users with NO roles assigned to them must NOT be able to log into the Logsearch UI. This behavior is seen after adding the "logsearch.roles.allowed" property, but not before that. Ideally, those users must not be able to log into Logsearch UI regardless of whether the "logsearch.roles.allowed" was added or not. > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > > A local Ambari user with no cluster roles assigned to it can successfully log > into the Logsearch UI. > Logsearch service exercises restriction on who can access its UI using a > property "logsearch.roles.allowed". This property is a comma-separated list > of roles to be allowed access to Logsearch UI. This defect deals with the > following 2 issues: > 1. If Logsearch service requires that only certain roles be allowed to access > its UI, then a local Ambari user with no roles must not be allowed to access > the UI. > 2. If some user with privilege to edit the config properties, updates > "logsearch.roles.allowed" by removing the "AMBARI.ADMINISTRATOR" role from > its list, then the Ambari Admins will not be able to access the Logsearch UI. > This violates the Ambari Administrator privilege which must be able to access > all frames of Ambari UI as well as perform all UI operations. > DESIRED BEHAVIOR: > = > 1. A local user with no role assigned to it, must not be able to access > Logsearch UI. > 2. Ambari Administrators must be always be allowed to access the Logsearch > UI. No user is allowed to revoke this access right of Ambari Administrator > for the Logsearch UI. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role must not be able to access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Summary: Local Ambari user with no cluster role must not be able to access Logsearch UI (was: Local Ambari user with no cluster role can access Logsearch UI) > Local Ambari user with no cluster role must not be able to access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > > Ambari admin and local Ambari user with no cluster roles assigned to it are > able to successfully log into Logsearch UI. > However, when the local user is assigned some cluster role, that user is not > able to log into Logsearch UI. > As a fix to access the Logsearch UI by the cluster roles, the property > "logsearch.roles.allowed" is added under Log > Search->configs->Advanced->Custom logsearch-properties. This value of this > property is a comma-separated list of the cluster roles allowed to log into > Logsearch UI. As a result of this, the local ambari users having the > corresponding roles are now able to log into Logsearch UI, but Ambari admins > show unsuccessful login. > On removing the "logsearch.roles.allowed" property, all Ambari admins, local > users with NO roles assigned are able to successfully log into Logsearch UI, > but users with some cluster roles assigned to them are not allowed to login. > The following behavior is what is required: > - Ambari Admins must be able to successfully log into Logsearch UI regardless > of whether the "logsearch.roles.allowed" property has been added or not. > - All local users with NO roles assigned to them must NOT be able to log into > the Logsearch UI. This behavior is seen after adding the > "logsearch.roles.allowed" property, but not before that. Ideally, those users > must not be able to log into Logsearch UI regardless of whether the > "logsearch.roles.allowed" was added or not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role can access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Affects Version/s: 2.5.0 > Local Ambari user with no cluster role can access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > > Ambari admin and local Ambari user with no cluster roles assigned to it are > able to successfully log into Logsearch UI. > However, when the local user is assigned some cluster role, that user is not > able to log into Logsearch UI. > As a fix to access the Logsearch UI by the cluster roles, the property > "logsearch.roles.allowed" is added under Log > Search->configs->Advanced->Custom logsearch-properties. This value of this > property is a comma-separated list of the cluster roles allowed to log into > Logsearch UI. As a result of this, the local ambari users having the > corresponding roles are now able to log into Logsearch UI, but Ambari admins > show unsuccessful login. > On removing the "logsearch.roles.allowed" property, all Ambari admins, local > users with NO roles assigned are able to successfully log into Logsearch UI, > but users with some cluster roles assigned to them are not allowed to login. > The following behavior is what is required: > - Ambari Admins must be able to successfully log into Logsearch UI regardless > of whether the "logsearch.roles.allowed" property has been added or not. > - All local users with NO roles assigned to them must NOT be able to log into > the Logsearch UI. This behavior is seen after adding the > "logsearch.roles.allowed" property, but not before that. Ideally, those users > must not be able to log into Logsearch UI regardless of whether the > "logsearch.roles.allowed" was added or not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20768) Local Ambari user with no cluster role can access Logsearch UI
[ https://issues.apache.org/jira/browse/AMBARI-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20768: Summary: Local Ambari user with no cluster role can access Logsearch UI (was: Local Ambari user not able to log into Logsearch UI post assigning a cluster role) > Local Ambari user with no cluster role can access Logsearch UI > -- > > Key: AMBARI-20768 > URL: https://issues.apache.org/jira/browse/AMBARI-20768 > Project: Ambari > Issue Type: Bug > Components: logsearch >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > > Ambari admin and local Ambari user with no cluster roles assigned to it are > able to successfully log into Logsearch UI. > However, when the local user is assigned some cluster role, that user is not > able to log into Logsearch UI. > As a fix to access the Logsearch UI by the cluster roles, the property > "logsearch.roles.allowed" is added under Log > Search->configs->Advanced->Custom logsearch-properties. This value of this > property is a comma-separated list of the cluster roles allowed to log into > Logsearch UI. As a result of this, the local ambari users having the > corresponding roles are now able to log into Logsearch UI, but Ambari admins > show unsuccessful login. > On removing the "logsearch.roles.allowed" property, all Ambari admins, local > users with NO roles assigned are able to successfully log into Logsearch UI, > but users with some cluster roles assigned to them are not allowed to login. > The following behavior is what is required: > - Ambari Admins must be able to successfully log into Logsearch UI regardless > of whether the "logsearch.roles.allowed" property has been added or not. > - All local users with NO roles assigned to them must NOT be able to log into > the Logsearch UI. This behavior is seen after adding the > "logsearch.roles.allowed" property, but not before that. Ideally, those users > must not be able to log into Logsearch UI regardless of whether the > "logsearch.roles.allowed" was added or not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
[ https://issues.apache.org/jira/browse/AMBARI-20769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-20769: Affects Version/s: 2.5.0 > Recommission fails for Cluster Operators, Service Adminstrators and Service > Operators > - > > Key: AMBARI-20769 > URL: https://issues.apache.org/jira/browse/AMBARI-20769 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: trunk, 2.5.0 >Reporter: Keta Patel >Assignee: Keta Patel > > Steps to reproduce: > 1. Create 4 local users assign one to each of the following roles: > - Cluster Administrator > - Cluster Operator > - Service Administrator > - Service Operator > 2. Logout and login back as one of the above created users. > 3. Decommission a node, the operation is successful with the Background > Operation pop-up showing the decommissioning operation being performed. > 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is > able to successfully perform this step. For the rest of the roles mentioned > in step-1, you will see the following behavior: > - The background operation pop-up shows up with "0 Operations" in progress. > - The background operation pop-up disappears and you see the login page > momentarily. > - The main Dashboard is seen immediately after that and the node is still in > the "Decommissioned" state. > Desired Behavior: > All the roles mentioned in step-1 must be able to successfully recommission > the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20769) Recommission fails for Cluster Operators, Service Adminstrators and Service Operators
Keta Patel created AMBARI-20769: --- Summary: Recommission fails for Cluster Operators, Service Adminstrators and Service Operators Key: AMBARI-20769 URL: https://issues.apache.org/jira/browse/AMBARI-20769 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: trunk Reporter: Keta Patel Assignee: Keta Patel Steps to reproduce: 1. Create 4 local users assign one to each of the following roles: - Cluster Administrator - Cluster Operator - Service Administrator - Service Operator 2. Logout and login back as one of the above created users. 3. Decommission a node, the operation is successful with the Background Operation pop-up showing the decommissioning operation being performed. 4. Recommission that node. Only the Ambari Admin and Cluster Administrator is able to successfully perform this step. For the rest of the roles mentioned in step-1, you will see the following behavior: - The background operation pop-up shows up with "0 Operations" in progress. - The background operation pop-up disappears and you see the login page momentarily. - The main Dashboard is seen immediately after that and the node is still in the "Decommissioned" state. Desired Behavior: All the roles mentioned in step-1 must be able to successfully recommission the nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMBARI-20768) Local Ambari user not able to log into Logsearch UI post assigning a cluster role
Keta Patel created AMBARI-20768: --- Summary: Local Ambari user not able to log into Logsearch UI post assigning a cluster role Key: AMBARI-20768 URL: https://issues.apache.org/jira/browse/AMBARI-20768 Project: Ambari Issue Type: Bug Components: logsearch Affects Versions: trunk Reporter: Keta Patel Assignee: Keta Patel Ambari admin and local Ambari user with no cluster roles assigned to it are able to successfully log into Logsearch UI. However, when the local user is assigned some cluster role, that user is not able to log into Logsearch UI. As a fix to access the Logsearch UI by the cluster roles, the property "logsearch.roles.allowed" is added under Log Search->configs->Advanced->Custom logsearch-properties. This value of this property is a comma-separated list of the cluster roles allowed to log into Logsearch UI. As a result of this, the local ambari users having the corresponding roles are now able to log into Logsearch UI, but Ambari admins show unsuccessful login. On removing the "logsearch.roles.allowed" property, all Ambari admins, local users with NO roles assigned are able to successfully log into Logsearch UI, but users with some cluster roles assigned to them are not allowed to login. The following behavior is what is required: - Ambari Admins must be able to successfully log into Logsearch UI regardless of whether the "logsearch.roles.allowed" property has been added or not. - All local users with NO roles assigned to them must NOT be able to log into the Logsearch UI. This behavior is seen after adding the "logsearch.roles.allowed" property, but not before that. Ideally, those users must not be able to log into Logsearch UI regardless of whether the "logsearch.roles.allowed" was added or not. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655746#comment-15655746
]
Keta Patel commented on AMBARI-17041:
-
Hello Alexandr,
Sorry for the late response. I have corrected the patch by removing this null
check from the condition. The corrected patch is attached under
**AMBARI-17041-branch-2.5-Nov-10.patch**.
Thank you
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5-Nov-10.patch, AMBARI-17041-branch-2.5.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk-fix-regression.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655746#comment-15655746
]
Keta Patel edited comment on AMBARI-17041 at 11/11/16 1:17 AM:
---
Hello Alexandr,
Sorry for the late response. I have corrected the patch by removing this null
check from the condition. The corrected patch is attached under
*AMBARI-17041-branch-2.5-Nov-10.patch*.
Thank you
was (Author: patel...@us.ibm.com):
Hello Alexandr,
Sorry for the late response. I have corrected the patch by removing this null
check from the condition. The corrected patch is attached under
**AMBARI-17041-branch-2.5-Nov-10.patch**.
Thank you
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5-Nov-10.patch, AMBARI-17041-branch-2.5.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk-fix-regression.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-branch-2.5-Nov-10.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5-Nov-10.patch, AMBARI-17041-branch-2.5.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk-fix-regression.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15592728#comment-15592728
]
Keta Patel commented on AMBARI-17041:
-
The latest 2 patches:
*AMBARI-17041-branch-2.5.patch* is attached to push in the changes for this
Jira into branch-2.5
*AMBARI-17041-trunk-fix-regression.patch* is attached to fix the regression
introduced by Jira AMBARI-18308 into the trunk code.
The ambari-web test results are as follows:
branch-2.5:
29536 tests complete (40 seconds)
154 tests pending
trunk:
30368 tests complete (40 seconds)
151 tests pending
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk-fix-regression.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-branch-2.5.patch
AMBARI-17041-trunk-fix-regression.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Fix For: 2.5.0
>
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-branch-2.5.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk-fix-regression.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Open (was: Patch Available) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071-Sep6.patch, AMBARI-18071.patch, > NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Patch Available (was: Open) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071-Sep6.patch, AMBARI-18071.patch, > NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: AMBARI-18071-Sep6.patch > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071-Sep6.patch, AMBARI-18071.patch, > NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: (was: AMBARI-18071-Sep6.patch) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: AMBARI-18071-Sep6.patch > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071-Sep6.patch, AMBARI-18071.patch, > NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18327) multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping of steps while installing a cluster
[ https://issues.apache.org/jira/browse/AMBARI-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18327: Status: Patch Available (was: In Progress) > multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping > of steps while installing a cluster > > > Key: AMBARI-18327 > URL: https://issues.apache.org/jira/browse/AMBARI-18327 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel >Priority: Minor > Attachments: AMBARI-18327.patch > > > While installing a cluster if the Ambari user happened to click the "Next" > button of Step-4 (Choose Services step) more than once, then it could lead to > skipping directly to step-6 or 7 or 8 depending on the number of times the > click got registered. This behavior is reproducible only when the host is > slow, which would allow enough time to click the Next button multiple times. > This issue is related to AMBARI-14574, and is a revised fix for the Step-4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18327) multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping of steps while installing a cluster
[ https://issues.apache.org/jira/browse/AMBARI-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468711#comment-15468711 ] Keta Patel commented on AMBARI-18327: - Step-4 needs revised fix > multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping > of steps while installing a cluster > > > Key: AMBARI-18327 > URL: https://issues.apache.org/jira/browse/AMBARI-18327 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel >Priority: Minor > Attachments: AMBARI-18327.patch > > > While installing a cluster if the Ambari user happened to click the "Next" > button of Step-4 (Choose Services step) more than once, then it could lead to > skipping directly to step-6 or 7 or 8 depending on the number of times the > click got registered. This behavior is reproducible only when the host is > slow, which would allow enough time to click the Next button multiple times. > This issue is related to AMBARI-14574, and is a revised fix for the Step-4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18327) multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping of steps while installing a cluster
[ https://issues.apache.org/jira/browse/AMBARI-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18327: Attachment: AMBARI-18327.patch > multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping > of steps while installing a cluster > > > Key: AMBARI-18327 > URL: https://issues.apache.org/jira/browse/AMBARI-18327 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel >Priority: Minor > Attachments: AMBARI-18327.patch > > > While installing a cluster if the Ambari user happened to click the "Next" > button of Step-4 (Choose Services step) more than once, then it could lead to > skipping directly to step-6 or 7 or 8 depending on the number of times the > click got registered. This behavior is reproducible only when the host is > slow, which would allow enough time to click the Next button multiple times. > This issue is related to AMBARI-14574, and is a revised fix for the Step-4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18327) multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping of steps while installing a cluster
Keta Patel created AMBARI-18327: --- Summary: multiple clicks on "Next" button of Step-4 (Choose Services) causes skipping of steps while installing a cluster Key: AMBARI-18327 URL: https://issues.apache.org/jira/browse/AMBARI-18327 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: trunk Reporter: Keta Patel Assignee: Keta Patel Priority: Minor While installing a cluster if the Ambari user happened to click the "Next" button of Step-4 (Choose Services step) more than once, then it could lead to skipping directly to step-6 or 7 or 8 depending on the number of times the click got registered. This behavior is reproducible only when the host is slow, which would allow enough time to click the Next button multiple times. This issue is related to AMBARI-14574, and is a revised fix for the Step-4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Open (was: Patch Available) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Patch Available (was: Open) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Patch Available (was: Open) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Open (was: Patch Available) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: AMBARI-18071.patch > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMBARI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: (was: AMABRI-18071.patch) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: AMABRI-18071.patch > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMABRI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: (was: AMABRI-18071.patch) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMABRI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: NoKeyProvider.png > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMABRI-18071.patch, NoKeyProvider.png > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Status: Patch Available (was: In Progress) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMABRI-18071.patch > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Description: When HDFS is configured with Encryption Zones, Files View to browser files will give "No KeyProvider" error. Steps to reproduce this issue: 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can follow the link https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html I have used Hadoop's KMS (installed tar manually). 2. Create a Files View instance and provide a user/group the privilege to use the instance. 3. Log into the Ambari console as the user with the Files View permission. 4. Open the Files View instance. 5. Go to the folder which is configured as an encrypted zone. 6. Try to open an existing file in this folder. 7. This throws an error - java.io.IOException: No KeyProvider is configured, cannot access an encrypted file. 8. When trying through the shell, opening this file works. This happens because Files View doesn't have enough configuration set to browse secured zone. Files view doesn't even provide an option to add these configurations.This is why we see errors "No KeyProvider is configured, cannot access an encrypted file", to work around this, you could download client configuration from HDFS service tab, and copy the core-site.xml and hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. After this, the user is able to open the file in the encrypted zone. was: When HDFS is configured with Encryption Zones, Files View to browser files will give "No KeyProvider" error. Steps to reproduce this issue: 1. Configure an encrypted zone in HDFS (Transparent Data Encryption) following the link https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html 2. Create a Files View instance and provide a user/group the privilege to use the instance. 3. Log into the Ambari console as the user with the Files View permission. 4. Open the Files View instance. 5. Go to the folder which is configured as an encrypted zone. 6. Try to open an existing file in this folder. 7. This throws an error - java.io.IOException: No KeyProvider is configured, cannot access an encrypted file. 8. When trying through the shell, opening this file works. This happens because Files View doesn't have enough configuration set to browse secured zone. Files view doesn't even provide an option to add these configurations.This is why we see errors "No KeyProvider is configured, cannot access an encrypted file", to work around this, you could download client configuration from HDFS service tab, and copy the core-site.xml and hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. After this, the user is able to open the file in the encrypted zone. > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMABRI-18071.patch > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption). You can > follow the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > I have used Hadoop's KMS (installed tar manually). > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (
[jira] [Updated] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keta Patel updated AMBARI-18071: Attachment: AMABRI-18071.patch > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > Attachments: AMABRI-18071.patch > > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption) > following the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
[ https://issues.apache.org/jira/browse/AMBARI-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453691#comment-15453691 ] Keta Patel commented on AMBARI-18071: - CAUSE: The error of "No KeyProvider is configured" is seen only for those cases when the HDFS uses DistributedFileSystem for its communication. When HDFS uses WebHDFSFileSystem for communication, this error is not seen and the Ambari View instance is able to open the files in the encrypted zones. Why Ambari Views use either Distributed or WebHDFS file systems is explained below: Ambari views can be created using one of the 3 modes of configuration: 1. Local cluster 2. Remote cluster 3. Custom configuration (no cluster is associated here). The HDFS works through abstraction. For Ambari Views, the actual file system used during execution depends on whether the view instance was created using a Local/Remote cluster or using Custom configuration. For instances created using Local/Remote cluster, HDFS uses Distributed File System and for instances created using Custom configuration, HDFS uses WebHDFSFileSystem. WebHDFSFileSystem is an integrated part of the HDFS ecosystem. It is aware of all the HDFS configuration. For this reason, when a KMS is configured in HDFS, WebHDFSFileSystem is aware of the KeyProvider and no special config mapping is needed. Thus, even the view instance created using Custom configuration doesn't need any special configuration and can talk to the Encryption Zones successfully. However, for view instances created using Local/Remote cluster configuration, HDFS uses the Distributed FileSystem. This Distributed FileSystem works as an HDFS client and hence, is not fully aware of all the HDFS configuration. We need to explicitly provide HDFS properties like "dfs.encryption.key.provider.uri" to these ambari view instances to provide details of the KeyProvider. The proposed fix helps in providing this property value to the view as follows. FIX: The proposed fix (attached as "AMBARI-18071.patch") checks if the current view instance configuration has any cluster associated in its context. If there is an associated cluster then the instance has a Local/Remote cluster configuration and needs to be provided with the HDFS KeyProvider information. Otherwise, the WebHDFSFileSystem will take care of the KeyProvider if KMS is configured. To provide the property information, the parseProperties() in ConfigurationBuilder.java looked best as we also set the defaultFS property here. If a cluster is associated with the context, and if the property "dfs.encryption.key.provider.uri" is not null, then this property is set in the Configuration object and thus made available to Distributed file system of HDFS. The Ambari VIew instance works successfully with both Local and Remote configurations. **One more point to note in the configuration aspect is the addition of proxyuser to the kms-site.xml for the ambari-server daemon. Without this proxyuser even the custom configuration will not work. (I had installed hadoop's KMS on the ambari-server manually) > Ambari Files View needs to have ability to load security configurations > --- > > Key: AMBARI-18071 > URL: https://issues.apache.org/jira/browse/AMBARI-18071 > Project: Ambari > Issue Type: Improvement > Components: contrib >Affects Versions: trunk >Reporter: Keta Patel >Assignee: Keta Patel > > When HDFS is configured with Encryption Zones, Files View to browser files > will give "No KeyProvider" error. > Steps to reproduce this issue: > 1. Configure an encrypted zone in HDFS (Transparent Data Encryption) > following the link > https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html > 2. Create a Files View instance and provide a user/group the privilege to use > the instance. > 3. Log into the Ambari console as the user with the Files View permission. > 4. Open the Files View instance. > 5. Go to the folder which is configured as an encrypted zone. > 6. Try to open an existing file in this folder. > 7. This throws an error - java.io.IOException: No KeyProvider is configured, > cannot access an encrypted file. > 8. When trying through the shell, opening this file works. > This happens because Files View doesn't have enough configuration set to > browse secured zone. Files view doesn't even provide an option to add these > configurations.This is why we see errors "No KeyProvider is configured, > cannot access an encrypted file", to work around this, you could download > client configuration from HDFS service tab, and copy the core-site.xml and > hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. > After this, the u
[jira] [Resolved] (AMBARI-17102) Pig view fails when execute/explain/syntax check in kerberos environment
[
https://issues.apache.org/jira/browse/AMBARI-17102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel resolved AMBARI-17102.
-
Resolution: Information Provided
> Pig view fails when execute/explain/syntax check in kerberos environment
>
>
> Key: AMBARI-17102
> URL: https://issues.apache.org/jira/browse/AMBARI-17102
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views, contrib
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
>
> Steps to reproduce the issue:
> 1. Install a cluster containing Pig and Hive services.
> 2. Create a Pig View Instance following the steps from
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/bk_ambari_views_guide-20150721.pdf
> 3. Go to the Pig View instance and create a new script with some content and
> save it. I have used the following content in my script:
> A = load '/tmp/passwd' using PigStorage(':');
> 4. Kerberize the Cluster from Admin -> Kerberos page
> 5. Kerberize the ambari-server following the link
> https://docs.hortonworks.com/HDPDocuments/Ambari-2.1.2.1/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html
> 6. Make sure to update the Pig View configuration with the correct Settings
> for "WebHDFS Authentication" and "WebHCat Username". Also ensure that the
> "Cluster Configuration" is "Custom" with the correct values set for "WebHDFS
> FileSystem URI*", "WebHCat Hostname" and "WebHCat Port".
> 7. Go to the Pig View instance and open the script created earlier. Click the
> "Execute" button to run the script.
> 8. The following error shows up:
> java.lang.IllegalArgumentException: Path segment is null
> java.lang.IllegalArgumentException: Path segment is null
> at
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:547)
> at
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:542)
> at com.sun.jersey.api.uri.UriBuilderImpl.path(UriBuilderImpl.java:267)
> at com.sun.jersey.api.client.WebResource.path(WebResource.java:390)
> at
> org.apache.ambari.view.pig.templeton.client.TempletonApi.checkJob(TempletonApi.java:128)
> at
> org.apache.ambari.view.pig.resources.jobs.JobResourceManager.retrieveJobStatus(JobResourceManager.java:245)
> at
> org.apache.ambari.view.pig.resources.jobs.JobService.getJob(JobService.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17102) Pig view fails when execute/explain/syntax check in kerberos environment
[
https://issues.apache.org/jira/browse/AMBARI-17102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415621#comment-15415621
]
Keta Patel commented on AMBARI-17102:
-
The configuration for Pig View in Kerberized environment is documented in the
following blog:
https://developer.ibm.com/hadoop/2016/08/08/ambari-pig-view-kerberos-enabled-clusters/
No changes in the code was required for the view to get working, only the
configuration had to be performed correctly.
> Pig view fails when execute/explain/syntax check in kerberos environment
>
>
> Key: AMBARI-17102
> URL: https://issues.apache.org/jira/browse/AMBARI-17102
> Project: Ambari
> Issue Type: Bug
> Components: ambari-views, contrib
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
>
> Steps to reproduce the issue:
> 1. Install a cluster containing Pig and Hive services.
> 2. Create a Pig View Instance following the steps from
> http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.0.0/bk_ambari_views_guide/bk_ambari_views_guide-20150721.pdf
> 3. Go to the Pig View instance and create a new script with some content and
> save it. I have used the following content in my script:
> A = load '/tmp/passwd' using PigStorage(':');
> 4. Kerberize the Cluster from Admin -> Kerberos page
> 5. Kerberize the ambari-server following the link
> https://docs.hortonworks.com/HDPDocuments/Ambari-2.1.2.1/bk_Ambari_Security_Guide/content/_optional_set_up_kerberos_for_ambari_server.html
> 6. Make sure to update the Pig View configuration with the correct Settings
> for "WebHDFS Authentication" and "WebHCat Username". Also ensure that the
> "Cluster Configuration" is "Custom" with the correct values set for "WebHDFS
> FileSystem URI*", "WebHCat Hostname" and "WebHCat Port".
> 7. Go to the Pig View instance and open the script created earlier. Click the
> "Execute" button to run the script.
> 8. The following error shows up:
> java.lang.IllegalArgumentException: Path segment is null
> java.lang.IllegalArgumentException: Path segment is null
> at
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:547)
> at
> com.sun.jersey.api.uri.UriBuilderImpl.appendPath(UriBuilderImpl.java:542)
> at com.sun.jersey.api.uri.UriBuilderImpl.path(UriBuilderImpl.java:267)
> at com.sun.jersey.api.client.WebResource.path(WebResource.java:390)
> at
> org.apache.ambari.view.pig.templeton.client.TempletonApi.checkJob(TempletonApi.java:128)
> at
> org.apache.ambari.view.pig.resources.jobs.JobResourceManager.retrieveJobStatus(JobResourceManager.java:245)
> at
> org.apache.ambari.view.pig.resources.jobs.JobService.getJob(JobService.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18071) Ambari Files View needs to have ability to load security configurations
Keta Patel created AMBARI-18071: --- Summary: Ambari Files View needs to have ability to load security configurations Key: AMBARI-18071 URL: https://issues.apache.org/jira/browse/AMBARI-18071 Project: Ambari Issue Type: Improvement Components: contrib Affects Versions: trunk Reporter: Keta Patel Assignee: Keta Patel When HDFS is configured with Encryption Zones, Files View to browser files will give "No KeyProvider" error. Steps to reproduce this issue: 1. Configure an encrypted zone in HDFS (Transparent Data Encryption) following the link https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.0/bk_hdfs_admin_tools/content/ch_configuring_hdfs_encryption.html 2. Create a Files View instance and provide a user/group the privilege to use the instance. 3. Log into the Ambari console as the user with the Files View permission. 4. Open the Files View instance. 5. Go to the folder which is configured as an encrypted zone. 6. Try to open an existing file in this folder. 7. This throws an error - java.io.IOException: No KeyProvider is configured, cannot access an encrypted file. 8. When trying through the shell, opening this file works. This happens because Files View doesn't have enough configuration set to browse secured zone. Files view doesn't even provide an option to add these configurations.This is why we see errors "No KeyProvider is configured, cannot access an encrypted file", to work around this, you could download client configuration from HDFS service tab, and copy the core-site.xml and hdfs-site.xml files to /etc/ambari-server/conf, then restart ambari-server. After this, the user is able to open the file in the encrypted zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15390185#comment-15390185
]
Keta Patel commented on AMBARI-17041:
-
Updated *AMBARI-17041-July22.patch* contains the corrections regarding variable
'FINAL' as per Review Board suggestions.
The ambari-web test results with the patch are as follows:
29343 tests complete (58 seconds)
154 tests pending
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Open (was: Patch Available)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-July22.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-July22.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Open (was: Patch Available)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: ambari_web_failed_to_execute_test.png
AMBARI-17041-July21-ES6.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-July21-updated.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-July21-ES6.patch,
> AMBARI-17041-July21-updated.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff, ambari_web_failed_to_execute_test.png,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388562#comment-15388562
]
Keta Patel commented on AMBARI-17041:
-
The updated patch **"AMBARI-17041-July21-updated.patch"** has been updated as
per the Review Board suggestions. I have slightly modified the following code
suggested to optimize the earlier code:
var attributes = [];
['FINAL', 'PASSWORD', 'USER', 'GROUP', 'TEXT', 'ADDITIONAL_USER_PROPERTY',
'NOT_MANAGED_HDFS_PATH', 'VALUE_FROM_PROPERTY_FILE'].forEach(function
(propertyName) {
attributes.push({
[propertyName] : Em.get(configJSON, 'properties_attributes.'+propertyName)
|| {}
});
});
The square brackets for [propertyName] while pushing the JSON object in
"attributes" is supported in EMCAScript 6 standard. When I use this syntax, the
build is successfully deployed and the UI behaves as intended. However, the
ambari-web tests fail throwing a Syntax Error (attachment
"ambari_web_failed_to_execute_test"). Looks like the test framework is not
supporting ECMAScript 6 standard. On avoiding the usage of square brackets for
this statement, as seen in the patch "AMBARI-17041-July21-updated.patch", the
ambari-web tests run successfully without any Syntax error.
The ambari-web test results for "AMBARI-17041-July21-updated.patch" is as
follows:
29343 tests complete (55 seconds)
154 tests pending
For reference, "AMBARI-17041-July21-ES6.patch" contains the ECMAScript 6
supported syntax.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386627#comment-15386627
]
Keta Patel commented on AMBARI-17041:
-
Attached updated patch "AMBARI-17041-July20.patch" with optimization in
config.js as suggested on Review Board.
The ambari-web tests after applying the patch:
29292 tests complete (42 seconds)
154 tests pending
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Open (was: Patch Available)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-July20.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-July20.patch, AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379968#comment-15379968
]
Keta Patel commented on AMBARI-17041:
-
Latest patch "AMBARI-17041-July15.patch"
Updated the patch to fix the failing tests.
Also, changed the reference of "password" to use a static string as suggested
on the Review Board.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Open (was: Patch Available)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-July15.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch, AMBARI-17041-July15.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-July14.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Open (was: Patch Available)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-July14.patch,
> AMBARI-17041-trunk-July08.patch, AMBARI-17041-trunk-Jun29.patch,
> AMBARI-17041-trunk.patch, add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378540#comment-15378540
]
Keta Patel commented on AMBARI-17041:
-
The following is the ambari-web test result for the latest patch
"AMBARI-17041-July14.patch"
29021 tests complete (43 seconds)
154 tests pending
This patch contains the correction in the way attributes are save in
"configs_saver.js" as per the suggestion by Matt on Review Board.
It also includes the code required to remove the masking for existing Custom
Password-type properties when a new configuration is saved. The changes are in
"AmbariManagementControllerImpl.java" for createConfiguration() and
updateCluster() functions.
The test case also includes updated test for the new property-types.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: AMBARI-17626-July08.patch
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: (was: AMBARI-17626-July08.patch)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371292#comment-15371292
]
Keta Patel commented on AMBARI-17041:
-
This particular test "ServicePropertiesTest" fails in the original trunk also,
it is not related to the changes in the patch.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368586#comment-15368586
]
Keta Patel commented on AMBARI-17626:
-
Updated the patch "AMBARI-17626-July08.patch" to include fix for the tests
failing in the last Hadoop QA run.
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Patch Available (was: Open)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Status: Open (was: Patch Available)
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17626) Blueprint registration step uses wrong format for property-attributes in Configuration
[
https://issues.apache.org/jira/browse/AMBARI-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17626:
Attachment: AMBARI-17626-July08.patch
> Blueprint registration step uses wrong format for property-attributes in
> Configuration
> --
>
> Key: AMBARI-17626
> URL: https://issues.apache.org/jira/browse/AMBARI-17626
> Project: Ambari
> Issue Type: Bug
> Components: blueprints
>Affects Versions: trunk
>Reporter: Keta Patel
>Assignee: Keta Patel
> Attachments: AMBARI-17626-July08.patch, AMBARI-17626.patch,
> cluster_with_defect_installed_from_blueprint.tiff,
> cluster_with_fix_insatlled_from_blueprint.tiff,
> original_cluster_used_to_create_blueprint.tiff
>
>
> Blueprints make use of a population strategy in the registration step to
> create JSON objects for properties and property-attributes. These properties
> and property-attributes get stored in the database (DB) in the
> "clusterconfig" table under "config_data" and "config_attributes"
> respectively. Format of these JSON objects is critical as the UI parses these
> objects assuming them to be in a certain format.
> At present property-attributes like "final" get stored in "clusterconfig"
> table in the format shown in attachment
> "original_cluster_used_to_create_blueprint.tiff".
> i.e. "final": {"attr1":"val1", "attr2":"val2"}
> When a new cluster is to be installed using a blueprint, after the blueprint
> is registered and the new cluster is installed using the registered
> blueprint, the format of "property-attributes" is as shown in attachment
> "cluster_with_defect_installed_from_blueprint.tiff".
> i.e. "attr1":{"final":"val1"}, "attr2":{"final":"val2"},
> "final":{"attr1":"val1", "attr2":"val2"}
> The population strategy is responsible for the "attr1":{"final":"val1"} and
> "attr2":{"final":"val2"}.
> The reason for "final":{"attr1":"val1", "attr2":"val2"} is because of a merge
> with the Parent Configuration during blueprint registration. This Parent
> Configuration comes from Stack using the XML files of the service properties.
> Because of this "final" attribute, the UI still shows the properties
> correctly and hence it went undetected.
> Proposed fix involves correcting the population strategy so that the
> attributes are placed in the correct format. After the fix, the new cluster
> installed via blueprint shows "property-attributes" as shown in attachment
> "cluster_with_fix_insatlled_from_blueprint.tiff"
> i.e. "final":{"attr1":"val1", "attr2":"val2"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368487#comment-15368487
]
Keta Patel commented on AMBARI-17041:
-
Uploaded new patch "AMBARI-17041-trunk-July08.patch" to include the feature of
selecting multiple values for the custom property.
For Password type custom properties, the blueprints will be contain these
custom properties with their values masked. The blueprint would have to be
updated to replace the masking with their desired values (similar to how it
happens currently for Password properties present in the XML properties files).
Installation of new cluster using this modified blueprint should show the
Password custom properties masked on the UI. This currently doesn't happen due
to a bug with blueprint registration. AMBARI-17626 tracks this issue.
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Attachment: AMBARI-17041-trunk-July08.patch
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-17041) Support password type for custom properties
[
https://issues.apache.org/jira/browse/AMBARI-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keta Patel updated AMBARI-17041:
Status: Patch Available (was: Open)
> Support password type for custom properties
> ---
>
> Key: AMBARI-17041
> URL: https://issues.apache.org/jira/browse/AMBARI-17041
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Tuong Truong
>Assignee: Keta Patel
> Attachments: AMBARI-17041-trunk-July08.patch,
> AMBARI-17041-trunk-Jun29.patch, AMBARI-17041-trunk.patch,
> add_property_pop_up.tiff,
> cluster_config_with_password_type_in_config_attributes_column.tiff,
> custom_properties_after_save.tiff, custom_property_password_type.tiff,
> custom_property_regular_type.tiff, property_type_schema.tiff,
> schema_of_clusterconfig_table.tiff
>
>
> Currently, services can define properties in the XML configuration files that
> is flagged as type password:
>
> my.special.password
>
> PASSWORD
> Password to be masked
>
> and it will be masked properly in the UI as well as blueprint.
> Custom property should also support this option so that password can be added
> as custom property and treat accordingly.
> ==
> Proposed Design for the fix:
> ==
> At present only the key-value information of the service properties is stored
> in the DB ("clusterconfig" table in the "config_data" column).
> The "config_attributes" column stores only certain attributes like "final"
> indicating the list of properties set with the Final flag = true.
> The information about the property-type (i.e PASSWORD, USER, GROUP,
> ADDITIONAL_USER_PROPERTY, VALUE_FROM_PROPERTY_FILE, NOT_MANAGED_HDFS_PATH,
> etc) is extracted from the corresponding service's property file (e.g.
> hive-site.xml, core-site.xml, webhcat-env.xml, etc). These files contain
> information of the existing properties only. Custom Properties added by
> ambari user have no provision to store their additional attributes.
> Since, for this Jira we are concerned with only attribute for
> Custom Properties, we could add an additional field called "Property Type" in
> the "Add Property" pop-up which shows up on clicking "Add Property ..." in
> the Custom property section for a service. For now, only 2 options are shown
> in the drop-down list: NONE and PASSWORD .
> A few sample test properties are created using the new "Add Property" pop-up
> as can be seen in the following attachments.
> Attachments:
> "add_property_pop_up.tiff"
> "custom_property_password_type.tiff"
> "custom_property_regular_type.tiff"
> "custom_properties_after_save.tiff"
> The information for these Custom properties is stored in the
> DB in "clusterconfig" table, "config_attributes" column.
> The schema for "clusterconfig" table can be seen in the attachment:
> "schema_of_clusterconfig_table.tiff"
> The content of the "config_attributes" column with the
> information from the new Custom properties can be seen in the attachment:
> "cluster_config_with_password_type_in_config_attributes_column.tiff"
> Note: The fix so far is performed only for new Custom properties. The
> information for existing properties is extracted from the
> corresponding property xml files for the service.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
