Re: [Spacewalk-list] Reposync and proxy servers

[Robert Paschedag]

Not true...

https://github.com/spacewalkproject/spacewalk/blob/master/backend/satellite_tools/repo_plugins/yum_src.py#L137

⁣sent from my mobile device​


 Originale Nachricht 
Von: Luca Menegus 
Gesendet: Thu Jun 20 18:34:48 GMT+02:00 2019
An: spacewalk-list@redhat.com
Betreff: Re: [Spacewalk-list] Reposync and proxy servers

Hi, 
spacewalk-repo-sync uses / etc/rhn/spacewalk-repo-sync/yum.conf for 
configuration. 

Luca 

- Original Message -

> From: "Larry Clegg" 
> To: spacewalk-list@redhat.com
> Sent: Thursday, June 20, 2019 6:16:27 PM
> Subject: [Spacewalk-list] Reposync and proxy servers

> Greetings Spacewalkers,

> My environment: Spacewalk 2.9 on Centos 6.10

> Everything is working well but a question from our networking/firewall team
> has come up.

> On the Spacewalk server the /etc/yum.conf has a proxy setting that is
> supposed to force all yum http traffic thru an internal proxy server. This
> works except in the case of /usr/bin/spacewalk-repo-sync operations. It
> appears to ignore that and go directly from the SW server to the various
> external repos for sync’ing.

> Has anyone noticed this before? Is there a setting to adjust to force the
> repo-sync to go thru the proxy server?

> Thank you,

> Larry E. Clegg

> Systems Engineer (SaaS Platform Operations) | Kyriba

> [Cell Phone] +1 858-357-5579

> [Address] 9620 Towne Centre Drive | Suite 250 | San Diego, California | 92121

> www.kyriba.com | Facebook | Twitter | LinkedIn | Blog

> ___
> 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 mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Re: [Spacewalk-list] Reposync and proxy servers

[Luca Menegus]

Hi, 
spacewalk-repo-sync uses / etc/rhn/spacewalk-repo-sync/yum.conf for 
configuration. 

Luca 

- Original Message -

> From: "Larry Clegg" 
> To: spacewalk-list@redhat.com
> Sent: Thursday, June 20, 2019 6:16:27 PM
> Subject: [Spacewalk-list] Reposync and proxy servers

> Greetings Spacewalkers,

> My environment: Spacewalk 2.9 on Centos 6.10

> Everything is working well but a question from our networking/firewall team
> has come up.

> On the Spacewalk server the /etc/yum.conf has a proxy setting that is
> supposed to force all yum http traffic thru an internal proxy server. This
> works except in the case of /usr/bin/spacewalk-repo-sync operations. It
> appears to ignore that and go directly from the SW server to the various
> external repos for sync’ing.

> Has anyone noticed this before? Is there a setting to adjust to force the
> repo-sync to go thru the proxy server?

> Thank you,

> Larry E. Clegg

> Systems Engineer (SaaS Platform Operations) | Kyriba

> [Cell Phone] +1 858-357-5579

> [Address] 9620 Towne Centre Drive | Suite 250 | San Diego, California | 92121

> www.kyriba.com | Facebook | Twitter | LinkedIn | Blog

> ___
> 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] Reposync and proxy servers

[Larry Clegg]

Greetings Spacewalkers,



My environment: Spacewalk 2.9 on Centos 6.10



Everything is working well but a question from our networking/firewall team
has come up.



On the Spacewalk server the /etc/yum.conf has a proxy setting that is
supposed to force all yum http traffic thru an internal proxy server.  This
works except in the case of /usr/bin/spacewalk-repo-sync operations.  It
appears to ignore that and go directly from the SW server to the various
external repos for sync’ing.



Has anyone noticed this before?  Is there a setting to adjust to force the
repo-sync to go thru the proxy server?



Thank you,



*Larry E. Clegg*

Systems Engineer (SaaS Platform Operations) | *Kyriba*

[Cell Phone] +1 858-357-5579

[Address] 9620 Towne Centre Drive | Suite 250 | San Diego, California |
92121

www.kyriba.com | Facebook  | Twitter
 | LinkedIn
 | Blog

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

Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update

[Paul Greene]

When I'd do upgrades from 7.5 to 7.6, they ran fine - no errors, everything
seemed normal. Nothing out of the ordinary in yum history.
I thought for a while that maybe 7.6 didn't like our video hardware - an
older NVIDIA card, some were dual head (the 315 card) and some were 3 heads
(the 440 card), but another sys admin with another group wasn't having any
issues with 7.6 using similar hardware. I tried building a clean machine
and did an update to 7.6, but didn't join it to Spacewalk and used it as my
work machine for a couple of weeks and didn't have any issues with it.
I like Spacewalk and want to continue using it. I did start to try Ansible,
but I was finding most of what I wanted to do with Ansible I could do using
remote commands through Spacewalk, and it was quick and easy, so I got lazy
about working through the Ansible learning curve. Ansible is probably a lot
more powerful for such things than Spacewalk, so maybe I just need to
revisit it again and grind through the learning curve.

On Thu, Jun 20, 2019 at 10:49 AM p.cook...@bham.ac.uk 
wrote:

> May be I should have said, don’t use a local repo unless you really have
> to – and it seems like you do. There are clear benefits in having Spacewalk
> patching though – you get a clearer graphical view of the system’s patch
> status etc. May be you could push for an exception for web access
> controlled through something like Squid but, obviously, I don’t know what
> hurdles you face within your organisation.
>
>
>
> As I suggested, running a manual “yum update” or checking out “yum
> history” may help you identify any problem in that area. Equally, tailing
> the sync log file, while syncing, or using “reposync” from the command line.
>
>
>
> 2.9 has been out since January and still the current version so, yes, I
> would say use that for any new build.
>
>
>
> The systems will continue to look to Spacewalk for updates as a yum plugin
> etc is installed during registration. I’ve developed a procedure to
> un-register a system or re-register to a different Spacewalk server, for
> our environments, if you think that would be useful?
>
>
>
> Re Scott’s comments, below, I’ve just began using Ansible AWX and starting
> to realise its benefitsJ
>
>
>
> Regards
>
> Phil
>
>
>
> *From:* spacewalk-list-boun...@redhat.com <
> spacewalk-list-boun...@redhat.com> *On Behalf Of *
> scott.c.worthing...@gmail.com
> *Sent:* 20 June 2019 15:08
> *To:* spacewalk-list 
> *Subject:* Re: [Spacewalk-list] Oddball question about Spacewalk possibly
> corrupting yum update
>
>
>
> If you want to stick to your local yum repo, have you considered the
> following:
>
>
>
> * For collecting hardware inventory and installed packages:
>
> 1.  https://github.com/fboender/ansible-cmdb
>
>
>
> * Using Ansible for configuration management ("sending remote commands to
> big groups at once")?
>
>
>
> And if you need a front end for Ansible, you could investigate:
>
> 1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
>
> 2. https://github.com/Batix/rundeck-ansible-plugin
>
> 3. https://github.com/ansible/awx
>
>
>
>
>
> On Thu, Jun 20, 2019 at 8:29 AM Paul Greene 
> wrote:
>
> These systems are on a network that has no access to the internet - local
> repos are the only way to update them.
>
> I have no idea which X package is causing trouble.
>
> I never really wanted to use the Spacewalk server for patching in the
> first place. My local yum repository works just fine. I like using
> Spacewalk as a management tool - it's good at showing the hardware
> inventory, and for sending remote commands to big groups at once. There
> isn't enough time in the day to have to go out and touch 250 systems one by
> one for basic maintenance tasks.
>
> Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?
>
>
>
> On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk 
> wrote:
>
> Hi Paul
>
>
>
> I haven’t got any CentOS systems to patch, with Spacewalk, but a few
> thoughts…..
>
>
>
> Not sure why you would start with 2.7 or sync from a local repo really? If
> you just didn’t want to go too bleeding edge with 2.9 I would at least
> start with 2.8. In addition, I wouldn’t bother syncing from a local repo as
> you can go direct to the CentOS web repo’s which are kept up to date – see
> eg’s below:
>
>
>
> http://mirror.centos.org/centos/7/os/x86_64/   #Base
>
> http://mirror.centos.org/centos/7/extras/x86_64/   #Extras
>
> http://mirror.centos.org/centos/7/updates/x86_64/   #Updates
>
>
>
> You should find this combination will resolve any issues but, if not, you
> could sync the repo from the command line (using “reposync”) so you can
> watch it go through. However, there are repo sync logs in
> /var/log/rhn/reposync/ as well.
>
>
>
> In addition, you could try manually updating a system from the command
> line (using “yum update”) and/or excluding  the X-Windows package you
> suspect (using “yum update -X ”), which may help you identify the
> proble

Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update

[p.cook...@bham.ac.uk]

May be I should have said, don’t use a local repo unless you really have to – 
and it seems like you do. There are clear benefits in having Spacewalk patching 
though – you get a clearer graphical view of the system’s patch status etc. May 
be you could push for an exception for web access controlled through something 
like Squid but, obviously, I don’t know what hurdles you face within your 
organisation.

As I suggested, running a manual “yum update” or checking out “yum history” may 
help you identify any problem in that area. Equally, tailing the sync log file, 
while syncing, or using “reposync” from the command line.

2.9 has been out since January and still the current version so, yes, I would 
say use that for any new build.

The systems will continue to look to Spacewalk for updates as a yum plugin etc 
is installed during registration. I’ve developed a procedure to un-register a 
system or re-register to a different Spacewalk server, for our environments, if 
you think that would be useful?

Re Scott’s comments, below, I’ve just began using Ansible AWX and starting to 
realise its benefits☺

Regards
Phil

From: spacewalk-list-boun...@redhat.com  On 
Behalf Of scott.c.worthing...@gmail.com
Sent: 20 June 2019 15:08
To: spacewalk-list 
Subject: Re: [Spacewalk-list] Oddball question about Spacewalk possibly 
corrupting yum update

If you want to stick to your local yum repo, have you considered the following:

* For collecting hardware inventory and installed packages:
1.  https://github.com/fboender/ansible-cmdb

* Using Ansible for configuration management ("sending remote commands to big 
groups at once")?

And if you need a front end for Ansible, you could investigate:
1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
2. https://github.com/Batix/rundeck-ansible-plugin
3. https://github.com/ansible/awx


On Thu, Jun 20, 2019 at 8:29 AM Paul Greene 
mailto:paul.greene...@gmail.com>> wrote:
These systems are on a network that has no access to the internet - local repos 
are the only way to update them.
I have no idea which X package is causing trouble.
I never really wanted to use the Spacewalk server for patching in the first 
place. My local yum repository works just fine. I like using Spacewalk as a 
management tool - it's good at showing the hardware inventory, and for sending 
remote commands to big groups at once. There isn't enough time in the day to 
have to go out and touch 250 systems one by one for basic maintenance tasks.
Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?

On Thu, Jun 20, 2019 at 4:26 AM 
p.cook...@bham.ac.uk 
mailto:p.cook...@bham.ac.uk>> wrote:
Hi Paul

I haven’t got any CentOS systems to patch, with Spacewalk, but a few thoughts…..

Not sure why you would start with 2.7 or sync from a local repo really? If you 
just didn’t want to go too bleeding edge with 2.9 I would at least start with 
2.8. In addition, I wouldn’t bother syncing from a local repo as you can go 
direct to the CentOS web repo’s which are kept up to date – see eg’s below:

http://mirror.centos.org/centos/7/os/x86_64/   #Base
http://mirror.centos.org/centos/7/extras/x86_64/   #Extras
http://mirror.centos.org/centos/7/updates/x86_64/   #Updates

You should find this combination will resolve any issues but, if not, you could 
sync the repo from the command line (using “reposync”) so you can watch it go 
through. However, there are repo sync logs in /var/log/rhn/reposync/ as well.

In addition, you could try manually updating a system from the command line 
(using “yum update”) and/or excluding  the X-Windows package you suspect (using 
“yum update -X ”), which may help you identify the problem too.

Unfortunately, Spacewalk does not provide an option to un-register a client 
system (similar to registering - “rhnreg_ks”) – the only option is to remove 
the client system’s profile from the Spacewalk server, then remove the 
/etc/sysconfig/rhn/systemid file etc on the client system.

Hope this is of help.

Regards
Phil





From: 
spacewalk-list-boun...@redhat.com 
mailto:spacewalk-list-boun...@redhat.com>> 
On Behalf Of paul.greene...@gmail.com
Sent: 19 June 2019 17:00
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting 
yum update

I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 
workstations, and synced it to a local yum repository.

After a few months I started adding some CentOS 7 systems to the mix, and also 
synced to the same local yum repository (same server, different path to the 
repositories, of course).

The Spacewalk server always seemed to have an issue getting a successful full 
sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't 
concerned at first because the systems were configured to go 

Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update

[Scott Worthington]

If you want to stick to your local yum repo, have you considered the
following:

* For collecting hardware inventory and installed packages:
1.  https://github.com/fboender/ansible-cmdb

* Using Ansible for configuration management ("sending remote commands to
big groups at once")?

And if you need a front end for Ansible, you could investigate:
1. https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin
2. https://github.com/Batix/rundeck-ansible-plugin
3. https://github.com/ansible/awx


On Thu, Jun 20, 2019 at 8:29 AM Paul Greene 
wrote:

> These systems are on a network that has no access to the internet - local
> repos are the only way to update them.
> I have no idea which X package is causing trouble.
> I never really wanted to use the Spacewalk server for patching in the
> first place. My local yum repository works just fine. I like using
> Spacewalk as a management tool - it's good at showing the hardware
> inventory, and for sending remote commands to big groups at once. There
> isn't enough time in the day to have to go out and touch 250 systems one by
> one for basic maintenance tasks.
> Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?
>
> On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk 
> wrote:
>
>> Hi Paul
>>
>>
>>
>> I haven’t got any CentOS systems to patch, with Spacewalk, but a few
>> thoughts…..
>>
>>
>>
>> Not sure why you would start with 2.7 or sync from a local repo really?
>> If you just didn’t want to go too bleeding edge with 2.9 I would at least
>> start with 2.8. In addition, I wouldn’t bother syncing from a local repo as
>> you can go direct to the CentOS web repo’s which are kept up to date – see
>> eg’s below:
>>
>>
>>
>> http://mirror.centos.org/centos/7/os/x86_64/   #Base
>>
>> http://mirror.centos.org/centos/7/extras/x86_64/   #Extras
>>
>> http://mirror.centos.org/centos/7/updates/x86_64/   #Updates
>>
>>
>>
>> You should find this combination will resolve any issues but, if not, you
>> could sync the repo from the command line (using “reposync”) so you can
>> watch it go through. However, there are repo sync logs in
>> /var/log/rhn/reposync/ as well.
>>
>>
>>
>> In addition, you could try manually updating a system from the command
>> line (using “yum update”) and/or excluding  the X-Windows package you
>> suspect (using “yum update -X ”), which may help you identify the
>> problem too.
>>
>>
>>
>> Unfortunately, Spacewalk does not provide an option to un-register a
>> client system (similar to registering - “rhnreg_ks”) – the only option is
>> to remove the client system’s profile from the Spacewalk server, then
>> remove the /etc/sysconfig/rhn/systemid file etc on the client system.
>>
>>
>>
>> Hope this is of help.
>>
>>
>>
>> Regards
>>
>> Phil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* spacewalk-list-boun...@redhat.com <
>> spacewalk-list-boun...@redhat.com> *On Behalf Of *
>> paul.greene...@gmail.com
>> *Sent:* 19 June 2019 17:00
>> *To:* spacewalk-list@redhat.com
>> *Subject:* [Spacewalk-list] Oddball question about Spacewalk possibly
>> corrupting yum update
>>
>>
>>
>> I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6
>> workstations, and synced it to a local yum repository.
>>
>>
>>
>> After a few months I started adding some CentOS 7 systems to the mix, and
>> also synced to the same local yum repository (same server, different path
>> to the repositories, of course).
>>
>>
>>
>> The Spacewalk server always seemed to have an issue getting a successful
>> full sync with the CentOS 7 local repository after the 7.6 series came out.
>> I wasn't concerned at first because the systems were configured to go to
>> the local yum repository anyway (configured in /etc/yum.repos.d).
>>
>>
>>
>> After the CentOS 7.6 series came out, I started having an issue with any
>> machine that got the 7.6 updates where the system would freeze and lock up,
>> requiring a hard reboot to get it usable again. That happened on at least a
>> daily basis and sometimes multiple times a day. I rolled those users back
>> to CentOS 7.5 to get them a functioning stable machine again, and didn't
>> update anybody that was running 7.5. It seemed definitely related to X
>> windows - I could still go to a command prompt with ctrl-alt-f2 and work
>> from a command prompt, but X windows wouldn't come back without a hard
>> reboot. On a couple of servers that didn't need X windows and had the run
>> level set to multi-user.target, they didn't have an issue - it was only the
>> workstations that needed X windows.
>>
>>
>>
>> I have access to another yum repository independent of the Spacewalk
>> server, and noticed if I updated a workstation to that repository and did
>> NOT join the machine to the Spacewalk server, they all ran fine with CentOS
>> 7.6. As long as I didn't join them to the Spacewalk server there were no
>> issues. I tried deleting the CentOS 7 yum repository from the Spacewalk
>> server, thinking maybe the y

Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update

[Paul Greene]

These systems are on a network that has no access to the internet - local
repos are the only way to update them.
I have no idea which X package is causing trouble.
I never really wanted to use the Spacewalk server for patching in the first
place. My local yum repository works just fine. I like using Spacewalk as a
management tool - it's good at showing the hardware inventory, and for
sending remote commands to big groups at once. There isn't enough time in
the day to have to go out and touch 250 systems one by one for basic
maintenance tasks.
Why do you call 2.9 "bleeding edge"? Hasn't it been out for awhile already?

On Thu, Jun 20, 2019 at 4:26 AM p.cook...@bham.ac.uk 
wrote:

> Hi Paul
>
>
>
> I haven’t got any CentOS systems to patch, with Spacewalk, but a few
> thoughts…..
>
>
>
> Not sure why you would start with 2.7 or sync from a local repo really? If
> you just didn’t want to go too bleeding edge with 2.9 I would at least
> start with 2.8. In addition, I wouldn’t bother syncing from a local repo as
> you can go direct to the CentOS web repo’s which are kept up to date – see
> eg’s below:
>
>
>
> http://mirror.centos.org/centos/7/os/x86_64/   #Base
>
> http://mirror.centos.org/centos/7/extras/x86_64/   #Extras
>
> http://mirror.centos.org/centos/7/updates/x86_64/   #Updates
>
>
>
> You should find this combination will resolve any issues but, if not, you
> could sync the repo from the command line (using “reposync”) so you can
> watch it go through. However, there are repo sync logs in
> /var/log/rhn/reposync/ as well.
>
>
>
> In addition, you could try manually updating a system from the command
> line (using “yum update”) and/or excluding  the X-Windows package you
> suspect (using “yum update -X ”), which may help you identify the
> problem too.
>
>
>
> Unfortunately, Spacewalk does not provide an option to un-register a
> client system (similar to registering - “rhnreg_ks”) – the only option is
> to remove the client system’s profile from the Spacewalk server, then
> remove the /etc/sysconfig/rhn/systemid file etc on the client system.
>
>
>
> Hope this is of help.
>
>
>
> Regards
>
> Phil
>
>
>
>
>
>
>
>
>
>
>
> *From:* spacewalk-list-boun...@redhat.com <
> spacewalk-list-boun...@redhat.com> *On Behalf Of *paul.greene...@gmail.com
> *Sent:* 19 June 2019 17:00
> *To:* spacewalk-list@redhat.com
> *Subject:* [Spacewalk-list] Oddball question about Spacewalk possibly
> corrupting yum update
>
>
>
> I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6
> workstations, and synced it to a local yum repository.
>
>
>
> After a few months I started adding some CentOS 7 systems to the mix, and
> also synced to the same local yum repository (same server, different path
> to the repositories, of course).
>
>
>
> The Spacewalk server always seemed to have an issue getting a successful
> full sync with the CentOS 7 local repository after the 7.6 series came out.
> I wasn't concerned at first because the systems were configured to go to
> the local yum repository anyway (configured in /etc/yum.repos.d).
>
>
>
> After the CentOS 7.6 series came out, I started having an issue with any
> machine that got the 7.6 updates where the system would freeze and lock up,
> requiring a hard reboot to get it usable again. That happened on at least a
> daily basis and sometimes multiple times a day. I rolled those users back
> to CentOS 7.5 to get them a functioning stable machine again, and didn't
> update anybody that was running 7.5. It seemed definitely related to X
> windows - I could still go to a command prompt with ctrl-alt-f2 and work
> from a command prompt, but X windows wouldn't come back without a hard
> reboot. On a couple of servers that didn't need X windows and had the run
> level set to multi-user.target, they didn't have an issue - it was only the
> workstations that needed X windows.
>
>
>
> I have access to another yum repository independent of the Spacewalk
> server, and noticed if I updated a workstation to that repository and did
> NOT join the machine to the Spacewalk server, they all ran fine with CentOS
> 7.6. As long as I didn't join them to the Spacewalk server there were no
> issues. I tried deleting the CentOS 7 yum repository from the Spacewalk
> server, thinking maybe the yum repository on the Spacewalk server had
> gotten corrupted and was pushing out some bad files, but that didn't work.
>
>
>
> The systems still seem to be looking to the Spacewalk server for updates,
> regardless of what is in /etc/yum.repos.d.
>
>
>
> Hopefully someone else has seen something like this before. I would either
> like to remove any and all yum configurations from the Spacewalk server, if
> possible, and just point to the local yum repository for any kind of
> updates.
>
>
>
> Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and
> would build a new 2.9 server, migrate everything over to that, and leave
> out any yum repository configuration at all

Re: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting yum update

[p.cook...@bham.ac.uk]

Hi Paul

I haven’t got any CentOS systems to patch, with Spacewalk, but a few thoughts…..

Not sure why you would start with 2.7 or sync from a local repo really? If you 
just didn’t want to go too bleeding edge with 2.9 I would at least start with 
2.8. In addition, I wouldn’t bother syncing from a local repo as you can go 
direct to the CentOS web repo’s which are kept up to date – see eg’s below:

http://mirror.centos.org/centos/7/os/x86_64/   #Base
http://mirror.centos.org/centos/7/extras/x86_64/   #Extras
http://mirror.centos.org/centos/7/updates/x86_64/   #Updates

You should find this combination will resolve any issues but, if not, you could 
sync the repo from the command line (using “reposync”) so you can watch it go 
through. However, there are repo sync logs in /var/log/rhn/reposync/ as well.

In addition, you could try manually updating a system from the command line 
(using “yum update”) and/or excluding  the X-Windows package you suspect (using 
“yum update -X ”), which may help you identify the problem too.

Unfortunately, Spacewalk does not provide an option to un-register a client 
system (similar to registering - “rhnreg_ks”) – the only option is to remove 
the client system’s profile from the Spacewalk server, then remove the 
/etc/sysconfig/rhn/systemid file etc on the client system.

Hope this is of help.

Regards
Phil





From: spacewalk-list-boun...@redhat.com  On 
Behalf Of paul.greene...@gmail.com
Sent: 19 June 2019 17:00
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] Oddball question about Spacewalk possibly corrupting 
yum update

I built a Spacewalk 2.7 server for managing a couple hundred CentOS 6 
workstations, and synced it to a local yum repository.

After a few months I started adding some CentOS 7 systems to the mix, and also 
synced to the same local yum repository (same server, different path to the 
repositories, of course).

The Spacewalk server always seemed to have an issue getting a successful full 
sync with the CentOS 7 local repository after the 7.6 series came out. I wasn't 
concerned at first because the systems were configured to go to the local yum 
repository anyway (configured in /etc/yum.repos.d).

After the CentOS 7.6 series came out, I started having an issue with any 
machine that got the 7.6 updates where the system would freeze and lock up, 
requiring a hard reboot to get it usable again. That happened on at least a 
daily basis and sometimes multiple times a day. I rolled those users back to 
CentOS 7.5 to get them a functioning stable machine again, and didn't update 
anybody that was running 7.5. It seemed definitely related to X windows - I 
could still go to a command prompt with ctrl-alt-f2 and work from a command 
prompt, but X windows wouldn't come back without a hard reboot. On a couple of 
servers that didn't need X windows and had the run level set to 
multi-user.target, they didn't have an issue - it was only the workstations 
that needed X windows.

I have access to another yum repository independent of the Spacewalk server, 
and noticed if I updated a workstation to that repository and did NOT join the 
machine to the Spacewalk server, they all ran fine with CentOS 7.6. As long as 
I didn't join them to the Spacewalk server there were no issues. I tried 
deleting the CentOS 7 yum repository from the Spacewalk server, thinking maybe 
the yum repository on the Spacewalk server had gotten corrupted and was pushing 
out some bad files, but that didn't work.

The systems still seem to be looking to the Spacewalk server for updates, 
regardless of what is in /etc/yum.repos.d.

Hopefully someone else has seen something like this before. I would either like 
to remove any and all yum configurations from the Spacewalk server, if 
possible, and just point to the local yum repository for any kind of updates.

Barring that, I'm interested in updating to Spacewalk 2.9 anyway, and would 
build a new 2.9 server, migrate everything over to that, and leave out any yum 
repository configuration at all on that new server.

The CentOS 6 systems are fine - no issues at all with updates and/or yum 
repositories.

Thanks,

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