Re: [Spacewalk-list] centos-errata.py and announcement list format changes
On Thu, Feb 02, 2012 at 06:30:17PM +, Lopez, Abel wrote: I was able to process the 2012-January file using the 0.2 version of the errata script. Few steps required. I changed my channel type to sha256 for both my base and update channel, I did a simple `sed -ie 's/CentOS 6/CentOS 6 x86_64' 2012-January.txt` So there isn't a valid reason why spacewalk search can't work. That is good to know. I will try changing my own channel types and if successful will activate both the affected search strategies. 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] centos-errata.py package_dir value
On Wed, Feb 08, 2012 at 12:34:42PM +, Peter Purvis wrote: Thanks Ege, I've just tried against our updates repo, which it turns out is really out of date which in turn causes the script to fail as it can't find the packages. Will grab a more recent sync now and see if that works. Seems a bit counter intuitive that the packages are needed for the errata script to work? Perhaps someone can explain the process. Basically the script needs the package NVREA that spacewalk has in order to find the package and associate it with the errata. The only way to get this reliably is to extract it from the RPM itself. So you need the updates repo for this to work. In the past it was possible to search spacewalk itself using the package checksum to find packages. However, changes to the format of the centos-announce list (namely use of sha256 signatures) have broken this, at least for those of us with channels with their base signature type set to md5sum. Other posters to this list have indicated that changing the channel signature type makes all well again but I have yet to test this myself. Other approaches such as indexing /var/satellite directly have been proposed as well. I've yet to evaluate any of these. 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] 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
Re: [Spacewalk-list] centos-errata.py and announcement list format changes
On Fri, Jan 27, 2012 at 09:34:45PM +0100, David Hrbáč wrote: Dne 23.1.2012 12:24, David Nutter napsal(a): OK, a new release (0.7) is out which should correct this problem. Thanks to Stefan F??rster for reporting this issue and testing the fix. http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Regards, David, Thanks, it works now for me. A few points: - I'm running it on C5, had to install C4 and C6 signing keys. Did not need to with previous version. Odd. I don't think I check the signature anywhere, at least not directly. Best advice is to run all pushes on Centos6 I guess. We're still on 5 here so I must admit this aspect of the script is somewhat untested. - Did not helped for C6, since C5 rpm is not capable to work with C6 rpms. :o( So it imports the errata but keeps complaining: .snip error: rpmts_HdrFromFdno: Header V4 RSA/SHA1 signature: BAD, key ID c105b9de process_pkg_file failed with exception error reading package header. Traceback (most recent call last): File ./centos-errata.py, line 1104, in processRPMFile header = rpmQuery.hdrFromFdno(fd) error: error reading package header Warning: package /var/satellite/redhat/strace-4.5.19-1.11.el6_2.1.x86_64.rpm does not exist or cannot be read. Searching for package strace-4.5.19-1.11.el6_2.1.x86_64.rpm failed Skipping errata CEBA-2012:0028 ..snip - I'm attaching the patch to work with mail-archive. Great, thanks. I will apply that with a slight tweak - first change should be to the constant MessageMailArchive.MAILARCHIVE_BASE rather than the string literal. - Are you willing to go to GitHub with script development? Yes indeed! I should have done this months ago. I shall try and sort out an account later on today and will post a further reply once I've got everything working. 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] centos-errata.py and announcement list format changes
On Tue, Jan 31, 2012 at 11:12:49AM +, David Nutter wrote: *snip* - Are you willing to go to GitHub with script development? Yes indeed! I should have done this months ago. I shall try and sort out an account later on today and will post a further reply once I've got everything working. OK, a nascent version 0.8 is in the master branch at https://github.com/davidnutter/Centos-Errata This includes: + fixes to the compile errors in error messages + patch to fix mailarchive.com parsing; my apologies for this error - I only tested with static testdata due to the SOPA blackout of mailarchive.com on the day I released version 0.7 and hence didn't exercise the problem code path. + Changed paths to testdata + Added various boilerplate text files. I'll get the docs on http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ updated just as soon as I may and port those documents into the git repo as well. At the moment I drive git like a granny so progress may be a little slow :) 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] centos-errata.py and announcement list format changes
On Thu, Jan 19, 2012 at 12:23:58PM +, David Nutter wrote: On Wed, Jan 18, 2012 at 06:54:47PM +, David Nutter wrote: *snip* I've been informed by a couple of people that there's a bug which occurs when using multiple architecture flavours of CentOS (e.g. x86_64 and i386) together. Essentially you only get errata published for the first one listed. Unfortunately I can't test this scenario as we're x86_64 only here so a fix will take a little while as any changes will have to be tested by an affected user. Working on it though :) OK, a new release (0.7) is out which should correct this problem. Thanks to Stefan F??rster for reporting this issue and testing the fix. http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ 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] centos-errata.py and announcement list format changes
On Wed, Jan 18, 2012 at 06:54:47PM +, David Nutter wrote: *snip* A new release is now available (finally): http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Due to format changes in the centos-announce mailing lists, the parsing logic has been completely rewritten. It's still horrible though :) Also, you will now have to use the dir package search strategy as the other two strategies spacewalk and satellitedir both rely on obtaining the md5sum from the centos-announce mailings. Since upstream now sends sha256 checksums these techniques can't work. I note with interest various discussions on the CentOS lists about making errata available in a more useful form. Hopefully my script won't be required for too much longer. Hi folks, I've been informed by a couple of people that there's a bug which occurs when using multiple architecture flavours of CentOS (e.g. x86_64 and i386) together. Essentially you only get errata published for the first one listed. Unfortunately I can't test this scenario as we're x86_64 only here so a fix will take a little while as any changes will have to be tested by an affected user. Working on it though :) Thanks 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] centos-errata.py and announcement list format changes
On Thu, Jan 19, 2012 at 11:49:43AM +, richard rigby wrote: hi david, excellent work - have just downloaded and updated, and all seems to be working well again, thanks for your efforts. Thanks :) i noticed there is a new requirement for python-lxml, which we didn't have installed, but all is now back up and running. Ah yes, that's just to aid the screen scraping of stuff downloaded from the RedHat site. I will mention it in the docs for version 0.7. Release is hopefully imminent, just awaiting test results now. 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] centos-errata.py and announcement list format changes
On Wed, Jan 04, 2012 at 08:54:16PM +, David Nutter wrote: Hi folks, As some of you may have noticed the format of the centos-announce messages has changed, thus breaking my script that creates errata for them (http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/) I am working on a fix but unfortunately the changes required are fairly involved so it may be a day or two before I have a release ready and tested. Apologies for any inconvenience you may experience in the meantime. Hi folks, A new release is now available (finally): http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Due to format changes in the centos-announce mailing lists, the parsing logic has been completely rewritten. It's still horrible though :) Also, you will now have to use the dir package search strategy as the other two strategies spacewalk and satellitedir both rely on obtaining the md5sum from the centos-announce mailings. Since upstream now sends sha256 checksums these techniques can't work. I note with interest various discussions on the CentOS lists about making errata available in a more useful form. Hopefully my script won't be required for too much longer. 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] Spacewalk 1.5 Monitoring issue
On Thu, Aug 11, 2011 at 10:30:48AM +0200, Jan Pazdziora wrote: thank for the awesome investigation. While there is a problem in IPC::Open3, it did not affect previous Spacewalk versions, so I digged around some more and I believe I caused it with my past commit. Could you please apply http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=32073ab4de72201e79ba587ee268ca0888247587 to see if it fixes the problem on your Spacewalk? Indeed it does fix it! As simple as that, eh? Thanks Jan. 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] Spacewalk 1.5 Monitoring issue
On Thu, Aug 11, 2011 at 11:57:40AM +0200, Jan Pazdziora wrote: On Thu, Aug 11, 2011 at 10:40:19AM +0100, David Nutter wrote: On Thu, Aug 11, 2011 at 10:30:48AM +0200, Jan Pazdziora wrote: thank for the awesome investigation. While there is a problem in IPC::Open3, it did not affect previous Spacewalk versions, so I digged around some more and I believe I caused it with my past commit. Could you please apply http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=32073ab4de72201e79ba587ee268ca0888247587 to see if it fixes the problem on your Spacewalk? Indeed it does fix it! As simple as that, eh? Thank you for the confirmation. With this hurdle out of the way -- is monitoring in working shape for you or are there some other known issues? It's working well enough for my needs now. I can create new probes, do a config push, all my probes are updating and I get notifications when probe thresholds are reached. That's all I really need. I'm currently building new packages to nightly with the changes that were circulated on the mailing list (mostly) applied and I will give it a try later. But if there are some scenarios that we should focus on, please let us know. Great. When the nightly packages are available tomorrow I'll give them a go. 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] 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] Spacewalk 1.5 Monitoring issue
On Fri, Aug 05, 2011 at 11:48:01AM +0530, trm asn wrote:
*snip*
Here I am getting another error after changing the above mentioned
parameters,
Status: UNKNOWN, The RHN Monitoring Daemon (RHNMD) is not responding: Auto
configuration failed 11851:error:0200100D:system library:fopen:Permission
denied:bss_file.c:122:fopen('/etc/pki/tls/openssl.cnf','rb')
11851:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:127:
11851:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:199:. Please make sure the daemon is running and the host is
accessible from the monitoring scout. Command was: /usr/bin/ssh -l nocpulse
-p 4545 -i /var/lib/nocpulse/.ssh/nocpulse-identity -o
StrictHostKeyChecking=no -o BatchMode=yes 192.169.1.20 /bin/sh -s
Have you got SELinux in enforcing mode? If so check your audit log. I
think you'll find that the security context for the monitoring scout
isn't allowed to access files with a context of cert_t like
/etc/pki/tls/openssl.cnf
Looks like the spacewalk selinux policy needs a tweak as well.
I'm currently running in Disabled mode so I don't have sample messages
to hand to confirm this hunch.
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] Spacewalk 1.5 Monitoring issue
On Fri, Aug 05, 2011 at 04:54:26PM +0200, Jan Pazdziora wrote: I assume the problem is that your scout config push does not finish. Could you check if patch at http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=6483c7e7e912df6cf60ad792c3e6de43431ff0d8 would improve things for you? I still need to investigate your patch some more. Hi, I already have locally-applied config that's similar to what's in the above patch so my scout config push was fine, and has been since I fiddled with 1.4. Anyway, I'll change my rhn_monitoring.conf to match that in the commit. My problem was that probes weren't updating due to the issue with IPC::Open3. Apologies if all my messages have caused confusion. 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] Spacewalk 1.5 Monitoring issue
On Tue, Aug 02, 2011 at 07:34:46PM +0100, David Nutter wrote: On Tue, Jul 26, 2011 at 11:27:19AM +0530, trm asn wrote: *snip* 'ProbeRecord', 'get_hostAddress') ; that error I have resolved by editing NPRecords.pm changed the parameter hostAddress to HOSTADDRESS . now my scout config push are getting success, but unfortunately still the monitoring status is PENDING, Awaiting Update . -bash-3.2$ rhn-runprobe --probe=261 --log=all=4 Can't locate object method hostname via package NOCpulse::Probe::Config::ProbeRecord at blib/lib/Class/MethodMaker/Engine.pm (autosplit into blib/lib/auto/Class/MethodMaker/Engine/new.al) line 941. Any idea... Hi, *snip* After a bit more digging I've narrowed down the problem area. The method NOCpulse::Probe::Shell::Unix::connect seems to be failing when running under the scheduler but not when running under rhn-runprobe. I jacked up logging for NOCpulse::Probe::Shell::Unix and this is what I see in kernel-err.log when monitoring is running (sorry for the mess, there seem to be two different logging frameworks in use which causes weird things to happen like multiple timestamps): 2011-08-04 12:31:44 2011-08-04 12:31:43 NOCpulse::Probe::Shell::Unix::connect Execute '/usr/bin/ssh -l nocpulse -p 4545 -i /var/lib/nocpulse/.ssh/nocpulse- identity -o StrictHostKeyChecking=no -o BatchMode=yes 212.219.57.230 /bin/sh -s' 2011-08-04 12:31:44 2011-08-04 12:31:43 NOCpulse::Probe::Shell::Unix::connect Opened pipe to 21109 2011-08-04 12:31:44 2011-08-04 12:31:43 (eval) Sending echo `uname -s`#`uname -r`#$$ 2011-08-04 12:31:44 echo NOCPULSE-1312457503-STATUS $? 2011-08-04 12:31:44 2011-08-04 12:31:44 2011-08-04 12:31:43 (eval) Done 2011-08-04 12:31:44 2011-08-04 12:31:43 NOCpulse::Probe::Shell::Unix::read_result stdout: 2011-08-04 12:31:44 2011-08-04 12:31:43 NOCpulse::Probe::Shell::Unix::read_result stderr: 2011-08-04 12:31:44 2011-08-04 12:31:43 NOCpulse::Probe::Shell::Unix::read_result status: 2011-08-04 12:31:44 2011-08-04 12:31:44 NOCpulse::Probe::Shell::Unix::connect Opened pipe to 2 2011-08-04 12:31:44 2011-08-04 12:31:44 (eval) Sending echo `uname -s`#`uname -r`#$$ 2011-08-04 12:31:44 echo NOCPULSE-1312457504-STATUS $? 2011-08-04 12:31:44 2011-08-04 12:31:44 2011-08-04 12:31:44 (eval) Done 2011-08-04 12:31:44 2011-08-04 12:31:44 NOCpulse::Probe::Shell::Unix::read_result stdout: 2011-08-04 12:31:44 2011-08-04 12:31:44 NOCpulse::Probe::Shell::Unix::read_result stderr: 2011-08-04 12:31:44 2011-08-04 12:31:44 NOCpulse::Probe::Shell::Unix::read_result status: 2011-08-04 12:31:44 Linux#2.6.18-238.12.1.el5xen#2834 2011-08-04 12:31:44 NOCPULSE-1312457503-STATUS 0 However, when run under rhn-runprobe --log=all=4 I get the expected output of: 2011-08-04 12:36:40 NOCpulse::Probe::Shell::Unix::connect Execute '/usr/bin/ssh -l nocpulse -p 4545 -i /var/lib/nocpulse/.ssh/nocpulse-identity -o StrictHostKeyChecking=no -o BatchMode=yes 212.219.57.233 /bin/sh -s' 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::connect Opened pipe to 22504 2011-08-04 12:36:41 (eval) Sending echo `uname -s`#`uname -r`#$$ echo NOCPULSE-1312457801-STATUS $? 2011-08-04 12:36:41 (eval) Done 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::read_result Read 32 bytes from 6: Linux#2.6.18-238.12.1.el5#16885 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::read_result Read 29 bytes from 6: NOCPULSE-1312457801-STATUS 0 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::read_result stdout: Linux#2.6.18-238.12.1.el5#16885 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::read_result stderr: 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::read_result status: 0 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::connect OS Linux 2.6.18-238.12.1.el5, shell pid 16885 2011-08-04 12:36:41 NOCpulse::Probe::Shell::Unix::connect OK ... What seems to be happening on the scheduler is the command's STDOUT is getting written to the logfile and not read by Unix::read_result. In the first trace you can see this in the last two log lines: 2011-08-04 12:31:44 Linux#2.6.18-238.12.1.el5xen#2834 2011-08-04 12:31:44 NOCPULSE-1312457503-STATUS 0 So, somewhere STDOUT is being redirected in such a way that it's interfering with the STDOUT of all the children. I'll see if I can find out why. Incidentally, the files in the TSDBLocalQueue I mentioned earlier are a red herring - they seem to contain the output from when the probe last worked properly but with the current time, for some reason. Nevertheless, they do actually get loaded into the DB (verified with SQLplus) so I think it's just the problems with output streams that are causing monitoring not to work. 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
Re: [Spacewalk-list] Spacewalk 1.5 Monitoring issue
On Thu, Aug 04, 2011 at 12:41:13PM +0100, David Nutter wrote: On Tue, Aug 02, 2011 at 07:34:46PM +0100, David Nutter wrote: On Tue, Jul 26, 2011 at 11:27:19AM +0530, trm asn wrote: *snip* 'ProbeRecord', 'get_hostAddress') ; that error I have resolved by editing NPRecords.pm changed the parameter hostAddress to HOSTADDRESS . now my scout config push are getting success, but unfortunately still the monitoring status is PENDING, Awaiting Update . -bash-3.2$ rhn-runprobe --probe=261 --log=all=4 Can't locate object method hostname via package NOCpulse::Probe::Config::ProbeRecord at blib/lib/Class/MethodMaker/Engine.pm (autosplit into blib/lib/auto/Class/MethodMaker/Engine/new.al) line 941. Any idea... Hi, *snip* After a bit more digging I've narrowed down the problem area. The method NOCpulse::Probe::Shell::Unix::connect seems to be failing when running under the scheduler but not when running under rhn-runprobe. *snip* What seems to be happening on the scheduler is the command's STDOUT is getting written to the logfile and not read by Unix::read_result. In the first trace you can see this in the last two log lines: 2011-08-04 12:31:44 Linux#2.6.18-238.12.1.el5xen#2834 2011-08-04 12:31:44 NOCPULSE-1312457503-STATUS 0 Got it. At long last. We're being bitten by this perl bug: https://rt.perl.org/rt3/Public/Bug/Display.html?id=66224 The test script there does indeed fail on my CentOS 5.6 system. Reason is that Process.pm redirects STDOUT and STDERR before spawning the probe runner. Then, the STDOUT of any subsequent processes (e.g. those started by open3 in Unix.pm) ends up going to STDOUT, not the IO::Handle created for it to write to. I believe rhn-runprobe doesn't exhibit the problem because it doesn't use Process.pm just calls the ProbeRunner directly. Anyway, applying the patch below from the perl bug report does indeed fix the problem on my spacewalk. All probes now update in the web UI and appear to be recording data. --- Open3.pm.~1~2005-03-19 18:43:52.0 +0100 +++ Open3.pm2010-04-29 10:30:54.0 +0200 @@ -200,6 +200,9 @@ # A tie in the parent should not be allowed to cause problems. untie *STDIN; untie *STDOUT; +open(STDOUT, =1); +open(STDERR, =2); + # If she wants to dup the kid's stderr onto her stdout I need to # save a copy of her stdout before I put something else there. if ($dad_rdr ne $dad_err $dup_err Question is, do I file a bug against RHEL5 or look at rewriting the logic in UnixCommand.pm to work around the issue? I hardly think that patching core perl modules is a sensible thing to do on a production server! 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] Spacewalk 1.5 Monitoring issue
On Tue, Jul 26, 2011 at 11:27:19AM +0530, trm asn wrote:
*snip*
'ProbeRecord', 'get_hostAddress') ; that error I have resolved by editing
NPRecords.pm changed the parameter hostAddress to HOSTADDRESS .
now my scout config push are getting success, but unfortunately still the
monitoring status is PENDING, Awaiting Update .
-bash-3.2$ rhn-runprobe --probe=261 --log=all=4
Can't locate object method hostname via package
NOCpulse::Probe::Config::ProbeRecord at
blib/lib/Class/MethodMaker/Engine.pm (autosplit into
blib/lib/auto/Class/MethodMaker/Engine/new.al) line 941.
Any idea...
Hi,
I've worked around/fixed the above error, and the error where
rhn-catalog output is missing probe details by changing
NOCPulse::Probe::Config::ProbeRecord
and /var/lib/nocpulse/libexec/ProbeCatalog.pm as per the patches
below. For information only, I don't recommend that anyone apply these
to a production install!
--- ProbeRecord.pm.orig 2011-08-02 19:27:20.0 +0100
+++ ProbeRecord.pm 2011-08-02 19:26:57.0 +0100
@@ -54,6 +54,8 @@
contactGroupCustomers = 'contact_group_customers',
contactGroupNames = 'contact_group_names',
hostAddress = 'host_ip',
+ HOSTADDRESS = 'host_ip',
+ HOSTNAME = 'host_name',
hostName = 'host_name',
hostRecid = 'host_id',
parsedCommandLine = 'parameters',
--- ProbeCatalog.pm.orig2011-08-02 19:27:41.0 +0100
+++ ProbeCatalog.pm 2011-08-02 19:25:58.0 +0100
@@ -35,10 +35,10 @@
my $result;
if ($probe_id) {
$result = $probeHashRef-{RECID}.' '.$probeHashRef-{PROBE_TYPE};;
- if ($probeHashRef-{hostName}) {
- $result .= ' on '.$probeHashRef-{hostName}.'
('.$probeHashRef-{hostAddress}.')';
+ if ($probeHashRef-{HOSTNAME}) {
+ $result .= ' on '.$probeHashRef-{HOSTNAME}.'
('.$probeHashRef-{HOSTADDRESS}.')';
} else {
- $result .= ' on '.$probeHashRef-{hostAddress};
+ $result .= ' on '.$probeHashRef-{HOSTADDRESS};
}
$result .= ': '.$probeHashRef-{DESCRIPTION};
So, now I can run a probe from the commandline and get correct results
but my probes still won't update as far as the UI is concerned.
I can even see the correct probe output is being placed in files like
/var/log/nocpulse/TSDBLocalQueue/queue/1312307617.13995
containing
1-33-latency,1312307616,0.367097
1-102-latency,1312307654,1.467809
1-40-load5,1312308198,2.02
1-40-load15,1312308198,2.00
1-40-load1,1312308198,2.00
1-39-nusers,1312308227,3
1-40-load5,1312308227,2.02
1-40-load15,1312308227,2.00
1-40-load1,1312308227,2.00
1-29-latency,1312308229,1.233025
1-39-nusers,1312308242,3
1-102-latency,1312308240,0.120207
1-31-latency,1312308242,0.940315
1-29-latency,1312308448,0.0258
1-40-load5,1312309441,2.02
1-40-load15,1312309441,2.00
1-40-load1,1312309441,2.00
1-32-pingtime,1312309441,0.2177
1-32-pctlost,1312309441,0
1-32-pingtime,1312309868,0.2177
1-32-pctlost,1312309868,0
so it's mostly working.
Any ideas where to go next? It seems that the probe outputs are not
being properly loaded into the DB after execution completes.
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] For info: rhnpush has implicit dependency on spacewalk-backend
Hi, We have rhnpush installed on a number of machines without the rest of the spacewalk libraries to allow various people to put packages on the spacewalk server. The version of rhnpush now in EPEL conflicts with the latest spacewalk client tools so I removed it and replaced it with the one from 1.4-server On running the new version of rhnpush, I got the message: Unable to load module rhnpush No module named UserDictCase To fix this I needed to install: spacewalk-backend-1.4.39-1.el5.noarch.rpm plus its dependencies: perl-Satcon-1.14-1.el5.noarch.rpm spacewalk-config-1.4.4-1.el5.noarch.rpm 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] monitoring-data-cleanup fails: Already in transaction
Hi,
Spacewalk 1.4, CentOS 5.6. Here's what I get when I run:
/usr/bin/monitoring-data-cleanup --no-delete-unmatched --keep-monitoring-data
1 month
Deleting probes data older than 10:50:35 Apr 16, 2011...
RHN::Exception: DBD::Oracle::db begin_work failed: Already in a transaction
RHN::DB /usr/lib/perl5/vendor_perl/5.8.8/RHN/DB.pm 228
RHN::Exception::DB::throw
main /usr/bin/monitoring-data-cleanup 128 RHN::DB::handle_error
Stripping monitoring-data-cleanup down to the following gives the same
error:
--
#!/usr/bin/perl
use strict;
use lib '/etc/rc.d/np.d';
use NOCpulse::NOCpulseini;
use PhysCluster;
my $cluster = PhysCluster-newInitialized('/etc/rhn/cluster.ini');
my $localConfig = $cluster-get_LocalConfig;
my $ini = NOCpulse::NOCpulseini-new;
if (%$localConfig) {
$ini-connect();
} else {
print Error: This script can be run only on monitoring
backend.\n;
exit 1;
}
$ini-dbh-begin_work;
---
Any ideas where I should start looking? I can't see anything in
RHN/DB.pm that would lead to a transaction being created implicitly
during connect(). Also, if I do:
$ini-dbh-rollback;
$ini-dbh-begin_work;
I still get the error on begin_work. There don't seem to be any
transactions pending in v$transaction. Any thoughts?
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] monitoring-data-cleanup fails: Already in transaction
On Mon, May 16, 2011 at 01:23:03PM +0200, Jan Pazdziora wrote: Could you please just delete / comment out the $ini-dbh-begin_work; calls -- the database handle now is not autocommit-ing, so that begin_work call is not needed anymore. Aha, thanks :) I assume now that autocommit is on that --dry-run as currently coded has no effect as it requires a transaction rollback? 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] monitoring-data-cleanup fails: Already in transaction
On Mon, May 16, 2011 at 01:54:00PM +0200, Jan Pazdziora wrote: On Mon, May 16, 2011 at 12:35:49PM +0100, David Nutter wrote: I assume now that autocommit is on that --dry-run as currently coded has no effect as it requires a transaction rollback? The AutoCommit is off. Any other database operations are now transactional even if they were AutoCommitting in the past. Oh dear, I seem to have a bad case of Monday Brain! Apologies for failing to read your post properly. Which I suspect might also be the cause of the other problems that you've reported with monitoring in Spacewalk 1.4. Sadly, I was not able to find the time needed to investigate that theory more. If you have a Spacewalk server where you could check it, that would be great. I shall certainly have a look. A quick grep in current master sources shows no references to begin_work in the monitoring code but I'll compare with what's on my server. Thanks 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] For information: python-sgmlop package and spacewalk XMLRPC problems
Hi folks, For some reason I had python-sgmlop kicking around on my spacewalk server. I think it might have been used by spacewalk itself way back when, looking at the date of the package install: [davidn@spacewalk ~]$ rpm -qi python-sgmlop Name: python-sgmlopRelocations: /usr Version : 1.1.1 Vendor: Fredrik Lundh fred...@pythonware.com Release : 20040207.15.el5 Build Date: Wed 14 May 2008 14:36:22 BST Install Date: Wed 10 Sep 2008 13:00:02 BST Build Host: ls20-bc2-14.build.redhat.com Group : Development/Libraries Source RPM: python-sgmlop-1.1.1-20040207.15.el5.src.rpm Size: 16912License: BSD Signature : DSA/SHA1, Thu 03 Jul 2008 14:36:20 BST, Key ID 95423d4e430a1c35 Packager: Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : http://www.effbot.org/zone/sgmlop-index.htm Summary : SGMLOP -- a small and fast SGML/XML parser Anyway, it isn't in use now. This package being there hadn't caused a problem in the past but on upgrading to spacewalk 1.4 nothing which used the XMLRPC interface (client tools, rhnpush etc would work). In ssl_error_log on the spacewalk server I'd get a big stack trace ending with: [Wed May 11 14:56:52 2011] [error] [client 212.219.57.224] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File /usr/lib/python2.4/site-packages/spacewalk/server/apacheRequest.py, line 64, in __init__\nself.parser._parser.returns_unicode = 0 [Wed May 11 14:40:17 2011] [error] [client 212.219.57.197] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: AttributeError: SgmlopParser instance has no attribute '_parser' Clients would see errors like: XMLRPC ProtocolError: ProtocolError for spacewalk.bioss.sari.ac.uk /XMLRPC: 500 Internal Server Error when running interactively and in /var/log/up2date: [Wed May 11 14:29:42 2011] up2date Error communicating with server. The message was: Internal Server Error You get the picture. This change appears to be the one that kicked off the error: https://fedorahosted.org/spacewalk/changeset/d3fbbbec76e3c983bfd947ba4d6a4a0682508c81 Anyway, deleting the package and restarting the spacewalk service got everything working again. Possibly spacewalk-backend-server should conflict with python-sgmlop or explicitly check the parser type it is working with before setting unicode behaviour. However, it's probably not worth bothering with since python-sgmlop isn't exactly widely distributed from what I can see. Regards, -david PS The chap who posted about error generated when running rhn_check on client back in April might be having this problem, or something similar. -- 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] 1.2 to 1.4 upgrade oracle conflicts
On Wed, May 11, 2011 at 10:42:53AM -0600, Jason M. Nielsen wrote: Other than jabberd and osad this is a perfectly working SW 1.2 install. The oracle server is a completely separate server. Following the https://fedorahosted.org/spacewalk/wiki/HowToUpgrade. Im seeing major issues with dep problems. Are we supposed to be upgrading the oracle instant client to 11? Although some of the spacewalk repo oracle files appear to be 10.2 and others 11 but none are the same. Looking for suggestions. Hi, You should probably upgrade via 1.3 first. See: https://fedorahosted.org/spacewalk/wiki/HowToUpgrade13 That will walk you through the oracle update step, and will also allow you time to catch any errors that may occur in the 1.2-1.3 upgrade. 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] CentOS 5.6 FASTTRACK errata and centos-errata.py
On Wed, May 04, 2011 at 05:31:30PM +0100, David Nutter wrote: Hi folks, Since CentOS upstream has started including these RPMS in their announcements, I was wondering if anyone is interested in pushing these errata types to spacewalk using my script (https://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/)? We don't use the FastTrack RPMS ourselves but realise they may be of community interest. The changes should be trivial; at present the regex doesn't like the subject line and there's no way to specify a specific fasttrack channel in which to place these errata. Let me know what you think. If there's no interest I probably won't bother implementing this feature. Hello again, A new version of the script with FastTrack support, configurable search strategies (so you can choose to use a spacewalk, a directory of packages or both and in any order you like) and a man page is now available here: http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/0.3/ Comments welcome. Regarding erratas which fail to be created, this is usually caused by the input emails not being formatted as the script expects. In the recent 5.6 update round there were the following problem messages: CESA-2011:0472, CESA-2011:0471, CESA-2011:0474: Missing Severity field CESA-2011:474, CEBA-2011:470: Errata ID is not four digits Both issues could be corrected by manually editing the input emails. Short of the updateinfo.xml file mentioned by another poster there's not much I can do about this. CentOS are usually very good about keeping their emails in a consistent format though, so it is rarely a huge issue. 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] CentOS 5.6 FASTTRACK errata and centos-errata.py
Hi folks, Since CentOS upstream has started including these RPMS in their announcements, I was wondering if anyone is interested in pushing these errata types to spacewalk using my script (https://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/)? We don't use the FastTrack RPMS ourselves but realise they may be of community interest. The changes should be trivial; at present the regex doesn't like the subject line and there's no way to specify a specific fasttrack channel in which to place these errata. Let me know what you think. If there's no interest I probably won't bother implementing this feature. 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] Connecting para-virtual clients?
On Thu, Jan 13, 2011 at 05:01:04PM -0500, Gomes, Rich wrote: Hello all - Has anyone had any luck connecting pararvirtualized clients to Spacewalk? I can register machines but they do not get assigned to a channel. Also xen kernels are not an available option when creating a new channel. What are my options here? Yes, no problems here (CentOS 5.5, Spacewalk 1.0), but I don't provision new systems using spacewalk. Once built the guests register fine and are shown as virtual guests in the systBem view. I'm assuming by xen kernels are not an available option when creating a new channel this is to do with creating a kickstart distribution rather than a package channel? 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] osad error - request to start session in non-serviced domain
On Tue, Nov 23, 2010 at 03:04:03PM +0100, David Hrbáč wrote: *snip* I have been trying to recreate instance for jabberd with: rm /var/lib/jabberd/db -rf rpm -e jabberd --nodeps yum install jabberd spacewalk-setup-jabberd --macros hostname:spacewalk.vsb.cz --verbose *snip* Is there someone successfully running jabberd and osad on Centos 5.5 64bit? Configuration is: [r...@spacewalk ~]# rpm -q jabberd jabberpy osad spacewalk-setup spacewalk-setup-jabberd jabberd-2.2.11-1.el5 jabberpy-0.5-0.17.el5 osad-5.9.38-1.el5 spacewalk-setup-1.1.14-1.el5 spacewalk-setup-jabberd-1.1.1-1.el5 Yes, I am, but I'm not running osad on the spacewalk server, just osa-dispatcher. ISTR that osad doesn't work on the spacewalk server but can't find a reference to this limitation so may well be wrong. For reference I have the following packages installed on my production box but I'm lagging behind at spacewalk 1.0 for now so they're a bit older than yours. rpm -q jabberd jabberpy osad osa-dispatcher spacewalk-setup spacewalk-setup-jabberd jabberd-2.2.8-2.el5 jabberpy-0.5-0.17.el5 package osad is not installed osa-dispatcher-5.9.31-1.el5 spacewalk-setup-1.0.1-1.el5 spacewalk-setup-jabberd-1.0.1-1.el5 If you think it may help I can post my Jabber config files to pastebin or something but I suspect the difference in versions may make this pointless. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] An issue with Centos client with Spacewalk server for updating packages.
On Tue, Nov 16, 2010 at 10:48:44PM -0600, Krishnakumar Dharmarajan wrote: Hello Team, I am having an issue with Centos client with Spacewalk server for updating packages. I have a CentOS updates/Base/Epel channel which follows the updates as they come from CentOS. I have a client that was installed as CentOS 5.3 and is subscribed to this Base/Updates channel. I can see updates outstanding for it but when i try to apply those updates, it is not showing the repository at client system. Yum repolist shows nothing Sounds like rhnplugin is broken in some way (disabled in /etc/yum/pluginconf.d/rhnplugin.conf?), but maybe there's another explanaiton: I did have a system that lost its registration credentials for the server and then behaved a bit like that. Is the system checking in? If not then it could have lost its registration creds. Also, what happens if you schedule an action at the server and run rhn_check - If you get authentication errors then maybe try reregistering the system and deleting its old profile. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] deleting packages
On Wed, Nov 03, 2010 at 12:45:52PM +0100, Marcus Moeller wrote: Hi all, we got now about 60.000 packages in no channel (due to deletion of old Fedora releases). It is not possible to delete them, neither via gui nor via api (which stucks during channel.software.listPackagesWithoutChannel either with a 502 Proxy Error, a connection timeout or a 500 Internal Server Error). Any idea how to get rid of these packages? When deleting old releases I find I have to do them bit by bit rather than all at once. I've encountered two errors caused by trying to delete large numbers of packages all at once and leading to a 500 error. Never seen a 502 in this situation though. The errors are 1) Oracle's UNDO tablespace is exhausted. Give it some more, this doesn't count to your 4Gb limit 2) The delete process itself takes too long to run, and causes a timeout. This is the situation where deleting in small batches may help. In my case at least at least part of the problem is a slightly underspecced VM for spacewalk: for most operation it's fine but big pushes or deletions seem to overstretch it. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] applying CESA-2010:0737 Important: freetype Update to x86_64 hosts doesn't work
On Thu, Oct 28, 2010 at 10:27:40AM -0400, Yungwei Chen wrote: Hi, I noticed that applying CESA-2010:0737 Important: freetype Update to 64-bit hosts doesn't work although spacewalk web UI said that action was completed successfully. One thing is that the packages associated with CESA-2010:0737 are for 32-bit hosts. I am wondering if this is the root cause of this problem. Did this happen to you as well? How can I fix it? Thanks. The packages associated with CESA-2010:0737: CentOS 5 Base - i386 md5:f74574c523f4fd9dbb493a64813aca87 freetype-2.2.1-28.el5_5-i386 md5:bc7dad9ba9e83cbc51a543c2eb4232ca freetype-demos-2.2.1-28.el5_5-i386 md5:b74f98b95c1915c92e01d91a131d251e freetype-devel-2.2.1-28.el5_5-i386 CentOS 5 Base - x86_64 md5:f74574c523f4fd9dbb493a64813aca87 freetype-2.2.1-28.el5_5-i386 md5:b74f98b95c1915c92e01d91a131d251e freetype-devel-2.2.1-28.el5_5-i386 Hi, I'm assuming you are using the centos-errata script from http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/. If not then I probably can't help. Anyway, that errata on my spacewalk install (generated with the centos-errata.py script) lists the following packages. CentOS 5.5 Updates x86_64 md5:5afa410c4f2974603ada97886e1ea5dd freetype-2.2.1-28.el5_5-i386 md5:d6c8f0a869ec4529e6cde8661a1c8356 freetype-2.2.1-28.el5_5-x86_64 md5:4615f98627de96657c307ca4fbffc8c3 freetype-demos-2.2.1-28.el5_5-x86_64 md5:f8f4e754eeaeeda39093f82b86699930 freetype-devel-2.2.1-28.el5_5-i386 md5:3485cd6fbf695c0c62e32e406dc3f33e freetype-devel-2.2.1-28.el5_5-x86_64 We're x86_64 only here so if the problem is with multiple-arch errata we likely wouldn't see it in normal operation. If it's only that specific errata that has the problem, just edit it manually in the spacewalk web interface and include the relevant x86_64 packages alongside the 32bit ones. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] applying CESA-2010:0737 Important: freetype Update to x86_64 hosts doesn't work
On Thu, Oct 28, 2010 at 12:29:54PM -0400, Yungwei Chen wrote: I checked my CentOS 5 Update - x86_64 channel, and I do see both 32-bit and 64-bit packages below. So for some reason spacewalk shows 32-bit packages for 64-bit hosts in some of the errata (CEBA-2010:0789, CESA-2010:0787, CEBA-2010:0764, etc). Besides manually adding 64-bit packages to those errata, Is there a way to fix this permanently? Thanks. freetype-2.2.1-28.el5_5.i386 CentOS 5 Update - x86_64 freetype-2.2.1-28.el5_5.x86_64CentOS 5 Update - x86_64 Most likely a bug in centos-errata.py then - it's not associating the correct packages with the errata when it creates it. I will try to take a look over the next week or so and fix the problem. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Deleted Package Cleanup?
On Tue, Sep 28, 2010 at 01:58:02PM -0400, Jason 'XenoPhage' Frisvold wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm trying to delete a few old channels that I have and running into a problem. For whatever reason, if I choose more than 50 packages, I'm typically greeted by a 500 Error from spacewalk. As a result, I don't think the packages are actually being deleted, though they are no longer listed in spacewalk. Is there anything I can run to clean up these orphaned packages? Is there a better way to remove channels so this doesn't happen? You may be running out of space in Oracle's UNDO tablespace, so check the spacewalk logs for oracle errors ocurring when you try and delete a bunch of packages. Fortunately Oracle XE's space limit doesn't include the UNDO tablespace so you can make it pretty big without running into problems. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] [spacewalk 1.1] how to populate errata?
On Mon, Sep 20, 2010 at 03:43:57PM -0400, Jet Wilda wrote: I also found spw-clone-errata.py (https://fedorahosted.org/spacewalk/browser/scripts/clone-errata/spw-clo ne-errata.py) and rhn-clone-errata.py (https://fedorahosted.org/spacewalk/browser/scripts/clone-errata/rhn-clo ne-errata.py). These scripts will copy errata from the Redhat Network if you have sufficient valid Redhat Enterprise Linux subscriptions for your machines. This is the preferred method for RHEL users. With spacewalk 1.1 what is the best way to populate the server with errata? I'm looking at this http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ page with the script centos-errata.py If you are a CentOS user as I am then my centos-errata script will create ersatz errata from postings to the centos-announce mailing list and put them on your spacewalk server. Not perfect, but rather better than no errata at all. and then I found the script apply_errata (https://fedorahosted.org/spacewalk/browser/utils/apply_errata) in the spacewalk-utils RPM. Any and all help is very much appreciated. These tools are for applying existing errata to your managed systems. They will not help you create errata in the first place. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] taskomatic repobuilding attempt 2
On Thu, Jun 24, 2010 at 10:08:15AM +1200, Andreas Hamberger wrote: Hi there A few days ago I have reported the inability of taskomatic to handle repositories with more than 3.8k packages in it. I have exported and reimported packages cutting out any older duplicates on one particular repository for 64-bit. It now has 4300 packages, yet still only creates .new files in the repodata directory. I would appreciate help on this. I am happy to send any information needed. Do you want me to open a ticket in bugzilla on this? I just want to exclude anything obvious first. Since I've got an EPEL channel with over 5000 packages at the moment which builds fine I suspect you've just got a bad taskomatic job in the rhnTaskQueue table, which is leading to this delete with null entity error. If you stop spacewalk, delete the contents of rhnTaskQueue and start it up again then you may find that taskomatic starts working again. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk doesn't show errata
On Mon, Jun 21, 2010 at 04:09:31PM -0400, Yungwei Chen wrote: Thanks for your help. Another question: does centos-errata.py look for CVEs? No. It can scrape textual information about the errata from the RedHat site but it currently doesn't associate any errata with CVEs. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk doesn't show errata
On Mon, Jun 21, 2010 at 10:57:25AM -0400, Yungwei Chen wrote: I found http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ on the Internet. It looks like it expects a directory with all packages files. I am wondering if it works with a channel associated with a yum repo, which by default stores packages in /var/satellite/redhat/1/???/package-name/full-packag-file-name/arch/. Or I have to create a folder and copy all packages to it. That script is intended for use with CentOS. If you are using spacewalk with Redhat Enterprise Linux then you need the clone-errata script pointers to which can be found in the list archives. Anyway, assuming you are using CentOS, version 0.2 of the centos-errata script can search spacewalk for the packages in the errata. It still needs a directory where it will try and look for RPM files if the spacewalk search fails. However, that directory needn't contain any files! To only look for stuff in spacewalk, just point package_dir for each of the arches you are syncing to an empty directory. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Version 0.2 of centos-errata.py script
Hi all, After nearly a year of shameful idleness, I have finally bestirred myself to produce a new version of the script to coincide with the release of CentOS 5.5. This was in no small part due to Raal Goff, who produced an amended version of the script in November last year. I've taken the liberty of incorporating his changes in this new version. Get it here: http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Improvements: - Multiple architecture support. Please note that I can't test this fully (we're x86_64 only here) but it should work. - (Raal Goff) Scraping of mail-archive.com - (Raal Goff) Scraping of errata details from RedHat. This is off by default. - (Raal Goff) Searching of spacewalk server for packages by matching the checksum. BTW Raal, that is a really clever solution and I tip my hat to you! Please note that directories for package_dir should still exist, but if you are relying on spacewalk for package searches they can be empty. - Improved argument parsing and added support for specifying the config file on the command line. Still TODO: - Better docs (as ever :)) - Facilitate offline testing of mail-archive.com scraping - Support multiple versions of CentOS (e.g. 4 and 5 in the same org). You can sort of do this with 2 config files, one for version 4 and one for version 5 if you really want it. - Make searching of spacewalk or the package directories (or both) configurable at runtime Next steps: Once everyone has had a chance to play with it and find bugs, I will submit this script to the contrib repository and maintain it there in future. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Version 0.2 of centos-errata.py script
On Fri, May 28, 2010 at 05:03:51PM +0100, David Nutter wrote: Hi all, After nearly a year of shameful idleness, I have finally bestirred myself to produce a new version of the script to coincide with the release of CentOS 5.5. This was in no small part due to Raal Goff, who produced an amended version of the script in November last year. I've taken the liberty of incorporating his changes in this new version. Get it here: FWIW, I've just done a bit more testing with the big centos-announce digest message today. No problems, other than one errata failing due to a missing package which hasn't been synced to spacewalk yet. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Package update weirdness
On Fri, May 21, 2010 at 05:24:18PM +1000, McLeod, Matt wrote: I'm running 0.8 on CentOS 5.4 with Oracle XE. The database doesn't seem to have maxed out yet (it's at ~3.3GB) and I'm not getting anything that looks like an error message. Ever since the daily spacewalk-sync cron job updated the CentOS 5 base channels to 5.5 I've been seeing unexpected behavior with respect to package upgrades. The SW web interface shows rather fewer than expected packages needing upgrade (~20 on most hosts) and yum update on the hosts show no packages needing upgrade. If I unsubscribe a client from all its channels then resubscribe the numbers look more reasonable -- 113 on the one I tested -- but yum update still doesn't think there's anything to upgrade. I've tried forcing the issue with yum (yum clean all, yum check-update) but it makes no difference. I've tried scheduling the updates via the web interface then doing a forced checkin (rhn_check), likewise no updates are applied. Finally, I've tried deleting the client from SW and then force re-registering. Same result. I'm not sure where to go from here. Does anyone have any suggestions? It sounds like Taskomatic is not rebuilding the repository metadata. Check your taskomatic logs in /var/log/rhn and also check that the package cobbler-web is not installed as I believe that was causing problems for others on the list. You can force an update of repository metadata by deleting the files in /var/cache/rhn/repodata/. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Moving child channels between parent channels
On Fri, May 14, 2010 at 11:31:01AM +0100, James Hogarth wrote: Hi All, With Centos 5.5 about to drop on us I'd like to create a new 5.5 parent channel and fill it up and when tested move my current child channels to it. It's possible I might have missed something but I can't see a way currently in the UI (or via the API) to accomplish this. Would it be as simple as a SQL statement to the Oracle DB of update RHNCHANNEL set PARENT_CHANNEL='new parent channel id' where label='Child channel label'; or does it go deeper than that? Possibly not but the way I accomplish this is to clone the unchanged child channels to a new child channel under the new base channel then delete the old one. Systems can then be migrated simply by changing their subscriptions. So for example when I do the upgrade I'll be cloning the child channel bioss-x86_64-custom-5.4 under centos-x86_64-base-5.4 to bioss-x86_64-custom-5.5 under centos-x86_64-base-5.5. No need to go into Oracle. Doing this through the UI involves quite a bit of clicking but it should be readily automatable through the API if you have loads of systems. Regarding DB usage, this doesn't seem to use up too much extra space, presumably because all a channel consists of is a list of package IDs. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Moving child channels between parent channels
On Fri, May 14, 2010 at 12:06:13PM +0100, James Hogarth wrote: Hmm I was hoping to avoid redoing my activation keys, kickstarts and system subscriptions (after all with a clone the channel ID will change) by just moving them Yeah, it is slightly annoying. We tend to move our systems piecemeal between releases over the course of a week or two so distributions necessarily coexist for a period. It also means we don't experience the pain of changing loads of systems subscriptions at once, just one or two a day which is easily accomplished through system set manager. We don't use cobbler for install so amending kickstarts is not required in our case[1] and we only have 3 activation keys so that's simple to deal with too. I can knock out something for the API perhaps and submit it but I was hoping Jan or Mirov would have some insight on how easy this would be or if it would bring a mountain of horribleness down on my head My base channel and update channel for centos of centos_5.4 and centos_5.4_update I'm regretting now as I could have just emptied it of packages and resync'd them to the new paths upstream but it looks like changing a channel label would be worse than changing the parent channel ID in the database so far as potential corruptions and where they are used... Can't help with that I'm afraid! Regards, [1] Our external kickstarts reference yum repositories which track the latest release anyway. -- 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] OT: Installing non-RHEL packages during kickstart
On Thu, Apr 29, 2010 at 07:36:14AM +0800, Colin Coe wrote: The Sun v3 RPMs (and Oracle RPMs for that matter) _can_ be signed on RHEL5.3 boxes and above (or maybe it was RHEL5.2)... The way I'm doing this is (for VMware RPMS) is to install an old statically-linked version of RPM specifically for signing such old packages. Is there a better way? It's something a pain to remember to resign with a different tool and if you forget obviously the package gets silently corrupted which is a terrible failure mode. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Error during schema upgrade
On Tue, Feb 16, 2010 at 08:53:51AM -0500, Frey, Evan wrote: here's the sql its executing when that error pops up You probably just have a lot of package file records that's exhausting the fixed-size tablespace that Oracle uses to store the information needed to rollback transactions. If possible you might have success by cleaning up some old package records (e.g. from packages in no channels) and try the schema upgrade again. Fortunately, the undo tablespace apparently does not count towards the XE size limit so you can just make it bigger! This is easy enough. First, you might like to examine the size of the DBF files containing your existing undo tablespace: sqlplus / as sysdba select file_name, trunc(bytes/1024/1024,2) size_mb, autoextensible, trunc(bytes/1024/1024,2) maxsize_mb from dba_data_files where tablespace_name='UNDO'; You'll get something like: FILE_NAME SIZE_MB AUT MAXSIZE_MB -- --- -- /usr/lib/oracle/xe/oradata/XE/undo.df 300 YES300 To resize this to something bigger, just do something like: alter database datafile '/usr/lib/oracle/xe/oradata/XE/undo.dbf' resize 1000m; This will take ages but once done you will have a much bigger undo tablespace. Note that if disk space is a consideration shrinking this tablespace again is much harder - the only way I found to do it was to shutdown spacewalk, create a new undo tablespace, switch oracle to using that then dropping the old one. HTH 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problem pushing OpenOffice packages
On Tue, Feb 02, 2010 at 09:29:28AM +, John Hodrien wrote: Pushing Openoffice 3 content to spacewalk 0.6 gave me the following: http://spacewalk.pastebin.com/m77af59ff End result is I can't push those RPMs into spacewalk, which is a bummer. Other packages work fine. I downloaded the standard 64bit RPMS from here: http://download.services.openoffice.org/files/stable/3.1.1/OOo_3.1.1_LinuxX86-64_install_wJRE_en-US.tar.gz If upgrading's a solution, I can do that, but I'd like confirmation from somebody that these can be pushed into 0.7. Seems to work OK for me on Spacewalk 0.7 with the ooobasis-3.1-pyuno package. I haven't tried a full push of all the packages. I ran into the same issue (with 0.6) but got around it by repackaging Openoffice. This had another advantage for us in that we could install OpenOffice 3 and the OpenOffice 2.3 packages side-by-side. You're welcome to my spec file if it's any use. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problem pushing OpenOffice packages
On Tue, Feb 02, 2010 at 10:43:28AM +, John Hodrien wrote: On Tue, 2 Feb 2010, David Nutter wrote: Seems to work OK for me on Spacewalk 0.7 with the ooobasis-3.1-pyuno package. I haven't tried a full push of all the packages. I ran into the same issue (with 0.6) but got around it by repackaging Openoffice. This had another advantage for us in that we could install OpenOffice 3 and the OpenOffice 2.3 packages side-by-side. You're welcome to my spec file if it's any use. Thanks. I tracked it down to a one line change in 0.7, so I've backported the fix. I was going to repackage, but that seemed like an unnecessary hassle. Ah, good. OO3 seems to sit alongside OO2.3 on my CentOS box reasonably happily as far as I can see, although I probably do plan on replacing OO2 entirely anyway. Just need to make sure I don't cause problems for users in the process. In your case, what did the spec file work around? Going off-topic but I think there were two issues: 1) a dependency on the JRE that ships with openoffice.org3 which conflicted with another JRE or JDK package which we already had installed. If you gave RPM --force --nodeps when installing the packages openoffice worked fine so the problem was purely in the packages headers. This was probably resolvable by other means but repackaging and explicitly resetting the dependency on Java fixed it for us without having to mess with our Java config which at the time was quite complicated due to the need to support 32bit browsers for plugin Java use. 2) The two different versions fought over who owned the commands /usr/bin/openoffice.org and some others. I wanted OO 2.3 to be the default for users who didn't take an explicit action to enable OO 3 (namely put it in their $PATH) and couldn't seem to get it to work reliably with both packages installed. I may have been using an older build at the time though. Maybe I should try again with the latest package rather than repackaging it every few months. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] errata question
On Tue, Dec 08, 2009 at 08:26:42PM -0600, Daniel Wittenberg wrote: Wouldn't this whole errata management be easier if you could point it at a repo and have it one level higher, so it could see the OS and the updates, and just mirror those over itself? It seems like this is way more complicated then it needs to be and I'm not understanding why it's done the way it is. Are you asking for my script to parse a yum repository's metadata to retrieve NVREA values, or just friendlier behaviour for package_dir? If the former, I suppose the script could do that but I suspect it would be rather more complex than querying an RPM. Since I have the RPMs on local disk anyway (for mock) it's not a priority for me. If the latter, I could change the handling of package_dir so that it looks for RPMS in all subdirectories, though I can't any advantage in doing so. Packages in the updates repository are the only ones that get mentioned in CentOS-announce mailings so looking in other repositories seems pointless. That said, most of the machinery to do such looking is already in the development version of the script for supporting multiple architectures so I might just add it and see what happens. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk + Oracle XE =ORA-12952: The request exceeds the maximum allowed database size of 4 GB
On Tue, Dec 01, 2009 at 11:38:27AM +0100, Michael Mraka wrote: *snip* Sometimes things are much simply then they seem; you've forgotten about indexes. oracle$ sqlplus / as sysdba SQL select trunc(sum(bytes)/1024/1024, 2) MB from dba_segments where owner = 'SPACEWALK'; Aha, that's much better. Thanks! Replacing the (non-working since it depends on db-control) check-oracle-space-usage.sh crontab from spacewalk-dobby with a call like this might be useful for spacewalk. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk + Oracle XE =ORA-12952: The request exceeds the maximum allowed database size of 4 GB
On Mon, Nov 23, 2009 at 11:01:44AM +0100, Santi Saez wrote: Hi! We're getting continuously this error via mail: SQL Error generated: (12952, 'ORA-12952: The request exceeds the maximum allowed database size of 4 GB\nORA-06512: at SPACEWALK.RHN_SERVER, line 231\nORA-06512: at line 1\n') What can I do to solve this? Any tips to purge/compact XE database? r...@spacewalk:~ # du -sh /usr/lib/oracle/xe/oradata/XE/* 3,7M/usr/lib/oracle/xe/oradata/XE/control.dbf 571M/usr/lib/oracle/xe/oradata/XE/sysaux.dbf 361M/usr/lib/oracle/xe/oradata/XE/system.dbf 149M/usr/lib/oracle/xe/oradata/XE/temp.dbf 501M/usr/lib/oracle/xe/oradata/XE/undo.dbf 4,1G/usr/lib/oracle/xe/oradata/XE/users.dbf I can't register new clients.. thanks!! If you are using monitoring it's a good idea to periodically clear out the monitoring data tables. There's a script kicking around somewhere that does this, probably it'll be included in Spacewalk 0.7. Also, if you have loads of old packages in your channels, clear them out and delete them from the server and trash any old errata. This helps a bit, but you'll probably have to bite the bullet and buy an oracle licence eventually. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] some questions about OSAD and cleaning up spacewalk
On Mon, Nov 09, 2009 at 02:52:03PM +0100, Michiel van Es wrote: *snip* - Our spacewalk diskspace is growing and growing (new updates arriving every day through our reposync script). Many packages are being kept with older versions, for example the kernel. Is there a clean up script to clean up , let's say, package versions older then 2 or 3 versions? Or how does anyone clean up their spacewalk packages? We rely on being quite strict about our channel lifespans. We maintain all channels as local yum repositories as well. In the case of upstream (CentOS, EPEL etc) we rely on upstream to keep them clean for us. We clean our own repositories manually. Each repository maps onto one channel in Spacewalk. Over the lifetime of a CentOS major release, the size of the channels for that release will tend towards infinity. When a new release is made we create a new set of channels for that release and repush all content from the yum repositories. This is nowhere near as painful as it sounds since most packages don't in fact change between releases and pushing a package that already exists is super-quick. Then we migrate systems to the new channel set and finally delete the old channels, which does away with the accumulated cruft when you delete the thousands of Packages in No Channels via Manage Packages. The above approach works for us but we don't have multiple distros/architectures and are not particularly disk-constrained as a result. Instead, you may be able to write an API script that navigates the package version tree to find and remove old versions. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Installing GPG Keys
On Wed, Oct 28, 2009 at 08:52:46PM -0400, Jason Frisvold wrote: Hi all, Just a quick question .. I have my channels set up with the URL, ID, and fingerprint of the associated GPG key. I thought this meant that yum would ask to install the appropriate GPG key if it wasn't already present, but this doesn't seem to be the case. How do I go about setting up spacewalk/yum to handle this? http://www.mail-archive.com/spacewalk-list@redhat.com/msg02881.html might explain your issue. Personally I just ship all relevant keys in a package which imports them as part of its postinstall. This is a hangover from pre-Spacewalk days really but it works for me. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] CentOS 5.4 64 bit and spacewalk client tools
On Tue, Oct 27, 2009 at 07:09:53PM -0400, Flaherty, Patrick wrote: *snip* I'm seeing the same issue on 32 and 64 bit CentOS boxes when I try to upgrade them from 5.3 to 5.4. The client tools repositories on the listed on the setup page for centos5 haven't been updated since 2008. The instructions for fedora point at http://spacewalk.redhat.com/yum/0.5 or http://spacewalk.redhat.com/yum/0.6/. Perhaps those packages will work? I'll likely try them tomorrow if I have enough time. FWIW I'm having no problems using the yum-rhn-plugin package from the 0.6 spacewalk repo on CentOS 5.4 here. If it's any help my client tools channel currently contains the following packages: libxml2-python-2.6.26-2.1.2.8.x86_64 nocpulse-common-2.1.17-1.el5.noarch osad-5.9.21-1.el5.noarch pyOpenSSL-0.6-1.p24.7.2.2.x86_64 rhel-instnum-1.0.8-1.el5.noarch rhncfg-5.9.7.2-1.el5.noarch rhncfg-actions-5.9.7.2-1.el5.noarch rhncfg-client-5.9.7.2-1.el5.noarch rhncfg-management-5.9.7.2-1.el5.noarch rhn-check-0.6.4-1.el5.noarch rhn-client-tools-0.6.4-1.el5.noarch rhn-custom-info-5.4.0-1.el5.noarch rhnlib-2.5.13-1.el5.noarch rhnmd-5.3.2-1.el5.x86_64 rhnsd-4.5.11-1.el5.x86_64 rhn-setup-0.6.4-1.el5.noarch rhn-setup-gnome-0.6.4-1.el5.noarch spacewalk-koan-0.1.18-1.el5.noarch yum-rhn-plugin-0.6.2-1.el5.noarch This is a mix from the Spacewalk and Stahnma repositories. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] CentOS 5.4 64 bit and spacewalk client tools
On Wed, Oct 28, 2009 at 11:07:41AM +0100, Michiel van Es wrote: So perhaps use the 0.6 repo for CentOS 5.4 server is your advise? Mixing the packages in this way works for me, and may suit you too if you need to get up and running quickly. Having checked, the only package I'm using from Stahnma is rhel-instnum which should be fairly safe. If you are more cautious then holding back the yum upgrade in CentOS 5.4 until the Stahnma repository is fully up-to-date again might be better for you. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Monitoring and notifications
Ever since upgrading to spacewalk 0.6, notifications have been piling
up in /var/lib/notification/queue/alert_queue/ but are not getting
picked up by the system that emails out alerts. Eventually of course I
get the infamous notification meltdown emails and have to
clean out the queue manually.
Some observations:
- The spacewalk web interface shows monitoring data, status etc just
fine so the problem appears to be confined to the notification
subsystem.
- show-queue and monitor-queue pick up the fact that there are
notifications waiting.
- The notification method is a simple email to the Spacewalk
administrator and is called Email2
- From the command line I can send email from the spacewalk server.
- /usr/bin/notifier has active SMTP sessions with localhost so it can
send mail if it wants to. However, the sendmail log shows no
activity then these connections time out.
- Nothing of use is logged in
/var/log/nocpulse/{NotifEscalator-error,notif-escalator,Notifier-error,notifier,NotifLauncher-error,notif-launcher}.log
All I get is the keepalive messages (variants on polling, waiting
for new sends etc. It's almost as if the queue of notifications is
not being read as I don't see any attempts to escalate or send
notifications.
- I tried increased the logging by editing the scripts
/usr/bin/{notifier,notif-escalator,notif-launcher} then restarting
monitoring. No joy. Notif-launcher logs an empty message once per
second at loglevel 9.
- All alerts generated are legit, from probes that have gone to
Warning or Critical and mention Email2 when
listed by show-alert. An example is attached.
- I can't find any way to get spacewalk to test the notification
method, other than the script test_alert which inserts a message
into the alert queue. This message is then just ignored like all the
others.
Any thoughts on further debugging steps? I'm rather confused about the
relationships between the three notifier scripts which isn't
helping. Any insight gratefully received :)
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
Scottish Crop Research Institute (SCRI), a registered Scottish charity
No. SC006662
$VAR1 = bless( {
'satcluster' = '1',
'commandLongName' = 'Memory Usage',
'time' = '1256136322',
'checkCommand' = '25',
'current_time' = 1256136329,
'probeType' = 'ServiceProbe',
'state' = 'WARNING',
'hostAddress' = '192.168.15.145',
'probeDescription' = 'Linux: Memory Usage',
'clusterId' = '1',
'mac' = '00:16:3E:25:C5:19',
'probeId' = '81',
'version' = '1.0',
'subject' = '',
'groupId' = '21',
'message' = 'RAM free 11.26 MB (below warning threshold of
20.00 MB)
Notification #1 for RAM free
',
'hostName' = 'bcsossg.bioss.sari.ac.uk',
'snmp' = '',
'customerId' = '1',
'probeGroupName' = 'linux',
'hostProbeId' = '',
'osName' = 'Linux System',
'groupName' = 'Email2',
'type' = 'service',
'physicalLocationName' = 'Generic All-Encompassing Location',
'clusterDesc' = 'RHN Monitoring Satellite',
'snmpPort' = '',
'ticket_id' = '01_1256136329_002233_001'
}, 'NOCpulse::Notif::Alert' );
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] question about patches pushed slow
On Tue, Oct 20, 2009 at 06:27:06AM +0200, Michiel van Es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone? I also have a problem that CentOS 4 machines don't see updates in spacewalk but when I do an up2date -fu all suddenly all updates are showing up :( Something similar happens from time to time here using CentOS 5. Usually the updates appear after a while, presumably when the client next checks in. If not, an explicit package profile refresh fixes it. Very occasionally, after a package push the updates will initially appear on the systems view but then vanish again before you have chance to apply them. Again, waiting a while or forcing a profile refresh gets them back. This only seems to happen with non-errata updates for some reason. I also found out that the rhn_check command is running on most of the clients but is sitting there waiting for hours (I have to manually kill it and rerun rhn_check -vv to update/pull the package updates.) I've never seen that. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] question about patches pushed slow
On Tue, Oct 20, 2009 at 11:50:44AM +0200, Michiel van Es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [osad] You mean on the clients right? There is no osad running on the server. Yes, sorry, I'm not being very clear. And you mean a ping from the client to the server via spacewalk? Yes, you can do that from the system info page. If osad is not running for whatever reason the clients will still wait until rhnsd checks in and then if there are pending actions rhn_check is invoked. Maybe start both rhnsd and rhn_check in the foreground on a client and watch their debugging output during a normal scheduled check in - that might give you a clue why rhn_check is hanging. Hmm I think it has all to do with the not working osad connections. The /etc/init.d/osa-dispatcher start takes a lot of time..also running the /usr/sbin/osa-dispatcher -v does not provide any verbose info.. If Jabber isn't listening on the correct interfaces/ports then waiting for those connection attempts to time out might be the cause of your hang. If this is the issue you can't get osa-dispatcher itself to give out decent debugging info then maybe wireshark might help. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Error Creating Kickstart Profile
On Mon, Oct 12, 2009 at 09:00:30AM -0400, Joshua Roys wrote: On 09/30/2009 11:48 AM, Wojtak, Greg wrote: I am following the directions outlined at https://fedorahosted.org/spacewalk/wiki/HowToKickstartCobbler to set up a distribution and kickstart profile. I’ve created the distribution, but then when I create the kickstart profile, I get a template error. The output is below this message. Any ideas? *snip* Sorry for the late reply. Someone else had this error, and they fixed it by opening the ks file (under /var/lib/rhn/kickstarts/*/) and changing the #errorCatcher line at the top. (Note that this doesn't fix the underlying problem - it's simply a work-around.) I would try replacing ListErrors with Echo, and if that doesn't work, just delete the line entirely. Hi, I'm not the original poster but I just ran into this problem with Spacewalk 0.6. The line in the kickstart file read #errorCatcher Echo already so I just deleted it. The kickstart file is generated OK now. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Error Creating Kickstart Profile
On Mon, Oct 12, 2009 at 04:11:26PM +0100, David Nutter wrote: *snip* Hi, I'm not the original poster but I just ran into this problem with Spacewalk 0.6. The line in the kickstart file read #errorCatcher Echo already so I just deleted it. The kickstart file is generated OK now. As an experiment I tried inserting the line #errorCatcher ListErrors and the kickstart was also generated correctly. I think Echo is the problem. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problem with RHNPUSH (ORACLE ???)
On Fri, Jul 24, 2009 at 10:01:30AM +0200, Tommaso Rossetto wrote: *Hi all, when I launch rhnpush I get this error message :* *snip* Error pushing base/CentOS/setroubleshoot-2.0.5-3.el5.noarch.rpm: Error 500Error Message: ORA-12899: value too large for column SPACEWALK.RHNPACKAGECHANGELOG.TEXT (actual: 3002, maximum: 3000) Error Class Code: 54 Error Class Info: Package Upload Failed due to uniqueness constraint violation. Make sure the package does not have any duplicate dependencies or does not already exists on the server (500) Waiting 2 seconds and trying again... The above should be easy to fix - just increase the size of the column TEXT in table RHNPACKAGECHANGELOG. Offhand, and untested, this will probably be a command like: ALTER TABLE RHNPACKAGECHANGELOG MODIFY (TEXT VARCHAR2(5000)); My knowledge of oracle is minimal so the above command may be wrong. Even if it succeeds it may have bad effects so use at your own risk. Error Message: ORA-1: unique constraint (SPACEWALK.RHN_CNP_CID_NID_UQ) violated ORA-06512: at SPACEWALK.RHN_CHANNEL, line 916 ORA-06512: at line 1 Error Class Code: 23 Error Class Info: Could not update database entry. xargs: rhnpush: exited with status 255; aborting Here follows some wild speculation: I think that constraint ensures that package IDs are unique on the spacewalk server. Possibly the previous error is leaving some kind of uncompleted upload which is causing the constraint to be violated but once the push session ends the failed uploads have their transactions rolled back leaving no visible evidence such as a half uploaded package visible on the spacewalk website. Consequently if you fix the first error, the second may go away too. End of wild speculation. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] question about status :Queued
On Fri, Jun 12, 2009 at 02:55:55PM +0200, Michiel van Es wrote: *snip* So if I get it right: there is a OSAD communication problem between the client|server and the spacewalkserver ? I have this for multiple machines but can not find anyhting in /var/log/rhn/*.log on the spacewalk server or in /var/log/osad (or osad debug mode = osad -N -vv) on the client. The way I check OSAD connectivity and functionality is to start OSAD on the client in debug mode as you do above and then schedule a ping from spacewalk. If you see some stuff being printed on the client's console when the ping is received then OSAD is working and any actions scheduled should be performed more or less instantly. If the ping works but scheduling actions doesn't, I'm afraid I don't have any idea what the problem might be. If the ping doesn't work, then restarting jabberd in debug mode, reading the jabberd logs and connecting to OSAD's jabber channel with a regular client can help resolve any problems. Firewalls, certs and authentication all might be an issue here, though usually OSAD on the client will complain bitterly if there's something wrong. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Feature request - Storage of Remote Commands and hardware detection
On Sun, May 31, 2009 at 05:03:49PM -0500, Czerak, Jason wrote: I'd like to spark the discussion about storing remote commands with in Spacewalk along side Configuration files as well as some sort of hardware detection. I'd imagine remote commands would be a subset of configuration files since they could and should be a dependency. For example, if my servers are VMware servers. I would need to not only install VMwareTools rpm, I need to execute VMware-config-tools.pl. After a kernel upgrade, the VMware-configu-tools.pl would need to be executed again. As a work around, I plan on storing templated remote commands on Sharepoint. I think this sort of thing is best dealt with by a fully-fledged config management system (e.g. LCFG, puppet, bcfg2 etc) rather than by making spacewalk a repository of scripts. The major advantage of such systems is that the system is automatically kept in compliance with the profile rather than requiring admin intervention to run the relevant commands, remotely or otherwise. That said, my current approach to this problem is a ghastly hack: I distribute such reusable remote commands as scripts in a package. Once the package is installed on all systems then (re)invoking the command is a simple one-liner remote command. For things like VMware, I have an init script that invokes the necessary config script when the server is rebooted, using the run-parts utility. In the future I plan to replace this flaky approach with LCFG, but any config management system would work just fine and provide many more features than simply storing the remote commands in Spacewalk. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Errata
On Fri, May 29, 2009 at 05:26:51PM +0100, David Nutter wrote: On Thu, May 28, 2009 at 03:00:03PM -0400, Frey, Evan wrote: I am currently running Spacewalk 0.5 on RH Server 5 and wanted to know if it was possible to sync errata from my RHN account. Hi, I can't help with syncing errata from rhn.redhat.com but I recently wrote a script (rhn-centos-errata.py) that scrapes the centos-announce mailing list (either archives or daily digest) and creates appropriate (if rather basic) errata using the Spacewalk API. These imported errata include a URL which links to the RHN errata pages allowing, you can get the full info if you want it. The script is heavily based on the handy rhn-tool script by Lars Jonsson, with some extra wrapper methods for the XMLRPC functions I needed. If you want it, let me know. It's here: http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Given the apparent level of interest I have taken a bit of time to write some basic docs and make the script more configurable by file and command line option, rather than by editing the code. Even with this cleanup there will undoubtedly be loads of bugs and annoyances! Implementing an equivalent tool for fedora should be a simple matter of replacing the mail message handling code with an RSS feed reader as someone suggested elsewhere in this thread. Those of you familiar with rhn-tool will notice strong similarity between RHNSession and the RHNServer class. I think that these support classes should be moved into a python module also in contrib[1] then future contrib tools can re-use them easily, rather than making a load of monolithic tools all containing basically the same code. Any thoughts on this? Regards, [1] I've actually already made this change to facilitate internal reuse of this handy library code. -- 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Monitoring
On Thu, May 28, 2009 at 09:18:40PM +0100, Ade wrote: Hi Im new to Spacewalk - installed my first Spacewalk server only 2 days ago. Im really pleased with how it works - I have 4 test clients connected in and successfully patched but . I dont seem to be able to get monitoring working - when I try to push the suites they stay pending. I have not made any changes to the clients. When you say [the suites] stay pending, do you mean that the Monitoring Scout Config push is failing to complete or just that all probes on the monitoring status page (ProbeList.do) show the little clock icon? If the latter, you may need to push the monitoring scout config. Visit https://spacewalk.example.com/network/monitoring/scout/index.pxt and if the RHN Monitoring Satellite shows a little spanner icon, schedule a push. Then your probes should start to update. Can someone point me in the right direction please? I cant seem to find where this is documented The satellite guide is the documentation I used: http://www.redhat.com/docs/manuals/satellite/Red_Hat_Network_Satellite-5.1.0/html/Reference_Guide/ch-monitoring.html You will need to make sure that the monitoring scout is running on the server (/sbin/service MonitoringScout status) and that the spacewalk server can communicate with the monitored client (either by SSH or rhnmd). You can test this by running the following command on the spacewalk server (port arg is for rhnmd, omit this if you are using plain SSH): /usr/bin/ssh -v -v -l nocpulse -p 4545 -i /var/lib/nocpulse/.ssh/nocpulse-identity -o StrictHostKeyChecking=no HOSTNAME.example.com Obviously /var/lib/nocpulse/.ssh/authorized_keys on the monitored client must contain the spacewalk server's /var/lib/nocpulse/.ssh/nocpulse-identity.pub. I install this in the system postinstall, the docs suggest using config file management to deploy it. YMMV. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Errata
On Thu, May 28, 2009 at 03:00:03PM -0400, Frey, Evan wrote: I am currently running Spacewalk 0.5 on RH Server 5 and wanted to know if it was possible to sync errata from my RHN account. Hi, I can't help with syncing errata from rhn.redhat.com but I recently wrote a script (rhn-centos-errata.py) that scrapes the centos-announce mailing list (either archives or daily digest) and creates appropriate (if rather basic) errata using the Spacewalk API. These imported errata include a URL which links to the RHN errata pages allowing, you can get the full info if you want it. The script is heavily based on the handy rhn-tool script by Lars Jonsson, with some extra wrapper methods for the XMLRPC functions I needed. If you want it, let me know. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] New .5 x64 install, Oracle issue?
On Tue, May 26, 2009 at 05:30:18PM -0400, Albert Bryndza wrote:
[r...@spacewalk /]# spacewalk-setup --disconnected
Can't load
'/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: libocci.so.10.1: wrong ELF class: ELFCLASS32 at
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
at /usr/lib/perl5/vendor_perl/5.8.8/RHN/DB.pm line 539
Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.8/RHN/DB.pm
line 539.
BEGIN failed--compilation aborted at
/usr/lib/perl5/vendor_perl/5.8.8/RHN/DB.pm line 539.
Compilation failed in require at
/usr/lib/perl5/vendor_perl/5.8.8/RHN/SatInstall.pm line 30.
BEGIN failed--compilation aborted at
/usr/lib/perl5/vendor_perl/5.8.8/RHN/SatInstall.pm line 30.
Compilation failed in require at /usr/bin/spacewalk-setup line 45.
BEGIN failed--compilation aborted at /usr/bin/spacewalk-setup line 45.
I've tried several of the fixes that I found on this mailing list and on
the net. No go. Any thoughts?
Possibly you have the 32bit oracle client packages installed instead
of the 64bit ones. On my spacewalk server libocci is found at:
/usr/lib/oracle/10.2.0.4/client64/lib/libocci.so.10.1
See what
rpm -q --queryformat %{NAME} %{ARCH}\n oracle-instantclient-basic
outputs. On my system I get (as expected):
oracle-instantclient-basic x86_64
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
Scottish Crop Research Institute (SCRI), a registered Scottish charity
No. SC006662
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] question about install/upgrade packages not being picked up by the guest
On Mon, May 25, 2009 at 04:53:15PM +0200, Michiel van Es wrote: Hi, We succesfully subsribed some CentOS 4 and 5 clients to our Spacewalk server (running CentOS 5 32 bit). We noticed that some of the guests don't automatically pickup the Install or Upgrade schedules. We also use the Jabber/OSAD setup so that we can push the rhn_check -vv requests emediatly. The guests only use the red hat network plugin and only spacewalk as yum repo. A rhn_check -vv works. but pushed through Spacewalk/OSAD/Jabber does not. How can I best troubleshoot this issue? It sounds like osad is not working for some reason. One way to debug this is to start OSAD on the client as follows: osad -N -vv You should see plenty of information being printed out about connections being made to the jabber server and so forth. Then, when you schedule an action (obviously a ping is good for testing) you will see this in OSAD's debugging output. Potential problems include: 1) incorrect SSL certs shared between the client and server 2) jabber daemon on the server inaccessible to the client due to firewall 3) Trying to run jabberd 2.2 with spacewalk 0.5 - uninstall this and use jabberd 2.0 4) ISTR having to fiddle with my jabberd configuration to get osad working when I set this up, so turning up the jabberd logging on the spacewalk server may help in turning up problems. Unfortunately this was some time ago so I cannot remember the details exactly. Finally, here's a posting I made to this list regarding OSAD configuration: http://www.mail-archive.com/spacewalk-list@redhat.com/msg00584.html The chap I was replying to then put some of that information on the wiki, I think on this page: https://fedorahosted.org/spacewalk/wiki/OSADSetup 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Mr. 500 here... more info
On Thu, Feb 05, 2009 at 05:54:02PM -0500, m.roth2...@rcn.com wrote: Interesting thought: so, let me ask: anyone with spacewalk running on CentOS 5.2 (final): what does your uname -a show? FWIW: Linux spacewalk.bioss.sari.ac.uk 2.6.18-92.1.22.el5xen #1 SMP Tue Dec 16 12:26:32 EST 2008 x86_64 x86_64 x86_64 GNU/Linux Working fine inside a Xen VM with 2G of RAM. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Tomcat Errors?
On Fri, Feb 06, 2009 at 10:29:40AM +0200, Cem Vedat ISIK wrote: Gents / Ladies, Do I need to give more information to you to get help / comments / ideas on that one? *snip* id: cannot find name for user ID 91 That's odd. The tomcat packages I use (from CentOS) insert an entry for tomcat as UID 91 into the password file. If tomcat is starting as a different user, there might be permission problems. Jan 27, 2009 12:23:30 PM org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(/usr/share/tomcat5/webapps/rhn/WEB-INF/lib/jspapi.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/jsp/JspPage.class Looking at the above error and reading the servlet spec reveals: SRV.9.7.2Web Application Classloader The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource. It must not allow the WAR to override J2SE or Java servlet API classes. It is further recommended that the loader not allow servlets in the WAR access to the web container's implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. Possibly you have a jspapi.jar file elsewhere in Java's classpath which is stopping the one in the Spacewalk web application from loading. This shouldn't stop your app from working since I get the same error and I'm fine. Therefore I'm wondering if rhn.jar (which contains com.redhat.rhn.webapp.RhnServletListener) is somehow failing to load resulting in the later error: 2009-01-27 12:23:31,498 [main] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/rhn] - Error configuring application listener of class com.redhat.rhn.webapp.RhnServletListener java.lang.ClassNotFoundException: com.redhat.rhn.webapp.RhnServletListener Possibly turning up tomcat logging so you can see what jars are being loaded might help. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Problems with update
On Tue, Feb 03, 2009 at 06:28:24PM +0100, Meier, Daniel (EXT) wrote: Nope i try both. Same error :-( Hi, Sounds like what I experienced after a 0.2 - 0.4 upgrade. See my message of a few days ago, here: http://www.mail-archive.com/spacewalk-list@redhat.com/msg00987.html Deleting the yum cache on the client had no effect in my case either. The approach described there of deleting an obscure package from the channel and re-accessing the channel with yum worked for me, but YMMV. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Slight weirdness post spacewalk 0.2-0.4 upgrade
Hello,
After (very smoothly :)) upgrading, package installs on clients
failed, claiming that (from up2date log):
[Fri Jan 23 17:12:55 2009] up2date
Traceback (most recent call last):
File /usr/sbin/rhn_check, line 273, in __run_action
(status, message, data) = CheckCli.__do_call(method, params)
File /usr/sbin/rhn_check, line 266, in __do_call
retval = method(*params)
File /usr/share/rhn/actions/packages.py, line 246, in update
return runTransaction(transaction_data)
File /usr/share/rhn/actions/packages.py, line 279, in
runTransaction
return _run_yum_action(command)
File /usr/share/rhn/actions/packages.py, line 301, in
_run_yum_action
yum_base = YumAction()
File /usr/share/rhn/actions/packages.py, line 53, in __init__
self.doTsSetup()
File /usr/lib/python2.4/site-packages/yum/depsolve.py, line 72, in
doTsSetup
return self._getTs()
File /usr/lib/python2.4/site-packages/yum/depsolve.py, line 85, in
_getTs
self._getTsInfo()
File /usr/lib/python2.4/site-packages/yum/depsolve.py, line 91, in
_getTsInfo
self._tsInfo.setDatabases(self.rpmdb, self.pkgSack)
File /usr/lib/python2.4/site-packages/yum/__init__.py, line 537,
in lambda
pkgSack = property(fget=lambda self: self._getSacks(),
File /usr/lib/python2.4/site-packages/yum/__init__.py, line 392,
in _getSacks
self.repos.populateSack(which=repos)
File /usr/lib/python2.4/site-packages/yum/repos.py, line 242, in
populateSack
sack.populate(repo, mdtype, callback, cacheonly)
File /usr/lib/python2.4/site-packages/yum/yumRepo.py, line 165, in
populate
xml = repo_get_function()
File /usr/lib/python2.4/site-packages/yum/yumRepo.py, line 880, in
getPrimaryXML
return self.retrieveMD('primary')
File /usr/lib/python2.4/site-packages/yum/yumRepo.py, line 867, in
retrieveMD
cache=self.http_caching == 'all')
File /usr/lib/yum-plugins/rhnplugin.py, line 299, in _getFile
raise yum.Errors.RepoError, \
yum.Errors.RepoError: failed to retrieve repodata/primary.xml.gz from
centos-x86_64-base-5
error was [Errno -1] Metadata file does not match checksum
Similarly, yum when run on the client reported:
Error: failed to retrieve repodata/primary.xml.gz from centos-x86_64-base-5
error was [Errno -1] Metadata file does not match checksum
I assumed that spacewalk's yum metadata update process had gone wrong
somehow, so I forced it to re-run by deleting an obscure package from
the affected channel and accessed the metadata again with yum.
Remarkably, this hideous hack worked. Is there a way to force
spacewalk to regenerate the metadata for a particular channel? Reading
the (tangentially related) page
https://fedorahosted.org/spacewalk/wiki/DeltaRpmSupport
suggests not but I'd welcome confirmation.
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
Scottish Crop Research Institute (SCRI), a registered Scottish charity
No. SC006662
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk 0.4 is here!
On Thu, Jan 15, 2009 at 05:43:23PM -0500, Jesus M. Rodriguez wrote: *snip* Known issues * in order to take full advantage of the multi-arch feature, you'll need: - updated client packages *snip* Which client packages need updating? I currently mirror http://stahnma.fedorapeople.org/spacewalk-tools/ which hasn't been updated for some months. Nevertheless, looking at the SRPMS for spacewalk 0.3 and 0.4, the most recent rhn-client-tools SRPM for EL5 appears to be rhn-client-tools-0.4.17-8.el5.src.rpm and I appear to have client packages built from that SRPM anyway. Do I need to get the relevant package sources from git? Thanks 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Issues registering Fedora 9 systems on baremetal ks
On Mon, Nov 17, 2008 at 09:54:53AM +, [EMAIL PROTECTED] wrote: Gerhardus, On Mon, 2008-11-17 at 09:41 +, [EMAIL PROTECTED] wrote: I had a similar problem which was caused by a clock difference between the spacewalk(satellite) server and the server being build. Its probably not your problem but worth while checking anyway. That could be an issue as though my spacewalk server knows it's x:yz UTC, my spacewalk appears to constantly think it's EST. I.e. my server knows that it's in Brighton, but spacewalk thinks it's in San Francisco. The time zone can be changed in the spacewalk web UI in the Locale Preferences. Click Preferences then Locale Preferences in the grey sidebar. Underneath spacewalk presumably uses UTC so a time mismatch probably isn't the issue, assuming both your hosts are synchronizing their clocks with NTP. 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Centos setup problems
On Thu, Nov 13, 2008 at 12:09:36PM -0600, Stephen Berg (Contractor) wrote: Adrián Márques wrote: I got it here: http://rpm.pbone.net/index.php3?stat=3search=rhel-instnumsrodzaj=3 It's a package for StartCom 5 (never heard of it before), but worked just fine for me on CentOS. I found a slightly newer version on ftp://fr2.rpmfind.net/linux/ASPLinux/i386/updates/12.1/x86_64/rhel-instnum-1.0.8-1.el5.asp121.noarch.rpm I tried restarting oracle-xe, satellite-httpd and tomcat5 and re-ran the setup. The output is pasted below. The strange part is I changed the defaults.conf file to answer the questions but it fails to login on the first attempt, the second attempt is when it hangs. Before I changed defaults.conf I would answer the questions and it would fail, then answer the questions again and it would hang. So I'm pretty confident it is reading defaults.conf correctly. [EMAIL PROTECTED] init.d]# spacewalk-setup --disconnected * Loading answer file: /usr/share/spacewalk/setup/defaults.conf. Only one database option available, assuming: oracle * Setting up Oracle environment. * Setting up database. ** Database: Setting up database connection. Could not connect to the database. Your connection information may be incorrect. Error: install_driver(Oracle) failed: Can't load '/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.10.1: wrong ELF class: ELFCLASS32 at /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230, This is a known issue - see the OracleXe setup page here: https://fedorahosted.org/spacewalk/wiki/OracleXeSetup Oracle for some reason installs the 32bit driver in the default library path, even on a 64bit machine. The 64bit perl DBD module then gets confused when the Oracle driver is apparently 32 bit. To fix it I have a file /etc/ld.so.conf.d/spacewalk.conf which contains /usr/lib/oracle/10.2.0.4/client64/lib/ Then ldconfig -v. Regarding rhel-instnum, I got mine from the Stahnma client tools repository: http://stahnma.fedorapeople.org/spacewalk-tools/5/x86_64/ 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Centos setup problems
On Thu, Nov 13, 2008 at 12:57:19PM -0600, Stephen Berg (Contractor) wrote: [EMAIL PROTECTED] ~]# locate libclntsh.so.10.1 /usr/lib/oracle/10.2.0.4/client64/lib/libclntsh.so.10.1 /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libclntsh.so.10.1 edit the file in /etc/ld.so.conf.d created earlier and run ldconfig -v to enable the changes. tn The client packages I grabbed from oracle are all 11.1.0.1. Do I need to remove them and downgrade to the 10.2.0.4 versions? If all else fails, it's worth a try (10.2.0.4 packages are working here). They should be backward compatible though. I had already made the wiki suggested changes in ld.so.conf.d but I'm still getting the libclntsh.so error. After adding the /etc/ld.so.conf.d/spacewalk.conf file with the paths to libclntsh.so I get two warnings: ldconfig: Path `/usr/lib/oracle/11.1.0.1/client64/lib' given more than once Ah, right. Then the linker is finding the wrong version of the shared library. ldconfig: Path `/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib' I don't have the above path in my linker configuration, just the client64 one. Oracle sets it up for itself from $ORACLE_HOME when it starts the server. Maybe the wiki is a bit misleading? 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] error pushing package update to spacewalk 0.2
On Fri, Oct 10, 2008 at 11:41:37AM -0700, Sean Allin wrote: I'm having an issue on pushing a package update up to spacewalk for libtiff-devel for CentOS. The spacewalk server is an update from 0.1 to 0.2. Following is the log message: Uploading package /mnt/sw-repo/CENTOS/centos/5/updates/i386/RPMS/libtiff-devel-3.8.2-7.el5_2.2.i386.rpm Using POST request Internal server error 500 Internal Server Error Error pushing /mnt/sw-repo/CENTOS/centos/5/updates/i386/RPMS/libtiff-devel-3.8.2-7.el5_2.2.i386.rpm: Error 500Error Message: Package upload failed: [Errno 13] Permission denied: '/var/satellite/redhat/1/a27/libtiff-devel' Error Class Code: 50 Error Class Info: Invalid information uploaded to the server (500) Waiting 4 seconds and trying again... Giving up after 3 attempts All other package updates worked ok. Any suggestions on debugging? Check the permissions on the /var/satellite/redhat directory and subdirectories. If you ran /usr/sbin/update-packages as root, the apache:apache permissions required for the upload to work will have been replaced with root:root. I have been bitten by that issue just today, in fact :) 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 Scottish Crop Research Institute (SCRI), a registered Scottish charity No. SC006662 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
