Re: [Spacewalk-list] OSAD - Clients not receiving actions
On Fri, Aug 05, 2011 at 08:29:53PM -0600, Jeremy Davis wrote: All, I have verified that this is DB corruption. Is there anyway to resolve this DB corruption issue? As a work-around you could try the db_recover tool from db4-utils. This should at least allow Jabber to open its databases again, rather than crashing on startup due to the DBs being in an inconsistent state. This probably isn't any better than removing the Jabber DBs though. 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
Re: [Spacewalk-list] Architecture question
Hi, the Updates channel receive all updates packages. I used this layout mostly because it was suggested for the CentOS channels, and it also matches my yum repositories as created by mrepo. For some systems I want to be able to subscribe them just to a specific Base channel (RHEL 5.x) and then adding updates later as needed. I created one main configuration channel pr. OS (we have both RHEL and Solaris systems), and then some role/application specific channels. Make sure to rank the more specific configuration channels higher than the general channel (so any common configuration files will read the more specific version). Martin Fra: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] På vegne av Pierre Casenove Sendt: 6. august 2011 09:06 Til: spacewalk-list@redhat.com Emne: Re: [Spacewalk-list] Architecture question Thanks for these useful links! There is one thing I don't understand: In the base channel you have 5.6 packages. In the update channel, with your solution, do you only have the latest version released by redhat of each package or do you have all the version released since rhel 5.6? In the first case, I can see clearly the advantage, in the second one, why don't you just put everything in the base channel? Another question, on the configuration channels: did you create many channels? just one? by arch? Your experience is more than useful for me! Thanks, Pierre 2011/8/5 Martin Eggen m...@steria.nomailto:m...@steria.no Hi, correct, my base channel is still 5.6 and the updates channel receives patches (now at 5.7). Mrepo runs daily (nightly), but I do not rebuild ISOs. Documentation for setting up mrepo with RHN is here: https://github.com/dagwieers/mrepo/blob/master/docs/redhat-network.txt Also check https://fedorahosted.org/spacewalk/browser/scripts/clone-errata/https://fedorahosted.org/spacewalk/browser/scripts/clone-errata/rhn-clone-errata.py for cloning RHN errata into your (Base) channel with rhn-clone-errata.py. You need to edit chanMap (ca line 455) to match your SPW channel name, but apart from that it was not too much work setting up. I did one errata clone with -begin-date=RHEL 5.6 release date and then I run it nightly with --begin-date=yesterday to clone new erratas. I only use rhn-clone-errata (not spw-clone-errata between local channels, yet). Martin Fra: spacewalk-list-boun...@redhat.commailto:spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.commailto:spacewalk-list-boun...@redhat.com] På vegne av Pierre Casenove Sendt: 5. august 2011 07:45 Til: spacewalk-list@redhat.commailto:spacewalk-list@redhat.com Emne: Re: [Spacewalk-list] Architecture question Hello, Thanks for the feedback. So all your system are in version 5.6 minimum and some subscribe to the updates channel, which now contains rhel 5.7 for example. Am I correct? Could you please point me to some tutorial to setup mrepo and rhn? Do you run mrepo and rebuild an iso every night or just once a week? Thanks, Pierre 2011/8/4 Martin Eggen m...@steria.nomailto:m...@steria.no Hi, I follow the advice on http://wiki.centos.org/HowTos/PackageManagement/Spacewalk also for our RHEL systems, that is, I rhnpushed 5.6 to a Base RHEL5 channel and sync updates from a yum repo (which uses mrepo to fetch updates from RHN) into a child Updates channel. This is probably redundant but I can see some uses for having separate channels (allowing some systems to only subscribe to Base for a certain minor release). I created similar channels (Base + Updates) for CentOS 5, and one child channel under each Base for EPEL. I experienced some trouble after adding CentOS though, for some reason CentOS packages were appearing in my RHEL channels, making clients system complain (invalid PGP keys) and not fetching updates. For the time being I have removed the CentOS channels/repos, but will have to make another try later. This email originates from Steria AS, Biskop Gunnerus' gate 14a, N-0051 OSLO, http://www.steria.no. This email and any attachments may contain confidential/intellectual property/copyright information and is only for the use of the addressee(s). You are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way if you are not the addressee(s) or responsible for delivery. If you receive this email by mistake, please advise the sender and cancel it immediately. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Any email is susceptible to alteration and its integrity cannot be assured. Steria shall not be liable if the message is altered, modified, falsified, or even edited. ___ Spacewalk-list mailing list Spacewalk-list@redhat.commailto:Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list This email originates from Steria
Re: [Spacewalk-list] Channel Deletion Problem - v1.4
Hey Andy, Nope, the traceback talks about database constraint RHN_ENQUEUE_CID_FK which says there are records in the rhnErrataNotificationQueue table for this channels -- it's not about channel being child or having children. Jan is correct here. But when you check: CREATE TABLE rhnErrataNotificationQueue ( errata_idNUMBER NOT NULL CONSTRAINT rhn_enqueue_eid_fk REFERENCES rhnErrata (id) ON DELETE CASCADE, org_id NUMBER NOT NULL CONSTRAINT rhn_enqueue_oid_fk REFERENCES web_customer (id) ON DELETE CASCADE, next_action DATE DEFAULT (sysdate), channel_id NUMBER NOT NULL CONSTRAINT rhn_enqueue_cid_fk REFERENCES rhnChannel(id) ON DELETE cascade, created DATE DEFAULT (sysdate) NOT NULL, modified DATE DEFAULT (sysdate) NOT NULL ) ENABLE ROW MOVEMENT ; the 'CONSTRAINT rhn_enqueue_cid_fk REFERENCES rhnChannel(id) ON DELETE cascade' shall ensure the all the rows from rhnErrataNotificationQueue get deleted together the associated channel. From my point the table definition look good. So, the question is, how did you manage to delete the channel without deleting appropriate rhnErrataNotificationQueue entries? Regards, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] OSAD - Clients not receiving actions
David, Thank you for the recommendation. I will use this command the next time jabber goes down and we will see if this is able to bring up the service. All, I have some more information. Over the weekend the remote command functionality has stayed up. I have not changed anything other than restarting the services noted in this email list. The only difference between the weekend and a weekday is users logging in and performing remote commands and package management. During the weekend the only user logging in would be my script account that performs 1 remote command every thirty minutes to determine when osad goes down. Any other thoughts as to what might be causing this issue? On Mon, Aug 8, 2011 at 3:00 AM, David Nutter dav...@bioss.ac.uk wrote: On Fri, Aug 05, 2011 at 08:29:53PM -0600, Jeremy Davis wrote: All, I have verified that this is DB corruption. Is there anyway to resolve this DB corruption issue? As a work-around you could try the db_recover tool from db4-utils. This should at least allow Jabber to open its databases again, rather than crashing on startup due to the DBs being in an inconsistent state. This probably isn't any better than removing the Jabber DBs though. 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 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Spacewalk Client 1.4 - 1.5 Upgrade, Config File Upload Fails
List: When upgrading a client from v1.4 to v1.5 and attempting to upload a config file from the client to the server, I receive a fatal python error with no success in uploading the config file to the server. The client provides the attached output in /var/log/up2date. I noticed tried applying the patch in this commit: ade5bad7b02032d32f8e62f4c16dbc6c86f670e0; however, the problem still persists. Any assistance with this would be appreciated. Thanks. Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. up2date.snippet Description: up2date.snippet ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Support for SUSE and RHEL4
Running Spacewalk 1.4 with RHEL 4.8 clients. I have seen some strange issues during the registration process. The registration appeared to be ok and the client would check in (via rhn_check) without issue but it would never show updates being available. Had to reregister every client after the initial registration to get this working. There is no yum rhn plugin as far as I know for RHEL4 so you will be back to using up2date which while it works its just not as nice as yum and it makes things inconsistent across installations. Also up2date doesnt appear to notify SW about actions that have taken place like yum does. ie: up2date install foo will not register an event in spacewalk. If you schedule from spacewalk though it works fine. Rollbacks also do not appear to work at all. On 08/05/2011 07:16 PM, Deependra Shekhawat wrote: Hi All, I am trying to see if spacewalk 1.5 can be deployed to support push updates for SLES 11 and RHEL 4.8. If someone here had configure these distributions kindly share their experiences on what are the various things we should keep in mind while going with such configuration. Thanks, Deependra ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Error 500 Spacewalk 1.5
In RHN/DB/Token.pm, you will find line like my $sth = $dbh-prepare(SELECT rhn_reg_token_seq.nextval FROM DUAL); That needs to be make database-agnostic, using the guide at https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide#Portablenextval Please send in a patch so that we can include the fix in the next version of Spacewalk. Jan thank you so much! That worked great. I was able to make the fix and I submitted the patch as well. Would you have any ideas on how to go about tackling my other errors? Thanks again, Robert ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Channel Deletion Problem - v1.4
Nope, the traceback talks about database constraint RHN_ENQUEUE_CID_FK which says there are records in the rhnErrataNotificationQueue table for this channels -- it's not about channel being child or having children. Jan is correct here. But when you check: CREATE TABLE rhnErrataNotificationQueue ( errata_idNUMBER NOT NULL CONSTRAINT rhn_enqueue_eid_fk REFERENCES rhnErrata (id) ON DELETE CASCADE, org_id NUMBER NOT NULL CONSTRAINT rhn_enqueue_oid_fk REFERENCES web_customer (id) ON DELETE CASCADE, next_action DATE DEFAULT (sysdate), channel_id NUMBER NOT NULL CONSTRAINT rhn_enqueue_cid_fk REFERENCES rhnChannel(id) ON DELETE cascade, created DATE DEFAULT (sysdate) NOT NULL, modified DATE DEFAULT (sysdate) NOT NULL ) ENABLE ROW MOVEMENT ; the 'CONSTRAINT rhn_enqueue_cid_fk REFERENCES rhnChannel(id) ON DELETE cascade' shall ensure the all the rows from rhnErrataNotificationQueue get deleted together the associated channel. From my point the table definition look good. So, the question is, how did you manage to delete the channel without deleting appropriate rhnErrataNotificationQueue entries? Actually, I haven't been able to delete the channel. spacewalk-remove-channel only handles base-channels seemingly (unless I'm missing some magic). And the WebUI is apprarently unable to do the work at present due to things previously mentioned in this thread. Andy ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Support for SUSE and RHEL4
On Mon, Aug 8, 2011 at 9:29 PM, Jason M. Nielsen jniel...@myriad.comwrote: Running Spacewalk 1.4 with RHEL 4.8 clients. I have seen some strange issues during the registration process. The registration appeared to be ok and the client would check in (via rhn_check) without issue but it would never show updates being available. Had to reregister every client after the initial registration to get this working. There is no yum rhn plugin as far as I know for RHEL4 so you will be back to using up2date which while it works its just not as nice as yum and it makes things inconsistent across installations. Also up2date doesnt appear to notify SW about actions that have taken place like yum does. ie: up2date install foo will not register an event in spacewalk. If you schedule from spacewalk though it works fine. Rollbacks also do not appear to work at all. Thanks for the input. For the time being we have only 2 RHEL 4.8 machines so we are keeping it on hold. I wonder if we will be able to install the latest spacewalk client in SLES 11 SP1 because the version of python there is 2.6 on the other hand spacewalk asks for python 2.7 Also for RHEL 5.5 , we have both x86_64 and i386, will I be able to sync with RHN both of them , specially the updates channel , via mrepo. Currently I am syncing the x86_64 channel. On 08/05/2011 07:16 PM, Deependra Shekhawat wrote: Hi All, I am trying to see if spacewalk 1.5 can be deployed to support push updates for SLES 11 and RHEL 4.8. If someone here had configure these distributions kindly share their experiences on what are the various things we should keep in mind while going with such configuration. Thanks, Deependra __**_ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/**mailman/listinfo/spacewalk-**listhttps://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] Spacewalk API using PHP
List, I am looking to use php for a web tool that I am creating that uses the Spacewalk API. I was wanting to know if anyone has used PHP to work with the Spacewalk API and if so could provide me some example code and libraries used. Any assistance you could provide would be greatly appreciated. Thanks, Jeremy ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
