Hide Forgot
Description of problem: We're missing a field for the parameter snmp_priv_passwd in the RHEV UI window for the host powermanagement. Thus they are forced to enter it in cleartext in the options field, which for them is a security concern and in general is error prone. Version-Release number of selected component (if applicable): RHEV 3.2 How reproducible: always Steps to Reproduce: 1. go to the power management settings 2. set the type to fence_apc_snmp 3. check the fields - there is none for the snmp_priv_passwd Actual results: The fields missing and has to be set up via the options Expected results: Fields for all possible parameters for the fence_apc_snmp type (for all fence devices we support would of course be best). Fields that contain passwords should be non-cleartext fields and contents should be displayed as asterisks. Additional info: N/A
(In reply to Marko Karg from comment #0) > Description of problem: > > We're missing a field for the parameter snmp_priv_passwd in the RHEV UI > window for the host powermanagement. Thus they are forced to enter it in > cleartext in the options field, which for them is a security concern and in > general is error prone. > > Version-Release number of selected component (if applicable): > > RHEV 3.2 > > How reproducible: > > always > > Steps to Reproduce: > 1. go to the power management settings > 2. set the type to fence_apc_snmp > 3. check the fields - there is none for the snmp_priv_passwd > > Actual results: > > The fields missing and has to be set up via the options > > Expected results: > > Fields for all possible parameters for the fence_apc_snmp type (for all > fence devices we support would of course be best). > Fields that contain passwords should be non-cleartext fields and contents > should be displayed as asterisks. This is fully supported by putting in the options field "P=<value>" The agent list handles 3 special parameters that are common to all PM agents 1) Secure flag 2) Port 3) Slot All other parameters should be issued in the options field with the following format <key1>=<val1>, ...... <keyN>=<valN> I think that this RFE should be closed
I'm not sure it merits closing - seems like a UI nit pick. However I don't understand the more secure part?
Marek, Can you please explain the what is the difference between the user/pass (that we can configure in apc_snmp) to the snmp_priv_passwd field the customer wants to add.
@Barak, In SNMPv3 there are 3 levels of security: * noAuthnoPriv - only community name is used * AuthNoPriv - authentication (normal password) * AuthPriv - authentication & encryption of SNMP password (snmp_priv_password)
Eli there is an option to add a simple checkbox whether to encrypt the options, This will solve the unencryped password in the DB, but the vdsm will still log it. This will not make it into 3.4 , hence moving to rhevm-future Eli please add the full description of this option in terms of building blocks.
(In reply to Barak from comment #5) > Eli please add the full description of this option in terms of building > blocks. DB : Add a field (boolean) indicating if to encrypt options or not - default false (so no need to handle upgrade of the options field content) ENGINE : Adding handling in VDSDbFacadeImpl for encrypt/decrypt the options field according to the flag API : Adding support for the additional flag in POST/PUT/GET As stated in comment 5 , options will stay plain-text in teh VDSM level Arthur ?
(In reply to Eli Mesika from comment #6) > (In reply to Barak from comment #5) > > > Eli please add the full description of this option in terms of building > > blocks. > > DB : > Add a field (boolean) indicating if to encrypt options or not - default > false (so no need to handle upgrade of the options field content) > > ENGINE : > Adding handling in VDSDbFacadeImpl for encrypt/decrypt the options > field according to the flag > > API : > Adding support for the additional flag in POST/PUT/GET > > As stated in comment 5 , options will stay plain-text in teh VDSM level > > Arthur ? This option sound good to me. Moving to consider to 3.6.0.
Alexander: details on Comment #6, please contact Eli before starting the implementation to verify that what you intend to do is what actually needed. thanks.
Alexander - should be in POST (since there is a patch)?
Yes, hadn't gotten around to the book keeping yet.
Build ID: 3.6.0-1 Verified. DB: Table 'fence_agents' contains 'encrypt_options', and if set, the options are encrypted. ENGINE: There is a 'Encrypt options' checkbox when 'apc_snmp' power management type is chosen. API: In /ovirt-engine/api/hosts/<HOST_ID>/fenceagents/<FENCEAGENT_ID> is '<encrypt_options>' flag.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html