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

Paul Greene paul.greene.va at gmail.com
Thu Jun 20 15:09:29 UTC 2019


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.Cookson at bham.ac.uk <P.Cookson at 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-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>
> 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 <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 <
> spacewalk-list-bounces at redhat.com> *On Behalf Of *paul.greene.va at gmail.com
> *Sent:* 19 June 2019 17:00
> *To:* 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
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190620/8d8fabf3/attachment.htm>


More information about the Spacewalk-list mailing list