[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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20190620/1cce3fb8/attachment.htm>