[Spacewalk-list] Updates not installing since Centos 8.1 - possible module issues.

[Simon Avery]

Hello. I've checked the recent archives and cannot find mention of this issue, 
and tried the irc channel last night where another user confirmed they had also 
encountered this. If it has been discussed already, please direct me 
accordingly.

Since the Centos repos were updated to symlink /8 to the new /8.1, Spacewalk 
managed updates are failing consistently on all our Centos 8.x machines.

My research suggests that this is because Spacewalk is not handling modules 
when populating its repos. This causes downstream updates to fail.

My questions are:

1) Am I right in my conclusions?

2) If so, will Spacewalk be updated to correctly handle Centos 8.1+ modules?


Thanks



Background:

  *   Spacewalk 2.9 running on Centos 7 and managing 139 Centos machines; 6.10, 
7 and a dozen or so 8.x   Each client runs the spacewalk-2.9-client suite.
  *   All our systems (including Centos 8.0) were behaving as expected.
  *   I have not knowingly installed a module, but it seems their use is 
largely transparent now.

Problem:
When running a package update through Spacewalk, or running dnf update from the 
client locally, the dnf/yum process fails. (Full logs below)

/var/log/messages
messages:Jan 20 05:02:34  server: WARNING: 
redstone.xmlrpc.XmlRpcFault: At least one of the channels this system is 
subscribed to contains modules. If you have activated modules on this system, 
please refrain from using Spacewalk for package operations. Instead, perform 
all package actions from the client using dnf.


On an example centos 8 machine;

[root@machine01 yum.repos.d] # cat /etc/centos-release
CentOS Linux release 8.1.1911 (Core)

When: Not subscribed to any channels in Spacewalk and using local repos only.

[root@machine01 scripts] # dnf update
This system is not subscribed to any channels.
Red Hat Satellite or Spacewalk channel support will be disabled.
CentOS-8 - AppStream

   20 kB/s | 4.3 kB 00:00
CentOS-8 - Base 

  9.0 kB/s | 3.8 kB 00:00
CentOS-8 - Extras   

  4.0 kB/s | 1.5 kB 00:00
Spacewalk_Client repo   

  6.5 kB/s | 3.6 kB 00:00
Extra Packages for Enterprise Linux Modular 8 - x86_64  

   59 kB/s |  30 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64  

   66 kB/s |  32 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!

If I then subscribe this system to the Centos8 Base Channel on Spacewalk which 
contains the single repo: http://mirror.centos.org/centos/8/BaseOS/x86_64/os/ 
and make no other changes;

[root@machine01 scripts] # dnf update
This system is receiving updates from Red Hat Satellite or Spacewalk server.
CentOS8 Updates 

   57 kB/s | 1.4 kB 00:00
CentOS8 Updates 

   97 MB/s |  34 MB 00:00
Last metadata expiration check: 0:00:10 ago on Wed 29 Jan 2020 12:25:16 PM GMT.
Error:
Problem 1: cannot install both 
perl-libs-4:5.24.4-398.module_el8.0.0+50+c3b345cd.x86_64 and 
perl-libs-4:5.26.3-416.el8.x86_64
  - package perl-Algorithm-Diff-1.1903-9.module_el8.0.0+50+c3b345cd.noarch 
requires perl(:MODULE_COMPAT_5.24.4), but none of the providers can be installed
  - cannot install the best update candidate for package 
perl-libs-4:5.26.3-416.el8.x86_64
  - cannot install the best update candidate for package 
perl-Algorithm-Diff-1.1903-9.el8.noarch
  - package perl-libs-4:5.24.4-404.module_el8.1.0+229+cd132df8.x86_64 is 
excluded
Problem 2: package perl-interpreter-4:5.26.3-416.el8.x86_64 requires 
libperl.so.5.26()(64bit), but none of the providers can be installed
  - package perl-interpreter-4:5.26.3-416.el8.x86_64 requires perl-libs(x86-64) 
= 4:5.26.3-416.el8, but none of the providers can be installed
  - cannot install both 
perl-libs-4:5.24.4-398.module

Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: Updates not installing since Centos 8.1 - possible module issues.

[Simon Avery]

Thanks for your suggestion, Steve, and the link to the bug report.  Sadly that 
report is over a year old so it seems the packaging problem there seems not to 
have been fixed, and if dnf is happy I can understand why it may not be seen as 
a priority to them.

I've tried your suggestion on two machines this morning with mixed results.

Machine 1 - a very low function machine doing not much at all.
Perl was not installed, but "yum update" via spwk's repo was still failing with 
a different message;

Modular dependency problems:

Problem 1: conflicting requests
  - nothing provides module(perl:5.26) needed by module 
perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64
Problem 2: conflicting requests
  - nothing provides module(perl:5.26) needed by module 
perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64

I was able to resolve this one with: yum module reset perl-DBI perl-DBD-MySQL

Then the machine was happy to receive updates through Spacewalk managed repos.  
This seems to prove the issue is currently with the perl-interpreter 
module/package, but that other modules cause different problems via spacewalk.

Machine 2:
This is a fairly busy machine with a lot of stuff installed.

I removed perl (and obviously that took away a lot of the stuff that was 
running, including mariadb, samba-client and a bunch o' stuff.

Yum update from Spacewalk then returned clean.

I switched off spacewalk repos and yum update from main repos was also clean.

I then reinstalled the removed packages and some manual libs, and this 
completed without error. (I repeated this step with and without spacewalk's 
repos)

Then the next yum update, the long list of errors returned as reported in my 
previous email.

yum list perl-interpreter
This system is receiving updates from Red Hat Satellite or Spacewalk server.
Last metadata expiration check: 0:00:16 ago on Thu 30 Jan 2020 08:27:47 AM GMT.
Installed Packages
perl-interpreter.x86_64 
 4:5.26.3-416.el8   
   @BaseOS

So even if I get beyond the troublesome 5.24 release of perl-interpreter, 
either from the main repos or via spacewalk, the issue persists.

Thanks for your thoughts anyway.

Simon


From: spacewalk-list-boun...@redhat.com  On 
Behalf Of li...@alderfamily.org
Sent: 29 January 2020 23:10
To: spacewalk-list@redhat.com
Subject: [EXTERNAL EMAIL] Re: [Spacewalk-list] Updates not installing since 
Centos 8.1 - possible module issues.

https://bugzilla.redhat.com/show_bug.cgi?id=1670435

The best solutions I came up with are to point the clients to another repo 
temporarily, or to remove perl (along with whatever required it, in my case 
logwatch) then update and reinstall the packages.  Either way you need to get 
beyond v5.24 of the perl-interpreter package.

The basis of the problem is spelled out in the Bugzilla.  But yes, the use of 
modules is near unavoidable at this point.

Good luck.


From: 
spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com> 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of Simon Avery
Sent: Wednesday, January 29, 2020 7:46
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [Spacewalk-list] Updates not installing since Centos 8.1 - possible 
module issues.

Hello. I've checked the recent archives and cannot find mention of this issue, 
and tried the irc channel last night where another user confirmed they had also 
encountered this. If it has been discussed already, please direct me 
accordingly.

Since the Centos repos were updated to symlink /8 to the new /8.1, Spacewalk 
managed updates are failing consistently on all our Centos 8.x machines.

My research suggests that this is because Spacewalk is not handling modules 
when populating its repos. This causes downstream updates to fail.

My questions are:

1) Am I right in my conclusions?

2) If so, will Spacewalk be updated to correctly handle Centos 8.1+ modules?


Thanks



Background:

  *   Spacewalk 2.9 running on Centos 7 and managing 139 Centos machines; 6.10, 
7 and a dozen or so 8.x   Each client runs the spacewalk-2.9-client suite.
  *   All our systems (including Centos 8.0) were behaving as expected.
  *   I have not knowingly installed a module, but it seems their use is 
largely transparent now.

Problem:
When running a package update through Spacewalk, or running dnf update from the 
client locally, the dnf/yum process fails. (Full logs below)

/var/log/messages
messages:Jan 20 05:02:34  server: WARNING: 
redstone.xmlrpc.XmlRpcFault: At least one of the channels this system is 
subscribed to contains modules. If you have activated modules on this system, 
please refrain from using Spacewalk for package operations. Instead, perform 
all package actions from the client using dnf.


On an example 

Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: Updates not installing since Centos 8.1 - possible module issues.

[Simon Avery]

As a follow up, and thanks to Sigurður offlist for some thoughts, we seem to 
have a working solution;


If we create new Spwk channels that use the 8.1 Repos ( 
http://mirror.centos.org/centos/8.1.1911/BaseOS/x86_64/os/   and the equivalent 
appstream) and then move machines onto that, then they... just work.

I don't pretend to know why pointing to the /8/ repos (which are symlinked to 
the same one above) doesn't work and this does, but there you go.

This seems like a working solution for us, although it does pros and cons 
besides having to create a new channel and repos.

Cons: We have to manually migrate machines between point releases.

Pros: We have to manually migrate machines between point releases.  (And can so 
test the new point releases in a more controlled way)

I can't say whether this will work for others or if it will work against future 
changes, but it seems to be working for us this morning on a few 8.1 machines.

S


From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Simon Avery
Sent: 30 January 2020 08:35
To: st...@alderfamily.org; spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: Updates not installing since 
Centos 8.1 - possible module issues.

Thanks for your suggestion, Steve, and the link to the bug report.  Sadly that 
report is over a year old so it seems the packaging problem there seems not to 
have been fixed, and if dnf is happy I can understand why it may not be seen as 
a priority to them.

I've tried your suggestion on two machines this morning with mixed results.

Machine 1 - a very low function machine doing not much at all.
Perl was not installed, but "yum update" via spwk's repo was still failing with 
a different message;

Modular dependency problems:

Problem 1: conflicting requests
  - nothing provides module(perl:5.26) needed by module 
perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64
Problem 2: conflicting requests
  - nothing provides module(perl:5.26) needed by module 
perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64

I was able to resolve this one with: yum module reset perl-DBI perl-DBD-MySQL

Then the machine was happy to receive updates through Spacewalk managed repos.  
This seems to prove the issue is currently with the perl-interpreter 
module/package, but that other modules cause different problems via spacewalk.

Machine 2:
This is a fairly busy machine with a lot of stuff installed.

I removed perl (and obviously that took away a lot of the stuff that was 
running, including mariadb, samba-client and a bunch o' stuff.

Yum update from Spacewalk then returned clean.

I switched off spacewalk repos and yum update from main repos was also clean.

I then reinstalled the removed packages and some manual libs, and this 
completed without error. (I repeated this step with and without spacewalk's 
repos)

Then the next yum update, the long list of errors returned as reported in my 
previous email.

yum list perl-interpreter
This system is receiving updates from Red Hat Satellite or Spacewalk server.
Last metadata expiration check: 0:00:16 ago on Thu 30 Jan 2020 08:27:47 AM GMT.
Installed Packages
perl-interpreter.x86_64 
 4:5.26.3-416.el8   
   @BaseOS

So even if I get beyond the troublesome 5.24 release of perl-interpreter, 
either from the main repos or via spacewalk, the issue persists.

Thanks for your thoughts anyway.

Simon


From: 
spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com> 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of li...@alderfamily.org<mailto:li...@alderfamily.org>
Sent: 29 January 2020 23:10
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [EXTERNAL EMAIL] Re: [Spacewalk-list] Updates not installing since 
Centos 8.1 - possible module issues.

https://bugzilla.redhat.com/show_bug.cgi?id=1670435

The best solutions I came up with are to point the clients to another repo 
temporarily, or to remove perl (along with whatever required it, in my case 
logwatch) then update and reinstall the packages.  Either way you need to get 
beyond v5.24 of the perl-interpreter package.

The basis of the problem is spelled out in the Bugzilla.  But yes, the use of 
modules is near unavoidable at this point.

Good luck.


From: 
spacewalk-list-boun...@redhat.com<mailto:spacewalk-list-boun...@redhat.com> 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of Simon Avery
Sent: Wednesday, January 29, 2020 7:46
To: spacewalk-list@redhat.com<mailto:spacewalk-list@redhat.com>
Subject: [Spacewalk-list] Updates not installing since Centos 8.1 - possible 
module issues.

Hello. I've checked the recent archives and cannot find mention of this issue, 
and tried the irc channel last night wh

Re: [Spacewalk-list] [EXTERNAL EMAIL] Packages listed as available to update, but no update done (Appstream/module issue for redhat8?)

[Simon Avery]

Hello Kent

We too have encountered several rounds of difficulties with Centos 8 since 8.1 
was released, despite not having specifically used modules on any of the target 
systems.

Summary:
8.0 repo fails with various module related issues (since master repo updated 
this to link to 8.1/). Additionally, manual yum update on clients whose repos 
were managed by spwk fails.
8.1 Repo worked for a bit when added explicitly (rather than /8/ whose 
symlinked changed on the master repo), but has since triggered other issues 
(earlier reported in here)

Our current workaround is to remove Centos 8 clients from Spacewalk repos by 
assigning them the channel 'None' and for regular patching, I'm using spacecmd 
to schedule the remote command "yum -y update".

Cons: We don't get to see patches/errata before they're applied. We're using 
more bandwidth through not using spacewalk's local mirror. (Although it's off 
peak so impact is low)

Pros: We do get some post-update logs via spacewalk through the event histories 
per machine, which is useful.

I echo Stefan's suggestion that someone please fix spacewalk to deal with 
modules properly. (Sadly I don't have these skills myself!)  I'm not ready to 
leave Spacewalk behind...

S


From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Brodie, Kent
Sent: 19 February 2020 16:19
To: spacewalk-list@redhat.com
Subject: [EXTERNAL EMAIL] [Spacewalk-list] Packages listed as available to 
update, but no update done (Appstream/module issue for redhat8?)

Hi- I am testing a couple of version 8 clients for spacewalk (One redhat8, one 
centos8).

I have a server for each OS doing a full reposync, then I sync the repositories 
into spacewalk.
No problems so far.

Everything pretty much works great EXCEPT for each of those 2 clients, I have 
about 16 packages that are listed in Spacewalk as being new versions that can 
be updated.

But when I try to update those clients, nothing. "No updates available".

I am pretty sure this is related to the new redhat appstream/module 
functionality.  And I'm guessing that those 16 packages can't actually be 
upgraded YET because of a module version limitation of something installed on 
those clients.(I confirmed this more or less by eliminating spacewalk   
And just using centos/redhat repos.   Same answer:  no updates available).

BUT...  my question is this: How can I tweak spacewalk (or my repos) so 
that the Spacewalk doesn't show update packages that I actually can't install?  
 In other words, those 2 clients should NOT show any updates available to 
install...

Is this spacewalk essentially not knowing how to handle modules/appstreams yet?

Thanks for any tips/pointers

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

Re: [Spacewalk-list] [EXTERNAL EMAIL] Too many open files while syncing Red hat repository on Spacewalk server 2.9

[Simon Avery]

Hi Chen

This may be an underlying Linux limit being reached.

If so, perhaps raising it using a method such as this will resolve;  
https://www.tecmint.com/increase-set-open-file-limits-in-linux/

SA

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Wenkai Chen
Sent: 24 February 2020 01:33
To: spacewalk-list@redhat.com
Subject: [EXTERNAL EMAIL] [Spacewalk-list] Too many open files while syncing 
Red hat repository on Spacewalk server 2.9

HI Spacewalk users,

I have an issue while running a repo sync on one of our red hat repositories in 
spacewalk.

This was the error log.

===
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-9.el7.x86_64.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-11.el7.x86_64.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-5.el7.x86_64.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-9.el7.i686.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-5.el7.i686.rpm'
2020/02/21 19:47:45 +08:00 [Errno 24] Too many open files: 
'/var/satellite/redhat/1/stage/zziplib-0.13.62-11.el7.i686.rpm'
2020/02/21 19:47:45 +08:00 Importing packages finished.
2020/02/21 19:47:45 +08:00
2020/02/21 19:47:45 +08:00   Linking packages to the channel.
2020/02/21 19:48:12 +08:00 ERROR: Could not find object 
[https://www.linkedin.com/company/ensign-infosecurity/>  [A 
picture containing tableware  Description generated with high confidence] 
  [A close up of a sign  Description 
generated with high confidence] 


  E:  
wenkai_c...@ensigninfosecurity.com
  A:  30A Kallang Place, Level 9 Right Wing, Singapore 339213








CONFIDENTIALITY NOTICE: "This email is confidential and may also be privileged. 
If this email has been sent to you in error, please delete it immediately and 
notify us. Please do not copy, distribute or disseminate part or whole of this 
email if you are not the intended recipient or if you have not been authorized 
to do so. We reserve the right, to the extent and under circumstances permitted 
by applicable laws, to monitor, retain, intercept and block email messages to 
and from our systems. Thank you."

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

Re: [Spacewalk-list] [EXTERNAL EMAIL] CentOS 8 patch push works in GUI, fails in spacecmd command

[Simon Avery]

Hi

I’ve not tested your scenario fully, but note that “ - - “ is often needed when 
passing some commands via spacecmd from the cli (rather than in spacecmd’s 
shell)

This is my three command “patch everything in a group” script. $1 expanded to 
the name of that group (excuse outlook munging two –‘s into a solid line – they 
are dash dash without a space in them: -- )

# Ensure nothing else in ssm
spacecmd ssm_clear

# Now add all the machines from the group in $1 to ssm
spacecmd -- ssm_add group:"$1"

# Now create the upgrade package schedule in 24h from when called
spacecmd -y -- system_upgradepackage ssm '*' -s 24h



From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Unix admin
Sent: 02 March 2020 13:16
To: spacewalk-list@redhat.com
Subject: [EXTERNAL EMAIL] [Spacewalk-list] CentOS 8 patch push works in GUI, 
fails in spacecmd command

Hi,

I am trying to push CentOS 8 update using spacecmd command, it gives the error 
'ERROR: failed to schdule the action' message. But I was to push the package  
using Spacewalk GUI.


spacecmd  system_upgradepackage  server01 '*' -y

How to fix this spacewalk error message? other spacecmd command works fine.

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

Re: [Spacewalk-list] issue after dnf update or yum update in rhel8

[Simon Avery]

Hi

Same. Had a lot of issues with variations of the "cannot install the best 
update candidate" Issue when using Spacewalk managed repos for Centos 8 clients.

I believe it is caused by the modules issue much discussed. I was able to get 
it working on one machine after 8.1 released, but not on others - and then the 
original one reverted to failing on another package after a few days.

Only reliable workaround for C8.1 clients I have is to remove it from all 
Spacewalk Channels and trigger a remote command for groups using spacecmd of 
"yum -y update"

This works but obviously doesn't give as much transparency as proper spwk 
management.

S



From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Mertens, Jonas
Sent: 23 March 2020 15:00
To: spacewalk-list@redhat.com
Subject: [EXTERNAL EMAIL] Re: [Spacewalk-list] issue after dnf update or yum 
update in rhel8

Hi,

I have this issue, too, but was not able to solve it yet. I hope an update to 
Spacewalk 2.10 would fix it.


Freundliche Grüße / Kind regards
Jonas Mertens



Jonas Mertens
ITK Services

S&N ENS GmbH
Klingenderstr. 5
33100 Paderborn 
Phone
Mobile
E-Mail
Web   

+49 5251 1581 986
+49 162 7825913
jonas.mert...@sn-ens.de
www.sn-ens.de 



Sitz der Gesellschaft:
33100 Paderborn, Klingenderstr. 5
Registergericht Paderborn HRB 3460
Geschäftsführer: Josef Tillmann

Der S&N Invent-Newsletter
Kundenprojekte, Fachthemen, Events...
Melden Sie sich hier an

Informationen zum Schutz Ihrer Daten sind in unserer Datenschutzerklärung 
einsehbar.
 
 
 
 Ursprüngliche Nachricht 
Von: Muhammad Mosleh Uddin  
Datum: 23.03.20 15:54 (GMT+01:00) 
An: spacewalk-list@redhat.com 
Betreff: Re: [Spacewalk-list] issue after dnf update or yum update in rhel8 

 
I have tested with redhat repo. I have no issues without spacewalk and directly 
to redhat  
 
[root@rhel8 yum.repos.d]# dnf update
There was an error communicating with Red Hat Satellite or Spacewalk server.
Red Hat Satellite or Spacewalk based repositories will be disabled.

Updating Subscription Management repositories.
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)   
  13 MB/s |  14 MB 00:01
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
  13 MB/s |  14 MB 00:01
Last metadata expiration check: 0:00:02 ago on Mon 23 Mar 2020 10:47:53 AM EDT.
Dependencies resolved.
=
 Package  Architecture   Version
  RepositorySize
=
Upgrading:
 libvncserver x86_64 0.9.11-9.el8_1.2   
  rhel-8-for-x86_64-appstream-rpms 274 k

Transaction Summary
=
Upgrade  1 Package

Total download size: 274 k
Is this ok [y/N]: N
Operation aborted.
 
On Mon, Mar 23, 2020 at 7:12 AM Michael Mraka  
wrote:
Muhammad Mosleh Uddin:
> I have set two repo for rhel8. rep syncing ok.
>
> https://cdn.redhat.com/content/dist/rhel8/8/x86_64/baseos/os
> https://cdn.redhat.com/content/dist/rhel8/8/x86_64/appstream/os
>
> problem is why I am getting the following error. Any suggestion is
> appreciated.
>
> [root@test2 yum.repos.d]# yum update
> This system is receiving updates from Red Hat Satellite or Spacewalk server.
> Updating Subscription Management repositories.
> Unable to read consumer identity
> Last metadata expiration check: 0:55:47 ago on Sat 21 Mar 2020 11:54:11 PM
> EDT.
> Error:
>  Problem: cannot install both kernel-core-4.18.0-147.5.1.el8_1.x86_64 and
> kernel-core-4.18.0-147.5.1.el8_1.x86_64
>   - cannot install the best update candidate for package
> kernel-core-4.18.0-147.5.1.el8_1.x86_64
>   - cannot install the best update candidate for package
> kernel-core-4.18.0-147.el8.x86_64
> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to
> use not only best candidate packages)

I think it's dnf not a Spacewalk issue. Does it work if you register the
machine directly without Spacewa

Re: [Spacewalk-list] Spacewalk and FreeIPA

[Simon Avery]

Hello Sanjeev

Note - I am not a part of Spacewalk. Freeipa is not relevant to this list, but 
I know nothing about it anyway.

Spacewalk 2.10 was recently released and announced to be the final version.  As 
it is end of life, it seems unlikely that any further dev work will be taking 
place, including future bug and security fixes. (Although I know some similar 
projects have occasionally later serious security fixes, that is not a given)   
My thanks to all who worked on Spacewalk.

In short - it will continue working until it doesn't. You should now be 
planning to move away from Spacewalk.

The general migration routes from here seem to be either Foreman/Katello, or 
Uyuni. The former does not suit our needs, but we are actively looking at Uyuni.

S

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of sanjeev.go...@orange.com
Sent: 06 April 2020 07:46
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] Spacewalk and FreeIPA

Hello 

As per spacewalk webite  home page spacewalk product will be discontinued on 
May 31 2020.
What I understood that there will be no new release of spacewalk  after this 
period but we will continue to get the bugfixes and security fixes and its 
community support.

Kindly let me know if my understanding is wrong.



Best Regards,



Sanjeev Gorai
Consultant - Linux Systems
OCB / CSD / Private Cloud Solutions
Orange Cloud for Business
CVS : 7359-3067 | Email : sanjeev.go...@orange.com

Tower A, 4th Floor, Building No. 8, DLF Cybercity, DLF Phase II, Sector 25, 
122002, Gurgaon, India www.orange-business.com




-Original Message-
From: spacewalk-list-boun...@redhat.com
[mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Ronald Wimmer
Sent: 02 April 2020 12:55
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Spacewalk and FreeIPA

Hi,

I followed the procedure on
https://github.com/spacewalkproject/spacewalk/wiki/SpacewalkAndIPA

Apache SSL logs show that Kerberos works but when I try to log in to Spacewalk 
with one of my IPA users, I get an HTTP 403 error. (We are using Spacewalk 2.7 
and FreeIPA 4.6.5)

Am I missing something? Which logs could reveal the problem in this case?

Cheers,
Ronald


___
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

[Spacewalk-list] Odd sync errors since upgrading to 2.10

[Simon Avery]

Hopefully someone can point me in the right direction for this puzzler.

I upgraded our 2.9 instance (host is Centos 7) to 2.10 on Friday. The process 
was not painless, but I think it completed successfully. (Details at end if 
relevant)

Clients: Centos 6 and 7

Since then, we get an intermittent email :



Taskomatic bunch repo-sync-bunch was scheduled to run within the 
repo-sync-1-119 schedule.

Subtask repo-sync failed.

For more information check 
/var/log/rhn/tasko/org1/repo-sync-bunch/repo-sync_18305548_err.

However - an hour later, we get another email



Taskomatic bunch repo-sync-bunch was scheduled to run within the 
repo-sync-1-135 schedule.

Subtask repo-sync finished successfuly and is back to normal.

I looked into this yesterday and as the _err file referenced centos 8 repos, I 
removed and cleaned them (We weren't using them anyway). Since then it's 
complaining about packages in the c7 and c6 repos, picking different packages 
to be upset with.

Example _err

08:00:06   Linking packages to the channel.
08:00:07 ERROR: Could not find object 
[http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/epel/6/x86_64/ but 
not in our local repos where the latest version is 2.3.2. However, other 
packages have been mentioned too.

Manually syncing the repo generates the same error as above, consistently:  
/usr/bin/spacewalk-repo-sync --channel epelupdatesc6_5 --type yum

Google tells me this happens occasionally to people across previous versions of 
Spacewalk, so it may not be a 2.10 specific issue, although in one version 
Redhat blame a code problem; https://access.redhat.com/solutions/124363  - I'm 
not sure that's the case here.

Why is spacewalk having this issue, then apparently fixing itself an hour 
later? (I'm not sure it is fixing itself as the issue persists when run 
manually)

How do I fix it?

Thank you



  *   Upgrade issues: Following this guide, 
https://github.com/spacewalkproject/spacewalk/wiki/HowToUpgrade Went okay until 
"spacewalk-setup -upgrade" when it failed and wiped config. However, a yum 
upgrade using the new repos completed successfully so I went with that.

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

Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: End of life for Spacewalk project?

[Simon Avery]

Hello Joe,

It’s worth noting, for those who can’t see Foreman/Katello fitting their use 
case,  that Spacewalk has already been forked by https://www.uyuni-project.org/ 
and is under active development there.

It’s quite familiar to Spacewalk users and also adds Salt Master functionality. 
(But not required to use this)

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Joe Belliveau
Sent: 21 May 2020 16:14
To: spacewalk-list@redhat.com
Subject: [EXTERNAL EMAIL] Re: [Spacewalk-list] End of life for Spacewalk 
project?


Means we have to either fork it or move on to the newer stack that redhat uses.

My plan so far is to start migrating to the newer stack. Sadly the value of 
spacewalk is dropping due to cloud usage. And a lack of understanding what 
Spacewalk can do.
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: End of life for Spacewalk project?

[Simon Avery]

You’re correct, the installer does only work on a Suse machine. I don’t know 
what it would take to force it onto Centos, but I suspect it would be not 
trivial.

That said, I found installing Suse and Uyuni pain free following their guide – 
although it obviously is another technology to support if you don’t already do 
Suse.

I’d rather it wasn’t on Suse, but it is. It was forked for and is and integral 
to the Suse management plan, so one can’t begrudge them tailoring it to their 
distro.

On balance, and the only other slightly viable alternative being 
Katello/Foreman, Uyuni is looking the lesser of two evils for us. YMMV.

S

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Andreas Dijkman
Sent: 22 May 2020 09:42
To:  
Subject: Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: End of life for Spacewalk 
project?

Uyuni would be a nice candidate, but in their docs it (obviously) states it can 
only be installed on SuSE Leap. I don’t have a single SuSE-machine running and 
I don’t intend to. Can I just add this repos to a CentOS or OracleLinux VM and 
do a ‘yum install uyuni’?

Andreas Dijkman

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

Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: End of life for Spacewalk project?

[Simon Avery]

That's very encouraging news, Neal - thanks for the info, and I wish you the 
best with that project!

-Original Message-
From: spacewalk-list-boun...@redhat.com  On 
Behalf Of Neal Gompa
Sent: 22 May 2020 13:28
To: spacewalk-list@redhat.com
Subject: Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: End of life for Spacewalk 
project?

Bringing Uyuni back to CentOS shouldn't be too bad. I'm starting with Fedora 
because there's a lot more stuff packaged there, and having a working state on 
Fedora is 80% of the work for bringing it to CentOS 8 anyway. Once I get it 
working on Fedora, then it should be straightforward to get it working on 
CentOS 8.

The Uyuni folks have committed to maintaining upstream support for Fedora and 
CentOS once it's supported again in the upstream tree. They haven't broken too 
much of the Fedora/CentOS server support. The main thing is that they switched 
from YUM to Zypper for some things, and that's not possible to support on 
CentOS. They've already approved switching to DNF as a community feature, so 
once that's done, it's just filling in any missing packages. :)

On Fri, May 22, 2020 at 8:03 AM Simon Avery  
wrote:
>
> You’re correct, the installer does only work on a Suse machine. I don’t know 
> what it would take to force it onto Centos, but I suspect it would be not 
> trivial.
>
>
>
> That said, I found installing Suse and Uyuni pain free following their guide 
> – although it obviously is another technology to support if you don’t already 
> do Suse.
>
>
>
> I’d rather it wasn’t on Suse, but it is. It was forked for and is and 
> integral to the Suse management plan, so one can’t begrudge them tailoring it 
> to their distro.
>
>
>
> On balance, and the only other slightly viable alternative being 
> Katello/Foreman, Uyuni is looking the lesser of two evils for us. YMMV.
>
>
>
> S
>
>
>
> From: spacewalk-list-boun...@redhat.com 
>  On Behalf Of Andreas Dijkman
> Sent: 22 May 2020 09:42
> To:  
> Subject: Re: [Spacewalk-list] [EXTERNAL EMAIL] Re: End of life for Spacewalk 
> project?
>
>
>
> Uyuni would be a nice candidate, but in their docs it (obviously) states it 
> can only be installed on SuSE Leap. I don’t have a single SuSE-machine 
> running and I don’t intend to. Can I just add this repos to a CentOS or 
> OracleLinux VM and do a ‘yum install uyuni’?
>
>
> Andreas Dijkman
>
>
>
> ___
> Spacewalk-list mailing list
> Spacewalk-list@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list



--
真実はいつも一つ！/ Always, there's only one truth!


___
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] [EXTERNAL EMAIL] ansible tower with spacewalk

[Simon Avery]

  *   Have any of you tried integrating ansible tower/awx with spacewalk?  I 
know it is supposed to be able to work with satellite, but not sure if it will 
do the same with spacewalk.  If you have done this, do you have any recommended 
websites describing how to do it?

Indirectly, yes. I wasn’t aware of any native linking, but not needed it.

AWX builds new virtual machines, and runs a playbook in the final stages which 
installs the required client software and then registers the new machine onto 
Spacewalk using the normal rhnsreg command.

Nothing fancy, and equivalent (in ansible friendly language) of

yum -y install rhn-setup osad rhncfg-actions
rhnreg_ks --serverUrl= --activationkey= --force
rhn-actions-control --enable-all
systemctl enable rhnsd osad
spacewalk-channel --add -c  -c  --user  
--password 




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