Bug 624673 - Rework fence_vmware fence agent to use SOAP API to connect to Virtual Center instead of VMware Perl API
Summary: Rework fence_vmware fence agent to use SOAP API to connect to Virtual Center ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fence-agents
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Marek Grac
QA Contact: Dean Jansa
URL:
Whiteboard:
: 486207 590696 (view as bug list)
Depends On: 668522 681835 755034
Blocks: GSS_6_2_PROPOSED 688370 688372 688374 688375
TreeView+ depends on / blocked
 
Reported: 2010-08-17 13:11 UTC by Perry Myers
Modified: 2018-11-14 17:52 UTC (History)
11 users (show)

Fixed In Version: fence-agents-3.1.5-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 634567 668522 (view as bug list)
Environment:
Last Closed: 2011-12-06 12:22:34 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 595380 None None None Never
Red Hat Bugzilla 634567 None None None Never
Red Hat Bugzilla 705072 None None None Never
Red Hat Knowledge Base (Legacy) 17342 None None None Never
Red Hat Knowledge Base (Legacy) 29440 None None None Never
Red Hat Product Errata RHBA-2011:1599 normal SHIPPED_LIVE fence-agents bug fix and enhancement update 2011-12-06 00:51:16 UTC

Internal Links: 634567 705072

Description Perry Myers 2010-08-17 13:11:14 UTC
Description of problem:
Existing fence_vmware uses 3rd party RPM dependency from VMware (VMware Perl API).  libvirt VMware/ESX driver implemented a SOAP method to connect to Virtual Center.

libvirt usage is fairly different than what we want for a general fence agent, so it's been recommended by libvirt team that we lift their SOAP code (just the parts of it that we need for the fence agent) and use it to rework the fence_vmware agent.

Comment 1 Ryan O'Hara 2010-08-30 18:13:27 UTC
Doing this will allow us to remove fence_vmware_helper.pl and fence_vware can be exclusively Python code. This will likely create a dependency on a SOAP module to be pulled into Pyton, such as SOAPy.

The vmware web site has a "VMware Infrastructure SDK Programming Guide" that seems helpful, too. Basic power on/off operations are PowerOnVM_Task and PowerOffVM_Task. Also look at libvirt, which uses a C API but has some python code to generate the SOAP code. This is more than we need for fence_vmware, but might be a handy reference.

Comment 2 Perry Myers 2010-09-16 11:53:33 UTC
*** Bug 486207 has been marked as a duplicate of this bug. ***

Comment 4 Perry Myers 2010-11-27 13:33:09 UTC
*** Bug 590696 has been marked as a duplicate of this bug. ***

Comment 6 Brian Likosar 2011-02-07 20:45:39 UTC
One thing to consider is that having a username/password combination with this level of access can be dangerous.  In documentation we ought to recommend that access levels be leveraged to provide a user with specific privileges.  Further, usernames and passwords can expire - using some authentication method (similar to ssh keys as in ESX connectivity previously) would be the ideal solution/option.

Comment 7 Perry Myers 2011-02-07 20:50:22 UTC
liko also mentioned that there may be a way to use some sort of vCenter auth token in place of traditional user/pass.  If this auth method exists in vCenter we should investigate and incorporate it into the design of the new fence agent.

Comment 8 Perry Myers 2011-02-28 02:06:52 UTC
Talked to marx about this, and he is not aware of any auth mechanism exposed via the SOAP interface aside from standard user/password.  There may be other auth mechanisms available to vCenter in general, but if they're not exposed via SOAP we can't take advantage of them.

As liko mentions above, we should document the following as best practice:

In vCenter create a new user that has limited permissions (i.e. user foo can only control guest 1 & 2 lifecycle functions).  Then the fence_vmware agent can be configured only with user foo credentials, limiting exposure of that user/pass.

liko: is pw timeout a hardcoded thing in vCenter or maybe does it only apply to the top level Administrator user?

Comment 9 Marek Grac 2011-02-28 08:50:32 UTC
I have found out that even it is not mentioned in manual, method LoginBySSPI is documented in API. So we can try to implement it.

Comment 10 Marek Grac 2011-02-28 13:47:34 UTC
LoginBySSPI in VMWare SOAP API:

http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html#loginBySSPI

@dpal: Can we use IPA for that instead of Windows AD?

Comment 11 Dmitri Pal 2011-02-28 14:48:03 UTC
(In reply to comment #10)
> LoginBySSPI in VMWare SOAP API:
> 
> http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vim.SessionManager.html#loginBySSPI
> 
> @dpal: Can we use IPA for that instead of Windows AD?

SSPI is a native Windows interface.
I am not sure but it actually might work.
Please see the following link 
http://msdn.microsoft.com/en-us/library/ms995352.aspx
I think you would have to implement service and client in a special way as described in the article.

Simo, can you add more?

Comment 12 Brian Likosar 2011-02-28 20:34:33 UTC
@pmyers, regarding https://bugzilla.redhat.com/show_bug.cgi?id=624673#c8, I was incorrect.  There is no session timeout, so this might no longer be an issue.  From the documentation I've seen - there is fine granularity in permissions, such that the fence user can be locked down quite a bit.  I agree that we should document that as a best practice.

Comment 26 errata-xmlrpc 2011-12-06 12:22:34 UTC
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.

http://rhn.redhat.com/errata/RHBA-2011-1599.html


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