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

Thu Jun 20 14:08:02 UTC 2019

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