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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 18 de dezembro de 2017 21:53 To: [email protected] Subject: Spacewalk-list Digest, Vol 115, Issue 36 Send Spacewalk-list mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: [email protected] Subject: [Spacewalk-list] syncing epel to spacewalk 2.7 Message-ID: <calipfw0jgsvhtndigr_vyprzqobxzfjecfhjqexf52hjmpb...@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" <[email protected]> To: "[email protected]" <[email protected]> Subject: [Spacewalk-list] Spacewalk 2.7 - errata & package issues Message-ID: <dm2pr01mb384a5910fce126ab4ba9fcbcc...@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 <[email protected]> To: [email protected] Subject: [Spacewalk-list] Support for Xenial clients Message-ID: <[email protected]> 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" <[email protected]> To: "[email protected]" <[email protected]> Subject: [Spacewalk-list] yup update/install gives 404 error Message-ID: <d30f2de34a5b4902a94d53ab26e67...@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:[email protected]]<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 [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list End of Spacewalk-list Digest, Vol 115, Issue 36 *********************************************** _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
