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

Thu Jun 20 14:47:20 UTC 2019

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-bounces at redhat.com <spacewalk-list-bounces at redhat.com> On Behalf Of scott.c.worthington at gmail.com
Sent: 20 June 2019 15:08
To: spacewalk-list <spacewalk-list at redhat.com>
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 <paul.greene.va at gmail.com<mailto:paul.greene.va at 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.Cookson at bham.ac.uk<mailto:P.Cookson at bham.ac.uk> <P.Cookson at bham.ac.uk<mailto:P.Cookson at 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 <package>”), 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-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com> <spacewalk-list-bounces at redhat.com<mailto:spacewalk-list-bounces at redhat.com>> On Behalf Of paul.greene.va at gmail.com<mailto:paul.greene.va at gmail.com>
Sent: 19 June 2019 17:00
To: spacewalk-list at redhat.com<mailto:spacewalk-list at 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 at redhat.com<mailto:Spacewalk-list at redhat.com>
https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com<mailto: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/20190620/7fc94907/attachment.htm>