Re: [Spacewalk-list] Clone errata with pkgs of another channel.
Hi, Any news on this one? I'm planning to add centos management in my setup..so I need this to be fixed. If you need any help, I can provide some. Andy, how do you plan to fix this? Thanks, Pierre 2012/1/27 Nilton Moura red...@nmoura.eti.br: Thank you. I'm trying to do this, but I guess you will finish early. How do you think you'll do this? With a new method or only changing the script? I'm searching a method to acomplish, but on getDetails for instance, I need to know the id. So, if I lookup with Nvrea and check the vendor or provider with getDetails, and after come back to a new lookup with Nvrea.. but I think this shouldn't work cause it will bring the same result, and sounds ugly too. Can you give me some light? Thanks. 2012/1/27 Speagle, Andy andy.spea...@wichita.edu Hi Nilton, That’s a good catch… that has never been an issue for me since I don’t have mixed vendors on my system. I’ll get this updated and put out a patch as soon as I can. Thanks for sharing your usage case. Andy From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Nilton Moura Sent: Friday, January 27, 2012 11:49 AM To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] Clone errata with pkgs of another channel. Hi. I've been reading the python-clone-errata.py and I see that it uses the findByNvrea method. Can I create another method like this, adding vendor or provider parameter? I guess this will solve my problem, which is the first entry matched on database is returned, no matter the channel. (I debug with some prints on the script and comparing with the id's on the database). If not, the another solution (workaround), is to first upload packages from RHN than the CentOS for example (but this sounds very ugly). Thanks, Nilton Moura. 2012/1/26 Nilton Moura red...@nmoura.eti.br Hi, I'm cloning erratas from RHN with rhn-clone-errata.py 0.9.0 by Andy Speagle, but some erratas are being associated with packages from another channel (when the same package exist on CentOS for example). For example, after publish the errata RHSA-2012:0060 from rhel-5-x86_64-server, I go to Packages and the GUI shows me only one package (openssl-0.9.8e-20.el5_7.1-i686), but if I go to Packages in Manage Errata, the list appears different: openssl-0.9.8e-20.el5_7.1-i686 RHEL x86_64 Server (v. 5) rhn openssl-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates openssl-devel-0.9.8e-20.el5_7.1-i386 CentOS x86_64 (v. 5) updates openssl-devel-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates openssl-perl-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates I uploaded two prints with this to better understanding: - http://static.inky.ws/image/1180/image.jpg - http://static.inky.ws/image/1181/image.jpg If I manually remove this CentOS packages from the errata and add the corrected packages from rhel channel I correct this. Thanks, Nilton Moura. ___ 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
Re: [Spacewalk-list] [Spacewalk 1.6] Issues with activationkey during kickstart
It seems the following step in the re-registration procedure is failing. perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/* Output is: Can't do inplace edit: /etc/sysconfig/rhn/allowed-actions is not a regular file. Can't do inplace edit: /etc/sysconfig/rhn/clientCaps.d is not a regular file. I believe the problem is addressed in the following commit? I'm kickstarting through a 1.6 proxy. Any input appreciated. http://miroslav.suchy.cz/spacewalk/gitstat/commit-detail.php?commit=502ccf36baae45950825ed75141837a25570d7b3 Best regards, Tomi Salmi On 31 January 2012 12:36, Tomi Salmi tomisalmi...@gmail.com wrote: Hi, After investigating the issue a bit more, the problem seems to be related to /etc/sysconfig/rhn/systemid. The file does not appear to a re-provisioned system. After kickstaring an already provisioned system, rhnreg_ks somehow fails. ks-rhn-post.log tells me ERROR: unable to read system id, which then results in: Error Message: Your account does not have access to any channels matching (release='6', arch='x86_64') Error Class Code: 19 Error Class Info: Architecture and OS version combination is not supported. Very odd, since the bare-metal kickstart works like a charm. Am I missing something really simple here? Regards, Tomi Salmi On 25 January 2012 11:29, Tomi Salmi tomisalmi...@gmail.com wrote: Hi, I am also experiencing this same issue. The weird thing is that a first-time bare-metal kickstart goes through without any problems. I prestage the client in Cobbler, kick off a pxe boot, installation ok, client gets registered in Spacewalk, osad works, the sun is shining and love is in the air. However, when I re-provision (koan) this system using the same kickstart profile, it fails to re-register ending up with the same errors as David has. I would imagine more people have experienced this issue, since it's quite an important part of Spacewalk functionality. Any ideas? Setup: Spacewalk 1.6 Proxy 1.6 Oracle 11g XE (did I take a leap of faith here?) Best Regards, Tomi Salmi ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Bug 770610: Anyone have any suggestions on workarounds ?
On Tue, Jan 31, 2012 at 11:07:16PM +, roy.ke...@us.army.mil wrote: Bug 770610 ( https://bugzilla.redhat.com/show_bug.cgi?id=770610 ) still remains in Spacewalk and this prevents us from being able to upload packages to Spacewalk. Is anyone else experiencing this issue ? We've been able to reproduce the issue. Are there any known workarounds ? No, apart from staying with 1.5 or moving away from Solaris. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] spacewalk-repo-sync taking over a minute to report no updates needed
Hello List, I have a Spacewalk 1.6 installation that has channels with over 2000+ packages in them. With these packages the initial sync completes and all packages are in Spacewalk. When I perform additional syncs to determine if there are any new packages the sync takes over a minute to report that there are no new packages to sync. For example I have a channel with 2764 packages. The total time that is displayed on this sync was 0:01:08. This to me seems like a really long time just to report there are no updates. Is there any way to speed this sync up? Thank you for your time and have a great day! Regards, Jeremy ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Clone errata with pkgs of another channel.
Hi Pierre, I'm going to do a targeted rewrite of the offending section of code as I have time this week. I'll get it updated ASAP. Andy -Original Message- From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list- boun...@redhat.com] On Behalf Of Pierre Casenove Sent: Wednesday, February 01, 2012 1:52 AM To: red...@nmoura.eti.br; spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] Clone errata with pkgs of another channel. Hi, Any news on this one? I'm planning to add centos management in my setup..so I need this to be fixed. If you need any help, I can provide some. Andy, how do you plan to fix this? Thanks, Pierre 2012/1/27 Nilton Moura red...@nmoura.eti.br: Thank you. I'm trying to do this, but I guess you will finish early. How do you think you'll do this? With a new method or only changing the script? I'm searching a method to acomplish, but on getDetails for instance, I need to know the id. So, if I lookup with Nvrea and check the vendor or provider with getDetails, and after come back to a new lookup with Nvrea.. but I think this shouldn't work cause it will bring the same result, and sounds ugly too. Can you give me some light? Thanks. 2012/1/27 Speagle, Andy andy.spea...@wichita.edu Hi Nilton, That's a good catch. that has never been an issue for me since I don't have mixed vendors on my system. I'll get this updated and put out a patch as soon as I can. Thanks for sharing your usage case. Andy From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Nilton Moura Sent: Friday, January 27, 2012 11:49 AM To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] Clone errata with pkgs of another channel. Hi. I've been reading the python-clone-errata.py and I see that it uses the findByNvrea method. Can I create another method like this, adding vendor or provider parameter? I guess this will solve my problem, which is the first entry matched on database is returned, no matter the channel. (I debug with some prints on the script and comparing with the id's on the database). If not, the another solution (workaround), is to first upload packages from RHN than the CentOS for example (but this sounds very ugly). Thanks, Nilton Moura. 2012/1/26 Nilton Moura red...@nmoura.eti.br Hi, I'm cloning erratas from RHN with rhn-clone-errata.py 0.9.0 by Andy Speagle, but some erratas are being associated with packages from another channel (when the same package exist on CentOS for example). For example, after publish the errata RHSA-2012:0060 from rhel-5-x86_64-server, I go to Packages and the GUI shows me only one package (openssl-0.9.8e-20.el5_7.1-i686), but if I go to Packages in Manage Errata, the list appears different: openssl-0.9.8e-20.el5_7.1-i686 RHEL x86_64 Server (v. 5) rhn openssl-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates openssl-devel-0.9.8e-20.el5_7.1-i386 CentOS x86_64 (v. 5) updates openssl-devel-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates openssl-perl-0.9.8e-20.el5_7.1-x86_64 CentOS x86_64 (v. 5) updates I uploaded two prints with this to better understanding: - http://static.inky.ws/image/1180/image.jpg - http://static.inky.ws/image/1181/image.jpg If I manually remove this CentOS packages from the errata and add the corrected packages from rhel channel I correct this. Thanks, Nilton Moura. ___ 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
Re: [Spacewalk-list] centos-errata.py and announcement list format changes
On Tue, Jan 31, 2012 at 08:15:27PM +0100, David Hrbáč wrote: Dne 31.1.2012 16:38, David Nutter napsal(a): OK, a nascent version 0.8 is in the master branch at https://github.com/davidnutter/Centos-Errata Thanks, just tag it wit 0.8, so we can download the package easily. Done. I'll move the documentation across to the github Wiki when I get a minute. Regards, -- David NutterTel: +44 (0)131 650 4888 BioSS, JCMB, King's Buildings, Mayfield Rd, EH9 3JZ. Scotland, UK Biomathematics and Statistics Scotland (BioSS) is formally part of The James Hutton Institute (JHI), a registered Scottish charity No. SC041796 and a company limited by guarantee No. SC374831 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
