[Spacewalk-list] Spacewalk-list Digest, Vol 115, Issue 36
Tânia Agulhas Marques Valente [EE] (SSI)
tania.marques.valente at cgd.pt
Tue Dec 19 10:00:42 UTC 2017
Hello
Did you upgraded your server recently?
I never had this error but I would guess that or you made an update without updating the schema, or there's a problem with your postgres database. Do you have a postgres DBA arround?
-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of spacewalk-list-request at redhat.com
Sent: 18 de dezembro de 2017 21:53
To: spacewalk-list at redhat.com
Subject: Spacewalk-list Digest, Vol 115, Issue 36
Send Spacewalk-list mailing list submissions to
spacewalk-list at redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/spacewalk-list
or, via email, send a message with subject or body 'help' to
spacewalk-list-request at redhat.com
You can reach the person managing the list at
spacewalk-list-owner at redhat.com
When replying, please edit your Subject line so it is more specific than "Re: Contents of Spacewalk-list digest..."
Today's Topics:
1. syncing epel to spacewalk 2.7 (Ku Dude)
2. Spacewalk 2.7 - errata & package issues (Kalchik, Jeffery)
3. Support for Xenial clients (Lai Wei-Hwa)
4. yup update/install gives 404 error (Clouse, Raymond)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Dec 2017 13:09:58 -0500
From: Ku Dude <tku703 at gmail.com>
To: spacewalk-list at redhat.com
Subject: [Spacewalk-list] syncing epel to spacewalk 2.7
Message-ID:
<CALipfw0JgSvHTNdigR_VYprzQOBXzFJecFHJqexf52HJmpBQ0g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I keep getting the following error when i try to sync the EPEL repo with my spacewalk 2.7 install:
Importing packages:
|##################################################| 100.0%
13:05:16 Linking packages to channel.
Traceback (most recent call last):
File "/usr/bin/spacewalk-repo-sync", line 257, in <module>
sys.exit(abs(main() or 0))
File "/usr/bin/spacewalk-repo-sync", line 240, in main
elapsed_time, channel_ret_code = sync.sync()
File
"/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/reposync.py",
line 475, in sync
ret = self.import_packages(plugin, repo_id, url)
File
"/usr/lib/python2.7/site-packages/spacewalk/satellite_tools/reposync.py",
line 1038, in import_packages
importer.run()
File
"/usr/lib/python2.7/site-packages/spacewalk/server/importlib/importLib.py",
line 664, in run
self.fix()
File
"/usr/lib/python2.7/site-packages/spacewalk/server/importlib/packageImport.py",
line 76, in fix
self.backend.lookupChecksums(self.checksums)
File
"/usr/lib/python2.7/site-packages/spacewalk/server/importlib/backendOracle.py",
line 686, in lookupChecksums
raise e
spacewalk.server.rhnSQL.sql_base.SQLSchemaError: (99999, 'ERROR: LOCK TABLE can only be used in transaction blocks', '', InternalError('LOCK TABLE can only be used in transaction blocks\n',))
My server is running CentOS Linux release 7.4.1708.
Any advice is appreciated.
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/spacewalk-list/attachments/20171218/ca439b0d/attachment.html>
------------------------------
Message: 2
Date: Mon, 18 Dec 2017 20:48:25 +0000
From: "Kalchik, Jeffery" <JDKalchik at landolakes.com>
To: "spacewalk-list at redhat.com" <spacewalk-list at redhat.com>
Subject: [Spacewalk-list] Spacewalk 2.7 - errata & package issues
Message-ID:
<DM2PR01MB384A5910FCE126AB4BA9FCBCC0E0 at DM2PR01MB384.prod.exchangelabs.com>
Content-Type: text/plain; charset="us-ascii"
Good afternoon, all.
I've got what I think is a fairly standard methodology: a set of release channels, that are cloned into local production channels in successive stages (dev -> qa -> production.) This has been working fairly well for quite some time, with the exception of errata population. I know I don't have a large installation, less than 300 client servers, and 273 distinct channels (including a sandbox set.)
Unfortunately, I have internal requirements to keep the channels fairly complete, i.e. not just the latest packages available during a channel cloning or rolling operation. This does mean that spacewalk-clone-by-date really doesn't appear to work effectively. And, in general, when we elect to roll content from one stage to the next, it's a complete "this point in time," all packages and errata that are currently there. I'd like to be able to perform this content roll programmatically, rather than working through the web GUI with it's multitude of selections, clicks and confirmations.
Programmatically, I can get a list of packages from the clone_original channel without issue, and determine which packages are missing. Calling channel.software.addPackages is pretty simple.
Errata.... That's turning out to be another story. As all channels in use by client systems here are cloned channels, all errata should also be cloned as opposed to original, correct? At least, from the standpoint of the original channel set creation through a cloning operation, all of the errata come in with a CL- advisory name. Much like the package lists, I can get a list of errata from the clone_original, compare it against the current channel during a content roll operation, and determine which errata need to be clone. It would seem that calling errata.clone into the target channel would be appropriate. That's turning out to not be the case. I have a rather serious issue where errata cover multiple major distribution releases. The original errata get populated properly into the appropriate release channels, and only the proper packages for that that particular distribution release show up in that channel. However, if I clone that errata into a channel cloned from that re
lease channel, all packages get copied into that clone channel. For example, an errata notice might cover an EL6 and an EL7 (derived) release. The release/source channels will only contain the .el6 packages. However, the dev-* clone channels after a channel roll operation now contain the .el7 packages referenced in that errata notice.
Is errata.clone behaving as intended (I'm fairly sure it is?) Is there some other RPC API function call I should be using?
Jeff Kalchik
Systems Engineering
Land O'Lakes
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/spacewalk-list/attachments/20171218/1616b870/attachment.html>
------------------------------
Message: 3
Date: Mon, 18 Dec 2017 16:19:53 -0500 (EST)
From: Lai Wei-Hwa <whlai at robco.com>
To: spacewalk-list at redhat.com
Subject: [Spacewalk-list] Support for Xenial clients
Message-ID: <44335329.264774.1513631993991.JavaMail.zimbra at robco.com>
Content-Type: text/plain; charset="utf-8"
Hi Everyone,
Where can I follow for official news regarding support for Ubuntu 16.04 clients? From what I can tell, it's not quite doable yet.
Best Regards,
Lai Wei-Hwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/spacewalk-list/attachments/20171218/f6b47499/attachment.html>
------------------------------
Message: 4
Date: Mon, 18 Dec 2017 21:52:28 +0000
From: "Clouse, Raymond" <raymond.clouse at hireright.com>
To: "spacewalk-list at redhat.com" <spacewalk-list at redhat.com>
Subject: [Spacewalk-list] yup update/install gives 404 error
Message-ID:
<d30f2de34a5b4902a94d53ab26e67815 at bnaprdint-mbx10.Corp.HireRight.com>
Content-Type: text/plain; charset="us-ascii"
We're having a vexing issue with a new Spacewalk 2.6 installation.
We've made it a slave to a master (security reasons; only one SW is exposed to the Internet) and have everything synchronized and communicating successfully. But when we try to do an update or install with yum, we get a 404 error like this:
Error downloading packages:
nss-tools-3.28.4-8.el7.x86_64: failed to retrieve getPackage/nss-tools-3.28.4-8.el7.x86_64.rpm from our_repo
I find errors get logged in /var/log/httpd/error_log simultaneously like this:
[Mon Dec 18 20:02:31.638648 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: WARNING: log path not found; attempting to create /var/log/rhn [Mon Dec 18 20:02:31.638680 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: (None, None) [Mon Dec 18 20:02:31.638810 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: ERROR: unable to create log file path /var/log/rhn [Mon Dec 18 20:02:31.638837 2017] [:error] [pid 53696] Spacewalk 53696 2017/12/18 20:02:31 +01:00: (<type 'exceptions.OSError'>, OSError(13, 'Permission denied'))
Of course, /var/log/rhn exists and has proper permissions. I even set permissions to 777 just in case with no positive effect.
One other possible clue: in /var/log/rhn/rhn_taskomatic_daemon.log I found this:
INFO | jvm 1 | 2017/12/18 20:06:32 | com.mchange.v2.cfg.DelayedLogItem [ level -> FINE, text -> "The configuration file for resource identifier '/mchange-commons.properties' could not be found. Skipping.", exception -> java.io.FileNotFoundException: Resource not found at path '/mchange-commons.properties'.]
And in Googling that I found an unreplied post here that says:
--
Tomcat6 is having a problem finding mchange-commons when it's starting up which causes the web / api interface to fail, causing other parts of spacewalk to fail to initialize.
How / where can I get the mchange-commons installed and linked properly so that tomcat will be able to start?
--
So, in summary:
- Spacewalk set up as slave
- Clients can see SW
- SW knows which systems need upgrades
- Upgrades or installs fail with 404 error
--
Ray Clouse | Senior Systems Application Engineer | 3349 Michelson Drive Suite 150 | Irvine, CA 92612
949.428.5880 [o] | 949.870.6935 [m]
[cid:image003.png at 01D20E7A.0BAA12E0]<http://www.hireright.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/spacewalk-list/attachments/20171218/2f7df74e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4242 bytes
Desc: image001.png
URL: <https://www.redhat.com/archives/spacewalk-list/attachments/20171218/2f7df74e/attachment.png>
------------------------------
_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
End of Spacewalk-list Digest, Vol 115, Issue 36
***********************************************
More information about the Spacewalk-list
mailing list