Re: [Spacewalk-list] Oracle -> Postgres migration woes

2016-01-14 Thread Jan Dobes 

On 17.12.2015 17:26 Funk, Alex wrote:

Greetings list!

I have a Centos 6 machine running spacewalk 2.2, with an external Oracle
database (managed by our DBA team).  I’m transitioning to two Centos 7
machines, one as an external postgres database, one as the application
server.  I was hoping to migrate the database over, upgrade it, then I
have a fallback with the original.  I got a constraint violation while
importing the data, and I assumed it was because of the version mismatch
(I initialized postgres as a spacewalk 2.4 database).  So, I upgraded my
original CentOS 6 machine to spacewalk 2.4, and followed the migration
procedure listed on the wiki
(https://fedorahosted.org/spacewalk/wiki/DatabaseMigrations).  Both when
trying to dump straight from spacewalk-dump-schema --from=oracle
--to=postgresql | psql, and when dumping to a file and using
spacewalk-sql -i on the new machine, I get “ERROR:  relation
"rhn_command_queue_sessions" does not exist”.

What am I doing wrong?

Thanks in advance!

Alex



Hello,

it seems like you found a bug in our schema upgrade scripts. This table 
should not definitely be there since Spacewalk 2.3. If you dump into a 
file and then remove all mentions of this table including copying into 
this table, it should not harm anything.


Or if you have backup of Spacewalk 2.2 Oracle database, you could try to 
upgrade to Spacewalk 2.4 again with updated package we could provide.


Regards,
--
Jan Dobes
Satellite Engineering, Red Hat

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Fedora update from 21 to 23

2016-01-14 Thread Jan Dobes 

On 13.1.2016 10:30 Angelo Gaverini wrote:

Hi,
i have spacewalk 2.1 installed from a pair of years.
I used it to update my hosts from fedora 18 -> 19 -> 20 -> 21.
Now i'm trying to update my hosts fedora from 21 to 23 but i get this error:

Error: dnf-plugin-spacewalk conflicts with
yum-rhn-plugin-2.3.3-2.fc23.noarch

My procedure is:
- subscribe my host to new Fedora23 Channel
- yum clean all
- yum distro-sync

I understand that yum is dying but i didn't find a way to make the
passage into my environment.

It can be a problem of spacewalk release?

Thanks in advance for your help,
Angelo



Hello,

yes, from Fedora 22 we use dnf plugin instead of yum plugin (and not 
supported on Fedora 23 yet). I'm not sure if you still can use yum 
plugin on Fedora >= 22 without experimenting and rebuilding packages 
with custom dependencies.


Regards,
--
Jan Dobes
Satellite Engineering, Red Hat

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] spacewalk 2.4 synch only lates packages

2016-01-14 Thread Jan Dobes 

On 13.1.2016 09:10 Harald Hackenberger wrote:

„Hello!

We`ve upgraded to spacewalk 2.4 and when i try to synch, i get the "ERROR:

'NoneType' object has no attribute 'group'".

I want to try the new attribute "-n" to only synch the latest packages.

BR

Harald“




Hello,

syncing without the '-n' parameter works? Is it failing for all 
repositories?


Regards,
--
Jan Dobes
Satellite Engineering, Red Hat

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Antwort: Re: Errata Cache bunch running forever on Spacewalk 2.4

2016-01-14 Thread Robert Paschedag 
Hello Jan,

I don't see anything useful, if debug logging is disabled in taskomatic.

Also when debugging is disabled, the only thing I see, is, that some 
errata-cache tasks are "SKIPPED". I also enabled all logging of SQL statements 
in postgres but - IMHO - everything looks " good".

I already started the whole server, restarted taskomatic, restarted 
spacewalk-service. Nothing seems to help.
I'm not sure, if sometimes the threads are colliding, so I wanted to set the 
number of workers to 1 for some time.

On my test system, everything looks good. But there are only about 10 systems 
registered, so I can't tell, if this "might" be some kind of performance 
problem.

Regards
Robert
Am 14.01.2016 3:52 nachm. schrieb Jan Dobes :
>
> On 12.1.2016 09:08 paschedag.netlut...@swr.de wrote: 
> > Hello again, 
> > 
> > still having problems, 
> > 
> > I noticed that the errata-cache gets triggerd when a client refreshes 
> > its repos or searches for updates. So I manually fired a "zypper ref -s" 
> > or a "apt-get update" on every client connected to this spacewalk 
> > server. This seems to have fixed "something". Suddenly, the 
> > "errata-cache" task has finished and I got some backtraces from spacewalk. 
> > 
> > But I still have trouble. The UI does not seem to get updated correctly 
> > (on the "system" page, nearly all systems look "up-to-date". But I know, 
> > it's not!). But the updates are available to the clients (searching on 
> > the client). 
> > 
> > When I look into the last errata-cache schedules (in Spacewalk "Admin" 
> > -> "Task schedules" -> "errata-cache-bunch") I can see, that the 
> > "errata-cache" tasks is often "SKIPPED" 
> > 
> > errata-cache _2016-01-12 08:50:00 MEZ _ 
> >  
> > 2016-01-12 08:50:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:49:00 MEZ _ 
> >  
> > 2016-01-12 08:49:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:48:00 MEZ _ 
> >  
> > 2016-01-12 08:48:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:47:00 MEZ _ 
> >  
> > 2016-01-12 08:50:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:46:00 MEZ _ 
> >  
> > 2016-01-12 08:46:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:45:00 MEZ _ 
> >  
> > 2016-01-12 08:45:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:44:00 MEZ _ 
> >  
> > 2016-01-12 08:46:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:43:00 MEZ _ 
> >  
> > 2016-01-12 08:43:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:43:00 MEZ _ 
> >  
> > 2016-01-12 08:43:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:42:00 MEZ _ 
> >  
> > 2016-01-12 08:42:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:41:00 MEZ _ 
> >  
> > 2016-01-12 08:41:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:40:00 MEZ _ 
> >  
> > 2016-01-12 08:40:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:39:00 MEZ _ 
> >  
> > 2016-01-12 08:42:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:38:00 MEZ _ 
> >  
> > 2016-01-12 08:38:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:38:00 MEZ _ 
> >  
> > 2016-01-12 08:38:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:37:00 MEZ _ 
> >  
> > 2016-01-12 08:37:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:37:00 MEZ _ 
> >  
> > 2016-01-12 08:37:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:36:00 MEZ _ 
> >  
> > 2016-01-12 08:36:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:35:00 MEZ _ 
> >  
> > 2016-01-12 08:35:00 MEZ SKIPPED 
> > errata-cache _2016-01-12 08:34:00 MEZ _ 
> >  
> > 2016-01-12 08:36:00 MEZ FINISHED 
> > errata-mailer _2016-01-12 08:33:00 MEZ _ 
> >  
> > 2016-01-12 08:33:00 MEZ FINISHED 
> > errata-cache _2016-01-12 08:33:00 MEZ _ 
> >

Re: [Spacewalk-list] Some CentOS/EL6 Packages show up for EL7, and some EL7 for EL6

2016-01-14 Thread prmarino1 
Try restarting taskomatic it sounds like the reposync bunch may have gotten 
frozen
If that helps then you may need to increase the ram limit for taskomatic

  Original Message  
From: Ricky Boone
Sent: Thursday, January 14, 2016 15:13
To: spacewalk-list@redhat.com
Reply To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Some CentOS/EL6 Packages show up for EL7, and 
some EL7 for EL6

Here's another example of it happening. I'm still not sure what's
causing it. This time it is with the ldb update from a few days ago.

Additionally, I will say that I am using the errata-import.pl script
from the "CEFS: CentOS Errata for Spacewalk" site
(http://cefs.steve-meier.de/). It is currently at version 20150630,
which isn't the most recent one, but it didn't look like there were
any updates that jumped out as relevant to this, and I didn't think
that it would be modifying which packages were linked to different
repositories. I can update it to the latest version, and if
necessary, temporarily disable the cron job to try to rule it out if
it is suspected to be the problem.

Here are some screenshots if anyone is interested.

libldb i686 and x86_64 EL7 packages, linked to EL6:
http://i.imgur.com/vmwaLqb.png
http://i.imgur.com/3Wtkmw2.png

Affected system details page (happens to be the Spacewalk server this time):
http://i.imgur.com/wz4yZ8l.png

Affected system package updates: http://i.imgur.com/Ihp83hx.png

Errata details: http://i.imgur.com/xrlVLl7.png

Errata packages: http://i.imgur.com/CTFB6zV.png

Packages in centos6-x86_64-updates matching "el7":
http://i.imgur.com/R2cd8RB.png

Packages in centos6-i686-updates matching "el7":
http://i.imgur.com/cF4IxnB.png

Packages in centos7-x86_64-updates matching "el6":
http://i.imgur.com/waob4vy.png


On Thu, Dec 31, 2015 at 5:38 PM, Ricky Boone  wrote:
> Adding further to the mystery...
>
> When I look at the logs under /var/log/rhn/reposync, I don't see any
> mention of el7 in centos6-x86_64-updates.log, or el6 in
> centos7-x86_64-updates.log. Strange...
>
> I've removed the el7 packages from CentOS 6 Updates, and visa versa,
> but yum update still marks the offending packages as available (even
> after yum clean all). I'm sure I'm missing a step, but I'll dig
> around some more.
>
> On Thu, Dec 31, 2015 at 4:55 PM, Ricky Boone  wrote:
>> My apologies for starting a new thread... there appears to be an
>> existing thread going on here, but I just subbed to this list, so I
>> can't reply to it yet.
>>
>> https://www.redhat.com/archives/spacewalk-list/2015-December/msg00024.html
>>
>> I think I see similar behavior with my system. The issue was prompted
>> by a coworker that noticed some odd yum errors when he was trying to
>> update one of his systems. When I looked into it, the update was
>> trying to install EL7 packages on his EL6 system.
>>
>> The Spacewalk server is running version 2.3, on CentOS 6.7, but has
>> been upgraded from Spacewalk 2.2. All of the repositories were
>> created by spacewalk-common-channels while on 2.2. All of the
>> repositories are one-to-one with their respective channel (CentOS 7
>> Updates x86_64, etc.), with no repositories being linked to other
>> channels.
>>
>> When I search for el6 under Packages in the "CentOS 7 Updates
>> (x86_64)" channel, there are currently 142 matches, ranging from
>> autocorr-af-4.2.8.2-11.el6_7.1:1.noarch to
>> openssl-static-1.0.1e-42.el6_7.1.x86_64. Alternatively, when I search
>> for el7 in "CentOS 6 Updates (x86_64)", there are 134 matches. I have
>> not checked all channels yet.
>>
>> My suspicion is that there was something going on with the
>> mirrorlist.centos.org site, sending requests for one release to the
>> other, or that one of the mirrors had the wrong release listed for the
>> wrong URL, etc. I can't prove this, but that's all I can think of at
>> the moment. When I manually browse some of the sites returned, they
>> look okay.
>>
>> I'm going to try removing the offending packages and manually running
>> a sync... and do a couple spot checks to be sure that none of them
>> somehow ended up on the wrong platforms.
>>
>> Any thoughts would be appreciated.

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Some CentOS/EL6 Packages show up for EL7, and some EL7 for EL6

2016-01-14 Thread Ricky Boone 
The symptoms for this KB page
(https://access.redhat.com/solutions/43122) don't seem to completely
line up with what I'm seeing, but I'll give it a shot.  The VM that
I'm running this on has a good amount of RAM available, and I do see
Taskomatic become unresponsive from time to time (not syncing, etc.).
Not sure why running out of heap space would cause it to link a
package to the wrong channel, though.  This is bizarre.

On Thu, Jan 14, 2016 at 3:24 PM,   wrote:
> Try restarting taskomatic it sounds like the reposync bunch may have gotten 
> frozen
> If that helps then you may need to increase the ram limit for taskomatic
>
>   Original Message
> From: Ricky Boone
> Sent: Thursday, January 14, 2016 15:13
> To: spacewalk-list@redhat.com
> Reply To: spacewalk-list@redhat.com
> Subject: Re: [Spacewalk-list] Some CentOS/EL6 Packages show up for EL7, and 
> some EL7 for EL6
>
> Here's another example of it happening. I'm still not sure what's
> causing it. This time it is with the ldb update from a few days ago.
>
> Additionally, I will say that I am using the errata-import.pl script
> from the "CEFS: CentOS Errata for Spacewalk" site
> (http://cefs.steve-meier.de/). It is currently at version 20150630,
> which isn't the most recent one, but it didn't look like there were
> any updates that jumped out as relevant to this, and I didn't think
> that it would be modifying which packages were linked to different
> repositories. I can update it to the latest version, and if
> necessary, temporarily disable the cron job to try to rule it out if
> it is suspected to be the problem.
>
> Here are some screenshots if anyone is interested.
>
> libldb i686 and x86_64 EL7 packages, linked to EL6:
> http://i.imgur.com/vmwaLqb.png
> http://i.imgur.com/3Wtkmw2.png
>
> Affected system details page (happens to be the Spacewalk server this time):
> http://i.imgur.com/wz4yZ8l.png
>
> Affected system package updates: http://i.imgur.com/Ihp83hx.png
>
> Errata details: http://i.imgur.com/xrlVLl7.png
>
> Errata packages: http://i.imgur.com/CTFB6zV.png
>
> Packages in centos6-x86_64-updates matching "el7":
> http://i.imgur.com/R2cd8RB.png
>
> Packages in centos6-i686-updates matching "el7":
> http://i.imgur.com/cF4IxnB.png
>
> Packages in centos7-x86_64-updates matching "el6":
> http://i.imgur.com/waob4vy.png
>
>
> On Thu, Dec 31, 2015 at 5:38 PM, Ricky Boone  wrote:
>> Adding further to the mystery...
>>
>> When I look at the logs under /var/log/rhn/reposync, I don't see any
>> mention of el7 in centos6-x86_64-updates.log, or el6 in
>> centos7-x86_64-updates.log. Strange...
>>
>> I've removed the el7 packages from CentOS 6 Updates, and visa versa,
>> but yum update still marks the offending packages as available (even
>> after yum clean all). I'm sure I'm missing a step, but I'll dig
>> around some more.
>>
>> On Thu, Dec 31, 2015 at 4:55 PM, Ricky Boone  wrote:
>>> My apologies for starting a new thread... there appears to be an
>>> existing thread going on here, but I just subbed to this list, so I
>>> can't reply to it yet.
>>>
>>> https://www.redhat.com/archives/spacewalk-list/2015-December/msg00024.html
>>>
>>> I think I see similar behavior with my system. The issue was prompted
>>> by a coworker that noticed some odd yum errors when he was trying to
>>> update one of his systems. When I looked into it, the update was
>>> trying to install EL7 packages on his EL6 system.
>>>
>>> The Spacewalk server is running version 2.3, on CentOS 6.7, but has
>>> been upgraded from Spacewalk 2.2. All of the repositories were
>>> created by spacewalk-common-channels while on 2.2. All of the
>>> repositories are one-to-one with their respective channel (CentOS 7
>>> Updates x86_64, etc.), with no repositories being linked to other
>>> channels.
>>>
>>> When I search for el6 under Packages in the "CentOS 7 Updates
>>> (x86_64)" channel, there are currently 142 matches, ranging from
>>> autocorr-af-4.2.8.2-11.el6_7.1:1.noarch to
>>> openssl-static-1.0.1e-42.el6_7.1.x86_64. Alternatively, when I search
>>> for el7 in "CentOS 6 Updates (x86_64)", there are 134 matches. I have
>>> not checked all channels yet.
>>>
>>> My suspicion is that there was something going on with the
>>> mirrorlist.centos.org site, sending requests for one release to the
>>> other, or that one of the mirrors had the wrong release listed for the
>>> wrong URL, etc. I can't prove this, but that's all I can think of at
>>> the moment. When I manually browse some of the sites returned, they
>>> look okay.
>>>
>>> I'm going to try removing the offending packages and manually running
>>> a sync... and do a couple spot checks to be sure that none of them
>>> somehow ended up on the wrong platforms.
>>>
>>> Any thoughts would be appreciated.
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>

Re: [Spacewalk-list] Some CentOS/EL6 Packages show up for EL7, and some EL7 for EL6

2016-01-14 Thread Ricky Boone 
Here's another example of it happening.  I'm still not sure what's
causing it.  This time it is with the ldb update from a few days ago.

Additionally, I will say that I am using the errata-import.pl script
from the "CEFS: CentOS Errata for Spacewalk" site
(http://cefs.steve-meier.de/).  It is currently at version 20150630,
which isn't the most recent one, but it didn't look like there were
any updates that jumped out as relevant to this, and I didn't think
that it would be modifying which packages were linked to different
repositories.  I can update it to the latest version, and if
necessary, temporarily disable the cron job to try to rule it out if
it is suspected to be the problem.

Here are some screenshots if anyone is interested.

libldb i686 and x86_64 EL7 packages, linked to EL6:
http://i.imgur.com/vmwaLqb.png
http://i.imgur.com/3Wtkmw2.png

Affected system details page (happens to be the Spacewalk server this time):
http://i.imgur.com/wz4yZ8l.png

Affected system package updates: http://i.imgur.com/Ihp83hx.png

Errata details: http://i.imgur.com/xrlVLl7.png

Errata packages: http://i.imgur.com/CTFB6zV.png

Packages in centos6-x86_64-updates matching "el7":
http://i.imgur.com/R2cd8RB.png

Packages in centos6-i686-updates matching "el7":
http://i.imgur.com/cF4IxnB.png

Packages in centos7-x86_64-updates matching "el6":
http://i.imgur.com/waob4vy.png


On Thu, Dec 31, 2015 at 5:38 PM, Ricky Boone  wrote:
> Adding further to the mystery...
>
> When I look at the logs under /var/log/rhn/reposync, I don't see any
> mention of el7 in centos6-x86_64-updates.log, or el6 in
> centos7-x86_64-updates.log.  Strange...
>
> I've removed the el7 packages from CentOS 6 Updates, and visa versa,
> but yum update still marks the offending packages as available (even
> after yum clean all).  I'm sure I'm missing a step, but I'll dig
> around some more.
>
> On Thu, Dec 31, 2015 at 4:55 PM, Ricky Boone  wrote:
>> My apologies for starting a new thread... there appears to be an
>> existing thread going on here, but I just subbed to this list, so I
>> can't reply to it yet.
>>
>> https://www.redhat.com/archives/spacewalk-list/2015-December/msg00024.html
>>
>> I think I see similar behavior with my system.  The issue was prompted
>> by a coworker that noticed some odd yum errors when he was trying to
>> update one of his systems.  When I looked into it, the update was
>> trying to install EL7 packages on his EL6 system.
>>
>> The Spacewalk server is running version 2.3, on CentOS 6.7, but has
>> been upgraded from Spacewalk 2.2.  All of the repositories were
>> created by spacewalk-common-channels while on 2.2.  All of the
>> repositories are one-to-one with their respective channel (CentOS 7
>> Updates x86_64, etc.), with no repositories being linked to other
>> channels.
>>
>> When I search for el6 under Packages in the "CentOS 7 Updates
>> (x86_64)" channel, there are currently 142 matches, ranging from
>> autocorr-af-4.2.8.2-11.el6_7.1:1.noarch to
>> openssl-static-1.0.1e-42.el6_7.1.x86_64.  Alternatively, when I search
>> for el7 in "CentOS 6 Updates (x86_64)", there are 134 matches.  I have
>> not checked all channels yet.
>>
>> My suspicion is that there was something going on with the
>> mirrorlist.centos.org site, sending requests for one release to the
>> other, or that one of the mirrors had the wrong release listed for the
>> wrong URL, etc.  I can't prove this, but that's all I can think of at
>> the moment.  When I manually browse some of the sites returned, they
>> look okay.
>>
>> I'm going to try removing the offending packages and manually running
>> a sync... and do a couple spot checks to be sure that none of them
>> somehow ended up on the wrong platforms.
>>
>> Any thoughts would be appreciated.

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Missing group (comps.xml) information with Fedora 22

2016-01-14 Thread Jan Dobes 

On 11.1.2016 21:53 Brian Buesker wrote:

I recently upgraded our spacewalk server to version 2.4 since that
version officially supports Fedora 22. I had previously created a Fedora
22 distribution (when my spacewalk server was still running 2.3) and
created a channel that I synced with the Fedora 22 Everything
repository. This sync indicated it was able to fetch the comps file.

Linking packages to channel.
Repo
http://mirror.pnl.gov/fedora/linux/releases/22/Everything/x86_64/os/
has comps file

1b6e2afe599e5969f9c6e50bad1bf85e2ab23929500e08a4d006330da602fdc4-comps-f22.xml.xz.
Repo
http://mirror.pnl.gov/fedora/linux/releases/22/Everything/x86_64/os/
has 0 errata.
Sync completed.
Total time: 1 day, 11:32:17

I also confirmed that this the comps file is present on the file system
as well as in the database.

When I went to install a machine, I found that both during kickstart and
during normal operation that the group information (provided by
comps.xml) does not seem to be available. During kickstart, I saw the
xz-compressed comps.xml file in the dnf cache directory (but not the
uncompressed one), but still received an error for each package group my
kickstart file specified.

After kickstart, I found that neither the compressed nor uncompressed
files were present in the dnf cache directory. All dnf groupinstall
operations fail with no such group and a dnf grouplist indicates there
is no group data available in the repositories.

After poking around in the dnf and librepo code, I think I may have a
clue as to why this is happening. The dnf python code is constructing a
librepo Handle that sets the file whitelist to only include the
compressed form of the groups ("groups_gz"). See how yumdlist gets
initialized in the repo module within dnf. Since it appears the
repomd.xml provided by Spacewalk only includes the uncompressed groups
file, librepo never ends up downloading the groups file and thus it is
not available for dnf operations.

At this point I think I'll be able to work around this by a combination
of a pre-nochroot script that updates this variable to include "group"
and then a patched dnf RPM that fixes this. With that said, are there
any plans in a future Spacewalk version to fix it so that it includes
both the group and group_gz types?

Thanks,
Brian



Hello,

thank you for investigating that. It makes sense to me to fix it.

Regards,
--
Jan Dobes
Satellite Engineering, Red Hat

___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Antwort: Re: Errata Cache bunch running forever on Spacewalk 2.4

2016-01-14 Thread Jan Dobes 

On 12.1.2016 09:08 paschedag.netlut...@swr.de wrote:

Hello again,

still having problems,

I noticed that the errata-cache gets triggerd when a client refreshes
its repos or searches for updates. So I manually fired a "zypper ref -s"
or a "apt-get update" on every client connected to this spacewalk
server. This seems to have fixed "something". Suddenly, the
"errata-cache" task has finished and I got some backtraces from spacewalk.

But I still have trouble. The UI does not seem to get updated correctly
(on the "system" page, nearly all systems look "up-to-date". But I know,
it's not!). But the updates are available to the clients (searching on
the client).

When I look into the last errata-cache schedules (in Spacewalk "Admin"
-> "Task schedules" -> "errata-cache-bunch") I can see, that the
"errata-cache" tasks is often "SKIPPED"

errata-cache_2016-01-12 08:50:00 MEZ _

2016-01-12 08:50:00 MEZ SKIPPED
errata-cache_2016-01-12 08:49:00 MEZ _

2016-01-12 08:49:00 MEZ SKIPPED
errata-cache_2016-01-12 08:48:00 MEZ _

2016-01-12 08:48:00 MEZ SKIPPED
errata-cache_2016-01-12 08:47:00 MEZ _

2016-01-12 08:50:00 MEZ FINISHED
errata-cache_2016-01-12 08:46:00 MEZ _

2016-01-12 08:46:00 MEZ SKIPPED
errata-cache_2016-01-12 08:45:00 MEZ _

2016-01-12 08:45:00 MEZ SKIPPED
errata-cache_2016-01-12 08:44:00 MEZ _

2016-01-12 08:46:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:43:00 MEZ _

2016-01-12 08:43:00 MEZ FINISHED
errata-cache_2016-01-12 08:43:00 MEZ _

2016-01-12 08:43:00 MEZ FINISHED
errata-cache_2016-01-12 08:42:00 MEZ _

2016-01-12 08:42:00 MEZ SKIPPED
errata-cache_2016-01-12 08:41:00 MEZ _

2016-01-12 08:41:00 MEZ SKIPPED
errata-cache_2016-01-12 08:40:00 MEZ _

2016-01-12 08:40:00 MEZ SKIPPED
errata-cache_2016-01-12 08:39:00 MEZ _

2016-01-12 08:42:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:38:00 MEZ _

2016-01-12 08:38:00 MEZ FINISHED
errata-cache_2016-01-12 08:38:00 MEZ _

2016-01-12 08:38:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:37:00 MEZ _

2016-01-12 08:37:00 MEZ FINISHED
errata-cache_2016-01-12 08:37:00 MEZ _

2016-01-12 08:37:00 MEZ FINISHED
errata-cache_2016-01-12 08:36:00 MEZ _

2016-01-12 08:36:00 MEZ SKIPPED
errata-cache_2016-01-12 08:35:00 MEZ _

2016-01-12 08:35:00 MEZ SKIPPED
errata-cache_2016-01-12 08:34:00 MEZ _

2016-01-12 08:36:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:33:00 MEZ _

2016-01-12 08:33:00 MEZ FINISHED
errata-cache_2016-01-12 08:33:00 MEZ _

2016-01-12 08:33:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:32:00 MEZ _

2016-01-12 08:32:00 MEZ FINISHED
errata-cache_2016-01-12 08:32:00 MEZ _

2016-01-12 08:32:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:31:00 MEZ _

2016-01-12 08:31:00 MEZ FINISHED
errata-cache_2016-01-12 08:31:00 MEZ _

2016-01-12 08:31:00 MEZ FINISHED
errata-mailer   _2016-01-12 08:30:00 MEZ _

2016-01-12 08:30:00 MEZ FINISHED
errata-cache_2016-01-12 08:30:00 MEZ _