Bug 705335 - the picking of remote actions fails after reregistration with Satellite
Summary: the picking of remote actions fails after reregistration with Satellite
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum-rhn-plugin
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Milan Zázrivec
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-17 12:11 UTC by Šimon Lukašík
Modified: 2014-06-16 08:17 UTC (History)
6 users (show)

Fixed In Version: yum-rhn-plugin-1.8.6-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-16 08:17:12 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Šimon Lukašík 2011-05-17 12:11:32 UTC
Description of problem:
see steps

Version-Release number of selected component (if applicable):
yum-rhn-plugin-0.9.1-26.el6_1.1.noarch
yum-3.2.29-17.el6.noarch

How reproducible:
2 of 2

Steps to Reproduce:
1, Register with Satellite
2. Pick up remote action
3. Unregister
4. Modify the channel
5. Register with Satellite again
6. Pick up another remote action

1. Register client with the satellite
2. Populate yum cache (yum repolist)
3. Delete the client on Satellite Web
4. Truncate /var/cache/yum/*/rhnplugin.repos (e.g. yum repolist)
5. Add package to the Satellite channel
6. Register again with the same channel
7. yum clean all
8. yum install the package


Actual results:
yum-rhn-plugin does have the channels in rhnplugin.repos file and therefore
the metadata cannot be purged by 'yum clean all'. As a result yum-rhn-plugin
works with old repomd.xml file which contains stale sha256 checksums. And
as a result 'yum install' command fails to retrieve other.xml.


Expected results:
Just work as in the old times. (rhel5)

Additional info:

Comment 1 Šimon Lukašík 2011-05-17 12:12:48 UTC
[Tue May 17 07:37:09 2011] up2date D: rpcServer: Calling XMLRPC up2date.listChannels
[Tue May 17 07:37:33 2011] up2date updateLoginInfo() login info
[Tue May 17 07:37:33 2011] up2date D: login(forceUpdate=True) invoked
[Tue May 17 07:37:33 2011] up2date logging into up2date server
[Tue May 17 07:37:33 2011] up2date D: rpcServer: Calling XMLRPC up2date.login
[Tue May 17 07:37:34 2011] up2date D: writeCachedLogin() invoked
[Tue May 17 07:37:34 2011] up2date D: Wrote pickled loginInfo at  1305632254.07  with expiration of  1305635854.07  seconds.
[Tue May 17 07:37:34 2011] up2date successfully retrieved authentication token from up2date server
[Tue May 17 07:37:34 2011] up2date D: logininfo: {'X-RHN-Server-Id': 1000010002, 'X-RHN-Auth-Server-Time': '1305632254.06', 'X-RHN-Auth': 'u44UgE7LPBtN38XrtvmlyQ==', 'X-RHN-Auth-Channels': [['rhel-x86_64-server-6', '20110517040045', '1', '1'], ['rhn-tools-rhel-x86_64-server-6', '20110516021352', '0', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
[Tue May 17 07:37:34 2011] up2date 
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 334, in __run_action
    (status, message, data) = CheckCli.__do_call(method, params, kwargs)
  File "/usr/sbin/rhn_check", line 326, in __do_call
    method = getMethod.getMethod(method, "/usr/share/rhn/", "actions")
  File "/usr/share/rhn/up2date_client/getMethod.py", line 78, in getMethod
    actions = __import__(modulename)
  File "/usr/share/rhn/actions/packages.py", line 271, in <module>
    yum_base = YumAction()
  File "/usr/share/rhn/actions/packages.py", line 69, in __init__
    self.repos.populateSack(mdtype='all')
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 289, in populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 183, in populate
    xml = repo_get_function()
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1636, in getOtherXML
    return self.retrieveMD('other')
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1551, in retrieveMD
    return self._retrieveMD(mdtype)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1607, in _retrieveMD
    size=thisdata.size)
  File "/usr/share/yum-plugins/rhnplugin.py", line 335, in _getFile
    self.id, e)
<class 'yum.Errors.RepoError'>: failed to retrieve repodata/5be839e5e09a40f6cb8c2a4f0f94ad3b0ad6222601fd8ac6e726804afaf3f3dd-other.xml.gz from rhel-x86_64-server-6
error was [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"

[Tue May 17 07:37:34 2011] up2date D: local action status:  ((6,), 'Fatal error in Python code occured', {})
[Tue May 17 07:37:34 2011] up2date D: rpcServer: Calling XMLRPC registration.welcome_message

Comment 2 Šimon Lukašík 2011-05-17 12:14:58 UTC
Apparently, rm -rf /var/cache/yum/* solves the issue.

Comment 4 Adrian 2011-06-03 22:10:28 UTC
this is the error I am getting on a simple install Red Hat updates

Error Type: <class 'yum.Errors.RepoError'>
Error Value: Error getting repository data for installed, repository not found
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in <module>
    main()
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3122, in main
    backend.dispatcher(sys.argv[1:])
  File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 710, in dispatcher
    self.dispatch_command(args[0], args[1:])
  File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 657, in dispatch_command
    self.update_packages(only_trusted, package_ids)
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in update_packages
    signed = self._is_package_repo_signed(pkg)
  File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in _is_package_repo_signed
    repo = self.yumbase.repos.getRepo(pkg.repoid)
  File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo
    'Error getting repository data for $s, repository not found' $ (repoid)

Comment 5 Michael Mráka 2011-08-08 12:56:22 UTC
This is not yum-rhn-plugin's fault. You can see the exactly same behaviour in yum + /etc/yum.repos.d/*.repo files. I.e.:

0. create a yum repo
1. add xxx.repo file which points to your yum repo
2. install an rpm from it
3. remove xxx.repo file (or rename to xxx.bak)
4. run yum clean all
5. put some more rpms into yum repo, run createrepo --update on it
6. add (rename) xxx.repo back again
7. yum install one_of_the_newly_added_packages

At the time of 'yum clean all' yum doesn't know about the xxx repo so the metadata remains in the cache and during subsequent 'yum install' it sees the old metadata.

Comment 6 Michael Mráka 2011-08-08 13:01:11 UTC
Re-assigning to yum component as it looks more like a yum bug.

Comment 7 James Antill 2011-08-08 14:05:26 UTC
 So from the yum POV:

1. You need to do all of the above within the repo. timeout, for this to "work". And then it'll fix itself again when the timeout expires.

2. If you use "normal" .repo files it's much more comment to change the config. to enabled=false instead of renaming the filename ... at which point it'll work anyway because yum checks the timestamp of the config. file.

3. In theory rhn-plugin could do the same thing as #2, as it would know when a repo is "new". In theory we could do this in core yum, as we could keep a list of "all the known" repos. ... that'd be a RHEL-7 feature probably though, RHEL-6 at best ... it's also not obvious it'd be easy to do the right thing for repodiff etc.

4. But, yes, in general we can only know that the server has changed by speaking across the network ... so we have a choice between always speaking across the network and always having correct information, or caching things and being wrong some of the time. You can config. metadata_expire to be 30 seconds, or 1 second or whatever ... but that seems very wrong as a default setting.

...going to move this back to rhnplugin, unless you have a suggestion for something we can do?

Comment 8 Miroslav Suchý 2011-08-08 14:19:59 UTC
I really do not think we should fix something which is not working in yum core.

I suppose something like 3) is correct, but done in yum itself. I'm strongly against fixing it in plugin.

I agree it is not RHEL6 material. Flipping to yum and RHEL7.

Comment 10 Zdeněk Pavlas 2013-06-05 12:14:36 UTC
(In reply to James Antill from comment #7)

> 3. In theory rhn-plugin could do the same thing as #2, as it would know when
> a repo is "new". In theory we could do this in core yum, as we could keep a
> list of "all the known" repos. ...

I assume yum-rhn-plugin receives a hash/timestamp of repos when registering, so it can check if the cached repomd.xml is still valid.  But that's private to the plugin, how could core yum use that?  And how's "list of all the known" repos going to help?

Comment 11 James Antill 2013-06-05 19:21:20 UTC
> But that's private to the plugin, how could core yum use that?  And how's "list of all the known" repos going to help?

What I meant is that in theory we could cache a list of all the known repos. each time yum runs (Eg. yum repolist all) ... and then if we see a repo. that was not in the previous list we do an "automatic" rm -rf on the cachedir. when we setup the repo.
But this kind of breaks optimizations in tmprepo. and repodiff and etc. (even the yum command doesn't really have the model of _the_ repos.)  ... which is why I'd moved it to the rhn plugin, it knows about it's known list of repos. and they are 100% correct for it ... so if a repo/channel appears that isn't on that list then it knows it's new.

Not even sure how much rhn plugin is used at this point though.

Comment 12 Karel Srot 2013-06-10 07:35:07 UTC
(In reply to James Antill from comment #11)
> > But that's private to the plugin, how could core yum use that?  And how's "list of all the known" repos going to help?
> 
> What I meant is that in theory we could cache a list of all the known repos.
> each time yum runs (Eg. yum repolist all) ... and then if we see a repo.
> that was not in the previous list we do an "automatic" rm -rf on the
> cachedir. when we setup the repo.

I would rather just force a test whether metadata are up to date and fetch them only when necessary. 

And what about checking the modification time of the repo file with the respective timestamps in yum cache?

Comment 13 James Antill 2013-06-19 20:17:16 UTC
> I would rather just force a test whether metadata are up to date and fetch them only when necessary. 

This requires talking over the network, which slows down most yum operations by3x-10x. However rhn-plugin can set it's metadata expire time to 0 seconds (it used to run in that type for most of RHEL-5, IIRC).

> And what about checking the modification time of the repo file with the respective timestamps in yum cache?

 This would be one of the things that could be done inside rhn-plugin, along with checking the new list of repos. vs. the stored list of repos.

 Again, there isn't much yum can do here. Moving back to the plugin.

Comment 14 Milan Zázrivec 2013-06-20 08:38:19 UTC
Both of the reproducing scenarios from initial comment were addressed
in upstream commit 75fe42bbfeba9e5d4411aea1ea8b880c57dc2fb8 which
will be available as well in RHEL-7.

Comment 15 Ludek Smid 2014-06-16 08:17:12 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


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