I have 2 customers reported the above concern for whom i have advised to use RHN Classic as we dont have such functionality as of now. Please correct me if I am wrong and let me know if there is any alternate solution for this.

Below article may give you more idea 

 "Using RHEL subscriptions (2013 packaging): Scenario 5 - Virtual Datacenter "
  >> https://access.redhat.com/site/articles/480693

Here are some more requested inputs from the customer.


> - business justification i.e list the business requirements

Only admin servers/desktops have access to vCenter.
So Red Hat must provide a way to register RHEL guests on third party hypervisors without requiring VMs to have admin access to vCenter (the current girt-who stuff is just defective by design)
Registration/enrollement must be automatic (no need to go on the RedHat support website and assign enrolments for each an every VM)

> - do you have specific timeline dependencies?

No specific timeline dependencies.

> - would you be able to assist in testing this functionality if implemented?

Sure

Hi, my current plan is following:

1) try to figure out, if virt-who could be used without administrator privileges on vCenter. Would it be OK for customer to have credentials for some non-admin user stored unencrypted in virt-who config file?

2) if not, add some possibility to encrypt the password that is supplied in the config file. I don't see any possibility how make the password storage secure but we can try to make it harder to read, but it will just be security through obscurity.

This is kind of roundrobbin.

CU's need to use virt-who to register the RHEL guest installed on VMware-ESX or Hyper-V.  CU cannot do that as their company security policy does not allow them to mention passwords in "clear text" in virt-who config which is an administrative user.  

Though I have seen another case where read only user may also work ? There is no alternate method to achieve this & customers are getting frustrated.  Case - 01066127 where customer has 5 QTY of SKU RH00002 Red Hat Enterprise Linux for Virtual Datacenters, Standard, which cannot be fully utilized because of this issue.

Regards
Yogendra.

So, is following solution acceptable for you:

Have some utility that will ask you for your password and will return encoded string. You will place this encoded string to virt-who config file.

On the background there will be file with the encryption key somewhere on the disk only accessible by root.

There is no added security in this approach, anyone with the root access will still be able to get your password, but the password won't be stored in plaintext in the configuration file.

That sounds like a better interim solution, than having the password saved as cleartext, along with having the permissions of the virt-who config file default to 600 instead of 644 ?

Also - I found another bug with the girt-who service:  If the password being used ends with an & character as the 3rd to last, the service fails as it’s being interpreted as a command.

For example, if the password is:  12345abcde&F1
when trying to start/stop the service, it will return
/etc/sysconfig/virt-who: line 44: F!: command not found

-Sal

Config file permissions will be changed to 600.

The behavior with ampersand in the password is expected. The /etc/sysconfig/virt-who file is read as a shell script that sets some environmental variables. The password should be quoted, e.g.

VIRTWHO_ESX_PASSWORD='12345abcde&F1'


I'll add note that this could happen.

Thanks for noticing.

This bug is fixed upstream and will be resolved by rebase of virt-who, see bug 1002640.

This is already implemented, removing FutureFeature keyword.

This bug is fixed by rebase to virt-who-0.10-1.el6.

Verify it on virt-who-0.10-3.el6.noarch. 

Config file /etc/sysconfig/virt-who permissions has been modified to 600.
[root@hp-z220-05 sysconfig]# ls -alt virt-who 
-rw-------. 1 root root 1846 Jul 28 14:29 virt-who

Hello Radek,

May I know whether is there any date planned for the release of this fix ? so that I can update customer accordingly.

Thank you in advance.

This will be part of RHEL-6.6 release that is currently planned to the mid of October.

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-2014-1513.html

-