Bug 1481197 - Fencing default parameters for PPC PM requires administrator access
Summary: Fencing default parameters for PPC PM requires administrator access
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.3.0
: ---
Assignee: Eli Mesika
QA Contact: Petr Matyáš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-14 10:52 UTC by Eli Mesika
Modified: 2019-02-13 07:46 UTC (History)
3 users (show)

Fixed In Version: ovirt-engine-4.3.0_rc
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-13 07:46:47 UTC
oVirt Team: Infra
Embargoed:
rule-engine: ovirt-4.2+
rule-engine: ovirt-4.3+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 83712 0 master MERGED core:setting operator role for fencing in PPC 2020-02-28 00:48:15 UTC

Description Eli Mesika 2017-08-14 10:52:10 UTC
Description of problem:

In order to access the PPC PM agent (iLO3, iLO4, IPMIlan) from ovirt, the user must have either operator or administrator role.

oVirt engine is sending to the PPC PM device a default parameter of "privlvl=administrator" , this will prevent a user with a operator role to access the PM operations supported by oVirt.
In order to enable that, the default setting for PPC PM (iLO3, iLO4, IPMIlan) should be set to "privlvl=operator"



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


How reproducible:


Steps to Reproduce:
1.Create a operator user using the PM device web interface 
2.Add 2 PPC hosts , one with PM agent using the created user/password for auth
3.Test the PM agent 

Actual results:

Failed to access the PM device since ovirt sends implicitly "privlvl=administrator" and the user has only the operator role 

Expected results:

Should succeed 


Additional info:

If the PM agent is accessed with "privlvl=operator" for an administrator user, the operation will succeed

Comment 1 Martin Perina 2018-03-21 10:09:19 UTC
Moving to 4.3, we will backport to 4.2.z as needed

Comment 2 Petr Matyáš 2019-01-02 13:33:31 UTC
2019-01-02 15:29:30,243+02 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default task-4) [97c702b7-b28c-48a2-8
1b6-3705144c9dbc] START, FenceVdsVDSCommand(HostName = host_mixed_2, FenceVdsVDSCommandParameters:{hostId='b21871be-7998-4e5f-96e8-403
dc478b243', targetVdsId='922cbc88-d2a3-448b-bbd9-3f346ae33ea5', action='STATUS', agent='FenceAgent:{id='null', hostId='null', order='1
', type='ipmilan', ip='$address', port='null', user='user1', password='***', encryptOptions='false',
options='cipher=1, privlvl=OPERATOR, power_wait=4, lanplus=1, retry_on=2'}', policy='null'}), log id: 7cbfea21
2019-01-02 15:29:30,891+02 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (default task-4) [97c702b7-b28c-48a2-8
1b6-3705144c9dbc] FINISH, FenceVdsVDSCommand, return: FenceOperationResult:{status='SUCCESS', powerStatus='ON', message=''}, log id: 7
cbfea21

Comment 3 Sandro Bonazzola 2019-02-13 07:46:47 UTC
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 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.


Note You need to log in before you can comment on or make changes to this bug.