[
https://issues.apache.org/jira/browse/AMBARI-21760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Di Li resolved AMBARI-21760.
----------------------------
Resolution: Invalid
The issue here was due to the procedure of our specific custom service upgrade
where we removed the service definition. We do not hit the issue if we keep the
service definition in place before dumping the configurations to the Ambari db
via REST API.
> POST config via Ambari REST API doesn't get the password mask revolved back
> to the real pwd
> -------------------------------------------------------------------------------------------
>
> Key: AMBARI-21760
> URL: https://issues.apache.org/jira/browse/AMBARI-21760
> Project: Ambari
> Issue Type: Bug
> Components: ambari-sever
> Affects Versions: 2.5.2
> Reporter: Di Li
> Fix For: 2.5.2
>
>
> we are hitting a kind of weird issue in the BigSQL upgrade process. We do
> the following:
> * BigSQL backup takes a backup of the bigsql configurations using Ambari REST
> API. This gives use password fields which are masked like
> SECRET:bigsql-users-env:1:bigsql_user_password
> * BigSQL upgrade updates the bigsql configurations using the Ambari REST API
> by passing in the backup (including the masked fields)
> The end result is that the configuration stored in the DB for the password is
> SECRET:bigsql-users-env:1:bigsql_user_password. Once BIGSQL is added back to
> the cluster and we attempt to start it, that masked password value is
> included in the command json rather than the unmasked password.
> So my questions are:
> 1) Is there a way of properly updating the configurations when they contain
> these masked passwords such that the passwords in the DB will actually be
> resolved?
> 2) Is this just an Ambari defect, in that it should unmask the password when
> it includes the value in the command json? As a note, kerberization of the
> cluster actually attempts to determine the actual password value by using the
> org.apache.ambari.server.utils.SecretReference (edited)
> [4:58]
> @here Please note this is a critical defect for us. It results in several
> problems, first we update the bigsql user OS password using the masked
> password value which means we can't log in using the normal password.
> Second, we are hitting DB consistency warnings from the old BigSQL
> configurations which got disassociated from BigSQL when it was removed from
> the cluster. If we clean up these old configurations and then enable
> kerberos post migration, the kerberization will fail because it can't resolve
> the masked password reference (in other words the SecretReference class
> throws an exception about missing a config version).
> Please note the issue we hit wasn't during blueprint installation. it was
> during bigsql upgrade, here is the workflow
> 1. bigsql backup before Ambari upgrade - bigsql will use ambari rest api to
> read all bigsql configurations. the rest api returns
> "SECRET:bigsql-users-env:1:bigsql_user_password" for the password field (
> instead of the real pwd, this is expected , by design)
> 2. Ambari upgrade then EU
> 3. Bigsql upgrade- bigsql will use ambari server rest api to HTTP PUT the
> data exported in step 1 back to the database. bigsql does not modify the
> mask. in other words, "SECRET:bigsql-users-env:1:bigsql_user_passwords" got
> stored back in to the db.
> 4. bigsql perform some ambari custom command, where it expects the password
> to be resolved in the command-[task_id].json file.
> _Step 4 is where the issue happened. The mask remained in the command json
> file, instead of the real pwd._
> The weird part is that our QA hit it on migration (Ambari at 2.2/2.4.0
> level), but didn't hit it on HDP 2.5.3/BigSQL 4.2.5 to HDP 2.6.2/BigSQL 5.0.1
> upgrade.
> So I am wondering if this has anything to do with starting with a cluser with
> Ambari 2.4.x ( thus me asked you for an HDP Ambari build)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
