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...@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 <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 <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-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 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 > > _______________________________________________ > 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