Bug 106734 - server caps exchange seems broken
server caps exchange seems broken
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Backend (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Fanny Augustin
Depends On:
Blocks: 106631
  Show dependency treegraph
Reported: 2003-10-09 20:23 EDT by Adrian Likins
Modified: 2007-04-18 12:58 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-14 20:18:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adrian Likins 2003-10-09 20:23:00 EDT
Description of problem:

        here is what I think
is happening.
if (call == queue.get or call == up2date.login):
        if call.has_caps:
        if call.has_caps:
                # dont change the caps
aka, it looks like if I make a call thats
not queue.get or up2date.login, and I
include caps info, it ignores the caps
info I actually send, and instead nulls
the caps.
It also seem like, if I make any call,
and dont include caps, it nullifies
the caps.
It seems like if the last call isnt
a queue.get or up2date.login, then
the caps are always going to be
nullified. Which is kind of broken.
Comment 1 Mihai Ibanescu 2003-10-10 18:47:44 EDT
Checked the code, I only update the capabilities in up2date.login and queue.get.
I don't touch the client capabilities from anywhere else (do a grep on
update_client_capabilities). The capabilities are extracted from a global flag
that is set by calling set_client_capabilities. set_client_capabilities is
called from apacheHandler.py in the header parsing handler.

It is arguable if "no capabilities from the client" means the client didn't send
them (in queue.get/up2date.login) or it doesn't support capabilities anymore
(older OS, or downgrading up2date). Donno.

I can't really see how the above-mentioned scenario would work. I'll have to
test a bit...
Comment 2 Adrian Likins 2003-10-13 13:47:56 EDT
I could be wrong, but thats the behaviour I was seeing after
a couple hours of testing.

Basically, if I send up caps info with any call other
than queue.get or login(), the caps get nullified. 

no caps in queue.get or login nullifying the store
caps is fine. Even nullifying it on other calls might
be fine. But nullifying it when the caps are sent 
seems wrong.
Comment 3 Adrian Likins 2003-10-14 19:36:25 EDT
hmm, I thought perhaps I was sending up the wrong systemid
on the login, but that does not appear to be the case.

And I still get the same behaviour. 

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