Re: [Spacewalk-list] Foolish me, keeping my systems up to date... cobbler... grr...
On Fri, 2011-10-28 at 14:35 -0700, Ian Forde wrote:
> > Before upgrading be sure to make a backup of /etc/cobbler
> > and /var/lib/cobbler, this is where all your data resides. As some
> > things have changed, read these before you get into reading about all
> > the new features.
> >
> > - Review/modify the /etc/cobbler/modules.conf.rpmnew file to include your
> > site specific settings. Then move the new file into place.
> > - Review/modify the /etc/httpd/conf.d/cobbler_web.conf.rpmnew file and move
> > it into place.
> > - Remove mod_python
> > - Uncomment the LoadModule command in /etc/httpd/conf.d/wsgi.conf
> > - Change $kickstart_start/_done to $SNIPPET('kickstart_start')/_done in the
> > default kickstart template.
Some additional notes from detective work...
> So, I did the first step - it's just making sure that I have "module =
> authn_spacewalk" rather than "module = authn_denyall"
I also had to enable the tftp server in the config - just remembered
that one...
> Third step? DO NOT DO THIS. IT WILL ATTEMPT TO REMOVE SPACEWALK. (why oh
> why would this step be listed in the first place?)
Still freaked out by this one...
> Fifth step? This is what I've run smack into. The generated kickstart files
> all have a section around line 43 as such:
>
> > %pre$kickstart_start
> >
> > echo "Saving RHN keys..." > /dev/ttyS0
> > SYSTEM_ID=/etc/sysconfig/rhn/systemid
> > rhn_keys_found=no
The end of the generated kickstart file also has the following:
$kickstart_done
So it looks like something in Spacewalk isn't evaluating properly, as
the $kickstart_start and $kickstart_done macros are supposed to include
the new cobbler templates, but are just spitting out the raw text
instead. I don't think this is something I've done wrong, but I'm
wondering if anyone else is seeing this, or if it's something obvious in
the code... I'm still digging to see if something pops out.
Here's another question - if it turns out to be a Spacewalk issue (ie -
cobbler upgrade broke it, not I, and one or more of the Spacewalk RPMs
needs an upgrade to address it), would we have to wait until 1.6 for the
fix? Thus requiring people to not upgrade their cobbler installations
btw... Or would this be fixed in the 1.5 series, as cobbler 2.2.x is now
in EPEL...
-I
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Foolish me, keeping my systems up to date... cobbler... grr...
Recently I updated cobbler on my both of my CentOS 5.7 Spacewalk 1.5
servers. After figuring out (last week) that I needed to enable wsgi
in /etc/httpd/conf.d/wsgi.conf things worked again. Until today when I
needed to kickstart a box.
Going to https://fedorahosted.org/cobbler/wiki/WhatsNewInTwoTwo I see
the following instructions:
> Before upgrading be sure to make a backup of /etc/cobbler
> and /var/lib/cobbler, this is where all your data resides. As some
> things have changed, read these before you get into reading about all
> the new features.
>
> - Review/modify the /etc/cobbler/modules.conf.rpmnew file to include your
> site specific settings. Then move the new file into place.
> - Review/modify the /etc/httpd/conf.d/cobbler_web.conf.rpmnew file and move
> it into place.
> - Remove mod_python
> - Uncomment the LoadModule command in /etc/httpd/conf.d/wsgi.conf
> - Change $kickstart_start/_done to $SNIPPET('kickstart_start')/_done in the
> default kickstart template.
So, I did the first step - it's just making sure that I have "module =
authn_spacewalk" rather than "module = authn_denyall"
Second step? Nothing to do. It put in the new file just fine.
Third step? DO NOT DO THIS. IT WILL ATTEMPT TO REMOVE SPACEWALK. (why oh why
would this step be listed in the first place?)
Fourth step? Found that one on my own. Done.
Fifth step? This is what I've run smack into. The generated kickstart files
all have a section around line 43 as such:
> %pre$kickstart_start
>
> echo "Saving RHN keys..." > /dev/ttyS0
> SYSTEM_ID=/etc/sysconfig/rhn/systemid
> rhn_keys_found=no
So it appears that I have to change some default kickstart template.
Somewhere. Anyone know where?
-Ian
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Still having rhnpush ISE errors
I am done for now... Spacewalk is able to run and do rhnpush on 1.3 (32 bit) with no issues. Spacewalk is running in version 1.5 without issue on a 64 bit server. Since all from scratch installs of OS (32 bit) and SW for both 1.4 and 1.5 have the rhnpush issue, I am guessing that it may be a bug or a package conflict. Can anyone confirm this? Is it\will it be resolved in 1.6 or maybe 1.7? From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of Gomes, Rich Sent: Thursday, October 27, 2011 2:55 PM To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] Still having rhnpush ISE errors Also, browsing to http://servername/XMLRPC gives a 500 error Have found some posts for this but nothing that has helped so far. From: Gomes, Rich Sent: Thursday, October 27, 2011 11:21 AM To: spacewalk-list@redhat.com Subject: Still having rhnpush ISE errors I decided to take a different approach on the server I was having issues with when renaming. Here are the steps I took: * Cloned VM and configured with IP of current working SP server with old naming convention * Removed Spacewalk via yum and rebooted * Renamed machine and rebooted * Installed Spacewalk 1.3 (oracle) o Only needed to remove old ssl cert and create new one * Services started without issue and rhnpush was successful. * Upgraded to 1.4 * Services started without issue * Rhnpush fails with Internal Server Error (although it gets to the "computing checksums" portion before it fails) httpd error log included below Interesting thing is I had a 64 bit RHEL server I decided to install 1.3 on. Install was successful, services started and rhnpush had no issues. Upgraded to 1.4. Services started, and rhnpush IS successful. Why is 64 bit successful and 32 bit is not? All of my from scratch installs (OS and SW) of 1.5 fail also, so is this a bug or a package conflict? What does "SgmlopParser instance has no attribute '_parser'" mean? (Google unsuccessful) [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: Traceback (most recent call last): [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch\nresult = object(req) [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/spacewalk/server/apacheHandler.py", line 71, in headerParserHandler\nret = apacheSession.headerParserHandler(self, req) [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/spacewalk/common/rhnApache.py", line 75, in headerParserHandler\nret = self._init_request_processor(req) [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/spacewalk/server/apacheHandler.py", line 107, in _init_request_processor\nself._req_processor = apachePOST(self.clientVersion, req) [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] 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 [Thu Oct 27 10:52:27 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: AttributeError: SgmlopParser instance has no attribute '_parser' [Thu Oct 27 10:52:46 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: Traceback (most recent call last): [Thu Oct 27 10:52:46 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch\nresult = object(req) [Thu Oct 27 10:52:46 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/spacewalk/server/apacheHandler.py", line 71, in headerParserHandler\nret = apacheSession.headerParserHandler(self, req) [Thu Oct 27 10:52:46 2011] [error] [client 127.0.0.1] PythonHeaderParserHandler spacewalk.server.apacheServer::HeaderParserHandler: File "/usr/lib/python2.4/site-packages/spacewalk/common/rhnApache.py", line 75, in headerParserHandler\nret = self._init_request_processor(req) [Thu Oct 27 10:52:46 2011] [error] [client 127.0.0.1] PythonHeaderParserHandle
[Spacewalk-list] Errors in postgresql Log File
I think I might have found why certain actions aren't being picked up by my spacewalk clients. The actions are indeed being picked up, but there are bunch of "compare config file revision tasks" blocking the queue. These are not completing, I'm hypothesizing, because of: ERROR: invalid input syntax for type bytea at character 114 STATEMENT: insert into rhnActionConfigRevisionResult (action_config_revision_id, result) values (69925, E'--- /root/.bashrc Wed Sep 22 23:59:52 2004 +++ /tmp/.rhn-cfg-tmp-30263-g_Y4rn Fri Oct 28 11:21:36 2011 @@ -6,7 +6,36 @@ alias cp=''cp -i'' alias mv=''mv -i'' … I'm having a hard time deciphering where character 114 is in this output. Is it the double-single quotes in the alias lines there that are throwing it off? The actual file contains only a single quote (alias cp='cp -i'). Anyone have any ideas? Spacewalk 1.5 on Cent 6 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
