Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1481197

Summary:	Fencing default parameters for PPC PM requires administrator access
Product:	[oVirt] ovirt-engine	Reporter:	Eli Mesika <emesika>
Component:	Backend.Core	Assignee:	Eli Mesika <emesika>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Matyáš <pmatyas>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.2.0	CC:	bugs, lsvaty, mperina
Target Milestone:	ovirt-4.3.0	Flags:	rule-engine: ovirt-4.2+ rule-engine: ovirt-4.3+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-engine-4.3.0_rc	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-02-13 07:46:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.