Bug 1557038

Summary:	ansible based deployment fails on iSCSI if the iSCSI password is contained in hostnames or target IQN
Product:	[oVirt] ovirt-ansible-collection	Reporter:	Simone Tiraboschi <stirabos>
Component:	hosted-engine-setup	Assignee:	Evgeny Slutsky <eslutsky>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nikolai Sednev <nsednev>
Severity:	medium	Docs Contact:	Tahlia Richardson <trichard>
Priority:	medium
Version:	1.0.18	CC:	bugs, hz9595s
Target Milestone:	ovirt-4.3.5	Keywords:	Triaged
Target Release:	1.0.18	Flags:	sbonazzo: ovirt-4.3? sbonazzo: planning_ack? sbonazzo: devel_ack+ sbonazzo: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-ansible-hosted-engine-setup-1.0.18	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-30 14:08:30 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1720896
Bug Blocks:

Description Simone Tiraboschi 2018-03-15 20:24:06 UTC

Description of problem:
Ansible based deployment fails on iSCSI if the iSCSI password is contained in hostname or target IQN.

This is not hosted-engine specific and it's due to:
https://github.com/ansible/ansible/issues/19278
When parameter uses no_log=True, the content of parameter obfuscate also other parameter values

So the iSCSI password can partially obscure also hostnames, URLs, IQNs and so on.

We are passing the iSCSI password in:
ovirt_hosts, ovirt_host_storage_facts, ovirt_storage_domains, uri

We had a similar bug on admin password and we solved it passing the admin password with an env variable instead of a module parameter:
https://bugzilla.redhat.com/1539734

Version-Release number of selected component (if applicable):
2.2.13

How reproducible:
100%

Steps to Reproduce:
1. deploy hosted-engine on iSCSI with an iSCSI password (retest also the admin one!) that is contained in IQN or hostname or URL.
2.
3.

Actual results:
[ INFO  ] ok: [localhost]
          The following targets have been found:
              [1]    iqn.2016-08.com.********:sds
                  TPGT: 1, portals:
                      192.168.122.1:3260

and then the login on iqn.2016-08.com.********:sds fails

Expected results:
iqn.2016-08.com.redhat:sds is properly consumed also if the password was redhat

Additional info:

Comment 1 Sandro Bonazzola 2019-01-21 08:28:44 UTC

re-targeting to 4.3.1 since this BZ has not been proposed as blocker for 4.3.0.
If you think this bug should block 4.3.0 please re-target and set blocker flag.

Comment 2 Sandro Bonazzola 2019-02-18 07:54:56 UTC

Moving to 4.3.2 not being identified as blocker for 4.3.1.

Comment 3 hz9595s 2019-02-27 04:05:27 UTC

qhen i  deploy hosted-engine with ansible,i meet iscsi iqn is ********,so led to login failed ,how can i do

Comment 4 Evgeny Slutsky 2019-05-13 12:21:00 UTC

Issue reproduced with this ENV
- hosted-engine upstream 4.3.
- centos 7.6

deployment performed with cockpit: failed on storage iSCSI deyployment with error "Retrieval of iSCSI LUNs failed."

the extra_vars file generated by cockpit contains *** in the target:
cat /var/lib/ovirt-hosted-engine-setup/cockpit/ansibleVarFileO2fIl9.var
he_fqdn: engine.es.localvms.com
he_host_name: hosted-engine.es.localvms.com
he_iscsi_username: vagrant
he_iscsi_password: vagrant
he_iscsi_target: iqn.2017-07.ovirt.com:********
he_iscsi_portal_addr: 192.168.100.103
he_iscsi_portal_port: 3260
he_filtered_tokens_vars: ADMIN_PASSWORD,APPLIANCE_PASSWORD,ISCSI_PASSWORD,ISCSI_DISCOVER_PASSWORD,ROOTPWD
he_filtered_tokens_re: BEGIN PRIVATE KEY(?P<filter>.*)END PRIVATE KEY



iscsi configuration:
  tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2017-07.ovirt.com:vagrant
  tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/vdb
  tgtadm --lld iscsi --op new --mode account --user vagrant --password vagrant
  tgtadm --lld iscsi --op bind --mode account --tid 1 --user vagrant
  tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

Comment 5 Evgeny Slutsky 2019-05-14 07:05:17 UTC

the actual obfuscation is performed by the ansible URI module: https://github.com/ansible/ansible/issues/24073
since we are using URI password in hosted-engine-setup:
https://github.com/oVirt/ovirt-ansible-hosted-engine-setup/blob/e6a69d3e2f44cbff289f1488acaa6dcd66293ce3/tasks/iscsi_discover.yml#L26

a possible workaround is not to  use a password option, use Authorization instead:
example:
- uri:
    url: "http://localhost:15672/api/parameters/shovel/{{ vhost }}"
    headers:
      Authorization: "Basic {{ (vhost_user + ':' + vhost_password) | b64encode }}"

https://github.com/ansible/ansible/issues/44635#issuecomment-415771504

Comment 6 Nikolai Sednev 2019-07-16 16:44:10 UTC

Works for me on these components:
rhvm-appliance-4.3-20190710.2.el7.x86_64
ovirt-hosted-engine-ha-2.3.3-1.el7ev.noarch
ovirt-hosted-engine-setup-2.3.11-1.el7ev.noarch
Linux 3.10.0-1061.el7.x86_64 #1 SMP Thu Jul 11 21:02:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.7 (Maipo)


[ INFO  ] changed: [localhost]
          Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs)[nfs]: iscsi
          Please specify the iSCSI portal IP address: 10.35.163.99
          Please specify the iSCSI portal port [3260]: 
          Please specify the iSCSI discover user: root
          Please specify the iSCSI discover password: 
          Please specify the iSCSI portal login user: root
          Please specify the iSCSI portal login password: 
[ INFO  ] Discovering iSCSI targets
[ INFO  ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Force facts gathering]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Prepare iSCSI parameters]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Fetch host facts]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : iSCSI discover with REST API]
[ INFO  ] ok: [localhost]
          The following targets have been found:
                [1]     iqn.puma18.scl.lab.tlv.redhat.com:sharetarget
                        TPGT: -1, portals:
                                10.35.163.99:3260
         
          Please select a target (1) [1]: 
[ INFO  ] Getting iSCSI LUNs list
[ INFO  ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Force facts gathering]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Obtain SSO token using username/password credentials]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : iSCSI login]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.hosted_engine_setup : Get iSCSI LUNs]
[ INFO  ] ok: [localhost]
          The following luns have been found on the requested target:
                [1]     36589cfc0000009c5bcd15929f1721ac3       97GiB   FreeNAS iSCSI Disk
                        status: free, paths: 1 active
         
          Please select the destination LUN (1) [1]: 
[ INFO  ] iSCSI discard after delete is enabled
[ INFO  ] Creating Storage Domain
[ INFO  ] TASK [ovirt.hosted_engine_setup : Execute just a specific set of steps]
[ INFO  ] ok: [localhost]

Comment 7 Sandro Bonazzola 2019-07-30 14:08:30 UTC

This bugzilla is included in oVirt 4.3.5 release, published on July 30th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.5 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.