Bug 1295325 - candlepin doesn't check owner and env that virt-who sends
candlepin doesn't check owner and env that virt-who sends
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Candlepin (Show other bugs)
Unspecified
x86_64 Linux
medium Severity medium (vote)
: Unspecified
: --
Assigned To: Barnaby Court
Katello QA List
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-04 03:13 EST by Eko
Modified: 2017-01-05 14:39 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-01-05 14:39:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eko 2016-01-04 03:13:45 EST
Description of problem:
run virt-who with an wrong owner or env value, virt-who still can work normally.

Version-Release number of selected component (if applicable):
virt-who-0.16-1.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. run virt-who with an wrong owner, such as "--libvirt-owner=xxxxxxxx ":
# virt-who --libvirt --libvirt-owner=xxxxxxxx --libvirt-env=Library --libvirt-server=10.66.144.8 --libvirt-username=root --libvirt-password=redhat -o -d

========= virt-who still can work normally with an wrong owner value ========
2016-01-04 16:09:29,521 [virtwho.main INFO] MainProcess(22354):MainThread @subscriptionmanager.py:hypervisorCheckIn:170 - Sending update in hosts-to-guests mapping: 1 hypervisors and 1 guests found
2016-01-04 16:09:29,522 [virtwho.main DEBUG] MainProcess(22354):MainThread @subscriptionmanager.py:hypervisorCheckIn:171 - Host-to-guest mapping: {
    "80804c56-82fb-e111-a260-b4b52fcb471e": [
        {
            "guestId": "cb33ddce-fd1e-0e6a-7e7f-d3c6fca67ede", 
            "state": 3, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "0.12.1", 
                "virtWhoType": "libvirt", 
                "hypervisorType": "QEMU"
            }
        }
    ]
}
2016-01-04 16:09:29,820 [virtwho.main DEBUG] MainProcess(22354):MainThread @virtwho.py:send_current_report:206 - Report for config "env/cmdline" sent
2016-01-04 16:09:29,823 [virtwho.main DEBUG] MainProcess(22354):MainThread @virtwho.py:<module>:890 - virt-who terminated
2016-01-04 16:09:29,823 [virtwho.main DEBUG] MainProcess(22354):MainThread @virtwho.py:terminate:413 - virt-who is shutting down


2.run virt-who with an wrong owner, such as "--libvirt-env=xxxxxxxx":
# virt-who --libvirt --libvirt-owner=ACME_Corporation --libvirt-env=xxxxxxxx --libvirt-server=10.66.144.8 --libvirt-username=root --libvirt-password=redhat -o -d

========= virt-who still can work normally with an wrong env value ========
2016-01-04 16:11:27,482 [virtwho.main INFO] MainProcess(22517):MainThread @subscriptionmanager.py:hypervisorCheckIn:170 - Sending update in hosts-to-guests mapping: 1 hypervisors and 1 guests found
2016-01-04 16:11:27,482 [virtwho.main DEBUG] MainProcess(22517):MainThread @subscriptionmanager.py:hypervisorCheckIn:171 - Host-to-guest mapping: {
    "80804c56-82fb-e111-a260-b4b52fcb471e": [
        {
            "guestId": "cb33ddce-fd1e-0e6a-7e7f-d3c6fca67ede", 
            "state": 3, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "0.12.1", 
                "virtWhoType": "libvirt", 
                "hypervisorType": "QEMU"
            }
        }
    ]
}
2016-01-04 16:11:27,769 [virtwho.main DEBUG] MainProcess(22517):MainThread @virtwho.py:send_current_report:206 - Report for config "env/cmdline" sent
2016-01-04 16:11:27,771 [virtwho.main DEBUG] MainProcess(22517):MainThread @virtwho.py:<module>:890 - virt-who terminated
2016-01-04 16:11:27,772 [virtwho.main DEBUG] MainProcess(22517):MainThread @virtwho.py:terminate:413 - virt-who is shutting down



Actual results:
run virt-who with an wrong owner or env value, virt-who still can work normally.

Expected results:
virt-who should show some error info with an wrong owner or env value

Additional info:
Comment 2 Radek Novacek 2016-01-28 05:22:34 EST
This is server-side issue which I believe is fixed in newer versions of candlepin. With (a bit older) candlepin master, I get:

[virtwho.main ERROR] MainProcess(16323):MainThread @virtwho.py:send:202 - Unable to send data: Communication with subscription manager failed with code 404: Organization with id xxxxxxxx could not be found.

Can you please check with latest candlepin?
Comment 3 Eko 2016-02-16 01:15:12 EST
hi Radek, 
I remember this issue is only for stage candlepin, but now I can duplicate it for satellite server
Comment 4 Radek Novacek 2016-02-18 05:19:32 EST
As I said, this is server side issue, virt-who can't tell if the owner and env is correct. It just sends it to the server and then the server has to tell if it's correct.

So I'm moving this bug to candlepin.
Comment 5 Chris Snyder 2016-03-01 16:03:53 EST
Tested with all pertinent versions of candlepin for satellite. I could not reproduce the failure as originally described.
Comment 6 Liushihui 2016-03-03 02:38:29 EST
Reproduce it on candlepin-0.9.49.11-1.el7.noarch(Satellite-6.1.0-RHEL-7-20160209.1/), Therefore, reopen it. 

Reproduced version:
Satellite-6.1.0-RHEL-7-20160209.1
candlepin-0.9.49.11-1.el7.noarch
katello-2.2.0.18-1.el7sat.noarch
foreman-1.7.2.53-1.el7sat.noarch

Reproduced process:
1. Register system to satellite
[root@sgi-xe270-01 ~]# subscription-manager  identity
system identity: 2998a4bc-1b79-43d9-8580-dd26a404e33c
name: sgi-xe270-01.rhts.eng.bos.redhat.com
org name: Default Organization
org ID: Default_Organization
environment name: Library

2. run virt-who with an wrong owner and env and check virt-who's log.
[root@sgi-xe270-01 ~]# virt-who --hyperv --hyperv-owner=xxxxxx --hyperv-env=xxxxx --hyperv-server=10.73.5.227 --hyperv-username=administrator --hyperv-password=Welcome1 -d
2016-03-03 02:34:26,933 [virtwho.init INFO] MainProcess(11414):MainThread @virtwho.py:parseOptions:630 - Using reporter_id='sgi-xe270-01.rhts.eng.bos.redhat.com'
2016-03-03 02:34:26,937 [virtwho.init INFO] MainProcess(11414):MainThread @virtwho.py:main:722 - Using configuration "env/cmdline" ("hyperv" mode)
2016-03-03 02:34:26,940 [virtwho.main DEBUG] MainProcess(11414):MainThread @virtwho.py:run:229 - Starting infinite loop with 60 seconds interval
2016-03-03 02:34:27,088 [virtwho.env_cmdline DEBUG] MainProcess(11414):MainThread @hyperv.py:__init__:473 - Hyper-V url: http://10.73.5.227:5985/wsman
2016-03-03 02:34:27,091 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @virt.py:run:358 - Virt backend 'env/cmdline' started
2016-03-03 02:34:28,410 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:retry_ntlm_negotitate:67 - Using NTLM authentication
2016-03-03 02:34:29,766 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:retry_ntlm_authenticate:80 - Sending NTLM authentication data
2016-03-03 02:34:30,482 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:retry_ntlm_authenticate:103 - NTLM authentication successful
2016-03-03 02:34:30,493 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @hyperv.py:getHostGuestMapping:521 - Unable to enumerate using root/virtualization namespace, trying root/virtualization/v2 namespace
2016-03-03 02:34:42,289 [virtwho.env_cmdline DEBUG] HyperV-1(11421):MainThread @virt.py:enqueue:351 - Report gathered, putting to queue for sending
2016-03-03 02:34:42,312 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:_connect:121 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2016-03-03 02:34:42,901 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:162 - Checking if server has capability 'hypervisor_async'
2016-03-03 02:34:43,513 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:174 - Server does not have 'hypervisors_async' capability
2016-03-03 02:34:43,513 [virtwho.main INFO] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:185 - Sending update in hosts-to-guests mapping for config "env/cmdline": 1 hypervisors and 1 guests found
2016-03-03 02:34:43,513 [virtwho.main DEBUG] MainProcess(11414):MainThread @subscriptionmanager.py:hypervisorCheckIn:186 - Host-to-guest mapping: {
    "564D4704-757E-A977-F67F-5402B8860710": [
        {
            "guestId": "32710A7E-94A9-A445-944E-16C01BFA63B3", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "6.3.9600.16404", 
                "virtWhoType": "hyperv", 
                "hypervisorType": "hyperv"
            }
        }
    ]
}
2016-03-03 02:34:44,751 [virtwho.main DEBUG] MainProcess(11414):MainThread @virtwho.py:send_current_report:159 - Report for config "env/cmdline" sent

Result:
Virt-who still can send host/guest mapping info to satellite.
Comment 7 Chris Snyder 2016-03-04 09:59:27 EST
I am not able to reproduce using an invalid organization against candlepin-0.9.49.11-1


----------------------

2016-03-03 17:08:55,834 [virtwho.init DEBUG] MainProcess(21433):MainThread @virtwho.py:__init__:125 - Using config named 'fake'
2016-03-03 17:08:55,834 [virtwho.init INFO] MainProcess(21433):MainThread @virtwho.py:main:736 - Using configuration "fake" ("fake" mode)
2016-03-03 17:08:55,884 [virtwho.fake DEBUG] FakeVirt-1(21437):MainThread @virt.py:run:359 - Virt backend 'fake' started
2016-03-03 17:08:55,885 [virtwho.fake DEBUG] FakeVirt-1(21437):MainThread @virt.py:enqueue:352 - Report gathered, putting to queue for sending
2016-03-03 17:08:55,895 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:_connect:121 - Authenticating with certificate: /etc/pki/consumer/cert.pem
2016-03-03 17:08:55,906 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:162 - Checking if server has capability 'hypervisor_async'
2016-03-03 17:08:55,915 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:174 - Server does not have 'hypervisors_async' capability
2016-03-03 17:08:55,915 [virtwho.main INFO] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:185 - Sending update in hosts-to-guests mapping for config "fake": 2 hypervisors and 4 guests found
2016-03-03 17:08:55,915 [virtwho.main DEBUG] MainProcess(21433):MainThread @subscriptionmanager.py:hypervisorCheckIn:186 - Host-to-guest mapping: {
    "ec071dd1-9059-4a36-ad8e-7a1a46734c72": [
        {
            "guestId": "2968925c-8603-4192-b6fc-783d114110de", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "", 
                "virtWhoType": "fake", 
                "hypervisorType": "fake"
            }
        }, 
        {
            "guestId": "eb46dc1f-05aa-48f1-95b0-82c95007329a", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "fake"
            }
        }
    ], 
    "d965733b-1908-4579-a11c-381243138d32": [
        {
            "guestId": "3a9bf950-55ad-4480-b985-bd5e503609f0", 
            "state": 1, 
            "attributes": {
                "active": 1, 
                "hypervisorVersion": "", 
                "virtWhoType": "fake", 
                "hypervisorType": "fake"
            }
        }, 
        {
            "guestId": "eb46dc1f-05aa-48f1-95b0-82c95007329a", 
            "state": 5, 
            "attributes": {
                "active": 0, 
                "virtWhoType": "fake"
            }
        }
    ]
}
2016-03-03 17:08:55,947 [virtwho.main ERROR] MainProcess(21433):MainThread @virtwho.py:send:201 - Unable to send data: Communication with subscription manager failed with code 404: Organization with id lolfake could not be found.
2016-03-03 17:08:55,947 [virtwho.main DEBUG] MainProcess(21433):MainThread @virtwho.py:send_current_report:166 - Report from "fake" failed to sent
2016-03-03 17:08:55,948 [virtwho.main DEBUG] MainProcess(21433):MainThread @virtwho.py:<module>:828 - virt-who terminated
2016-03-03 17:08:55,948 [virtwho.main DEBUG] MainProcess(21433):MainThread @virtwho.py:terminate:352 - virt-who is shutting down


----------------------------------------------------------------------------

➜  virt-who git:(master) ✗ subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.49.11-1
subscription management rules: 5.16
subscription-manager: 1.16.8-3-2-gea726d1
python-rhsm: 1.16.5-1-2-gbdcfee3



-------------------------------------------


The above is when I register directly to candlepin.

It seems that candlepin does not do anything and has not done anything with the environment sent as a query parameter by virt-who.


Radek,

What is the historical significance of virt-who sending an environment along with a report?

What is expected of candlepin?
Comment 8 Chris Snyder 2016-03-04 11:01:57 EST
Please see comment 7 above
Comment 9 Radek Novacek 2016-03-08 10:45:55 EST
The python-rhsm API function `hypervisorCheckIn` requires env argument: https://github.com/candlepin/python-rhsm/blob/master/src/rhsm/connection.py#L915

It was there when the first version of virt-who was being implemented. So I thought it's something important and added commandline and config option for that.

If it is not needed, we can remove it from required config and commandline options and silently ignore it for compatibility.
Comment 10 Bryan Kearney 2016-07-08 16:39:55 EDT
Per 6.3 planning, moving out non acked bugs to the backlog
Comment 12 Barnaby Court 2016-12-05 14:19:09 EST
Chris, did you test this integrated with Satellite or with Candlepin only?
Comment 13 Chris Snyder 2016-12-19 14:09:59 EST
Barnaby,

With candlepin directly only.
I can try again with an older version of satellite. My guess is the problem was fixed in newer versions of satellite. At any rate I do not believe this to be a candlepin.

Leaving a needinfo on bcourt to move this to the right component as I am unsure where this needs to go.
Comment 14 Barnaby Court 2016-12-19 23:22:49 EST
Chris,

If we know that the owner is being validated on the Candlepin side, please validate with a newer version of Satellite to ensure that the environment is being validated as well. The validation can be happening either in Candlepin (if we know about it) or in Katello but one of the two needs to be checking to provide a good customer experience. If Candlepin knows about all the environments for an owner when the call comes in, and we receive the parameter that specifies an environment, then why wouldn't we validate it?
Comment 15 Chris Snyder 2017-01-05 14:39:51 EST
Barnaby,

Running a similar test against the sat-ga-rhel7 vagrant box in forklift/sat-deploy results in a failure in virt-who (which is the proper expected behaviour).

Setting either or both of the owner or env to a bad value returns a 403 Access Denied when virt-who attempts the hypervisor checkin.


I believe this is fixed in virt-who/satellite latest as such I'm closing this as CURRENT_RELEASE. If anyone believes this is in error, please re-open the bug.


Thanks!

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