RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1418930 - [ESXi][RHEL8]RFE: Please increase granularity of open-vm-tools packaging
Summary: [ESXi][RHEL8]RFE: Please increase granularity of open-vm-tools packaging
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: open-vm-tools
Version: 8.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Cathy Avery
QA Contact: Bo Yang
URL:
Whiteboard:
Depends On:
Blocks: 1420851
TreeView+ depends on / blocked
 
Reported: 2017-02-03 07:51 UTC by Vladimir Dulava
Modified: 2020-11-14 11:11 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-03 20:35:14 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Vladimir Dulava 2017-02-03 07:51:26 UTC 
Description of problem:
Customer requested this RFE:
The open-vm-tools package, as it is currently packaged, contains the almost complete list of utilities and libraries corresponding to:

vmware-tools-guestlib
vmware-tools-core-9.10.5-1.el6.x86_64
vmware-tools-foundation-9.10.5-1.el6.x86_64
vmware-tools-libraries-nox-9.10.5-1.el6.x86_64
vmware-tools-plugins-guestInfo-9.10.5-1.el6.x86_64
vmware-tools-plugins-powerOps-9.10.5-1.el6.x86_64
vmware-tools-plugins-timeSync-9.10.5-1.el6.x86_64
vmware-tools-pvscsi-common-9.10.5-5.el6.x86_64
vmware-tools-services-9.10.5-1.el6.x86_64
vmware-tools-vmmemctl-common-9.10.5-5.el6.x86_64
vmware-tools-vmxnet3-common-9.10.5-5.el6.x86_64
vmware-tools-plugins-autoUpgrad
vmware-tools-plugins-deployPkg
vmware-tools-plugins-grabbitmqProxy
vmware-tools-plugins-hgfsServer
vmware-tools-plugins-vix
vmware-tools-plugins-vmbackup

To reduce impact of possible client -> hypervisor interaction we reduce (in RHEL6) the list of available VM functionality to just:

vmware-tools-guestlib
vmware-tools-core-9.10.5-1.el6.x86_64
vmware-tools-foundation-9.10.5-1.el6.x86_64
vmware-tools-libraries-nox-9.10.5-1.el6.x86_64
vmware-tools-plugins-guestInfo-9.10.5-1.el6.x86_64
vmware-tools-plugins-powerOps-9.10.5-1.el6.x86_64
vmware-tools-plugins-timeSync-9.10.5-1.el6.x86_64
vmware-tools-pvscsi-common-9.10.5-5.el6.x86_64
vmware-tools-services-9.10.5-1.el6.x86_64
vmware-tools-vmmemctl-common-9.10.5-5.el6.x86_64
vmware-tools-vmxnet3-common-9.10.5-5.el6.x86_64

and exclude:

vmware-tools-plugins-autoUpgrad
vmware-tools-plugins-deployPkg
vmware-tools-plugins-grabbitmqProxy
vmware-tools-plugins-hgfsServer
vmware-tools-plugins-vix
vmware-tools-plugins-vmbackup

To do the same with open-vm-tools we need to remove/put to a subpackage the following parts of open-vm-tools:

/usr/lib64/libDeployPkg.so.0
/usr/lib64/libDeployPkg.so.0.0.0
/usr/lib64/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
/usr/lib64/open-vm-tools/plugins/vmsvc/libgrabbitmqProxy.so
/usr/bin/vmhgfs-fuse
/usr/bin/vmware-hgfsclient
/usr/lib64/libhgfs.so.0
/usr/lib64/libhgfs.so.0.0.0
/usr/lib64/open-vm-tools/plugins/common/libhgfsServer.so
/usr/lib64/open-vm-tools/plugins/common/libvix.so
/usr/lib64/open-vm-tools/plugins/vmsvc/libvmbackup.so

Is it possible to move these bits to a subpackage so that there is a sane way to remove these utilities and libraries?

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
Bigger granularity of open-vm-tools packaging

Additional info:
Comment 2 Ravindra Kumar 2017-02-03 20:20:25 UTC 
(In reply to Vladimir Dulava from comment #0)
> To reduce impact of possible client -> hypervisor interaction we reduce (in
> RHEL6) the list of available VM functionality to just:
> 
> vmware-tools-guestlib
> vmware-tools-core-9.10.5-1.el6.x86_64
> vmware-tools-foundation-9.10.5-1.el6.x86_64
> vmware-tools-libraries-nox-9.10.5-1.el6.x86_64
> vmware-tools-plugins-guestInfo-9.10.5-1.el6.x86_64
> vmware-tools-plugins-powerOps-9.10.5-1.el6.x86_64
> vmware-tools-plugins-timeSync-9.10.5-1.el6.x86_64
> vmware-tools-pvscsi-common-9.10.5-5.el6.x86_64
> vmware-tools-services-9.10.5-1.el6.x86_64
> vmware-tools-vmmemctl-common-9.10.5-5.el6.x86_64
> vmware-tools-vmxnet3-common-9.10.5-5.el6.x86_64
> 
> and exclude:
> 
> vmware-tools-plugins-autoUpgrad
> vmware-tools-plugins-deployPkg
> vmware-tools-plugins-grabbitmqProxy
> vmware-tools-plugins-hgfsServer
> vmware-tools-plugins-vix
> vmware-tools-plugins-vmbackup
> 
> To do the same with open-vm-tools we need to remove/put to a subpackage the
> following parts of open-vm-tools:
> 
> /usr/lib64/libDeployPkg.so.0
> /usr/lib64/libDeployPkg.so.0.0.0
> /usr/lib64/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
> /usr/lib64/open-vm-tools/plugins/vmsvc/libgrabbitmqProxy.so
> /usr/bin/vmhgfs-fuse
> /usr/bin/vmware-hgfsclient
> /usr/lib64/libhgfs.so.0
> /usr/lib64/libhgfs.so.0.0.0
> /usr/lib64/open-vm-tools/plugins/common/libhgfsServer.so
> /usr/lib64/open-vm-tools/plugins/common/libvix.so
> /usr/lib64/open-vm-tools/plugins/vmsvc/libvmbackup.so
> 
> Is it possible to move these bits to a subpackage so that there is a sane
> way to remove these utilities and libraries?

If the reasons for doing this is related to security then this is not the right way to do it. The customer should follow https://www.vmware.com/security/hardening-guides.html instead.

> Expected results:
> Bigger granularity of open-vm-tools packaging

We want less packages to simplify package management.
Comment 3 John Savanyo 2017-02-07 19:31:18 UTC 
Filed internal VMware bug 1808026 to track this RFE.
Comment 5 Beat Rubischon 2017-06-16 07:39:51 UTC 
Another request for granularity: Split out of the vmhgfs functionality. It depends on fuse which is avoided in high security environments like banks and useless in enterprise environments using ESX/ESXi as vmhgfs is only supported in the VMware Workstation and Fusion products.

John, would you mind to add this request to your internal bug 1808026? Please contact me out of band in case you need a business justification.
Comment 6 John Savanyo 2017-06-26 19:08:39 UTC 
Hi Beat, 
Thanks for additional information. I updated our internal RFE with additional information.

-John
Comment 7 John Savanyo 2017-06-27 21:36:17 UTC 
Implementing more granularity would also help solve Bug 1358108

-John
Comment 9 Cathy Avery 2018-07-05 17:57:40 UTC 
I'm assigning this bug to myself. Ravindra please continue to work this issue.
Comment 11 Marina Kalinin 2018-11-27 21:53:36 UTC 
(In reply to Ravindra Kumar from comment #2)
> (In reply to Vladimir Dulava from comment #0)
> > To reduce impact of possible client -> hypervisor interaction we reduce (in
> > RHEL6) the list of available VM functionality to just:
> > 
> > vmware-tools-guestlib
> > vmware-tools-core-9.10.5-1.el6.x86_64
> > vmware-tools-foundation-9.10.5-1.el6.x86_64
> > vmware-tools-libraries-nox-9.10.5-1.el6.x86_64
> > vmware-tools-plugins-guestInfo-9.10.5-1.el6.x86_64
> > vmware-tools-plugins-powerOps-9.10.5-1.el6.x86_64
> > vmware-tools-plugins-timeSync-9.10.5-1.el6.x86_64
> > vmware-tools-pvscsi-common-9.10.5-5.el6.x86_64
> > vmware-tools-services-9.10.5-1.el6.x86_64
> > vmware-tools-vmmemctl-common-9.10.5-5.el6.x86_64
> > vmware-tools-vmxnet3-common-9.10.5-5.el6.x86_64
> > 
> > and exclude:
> > 
> > vmware-tools-plugins-autoUpgrad
> > vmware-tools-plugins-deployPkg
> > vmware-tools-plugins-grabbitmqProxy
> > vmware-tools-plugins-hgfsServer
> > vmware-tools-plugins-vix
> > vmware-tools-plugins-vmbackup
> > 
> > To do the same with open-vm-tools we need to remove/put to a subpackage the
> > following parts of open-vm-tools:
> > 
> > /usr/lib64/libDeployPkg.so.0
> > /usr/lib64/libDeployPkg.so.0.0.0
> > /usr/lib64/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
> > /usr/lib64/open-vm-tools/plugins/vmsvc/libgrabbitmqProxy.so
> > /usr/bin/vmhgfs-fuse
> > /usr/bin/vmware-hgfsclient
> > /usr/lib64/libhgfs.so.0
> > /usr/lib64/libhgfs.so.0.0.0
> > /usr/lib64/open-vm-tools/plugins/common/libhgfsServer.so
> > /usr/lib64/open-vm-tools/plugins/common/libvix.so
> > /usr/lib64/open-vm-tools/plugins/vmsvc/libvmbackup.so
> > 
> > Is it possible to move these bits to a subpackage so that there is a sane
> > way to remove these utilities and libraries?
> 
> If the reasons for doing this is related to security then this is not the
> right way to do it. The customer should follow
> https://www.vmware.com/security/hardening-guides.html instead.
Hi Ravindra can you please give more specific recommendation on how to achieve what the customers are asking for?
How can the customer avoid installing vmhgfs-fuse or what security adjustment need to be made otherwise?
> 
> > Expected results:
> > Bigger granularity of open-vm-tools packaging
> 
> We want less packages to simplify package management.
Comment 17 John Savanyo 2019-09-25 20:58:26 UTC 
From discussion this morning - There is concern that if we attempt to change the package structure that this would result in customer disruption and regressions. If we change package structure we think it is better to do this with RHEL 9.0.
Comment 18 Rick Barry 2019-10-03 20:35:14 UTC 
We'll work with VMware and look at restructuring the packaging in RHEL 9.0.
Note You need to log in before you can comment on or make changes to this bug.