[Spacewalk-list] Re: Concern over upgrades not showing...

James Hogarth james.hogarth at gmail.com
Tue Dec 8 01:35:27 UTC 2009


Hmm... doesn't sound like it is quite representative of the issue I am
seeing - unless the underlying causes are similar.

I have no upstream RHN server so there are no errata. The packages are
pulled from a spacewalk-repo-sync cron job ... or pushed via rhnpush.

If there is a new package via rhnpush or repo-sync (seen both ways) although
the spacewalk server will show that new package exists in the details for
that package name in the relevant channel no systems will show the update
available until a rhn-profile-sync is done.

At this point I'm considering just doing a daily rhn-profile-sync from cron
(along with a daily service osad restart to deal with an osad ->
osa-dispatcher connection issue someone else mentioned on these lists) to
ensure that the systems show the updates avaliable... at least for something
I've just rhnpushed for immediate install somewhere will still be seen on
the client during a yum update...

James

2009/12/7 Colin Coe <colin.coe at gmail.com>

> Hi
>
> If I'm reading your description correctly, this problem has existed since
> about Satellite 5.1 and I logged a service request regarding this at my
> previous contract.  The problem is that you have some Satellite/Spacewalk
> clients with outstanding errata, after a few days the Satellite/Spacewalk
> server 'forgets' about them and they don't show up again until you run
> 'rhn-profile-sync' (RHEL5) or 'up2date -p' (RHEL3/4).
>
> I can no longer log in to the RHN account belonging to my previous employer
> so I can't provide the SR number.
>
> CC
>
>
> On 12/7/09, James Hogarth <james.hogarth at gmail.com> wrote:
>
>> Further to the below last week.
>>
>> The backend system is upgraded to 0.7 and the new client tools repo has
>> been imported as a child channel. None of the systems are showing the new
>> client tools as available upgrades even after yum makecache and rhn_check is
>> run.
>>
>> yum list upgrades shows the packages as valid upgrade packages if run
>> locally on the host and after running rhn-profile-sync the spacewalk server
>> then shows the packages as possible upgrades for the hosts.
>>
>> The result of this is that the spacewalk systems overview is out of date
>> with regards to any packages that have updates available.
>>
>> Is the server meant to determine available updates from the database or
>> the client informing it?
>>
>> Right now I'm not sure what the correct behaviour is meant to be when an
>> updated packages is pushed/sync'd into the channels.
>>
>> James
>>
>> 2009/12/4 James Hogarth <james.hogarth at gmail.com>
>>
>> Hi,
>>>
>>> The spacewalk 0.6 server on Centos 5.4 I have is using a scheduled cron
>>> job to run spacewalk-repo-sync to import a variety of upstream repositories
>>> into various channels. That appears to be running fine and I can see
>>> packages being imported and see them in the required channels afterwards.
>>>
>>> However this morning I noticed something a little odd.....
>>>
>>> The spacewalk server itself reported that there was a new cups and
>>> cups-lib package available for it - considering I have the cups service
>>> disabled I wasn't concerned initially. It was only when looking into the
>>> other systems that are subscribed to my spacewalk instance that I realised
>>> the package should apply to most of them and yet only the spacewalk server
>>> itself showed any packages out of date.
>>>
>>>
>>> Comparing a system built a couple of weeks ago to one built yesterday
>>> shows
>>>
>>>
>>> Package This System system2 Difference   cups 1.3.7-11.el5_4.3:1.x86_64 1.3.7-11.el5_4.4:1.x86_64
>>> system2 newer   cups-libs 1.3.7-11.el5_4.3:1.i386
>>> This system only   cups-libs
>>> 1.3.7-11.el5_4.4:1.x86_64 system2 only   cups-libs 1.3.7-11.el5_4.3:1.x86_64
>>>
>>> This system only   cups-libs
>>> 1.3.7-11.el5_4.4:1.i386 system2 only
>>>
>>> However spacewalk shows no updates for 'this system' even though the
>>> relevant packages if checked in the channel show 4.4 as a newer version of
>>> 4.3 and yum list updates on the system shows 4.4 as an update to 4.3.
>>>
>>> If the newest package is chosen in the channel listing the older system
>>> is showing as a valid target in target systems for deployment.
>>>
>>> Both servers were built with the same kickstarts with the same activation
>>> key and have the same channel subscriptions.
>>>
>>> Any ideas?
>>>
>>> James
>>>
>>
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>
>
>
> --
> RHCE#805007969328369
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20091208/99c4bb2a/attachment.htm>


More information about the Spacewalk-list mailing list