Re: [Spacewalk-list] Upgrade issue when umask set to 0077
Hi, What is the conclusion on this issue? Thanks, Pierre 2012/2/6 Pierre Casenove pcasen...@gmail.com: Hello, I was not very clear on my issue on my first post, apologies. So, what happens exactly when the file is created with 600 access mode: - When navigating to Systems -- Kickstart -- Profiles and selecting a kickstart, the following msg appears on the top: There are errors in your kickstart template. Please check the a href=/rhn/kickstart/KickstartFileDownload.do?ksid=2template errors/a to determine the problem with the template. - When opening the kickstart in a browser, here is the error: pre Mod_python error: PythonHandler services Traceback (most recent call last): File /usr/lib64/python2.4/site-packages/mod_python/apache.py, line 287, in HandlerDispatch log=debug) File /usr/lib64/python2.4/site-packages/mod_python/apache.py, line 464, in import_module module = imp.load_module(mname, f, p, d) File /var/www/cobbler/svc/services.py, line 22, in ? from cobbler.services import CobblerSvc File /usr/lib/python2.4/site-packages/cobbler/services.py, line 36, in ? import remote File /usr/lib/python2.4/site-packages/cobbler/remote.py, line 45, in ? import api as cobbler_api File /usr/lib/python2.4/site-packages/cobbler/api.py, line 28, in ? import action_sync File /usr/lib/python2.4/site-packages/cobbler/action_sync.py, line 36, in ? import templar File /usr/lib/python2.4/site-packages/cobbler/templar.py, line 29, in ? from template_api import Template File /usr/lib/python2.4/site-packages/cobbler/template_api.py, line 42, in ? raise CX(/etc/cobbler/settings is not a valid YAML file) CX: '/etc/cobbler/settings is not a valid YAML file' /pre Here is the appache_error_log: [Mon Feb 06 15:59:31 2012] [notice] mod_python: (Re)importing module 'services' [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: Traceback (most recent call last): [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib64/python2.4/site-packages/mod_python/apache.py, line 287, in HandlerDispatch\n log=debug) [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib64/python2.4/site-packages/mod_python/apache.py, line 464, in import_module\n module = imp.load_module(mname, f, p, d) [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /var/www/cobbler/svc/services.py, line 22, in ?\n from cobbler.services import CobblerSvc [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib/python2.4/site-packages/cobbler/services.py, line 36, in ?\n import remote [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib/python2.4/site-packages/cobbler/remote.py, line 45, in ?\n import api as cobbler_api [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib/python2.4/site-packages/cobbler/api.py, line 28, in ?\n import action_sync [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib/python2.4/site-packages/cobbler/action_sync.py, line 36, in ?\n import templar [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib/python2.4/site-packages/cobbler/templar.py, line 29, in ?\n from template_api import Template [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: File /usr/lib/python2.4/site-packages/cobbler/template_api.py, line 42, in ?\n raise CX(/etc/cobbler/settings is not a valid YAML file) [Mon Feb 06 15:59:31 2012] [error] [client 10.120.193.15] PythonHandler services: CX: '/etc/cobbler/settings is not a valid YAML file' When setting 644 access mode on file /etc/cobbler/settings, everything is correct I have ran 2 spacewalk upgrades, and this file permission issue is the only one I encountered each time. The rest was correct. As spacewalk-upgrade is run as root, it could also save the current umask value at the beggining, change it to 0022 and returns to original value at the end. I checked a bit the upgrade script when I worked on the fix, and this file is the only one created from scratch, this might be the real issue. Anyway, I let you decide what's best. Pierre 2012/2/6 Jan Pazdziora jpazdzi...@redhat.com: On Wed, Jan 25, 2012 at 08:51:20AM +0100, Pierre Casenove wrote: Hello, I ran into an issue when I upgraded from SW 1.5 to SW 1.6: - on my set up, root user has an umask of 0077 - during setup, /etc/cobbler/settings is backuped and recreated... but with permission set to root:root 600 - Apache can't access the file until chmod 644 is performed What is the error produced by Apache? Please find attached a patch that simply calls chmod after cobbler file has been created in spacewalk-setup
Re: [Spacewalk-list] Random Spacewalk things I've found...
On Wed, Jan 18, 2012 at 10:15:17AM +0100, Jan Pazdziora wrote:
On Tue, Jan 17, 2012 at 09:29:06PM -0800, Ian Forde wrote:
Here are some things that I've found recently...
We might prefer to have these issues tracked in separate posts/threads
'cause from the long post we might lose some things.
(more info on this)
I just kickstarted a node, and had it happen again. I logged in, did
a 'rhn-profile-sync' successfully. Then I did a 'rhn_check -vv' and
got the following back:
XMLRPC ProtocolError: ProtocolError for ordmantell.iforde.net
/XMLRPC: 500 Internal Server Error
I looked in /var/log/messages on the spacewalk server (I have logging
to syslog enabled in postgres for things like this), and saw the
following:
Jan 17 21:25:05 ordmantell postgres[22246]: [3-1] ERROR: new row for
relation rhnpackageevr violates check constraint
vn_rhnpackageevr_epoch
Jan 17 21:25:05 ordmantell postgres[22246]: [3-2] CONTEXT: SQL
statement INSERT INTO rhnPackageEvr (id, epoch, version, release,
evr) VALUES (nextval('rhn_pkg_evr_seq'), $1 , $2 , $3 ,EVR_T( $1 ,
$2 , $3 ))
Jan 17 21:25:05 ordmantell postgres[22246]: [3-3] #011PL/pgSQL
function lookup_evr line 10 at SQL statement
Jan 17 21:25:05 ordmantell postgres[22246]: [3-4] #011SQL statement
SELECT LOOKUP_EVR( $1 , $2 , $3 )
Jan 17 21:25:05 ordmantell postgres[22246]: [3-5] #011PL/pgSQL
function lookup_transaction_package line 20 at SQL statement
Jan 17 21:25:05 ordmantell postgres[22246]: [3-6] STATEMENT:
Jan 17 21:25:05 ordmantell postgres[22246]: [3-7] #011insert into
rhnPackageDeltaElement
Jan 17 21:25:05 ordmantell postgres[22246]: [3-8] #011
(package_delta_id, transaction_package_id)
Jan 17 21:25:05 ordmantell postgres[22246]: [3-9] #011values
Jan 17 21:25:05 ordmantell postgres[22246]: [3-10] #011 (9240,
Jan 17 21:25:05 ordmantell postgres[22246]: [3-11] #011
lookup_transaction_package(E'insert', E'389-ds-base', E'',
E'1.2.9.14', E'1.el6', NULL))
Jan 17 21:25:05 ordmantell postgres[22246]: [3-12] #011
Hope that helps...
Can you try to patch your server_kickstart.py with
diff --git a/backend/server/rhnServer/server_kickstart.py
b/backend/server/rhnServer/server_kickstart.py
index 7ba167b..0eca170 100644
--- a/backend/server/rhnServer/server_kickstart.py
+++ b/backend/server/rhnServer/server_kickstart.py
@@ -580,8 +580,7 @@ def _packages_from_cursor(cursor):
# We ignore GPG public keys since they are too weird to schedule
# as a package delta
continue
-result.append((p_name, row['version'], row['release'],
-row['epoch'] or ''))
+result.append((p_name, row['version'], row['release'], row['epoch']))
return result
_query_lookup_pending_kickstart_sessions = rhnSQL.Statement(
restart httpd and see if it fixes the problem for you?
I've pushed this change now anyway.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Upgrade issue when umask set to 0077
On Mon, Feb 06, 2012 at 05:11:02PM +0100, Pierre Casenove wrote: When setting 644 access mode on file /etc/cobbler/settings, everything is correct I have ran 2 spacewalk upgrades, and this file permission issue is the only one I encountered each time. The rest was correct. As I have now added explicit chmod to Spacewalk master, 3c3a1f678f373e00daa97199690b0dea54953417. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Fedora 16 client not getting updates from Spacewalk 1.6
On Fri, Feb 03, 2012 at 05:38:18PM +, Alan Pittman wrote: Jonathan, Thanks for the reply. Unfortunately, I have tried that and it does not work. The steps that I have taken are: # yum clean all # cd /var/cache/yum # rm -Rf ./* # yum makecache # yum check-update With the /etc/yum/repos.d/fedora-updates.repo turned off (enable=0), I don't receive any messages stating that there are RPMs to receive and apply. If I turn fedora-updates.repo on, the I get a list. Whatever the problem is, it just recently occurred. Up until approximately a week ago, I was able to update F16 from Spacewalk without any issues. I even tried removing the spacewalk-client RPMs, re-installing them and re-registering the client. Still no luck. I don't think the problem is on the client at all. To yum, Spacewalk-based repos are more-or-less the same as normal repos -- yum downloads the repodata and acts based on those. So you need to check the status of the repo sync and repodata generation on the server first. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] upgrade to 1.6 error -- login impossible
On Fri, Feb 03, 2012 at 11:16:43AM -0500, Janet Houser wrote: Hi, Our spacewalk server is running Centos 5.7 (2.6.18-274.17.1.el5) and was running vs. 1.3 (very old). Over the last two days I've upgraded the system from 1.3 to 1.4. Then from 1.4 to 1.5 following the instructions located at the links shown below: https://fedorahosted.org/spacewalk/wiki/HowToUpgrade14 https://fedorahosted.org/spacewalk/wiki/HowToUpgrade15 The system seemed to upgrade fine. This morning, I attempted an upgrade from 1.5 to 1.6 following the instructions provided below: https://fedorahosted.org/spacewalk/wiki/HowToUpgrade After the upgrade, it seems that spacewalk does not start properly. The errors that I get are: /usr/sbin/spacewalk-service start Starting spacewalk services... Initializing jabberd processes ... Starting router: [ OK ] Starting sm: [ OK ] Starting c2s: [ OK ] Starting s2s: [ OK ] Starting osa-dispatcher: [ OK ] Starting tomcat5: [ OK ] Waiting for tomcat to be ready ... Starting httpd:[ OK ] Starting Monitoring ...Starting InstallSoftwareConfig ... [ OK ] Starting NotifEscalator ... [ OK ] Starting GenerateNotifConfig ... [ OK ] Starting NotifLauncher ... [ OK ] Starting Notifier ... [ OK ] Starting AckProcessor ... [ OK ] Starting TSDBLocalQueue ... [ OK ] [ OK ] Starting MonitoringScout ...Starting NPBootstrap ... 2012-02-03 11:04:13 NPBootstrap: !! ERROR FROM SHELL COMM ND: 2012-02-03 11:04:13 NPBootstrap:!! STDOUT: Requesting **XPROTO**://**RHN_SAT_HOSTNAME**/ atconfig/cgi-bin/fetch_netsaintid.cgi?ssk=1f0cecc3cb76publickey=ssh-dss%20B3NzaC1kc3MAAACBA xOjbDcw5rbUyijJO3BMrSeUcY4s5%2FBbykqOuMF2Hq6yAfUxsHkzdynQTag1F6orA3UFkwlAyzWqKJ2lv9n9%2FeLe09XxY MhLDlzO%2B6u8Kktfr5k5JeXsmPPCBg0DyFUTTB3Cau3dj%2FOxDuf0eeouydXS6xFHhKJNffsTexMUlxFQCMr%2FJ55 mSrJVvzV2oV9ek6YotGQAAAIBZdEKNkbKiXMqllO9ocSxOwxHSvvLHKtU0h1vMCdIK16%2B3fAkDx8RDxGrS5je75aZTRXVy iBCq0u3LJ%2B30bcRFAuGt86TIzIe6v81t%2BZu3hKopz%2FXn0zQAZsQVIkIccQXXzCwmAW22hPUvbWXJ%2BlM%2FNcwGFJ %2BBUzYrFDh%2F0lagAAAIB3bP%2B4rxnQP9L5fDJi5e2kCflPDLcr51SRNyf7FCapbYRPNCfzV96vryfpVjW0EDqUJJiPyr %wvMKkpvPr8gLvLLfx%2FlEjjhFPIJZWeQAVVSY9fUI7RaD4SZ0wBC9hI2Q6XIi6ab4IJVRKhePsuBk1tKnaXyk660JTkPJLr %XnKA%3D%3D%20nocpulse%40yummy%2Eocc%2Eharvard%2Eedu%0A Error on attempt 1: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 2: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 3: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 4: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Failed 5 times to get data for this node. 2012-02-03 11:04:13 NPBootstrap:!! STDERR: 2012-02-03 11:04:13 NPBootstrap:!! EXIT: 256 [ FAIL ] 2012-02-03 11:04:13 NPBootstrap: WARNING: STARTED BUT *NOT* RUNNING 2012-02-03 11:04:13 NPBootstrap: ERRORS ENCOUNTERED DURING LAST ACTION: 2012-02-03 11:04:13 NPBootstrap:!! ERROR FROM SHELL COMMAND: 2012-02-03 11:04:13 NPBootstrap:!! STDOUT: Requesting **XPROTO**://**RHN_SAT_HOSTNAME**/satconfig/cgi-bin/fetch_netsaintid.cgi?ssk=1f0cecc3cb76publickey=ssh-dss%20B3NzaC1kc3MAAACBAJxOjbDcw5rbUyijJO3BMrSeUcY4s5%2FBbykqOuMF2Hq6yAfUxsHkzdynQTag1F6orA3UFkwlAyzWqKJ2lv9n9%2FeLe09XxYcMhLDlzO%2B6u8Kktfr5k5JeXsmPPCBg0DyFUTTB3Cau3dj%2FOxDuf0eeouydXS6xFHhKJNffsTexMUlxFQCMr%2FJ55BmSrJVvzV2oV9ek6YotGQAAAIBZdEKNkbKiXMqllO9ocSxOwxHSvvLHKtU0h1vMCdIK16%2B3fAkDx8RDxGrS5je75aZTRXVyriBCq0u3LJ%2B30bcRFAuGt86TIzIe6v81t%2BZu3hKopz%2FXn0zQAZsQVIkIccQXXzCwmAW22hPUvbWXJ%2BlM%2FNcwGFJB%2BBUzYrFDh%2F0lagAAAIB3bP%2B4rxnQP9L5fDJi5e2kCflPDLcr51SRNyf7FCapbYRPNCfzV96vryfpVjW0EDqUJJiPyr0wvMKkpvPr8gLvLLfx%2FlEjjhFPIJZWeQAVVSY9fUI7RaD4SZ0wBC9hI2Q6XIi6ab4IJVRKhePsuBk1tKnaXyk660JTkPJLrVXnKA%3D%3D%20nocpulse%40yummy%2Eocc%2Eharvard%2Eedu%0A Error on attempt 1: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 2: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 3: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 4: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Failed 5 times to get data for this node. Did you run /usr/share/spacewalk/setup/upgrade/rhn-enable-monitoring.pl --enable-scout during upgrade? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list
Re: [Spacewalk-list] upgrade to 1.6 error -- login impossible
On Tue, Feb 28, 2012 at 12:20:27PM +0100, Jan Pazdziora wrote: On Fri, Feb 03, 2012 at 11:16:43AM -0500, Janet Houser wrote: Hi, Our spacewalk server is running Centos 5.7 (2.6.18-274.17.1.el5) and was running vs. 1.3 (very old). Over the last two days I've upgraded the system from 1.3 to 1.4. Then from 1.4 to 1.5 following the instructions located at the links shown below: https://fedorahosted.org/spacewalk/wiki/HowToUpgrade14 https://fedorahosted.org/spacewalk/wiki/HowToUpgrade15 The system seemed to upgrade fine. This morning, I attempted an upgrade from 1.5 to 1.6 following the instructions provided below: https://fedorahosted.org/spacewalk/wiki/HowToUpgrade After the upgrade, it seems that spacewalk does not start properly. The errors that I get are: /usr/sbin/spacewalk-service start Starting spacewalk services... Initializing jabberd processes ... Starting router: [ OK ] Starting sm: [ OK ] Starting c2s: [ OK ] Starting s2s: [ OK ] Starting osa-dispatcher: [ OK ] Starting tomcat5: [ OK ] Waiting for tomcat to be ready ... Starting httpd:[ OK ] Starting Monitoring ...Starting InstallSoftwareConfig ... [ OK ] Starting NotifEscalator ... [ OK ] Starting GenerateNotifConfig ... [ OK ] Starting NotifLauncher ... [ OK ] Starting Notifier ... [ OK ] Starting AckProcessor ... [ OK ] Starting TSDBLocalQueue ... [ OK ] [ OK ] Starting MonitoringScout ...Starting NPBootstrap ... 2012-02-03 11:04:13 NPBootstrap: !! ERROR FROM SHELL COMM ND: 2012-02-03 11:04:13 NPBootstrap:!! STDOUT: Requesting **XPROTO**://**RHN_SAT_HOSTNAME**/ atconfig/cgi-bin/fetch_netsaintid.cgi?ssk=1f0cecc3cb76publickey=ssh-dss%20B3NzaC1kc3MAAACBA xOjbDcw5rbUyijJO3BMrSeUcY4s5%2FBbykqOuMF2Hq6yAfUxsHkzdynQTag1F6orA3UFkwlAyzWqKJ2lv9n9%2FeLe09XxY MhLDlzO%2B6u8Kktfr5k5JeXsmPPCBg0DyFUTTB3Cau3dj%2FOxDuf0eeouydXS6xFHhKJNffsTexMUlxFQCMr%2FJ55 mSrJVvzV2oV9ek6YotGQAAAIBZdEKNkbKiXMqllO9ocSxOwxHSvvLHKtU0h1vMCdIK16%2B3fAkDx8RDxGrS5je75aZTRXVy iBCq0u3LJ%2B30bcRFAuGt86TIzIe6v81t%2BZu3hKopz%2FXn0zQAZsQVIkIccQXXzCwmAW22hPUvbWXJ%2BlM%2FNcwGFJ %2BBUzYrFDh%2F0lagAAAIB3bP%2B4rxnQP9L5fDJi5e2kCflPDLcr51SRNyf7FCapbYRPNCfzV96vryfpVjW0EDqUJJiPyr %wvMKkpvPr8gLvLLfx%2FlEjjhFPIJZWeQAVVSY9fUI7RaD4SZ0wBC9hI2Q6XIi6ab4IJVRKhePsuBk1tKnaXyk660JTkPJLr %XnKA%3D%3D%20nocpulse%40yummy%2Eocc%2Eharvard%2Eedu%0A Error on attempt 1: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 2: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 3: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 4: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Failed 5 times to get data for this node. 2012-02-03 11:04:13 NPBootstrap:!! STDERR: 2012-02-03 11:04:13 NPBootstrap:!! EXIT: 256 [ FAIL ] 2012-02-03 11:04:13 NPBootstrap: WARNING: STARTED BUT *NOT* RUNNING 2012-02-03 11:04:13 NPBootstrap: ERRORS ENCOUNTERED DURING LAST ACTION: 2012-02-03 11:04:13 NPBootstrap:!! ERROR FROM SHELL COMMAND: 2012-02-03 11:04:13 NPBootstrap:!! STDOUT: Requesting **XPROTO**://**RHN_SAT_HOSTNAME**/satconfig/cgi-bin/fetch_netsaintid.cgi?ssk=1f0cecc3cb76publickey=ssh-dss%20B3NzaC1kc3MAAACBAJxOjbDcw5rbUyijJO3BMrSeUcY4s5%2FBbykqOuMF2Hq6yAfUxsHkzdynQTag1F6orA3UFkwlAyzWqKJ2lv9n9%2FeLe09XxYcMhLDlzO%2B6u8Kktfr5k5JeXsmPPCBg0DyFUTTB3Cau3dj%2FOxDuf0eeouydXS6xFHhKJNffsTexMUlxFQCMr%2FJ55BmSrJVvzV2oV9ek6YotGQAAAIBZdEKNkbKiXMqllO9ocSxOwxHSvvLHKtU0h1vMCdIK16%2B3fAkDx8RDxGrS5je75aZTRXVyriBCq0u3LJ%2B30bcRFAuGt86TIzIe6v81t%2BZu3hKopz%2FXn0zQAZsQVIkIccQXXzCwmAW22hPUvbWXJ%2BlM%2FNcwGFJB%2BBUzYrFDh%2F0lagAAAIB3bP%2B4rxnQP9L5fDJi5e2kCflPDLcr51SRNyf7FCapbYRPNCfzV96vryfpVjW0EDqUJJiPyr0wvMKkpvPr8gLvLLfx%2FlEjjhFPIJZWeQAVVSY9fUI7RaD4SZ0wBC9hI2Q6XIi6ab4IJVRKhePsuBk1tKnaXyk660JTkPJLrVXnKA%3D%3D%20nocpulse%40yummy%2Eocc%2Eharvard%2Eedu%0A Error on attempt 1: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 2: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 3: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Error on attempt 4: Status: '400 URL must be absolute'; content: '400 URL must be absolute ' Failed 5 times to get data for this node. Did you run /usr/share/spacewalk/setup/upgrade/rhn-enable-monitoring.pl --enable-scout during upgrade? Also, what
Re: [Spacewalk-list] Kickstart CentOS 6 Fail Spacewalk
On Wed, Feb 08, 2012 at 12:35:08PM -0700, Jeremy Davis wrote: An update to this issue is if I use repodata generated from a local yum repository it works just fine. One other note I would like to add is that So what is the difference (the content difference) between those and the repodata you got from that /var/cache? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] spacecmd config channel export error
On Thu, Feb 09, 2012 at 05:53:35PM +0100, VAN LIEDEKERKE Franky ATO-TOB
wrote:
When using the configchannel_export function of spacecmd, I seem to bump
into an error with a specific config channel:
spacecmd {SSM:0} configchannel_export TEST
INFO: Exporting cc TEST to TEST.json
INFO: Getting config channel details for TEST
ERROR: xml declaration not at start of external entity: line 1330, column 15
Any hints on how to debug this?
What is the Spacewalk server version?
What is specific about that config channel?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] OSA Not Picking Up Actions - Most of the Time
On Tue, Jan 24, 2012 at 07:21:02PM +, Wojtak, Greg (Superfly) wrote:
I've been having troubles on and off with OSA picking up actions for a long
time now (since the middle of 2011). It's been broken completely for months
and I had given up on it for a while so I could focus on other projects.
Recently, I updated the spacewalk client on one of my Cent 5 servers to the
packages from the 1.6 repository (everything else is 1.5). That client
started picking up actions. I upgraded a Cent 6 client and it started
picking up actions. Now, we're back to everything not working again. I've
tried stopping OSA clients, osa-dispatcher, and jabberd and cleaning out
/var/lib/jabber/db, but still no scheduled actions get picked up. I'm not
sure what's changing that causes this to break. At one point when I first
set this up, all clients were picking up tasks normally (even those behind
our proxy).
The general rule is -- do not clean the /var/lib/jabber/db stop.
If you need to debug, stop osad service on the client and run
something like osad -N -v and see if it gets the subscription='both'
message eventually.
I upped the verbosity of everything OSA related I could think of (jabber,
osad, osa-dispatcher) and I noticed in the osa-dispatcher.log that I keep
getting the following message repeated every 15 seconds or so:
2012/01/24 14:13:39 -04:00 10143 0.0.0.0:
osad/jabber_lib._roster_callback('Updating the roster', iq type='result'
id='iq-request-1485e3-1362'query xmlns = 'jabber:iq:roster' item
jid='osad-6dd99be55c@spacewalk' subscription='both' /item
jid='osad-85a280d1a5@spacewalk' subscription='both' /item
jid='osad-25ed3808b1@spacewalk' subscription='both' /item
jid='osad-b3b8a0898c@spacewalk' subscription='both' /item
jid='osad-b902405a31@spacewalk' subscription='both' /item
jid='osad-fe3f0f59f6@spacewalk' subscription='both' /item
jid='osad-10b42d611a@spacewalk' subscription='both' /item
jid='osad-f0f388c885@spacewalk' subscription='both' /item
jid='osad-6021c959dd@spacewalk' subscription='both' /item
jid='osad-28dc0ddee4@spacewalk' subscription='both' /item
jid='osad-403d7f1572@spacewalk' subscription='both' /item
jid='osad-c294e8be55@spacewalk' subscription='both' /item
jid='osad-bdd7889037@spacewalk' subscription='both' /item
jid='osad-6398479353@s!
pa!
cewalk' subscription='both' /item jid='osad-c182dc85c6@spacewalk'
subscription='both' /item jid='osad-11a37bc699@spacewalk'
subscription='both' /item jid='osad-77dbbcccd5@spacewalk'
subscription='both' /item jid='osad-c67db0d167@spacewalk'
subscription='both' /item jid='osad-bf92fac08a@spacewalk'
subscription='both' /item jid='osad-bfbff17037@spacewalk'
subscription='both' /item jid='osad-18812f1a6b@spacewalk'
subscription='both' /item jid='osad-e649e75e71@spacewalk'
subscription='both' /item jid='osad-2a7e50b55f@spacewalk'
subscription='both' /item jid='osad-688025edeb@spacewalk'
subscription='both' /item jid='osad-4b6e8f533a@spacewalk'
subscription='both' /item jid='osad-0451103b21@spacewalk'
subscription='both' /item jid='osad-b011b1c0d2@spacewalk'
subscription='both' /item jid='osad-451aaaee64@spacewalk'
subscription='both' /item jid='osad-1b0a719359@spacewalk'
subscription='both' /item jid='osad-194a9a90a0@spacewalk'
subscription='both!
' !
/item jid='osad-67b967a5ec@spacewalk' subscription='both' /item ji
d='osad-9eebbd9684@spacewalk' subscription='both' /item
jid='osad-af9f4b0a93@spacewalk' subscription='both' /item
jid='osad-2dee90ef72@spacewalk' subscription='both' /item
jid='osad-c4dabbab4a@spacewalk' subscription='both' /item
jid='osad-82c3fd1196@spacewalk' subscription='both' /item
jid='osad-f6336873b9@spacewalk' subscription='both' /item
jid='osad-08e127bbe1@spacewalk' subscription='both' /item
jid='osad-981cef0a59@spacewalk' subscription='both' /item
jid='osad-2299f285cb@spacewalk' subscription='both' /item
jid='osad-e5bb60fae6@spacewalk' subscription='both' /item
jid='osad-ceee60b35a@spacewalk' subscription='both' /item
jid='osad-4ab5858f26@spacewalk' subscription='both' /item
jid='osad-c5d8b414cf@spacewalk' subscription='both' /item
jid='osad-ed5c434fb0@spacewalk' subscription='both' /item
jid='osad-395b66990a@spacewalk' subscription='both' /item
jid='osad-4d777a57e3@spacewalk' subscription='both' /item
jid='osad-dbb78ff69a@spacewal!
k'!
subscription='both' /item jid='osad-6993a948ba@spacewalk'
subscription='both' /item jid='osad-ff2a8b73b3@spacewalk'
subscription='both' /item jid='osad-293b707684@spacewalk'
subscription='both' /item jid='osad-c62f89446c@spacewalk'
subscription='both' /item jid='osad-77eecb67cc@spacewalk'
subscription='both' /item jid='osad-8af17b5e81@spacewalk'
subscription='both' /item jid='osad-956277335c@spacewalk'
subscription='both' /item jid='osad-2c8fbbb064@spacewalk'
subscription='both' /item jid='osad-22f5357ae2@spacewalk'
subscription='both' /item
Re: [Spacewalk-list] Lock computers
On Fri, Feb 17, 2012 at 08:40:48AM -0800, Hector Jimenez wrote: Does anyone knows if you can lock Firefox and Google chrome settings then clients cannot change it using Spacewalk 1.6? How do you lock Firefox and Google Chrome without Spacewalk? In other words, how would you achieve that locally on that machine? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] 500 ISE (Timeout) When Updating Kickstart Profile?
On Fri, Feb 17, 2012 at 02:06:56PM +, Wojtak, Greg (Superfly) wrote: Hi there, Spacewalk 1.6 Postgres Cent 6.2 (64-bit) Has anyone else run into an issue where, when updating a kickstart profile (or cloning, or doing anything with it really) that you consistently time out with a 500 error after the request times out? What I'm seeing looks to be nothing more than the query (queries?) taking too long to run. I can see the queries while I'm waiting for a response after I hit the Update Profile button. Eventually, when the request times out and the query finally finishes and I browse back into Spacewalk, I get the message at the top of the screen that the profile has been updated successfully (and indeed it appears it has been). I've increased the HTTP timeout to 300 seconds (from 120) to try and work around this, but should it really take five minutes to update a profile? The one query I was able to capture during this was: SELECT CP.package_id, CP.name_id, CP.evr_id, CP.package_arch_id FROM rhnPackageName PN inner join rhnChannelNewestPackage CP on CP.name_id = PN.id inner join rhnChannel C on C.id = Cp.channel_id inner join rhnPackage P on P.id = CP.package_id inner join rhnPackageEvr EVR on P.evr_id = EVR.id WHERE ( C.id = $1 or C.parent_channel = $2) AND PN.name = $3 AND C.label not like '%beta%' order by EVR.evr DESC (sorry for the bad formatting) I'm not sure what the $1, $2, and $3 are (I presume this is calling some sort of a procedure and those are arguments). Those are bind parameters. You can replace them with some reasonable values. Please analyze your tables and run explain plan to see what is happening. I assume your cobbler is running and is reachable just fine. Anything of interest in /var/log/tomcat6/catalina.out? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] OSA Not Picking Up Actions - Most of the Time
Thanks Jan. I'll dig into whether these machines (specifically the last
one) are getting their actions picked up. That's good to know about not
cleaning up /var/lib/jabber/db - it seemed like for a while there that
recommendation was flying around all over this list.
On a side note, I've noticed that after upgrading the spacewalk server to
1.6, any 1.6 clients are consistently picking up their actions as long as
they are not behind a proxy. I've not tested the success rate for servers
connecting through a proxy.
- Greg
On 2012-02-28 7:37 AM, Jan Pazdziora jpazdzi...@redhat.com wrote:
On Tue, Jan 24, 2012 at 07:21:02PM +, Wojtak, Greg (Superfly) wrote:
I've been having troubles on and off with OSA picking up actions for a
long time now (since the middle of 2011). It's been broken completely
for months and I had given up on it for a while so I could focus on
other projects. Recently, I updated the spacewalk client on one of my
Cent 5 servers to the packages from the 1.6 repository (everything else
is 1.5). That client started picking up actions. I upgraded a Cent 6
client and it started picking up actions. Now, we're back to everything
not working again. I've tried stopping OSA clients, osa-dispatcher, and
jabberd and cleaning out /var/lib/jabber/db, but still no scheduled
actions get picked up. I'm not sure what's changing that causes this to
break. At one point when I first set this up, all clients were picking
up tasks normally (even those behind our proxy).
The general rule is -- do not clean the /var/lib/jabber/db stop.
If you need to debug, stop osad service on the client and run
something like osad -N -v and see if it gets the subscription='both'
message eventually.
I upped the verbosity of everything OSA related I could think of
(jabber, osad, osa-dispatcher) and I noticed in the osa-dispatcher.log
that I keep getting the following message repeated every 15 seconds or
so:
2012/01/24 14:13:39 -04:00 10143 0.0.0.0:
osad/jabber_lib._roster_callback('Updating the roster', iq
type='result' id='iq-request-1485e3-1362'query xmlns =
'jabber:iq:roster' item jid='osad-6dd99be55c@spacewalk'
subscription='both' /item jid='osad-85a280d1a5@spacewalk'
subscription='both' /item jid='osad-25ed3808b1@spacewalk'
subscription='both' /item jid='osad-b3b8a0898c@spacewalk'
subscription='both' /item jid='osad-b902405a31@spacewalk'
subscription='both' /item jid='osad-fe3f0f59f6@spacewalk'
subscription='both' /item jid='osad-10b42d611a@spacewalk'
subscription='both' /item jid='osad-f0f388c885@spacewalk'
subscription='both' /item jid='osad-6021c959dd@spacewalk'
subscription='both' /item jid='osad-28dc0ddee4@spacewalk'
subscription='both' /item jid='osad-403d7f1572@spacewalk'
subscription='both' /item jid='osad-c294e8be55@spacewalk'
subscription='both' /item jid='osad-bdd7889037@spacewalk'
subscription='both' /item jid='osad-6398479353@s!
pa!
cewalk' subscription='both' /item jid='osad-c182dc85c6@spacewalk'
subscription='both' /item jid='osad-11a37bc699@spacewalk'
subscription='both' /item jid='osad-77dbbcccd5@spacewalk'
subscription='both' /item jid='osad-c67db0d167@spacewalk'
subscription='both' /item jid='osad-bf92fac08a@spacewalk'
subscription='both' /item jid='osad-bfbff17037@spacewalk'
subscription='both' /item jid='osad-18812f1a6b@spacewalk'
subscription='both' /item jid='osad-e649e75e71@spacewalk'
subscription='both' /item jid='osad-2a7e50b55f@spacewalk'
subscription='both' /item jid='osad-688025edeb@spacewalk'
subscription='both' /item jid='osad-4b6e8f533a@spacewalk'
subscription='both' /item jid='osad-0451103b21@spacewalk'
subscription='both' /item jid='osad-b011b1c0d2@spacewalk'
subscription='both' /item jid='osad-451aaaee64@spacewalk'
subscription='both' /item jid='osad-1b0a719359@spacewalk'
subscription='both' /item jid='osad-194a9a90a0@spacewalk'
subscription='both!
' !
/item jid='osad-67b967a5ec@spacewalk' subscription='both' /item ji
d='osad-9eebbd9684@spacewalk' subscription='both' /item
jid='osad-af9f4b0a93@spacewalk' subscription='both' /item
jid='osad-2dee90ef72@spacewalk' subscription='both' /item
jid='osad-c4dabbab4a@spacewalk' subscription='both' /item
jid='osad-82c3fd1196@spacewalk' subscription='both' /item
jid='osad-f6336873b9@spacewalk' subscription='both' /item
jid='osad-08e127bbe1@spacewalk' subscription='both' /item
jid='osad-981cef0a59@spacewalk' subscription='both' /item
jid='osad-2299f285cb@spacewalk' subscription='both' /item
jid='osad-e5bb60fae6@spacewalk' subscription='both' /item
jid='osad-ceee60b35a@spacewalk' subscription='both' /item
jid='osad-4ab5858f26@spacewalk' subscription='both' /item
jid='osad-c5d8b414cf@spacewalk' subscription='both' /item
jid='osad-ed5c434fb0@spacewalk' subscription='both' /item
jid='osad-395b66990a@spacewalk' subscription='both' /item
jid='osad-4d777a57e3@spacewalk' subscription='both' /item
jid='osad-dbb78ff69a@spacewal!
k'!
subscription='both' /item jid='osad-6993a948ba@spacewalk'
subscription='both' /item
Re: [Spacewalk-list] 500 ISE (Timeout) When Updating Kickstart Profile?
I'll look at this today as well Jan. It appears that 300 seconds timeout in httpd makes it so it doesn't time out in all cases I've tried so far, so at least I have a workaround for now. Thanks! Greg On 2012-02-28 7:52 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Fri, Feb 17, 2012 at 02:06:56PM +, Wojtak, Greg (Superfly) wrote: Hi there, Spacewalk 1.6 Postgres Cent 6.2 (64-bit) Has anyone else run into an issue where, when updating a kickstart profile (or cloning, or doing anything with it really) that you consistently time out with a 500 error after the request times out? What I'm seeing looks to be nothing more than the query (queries?) taking too long to run. I can see the queries while I'm waiting for a response after I hit the Update Profile button. Eventually, when the request times out and the query finally finishes and I browse back into Spacewalk, I get the message at the top of the screen that the profile has been updated successfully (and indeed it appears it has been). I've increased the HTTP timeout to 300 seconds (from 120) to try and work around this, but should it really take five minutes to update a profile? The one query I was able to capture during this was: SELECT CP.package_id, CP.name_id, CP.evr_id, CP.package_arch_id FROM rhnPackageName PN inner join rhnChannelNewestPackage CP on CP.name_id = PN.id inner join rhnChannel C on C.id = Cp.channel_id inner join rhnPackage P on P.id = CP.package_id inner join rhnPackageEvr EVR on P.evr_id = EVR.id WHERE ( C.id = $1 or C.parent_channel = $2) AND PN.name = $3 AND C.label not like '%beta%' order by EVR.evr DESC (sorry for the bad formatting) I'm not sure what the $1, $2, and $3 are (I presume this is calling some sort of a procedure and those are arguments). Those are bind parameters. You can replace them with some reasonable values. Please analyze your tables and run explain plan to see what is happening. I assume your cobbler is running and is reachable just fine. Anything of interest in /var/log/tomcat6/catalina.out? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] OSA Not Picking Up Actions - Most of the Time
On Tue, Feb 28, 2012 at 01:03:23PM +, Wojtak, Greg (Superfly) wrote: Thanks Jan. I'll dig into whether these machines (specifically the last one) are getting their actions picked up. That's good to know about not cleaning up /var/lib/jabber/db - it seemed like for a while there that recommendation was flying around all over this list. That recommendation was a result of community creativity and it never could have improved the situation significantly. It should never be done unless as specified in certain situations by the upgrade documentation. On a side note, I've noticed that after upgrading the spacewalk server to 1.6, any 1.6 clients are consistently picking up their actions as long as Great, thank you for confirming this. they are not behind a proxy. I've not tested the success rate for servers connecting through a proxy. We have bugzilla 795680 for osad through proxy issue. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] 500 ISE (Timeout) When Updating Kickstart Profile?
Oh, I forgot to mention - during an update the only thing I'm seeing in catalina.out is: 2012-02-28 09:00:24,630 [ajp-127.0.0.1-8009-1] WARN com.redhat.rhn.common.hibernate.EmptyVarcharInterceptor - Object com.redhat.rhn.domain.kickstart.KickstartData is setting empty string comments On 2012-02-28 7:52 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Fri, Feb 17, 2012 at 02:06:56PM +, Wojtak, Greg (Superfly) wrote: Hi there, Spacewalk 1.6 Postgres Cent 6.2 (64-bit) Has anyone else run into an issue where, when updating a kickstart profile (or cloning, or doing anything with it really) that you consistently time out with a 500 error after the request times out? What I'm seeing looks to be nothing more than the query (queries?) taking too long to run. I can see the queries while I'm waiting for a response after I hit the Update Profile button. Eventually, when the request times out and the query finally finishes and I browse back into Spacewalk, I get the message at the top of the screen that the profile has been updated successfully (and indeed it appears it has been). I've increased the HTTP timeout to 300 seconds (from 120) to try and work around this, but should it really take five minutes to update a profile? The one query I was able to capture during this was: SELECT CP.package_id, CP.name_id, CP.evr_id, CP.package_arch_id FROM rhnPackageName PN inner join rhnChannelNewestPackage CP on CP.name_id = PN.id inner join rhnChannel C on C.id = Cp.channel_id inner join rhnPackage P on P.id = CP.package_id inner join rhnPackageEvr EVR on P.evr_id = EVR.id WHERE ( C.id = $1 or C.parent_channel = $2) AND PN.name = $3 AND C.label not like '%beta%' order by EVR.evr DESC (sorry for the bad formatting) I'm not sure what the $1, $2, and $3 are (I presume this is calling some sort of a procedure and those are arguments). Those are bind parameters. You can replace them with some reasonable values. Please analyze your tables and run explain plan to see what is happening. I assume your cobbler is running and is reachable just fine. Anything of interest in /var/log/tomcat6/catalina.out? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] 500 ISE (Timeout) When Updating Kickstart Profile?
Here is an EXPLAIN prior to an ANALYZE (sorry for the lengthiness): spaceschema=# explain SELECT CP.package_id, CP.name_id, CP.evr_id, CP.package_arch_id FROM rhnPackageName PN inner join rhnChannelNewestPackage CP on CP.name_id = PN.id inner join rhnChannel C on C.id = Cp.channel_id inner join rhnPackage P on P.id = CP.package_id inner join rhnPackageEvr EVR on P.evr_id = EVR.id WHERE ( C.id = 1 or C.parent_channel = 2) AND PN.name = 'httpd' AND C.label not like '%beta%' order by EVR.evr DESC; QUERY PLAN --- - Sort (cost=627029.51..627029.52 rows=1 width=70) Sort Key: evr.evr - Nested Loop (cost=113975.12..627029.50 rows=1 width=70) - Nested Loop (cost=113975.12..627029.19 rows=1 width=38) - Hash Join (cost=113975.12..627028.89 rows=1 width=30) Hash Cond: (cp.name_id = pn.id) - Nested Loop (cost=113966.83..626995.91 rows=6584 width=30) - Bitmap Heap Scan on rhnchannel c (cost=8.52..12.53 rows=1 width=7) Recheck Cond: ((id = 1::numeric) OR (parent_channel = 2::numeric)) Filter: ((label)::text !~~ '%beta%'::text) - BitmapOr (cost=8.52..8.52 rows=1 width=0) - Bitmap Index Scan on rhn_channel_id_pk (cost=0.00..4.26 rows=1 width=0) Index Cond: (id = 1::numeric) - Bitmap Index Scan on rhn_channel_parent_id_idx (cost=0.00..4.26 rows=1 width=0) Index Cond: (parent_channel = 2::numeric) - Bitmap Heap Scan on rhnchannelnewestpackage cp (cost=113958.32..616242.98 rows=859232 width=37) Recheck Cond: (cp.channel_id = c.id) - Bitmap Index Scan on rhn_cnp_cid_nid_uq (cost=0.00..113743.51 rows=859232 width=0) Index Cond: (cp.channel_id = c.id) - Hash (cost=8.27..8.27 rows=1 width=7) - Index Scan using rhn_pn_name_uq on rhnpackagename pn (cost=0.00..8.27 rows=1 width=7) Index Cond: ((name)::text = 'httpd'::text) - Index Scan using rhn_package_id_pk on rhnpackage p (cost=0.00..0.28 rows=1 width=16) Index Cond: (p.id = cp.package_id) - Index Scan using rhn_pe_id_pk on rhnpackageevr evr (cost=0.00..0.30 rows=1 width=48) Index Cond: (evr.id = p.evr_id) (26 rows) I then ran an ANALYZE on rhnPackageName, rhnChannelNewestPackage, rhnChannel, and rhnPackageEvr After, I get the following from the same EXPLAIN: Sort (cost=593711.04..593711.04 rows=1 width=70) Sort Key: evr.evr - Nested Loop (cost=75858.49..593711.03 rows=1 width=70) - Nested Loop (cost=75858.49..593710.72 rows=1 width=38) - Hash Join (cost=75858.49..593710.42 rows=1 width=30) Hash Cond: (cp.name_id = pn.id) - Nested Loop (cost=75850.21..593680.13 rows=5867 width=30) - Bitmap Heap Scan on rhnchannel c (cost=8.52..12.53 rows=1 width=7) Recheck Cond: ((id = 1::numeric) OR (parent_channel = 2::numeric)) Filter: ((label)::text !~~ '%beta%'::text) - BitmapOr (cost=8.52..8.52 rows=1 width=0) - Bitmap Index Scan on rhn_channel_id_pk (cost=0.00..4.26 rows=1 width=0) Index Cond: (id = 1::numeric) - Bitmap Index Scan on rhn_channel_parent_id_idx (cost=0.00..4.26 rows=1 width=0) Index Cond: (parent_channel = 2::numeric) - Bitmap Heap Scan on rhnchannelnewestpackage cp (cost=75841.69..586728.21 rows=555151 width=37) Recheck Cond: (cp.channel_id = c.id) - Bitmap Index Scan on rhn_cnp_cid_nid_uq (cost=0.00..75702.90 rows=555151 width=0) Index Cond: (cp.channel_id = c.id) - Hash (cost=8.27..8.27 rows=1 width=7) - Index Scan using rhn_pn_name_uq on rhnpackagename pn (cost=0.00..8.27 rows=1 width=7) Index Cond: ((name)::text = 'httpd'::text) - Index Scan using rhn_package_id_pk on rhnpackage p (cost=0.00..0.28 rows=1 width=16) Index Cond: (p.id = cp.package_id) - Index Scan using
[Spacewalk-list] Yum doesn't communicate with server
Hi! I have some Red Hat hosts freshly registered with Spacewalk, but one specific (5.4) won't communicate with the server on yum command. $ sudo yum search rhncfg Warning: No matches found for: rhncfg No Matches found I upgraded yum* packages manually, but the problem still. No traffic is generated to the server when I watch with tcpdump. yum clean all, etc.. Someone has any idea? Thanks, Nilton. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Yum doesn't communicate with server
On Tue, Feb 28, 2012 at 12:12:35PM -0300, Nilton Moura wrote: Hi! I have some Red Hat hosts freshly registered with Spacewalk, but one specific (5.4) won't communicate with the server on yum command. $ sudo yum search rhncfg Warning: No matches found for: rhncfg No Matches found I upgraded yum* packages manually, but the problem still. No traffic is generated to the server when I watch with tcpdump. yum clean all, etc.. Someone has any idea? Do you have yum-rhn-plugin installed and enabled? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Yum doesn't communicate with server
* Nilton Moura red...@nmoura.eti.br [2012-02-28 12:12]: Hi! I have some Red Hat hosts freshly registered with Spacewalk, but one specific (5.4) won't communicate with the server on yum command. $ sudo yum search rhncfg Warning: No matches found for: rhncfg No Matches found I upgraded yum* packages manually, but the problem still. No traffic is generated to the server when I watch with tcpdump. yum clean all, etc.. What happens if you: yum repolist That will tell you what repos you are actually using, which should give you some idea about why rhncfg isn't available. If no repos show up, or if weird ones show up, that's a good reason not to find rhncfg. -- David Rock da...@graniteweb.com pgpRVvfKCshLD.pgp Description: PGP signature ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk client - yum - proxy behavior
On Mon, Feb 27, 2012 at 06:50:06PM +0100, Jan Arild Lindstrøm wrote: 3) lintest3-virt(root) ~ 34# yum update Loaded plugins: refresh-packagekit, rhnplugin, security Loading mirror speeds from cached hostfile Error: Cannot retrieve repository metadata (repomd.xml) for repository: centos6-x86_64. Please verify its path and try again ( - yum update starts here - ) 14:20:33.362368 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.375652 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 14:20:33.375852 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.377344 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 627 14:20:33.377522 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 1380 14:20:33.378321 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 --cut-- 14:20:33.402821 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.402825 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 467 14:20:33.402829 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.402846 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 14:20:33.406011 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.406976 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 14:20:33.460341 IP 10.10.0.62.50796 10.10.0.60.80: tcp 0 14:20:36.460258 IP 10.10.0.62.50796 10.10.0.60.80: tcp 0 14:20:42.460278 IP 10.10.0.62.50796 10.10.0.60.80: tcp 0 --cut-- Proxy = 10.10.30.183 Spacewalk server = 10.10.0.62 Is it possible that it's actually Spacewalk client = 10.10.0.62 Proxy = 10.10.30.183 Spacewalk server 10.10.0.60 ? Can you do more tcpdumping to see what are the HTTP requests that are being sent directly? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Yum doesn't communicate with server
When I manually updated the yum*, I updated the yum-rhn-plugin too. $ sudo yum -v --enableplugin=yum-rhn-plugin repolist Config time: 0.027 Yum Version: 3.2.22 Setting up Package Sacks repolist: 0 This strange because I just registered this system with spacewalk, and there (SW) I can see the packages, etc. 2012/2/28 David Rock da...@graniteweb.com * Nilton Moura red...@nmoura.eti.br [2012-02-28 12:12]: Hi! I have some Red Hat hosts freshly registered with Spacewalk, but one specific (5.4) won't communicate with the server on yum command. $ sudo yum search rhncfg Warning: No matches found for: rhncfg No Matches found I upgraded yum* packages manually, but the problem still. No traffic is generated to the server when I watch with tcpdump. yum clean all, etc.. What happens if you: yum repolist That will tell you what repos you are actually using, which should give you some idea about why rhncfg isn't available. If no repos show up, or if weird ones show up, that's a good reason not to find rhncfg. -- David Rock da...@graniteweb.com ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Kickstart CentOS 6 Fail Spacewalk
On Tue, Feb 28, 2012 at 09:24:07AM -0700, Jeremy Davis wrote: There seems to be a lot of differences in the files but for packages they are identical. The same repo that Spacewalk syncs from is the same repo I used for the repodata that works. Not sure what is going on there. Packages are not that interesting. What's interesting is the top level repomd.xml file and whether it references the same types of information. If I should venture a guess, I'd say that the Spacewalk-generated repomd.xml does not have the group data because there are no comps there. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Problem create Distribution KickStart
Hi all, I have a new installation with CentOS 6.2 and Spacewalk 1,6. I download the ISOS of CentOS 5,7 and mount it, tried to go to add a new Distribution in Systems-Kickstart-Distribution but when I click on create botton I receive: --- errore Errore del server interno Il server ha incontrato un problema il quale impedisce alla vostra richiesta di essere completata. Al momento è impossibile eseguire tale azione. Please help us correct this problem by contacting us with details of how you received this message. - Translation: Internal server error The server has encountered a problem which prevents your request to be completed. At the moment it is impossible to perform this action. - What I have to do? Where I can find some logs? in /var/log/rhn I can't find nothing Thank's --- Carlo Filippetto ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Yum doesn't communicate with server
On 28.2.2012 17:10, Nilton Moura wrote: yum -v --enableplugin=yum-rhn-plugin repolist It should be: --enableplugin=rhnplugin Mirek ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Yum doesn't communicate with server
Oh, sorry. But there's no difference. 2012/2/28 Miroslav Suchy msu...@redhat.com On 28.2.2012 17:10, Nilton Moura wrote: yum -v --enableplugin=yum-rhn-plugin repolist It should be: --enableplugin=rhnplugin Mirek ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk client - yum - proxy behavior
At 16:43 28.02.2012, Jan Pazdziora wrote: On Mon, Feb 27, 2012 at 06:50:06PM +0100, Jan Arild Lindstrøm wrote: 3) lintest3-virt(root) ~ 34# yum update Loaded plugins: refresh-packagekit, rhnplugin, security Loading mirror speeds from cached hostfile Error: Cannot retrieve repository metadata (repomd.xml) for repository: centos6-x86_64. Please verify its path and try again ( - yum update starts here - ) 14:20:33.362368 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.375652 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 14:20:33.375852 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.377344 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 627 14:20:33.377522 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 1380 14:20:33.378321 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 --cut-- 14:20:33.402821 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.402825 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 467 14:20:33.402829 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.402846 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 14:20:33.406011 IP 10.10.0.62.51822 10.10.30.183.8080: tcp 0 14:20:33.406976 IP 10.10.30.183.8080 10.10.0.62.51822: tcp 0 14:20:33.460341 IP 10.10.0.62.50796 10.10.0.60.80: tcp 0 14:20:36.460258 IP 10.10.0.62.50796 10.10.0.60.80: tcp 0 14:20:42.460278 IP 10.10.0.62.50796 10.10.0.60.80: tcp 0 --cut-- Proxy = 10.10.30.183 Spacewalk server = 10.10.0.62 Is it possible that it's actually Spacewalk client = 10.10.0.62 Proxy = 10.10.30.183 Spacewalk server 10.10.0.60 ? Yes, I just make sure my two test clients can not speak directly with the Spacewalk server: spacewalk01(root) ~ 1442# iptables -L -n -v Chain INPUT (policy ACCEPT 11M packets, 4471M bytes) pkts bytes target prot opt in out source destination 636 38304 DROP all -- * * 10.123.0.62 0.0.0.0/0 29538 1182K DROP all -- * * 10.123.0.61 0.0.0.0/0 --cut-- I want them to use only the proxy and not be able to shortcut it by using the Spacewalk server directly. That is because I do not want to open port 80 out from all our other VLANs. Can you do more tcpdumping to see what are the HTTP requests that are being sent directly? The proxy is Squid 3.1.x. Disabled iptables on the Spacewalk server while running tshark on the client. Captured: yum repolist (run after a yum clean all). Without http_proxy=http://proxy-z2.mydomain.no:8080 ; export http_proxy: lintest3-virt(root) ~ 162# tshark -c 500 -R 'http' port 80 or port 8080 Running as user root and group root. This could be dangerous. Capturing on eth0 0.014810 10.123.0.62 - 10.123.30.183 HTTP/XML POST http://spacewalk01.mydomain.no/XMLRPC HTTP/1.1 0.045528 10.123.30.183 - 10.123.0.62 HTTP/XML HTTP/1.0 200 OK 0.070893 10.123.0.62 - 10.123.30.183 HTTP/XML POST http://spacewalk01.mydomain.no/XMLRPC HTTP/1.1 0.107598 10.123.30.183 - 10.123.0.62 HTTP/XML HTTP/1.0 200 OK 0.155940 10.123.0.62 - 10.123.0.60 HTTP GET /XMLRPC/GET-REQ/centos6-x86_64/repodata/repomd.xml HTTP/1.1 0.159237 10.123.0.60 - 10.123.0.62 HTTP/XML HTTP/1.1 200 OK 0.184609 10.123.0.62 - 10.123.0.60 HTTP GET /XMLRPC/GET-REQ/centos6-x86_64/repodata/primary.xml.gz HTTP/1.1 4.318590 10.123.0.62 - 10.123.0.60 HTTP GET /XMLRPC/GET-REQ/centos6-x86_64-addons/repodata/repomd.xml HTTP/1.1 4.321661 10.123.0.60 - 10.123.0.62 HTTP/XML HTTP/1.1 200 OK --cut-- It start using the Spacewalk server directly when fetching the repo stuff. With http_proxy=http://proxy-z2.mydomain.no:8080 ; export http_proxy: lintest3-virt(root) ~ 167# tshark -c 5000 -R 'http' port 80 or port 8080 Running as user root and group root. This could be dangerous. Capturing on eth0 0.004991 10.123.0.62 - 10.123.30.183 HTTP/XML POST http://spacewalk01.mydomain.no/XMLRPC HTTP/1.1 0.028022 10.123.30.183 - 10.123.0.62 HTTP/XML HTTP/1.0 200 OK 0.051706 10.123.0.62 - 10.123.30.183 HTTP/XML POST http://spacewalk01.mydomain.no/XMLRPC HTTP/1.1 0.071484 10.123.30.183 - 10.123.0.62 HTTP/XML HTTP/1.0 200 OK 0.132816 10.123.0.62 - 10.123.30.183 HTTP GET http://spacewalk01.mydomain.no/XMLRPC/GET-REQ/centos6-x86_64/repodata/repomd.xml HTTP/1.1 0.141334 10.123.30.183 - 10.123.0.62 HTTP/XML HTTP/1.0 200 OK 0.174648 10.123.0.62 - 10.123.30.183 HTTP GET http://spacewalk01.mydomain.no/XMLRPC/GET-REQ/centos6-x86_64/repodata/primary.xml.gz HTTP/1.1 4.577575 10.123.0.62 - 10.123.30.183 HTTP GET http://spacewalk01.mydomain.no/XMLRPC/GET-REQ/centos6-x86_64-addons/repodata/repomd.xml HTTP/1.1 4.587044 10.123.30.183 - 10.123.0.62 HTTP/XML HTTP/1.0 200 OK
Re: [Spacewalk-list] Yum doesn't communicate with server
Hi. The yum.conf was changed to contain plugins=0 for some reason in this host and I didn't know. I changed and now works correctly. I thought command line take precedence. Thanks all. I have one doubt. What is better? Use on the RHEL clients packages from spacewalk-client repo or the official packages by RHN? (talking about rhn-setup, rhn-check, etc.). If I use packages from spacewalk-client repo I can lost technical support on the host, but if I use official packages, something maybe cannot work properly I guess. Am I wrong? Thanks, Nilton. 2012/2/28 Nilton Moura red...@nmoura.eti.br Oh, sorry. But there's no difference. 2012/2/28 Miroslav Suchy msu...@redhat.com On 28.2.2012 17:10, Nilton Moura wrote: yum -v --enableplugin=yum-rhn-plugin repolist It should be: --enableplugin=rhnplugin Mirek ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Issues with Kickstart
Hello, I am having issue with creating a kickstart on Spacewalk 1.6, I am trying to follow the set up from CentOS Page (http://wiki.centos.org/HowTos/PackageManagement/Spacewalk ). I have download the lastest CentOS 5, and I have it mount, but when I go to create a distro ( System -- Kickstart -- Distributions ) Distribution Label: CentOS-5-i386 Tree Path:/var/distro-trees/CentOS-5-i386/images/pxeboot/ Base Channel: CentOS 5 Base - i386 Installer Generation: Red Hat Enterprise Linux 5 I am getting the following error The initrd could not be found at the specified location: /var/distro-trees/CentOS-5-i386/images/pxeboot/images/pxeboot/initrd.img I know that the page states to make sure that the iso can be read by tomcat so I have in /etc/fstab that it's owned by tomcat. /var/iso-images/CentOS-5.7-i386-bin-DVD-1of2.iso /var/distro-trees/CentOS-5-i386 iso9660 rw,uid=91,gid=91,loop=/dev/loop1 0 0 I can see that works drwxrwxr-x 6 tomcat tomcat 6144 Sep 5 08:10 CentOS-5-i386 I can see that initrd.img is there [root@spacewalk CentOS-5-i386]# cd images/pxeboot/ [root@spacewalk pxeboot]# pwd /var/distro-trees/CentOS-5-i386/images/pxeboot [root@spacewalk pxeboot]# ls initrd.img README TRANS.TBL vmlinuz [root@spacewalk pxeboot]# ls -l total 12058 -rw-r--r-- 1 tomcat tomcat 10450542 Sep 5 07:53 initrd.img -rw-r--r-- 1 tomcat tomcat 265 Sep 5 07:53 README -r--r--r-- 1 tomcat tomcat 659 Sep 5 08:10 TRANS.TBL -rw-r--r-- 1 tomcat tomcat 1894036 Sep 5 07:53 vmlinuz Am I missing something? Is there a page I can view or can someone please example to me what I am doing wrong? I have even tried to set the tree as follows but I get an internal error 500 Tree Path:/var/distro-trees/CentOS-5-i386/ I looked at the Coobler logs and I am seeing that running, but I am not seeing any errors Tue Feb 28 18:12:49 2012 - DEBUG | API handle initialized Tue Feb 28 18:12:50 2012 - DEBUG | XMLRPC running on 25151 I have looked into the Apache, Spacewalk, and Tomcat logs and don't see any errors. Chuck Payne ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Yum doesn't communicate with server
On 28.2.2012 20:48, Nilton Moura wrote: I have one doubt. What is better? Use on the RHEL clients packages from spacewalk-client repo or the official packages by RHN? (talking about rhn-setup, rhn-check, etc.). If I use packages from spacewalk-client repo I can lost technical support on the host, but if I use official packages, something maybe cannot work properly I guess. Am I wrong? For production server? Use official package from Red Hat. Of course Spacewalk version is latest greatest and über cool, but may also contains some bugs. Packages in RHEL got all important bugs backported. And even most features. And it is supported. If you pay for RHEL, get what you are paying for. Seriously. But on your developers station you can use Spacewalk version, just to see what will land in RHEL soon. Mirek ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Issues with Kickstart
By the way, I have also tried with this CentOS 6, and it's doing the same thing. So there is something going on. Chuck On Tue, Feb 28, 2012 at 3:07 PM, themaster001 themaster...@gmail.com wrote: Hello, I am having issue with creating a kickstart on Spacewalk 1.6, I am trying to follow the set up from CentOS Page (http://wiki.centos.org/HowTos/PackageManagement/Spacewalk ). I have download the lastest CentOS 5, and I have it mount, but when I go to create a distro ( System -- Kickstart -- Distributions ) Distribution Label: CentOS-5-i386 Tree Path:/var/distro-trees/CentOS-5-i386/images/pxeboot/ Base Channel: CentOS 5 Base - i386 Installer Generation: Red Hat Enterprise Linux 5 I am getting the following error The initrd could not be found at the specified location: /var/distro-trees/CentOS-5-i386/images/pxeboot/images/pxeboot/initrd.img I know that the page states to make sure that the iso can be read by tomcat so I have in /etc/fstab that it's owned by tomcat. /var/iso-images/CentOS-5.7-i386-bin-DVD-1of2.iso /var/distro-trees/CentOS-5-i386 iso9660 rw,uid=91,gid=91,loop=/dev/loop1 0 0 I can see that works drwxrwxr-x 6 tomcat tomcat 6144 Sep 5 08:10 CentOS-5-i386 I can see that initrd.img is there [root@spacewalk CentOS-5-i386]# cd images/pxeboot/ [root@spacewalk pxeboot]# pwd /var/distro-trees/CentOS-5-i386/images/pxeboot [root@spacewalk pxeboot]# ls initrd.img README TRANS.TBL vmlinuz [root@spacewalk pxeboot]# ls -l total 12058 -rw-r--r-- 1 tomcat tomcat 10450542 Sep 5 07:53 initrd.img -rw-r--r-- 1 tomcat tomcat 265 Sep 5 07:53 README -r--r--r-- 1 tomcat tomcat 659 Sep 5 08:10 TRANS.TBL -rw-r--r-- 1 tomcat tomcat 1894036 Sep 5 07:53 vmlinuz Am I missing something? Is there a page I can view or can someone please example to me what I am doing wrong? I have even tried to set the tree as follows but I get an internal error 500 Tree Path:/var/distro-trees/CentOS-5-i386/ I looked at the Coobler logs and I am seeing that running, but I am not seeing any errors Tue Feb 28 18:12:49 2012 - DEBUG | API handle initialized Tue Feb 28 18:12:50 2012 - DEBUG | XMLRPC running on 25151 I have looked into the Apache, Spacewalk, and Tomcat logs and don't see any errors. Chuck Payne ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Issues with Kickstart
On my system, I do not include the images/pxeboot portion of the path in the Tree Path field. I also do not include a trailing slash. Jonathan On 02/28/2012 04:00 PM, themaster001 wrote: By the way, I have also tried with this CentOS 6, and it's doing the same thing. So there is something going on. Chuck On Tue, Feb 28, 2012 at 3:07 PM, themaster001themaster...@gmail.com wrote: Hello, I am having issue with creating a kickstart on Spacewalk 1.6, I am trying to follow the set up from CentOS Page (http://wiki.centos.org/HowTos/PackageManagement/Spacewalk ). I have download the lastest CentOS 5, and I have it mount, but when I go to create a distro ( System -- Kickstart -- Distributions ) Distribution Label: CentOS-5-i386 Tree Path:/var/distro-trees/CentOS-5-i386/images/pxeboot/ Base Channel: CentOS 5 Base - i386 Installer Generation: Red Hat Enterprise Linux 5 I am getting the following error The initrd could not be found at the specified location: /var/distro-trees/CentOS-5-i386/images/pxeboot/images/pxeboot/initrd.img I know that the page states to make sure that the iso can be read by tomcat so I have in /etc/fstab that it's owned by tomcat. /var/iso-images/CentOS-5.7-i386-bin-DVD-1of2.iso /var/distro-trees/CentOS-5-i386 iso9660 rw,uid=91,gid=91,loop=/dev/loop1 0 0 I can see that works drwxrwxr-x 6 tomcat tomcat 6144 Sep 5 08:10 CentOS-5-i386 I can see that initrd.img is there [root@spacewalk CentOS-5-i386]# cd images/pxeboot/ [root@spacewalk pxeboot]# pwd /var/distro-trees/CentOS-5-i386/images/pxeboot [root@spacewalk pxeboot]# ls initrd.img README TRANS.TBL vmlinuz [root@spacewalk pxeboot]# ls -l total 12058 -rw-r--r-- 1 tomcat tomcat 10450542 Sep 5 07:53 initrd.img -rw-r--r-- 1 tomcat tomcat 265 Sep 5 07:53 README -r--r--r-- 1 tomcat tomcat 659 Sep 5 08:10 TRANS.TBL -rw-r--r-- 1 tomcat tomcat 1894036 Sep 5 07:53 vmlinuz Am I missing something? Is there a page I can view or can someone please example to me what I am doing wrong? I have even tried to set the tree as follows but I get an internal error 500 Tree Path:/var/distro-trees/CentOS-5-i386/ I looked at the Coobler logs and I am seeing that running, but I am not seeing any errors Tue Feb 28 18:12:49 2012 - DEBUG | API handle initialized Tue Feb 28 18:12:50 2012 - DEBUG | XMLRPC running on 25151 I have looked into the Apache, Spacewalk, and Tomcat logs and don't see any errors. Chuck Payne ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list -- Jonathan DeHaan Linux Systems Engineer ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Issues with Kickstart
On Tue, Feb 28, 2012 at 5:10 PM, Jonathan DeHaan jdeh...@nexstar.tv wrote: On my system, I do not include the images/pxeboot portion of the path in the Tree Path field. I also do not include a trailing slash. Jonathan On 02/28/2012 04:00 PM, themaster001 wrote: By the way, I have also tried with this CentOS 6, and it's doing the same thing. So there is something going on. Chuck On Tue, Feb 28, 2012 at 3:07 PM, themaster001themaster...@gmail.com wrote: Hello, I am having issue with creating a kickstart on Spacewalk 1.6, I am trying to follow the set up from CentOS Page (http://wiki.centos.org/HowTos/PackageManagement/Spacewalk ). I have download the lastest CentOS 5, and I have it mount, but when I go to create a distro ( System -- Kickstart -- Distributions ) Distribution Label: CentOS-5-i386 Tree Path:/var/distro-trees/CentOS-5-i386/images/pxeboot/ Base Channel: CentOS 5 Base - i386 Installer Generation: Red Hat Enterprise Linux 5 I am getting the following error The initrd could not be found at the specified location: /var/distro-trees/CentOS-5-i386/images/pxeboot/images/pxeboot/initrd.img I know that the page states to make sure that the iso can be read by tomcat so I have in /etc/fstab that it's owned by tomcat. /var/iso-images/CentOS-5.7-i386-bin-DVD-1of2.iso /var/distro-trees/CentOS-5-i386 iso9660 rw,uid=91,gid=91,loop=/dev/loop1 0 0 I can see that works drwxrwxr-x 6 tomcat tomcat 6144 Sep 5 08:10 CentOS-5-i386 I can see that initrd.img is there [root@spacewalk CentOS-5-i386]# cd images/pxeboot/ [root@spacewalk pxeboot]# pwd /var/distro-trees/CentOS-5-i386/images/pxeboot [root@spacewalk pxeboot]# ls initrd.img README TRANS.TBL vmlinuz [root@spacewalk pxeboot]# ls -l total 12058 -rw-r--r-- 1 tomcat tomcat 10450542 Sep 5 07:53 initrd.img -rw-r--r-- 1 tomcat tomcat 265 Sep 5 07:53 README -r--r--r-- 1 tomcat tomcat 659 Sep 5 08:10 TRANS.TBL -rw-r--r-- 1 tomcat tomcat 1894036 Sep 5 07:53 vmlinuz Am I missing something? Is there a page I can view or can someone please example to me what I am doing wrong? I have even tried to set the tree as follows but I get an internal error 500 Tree Path:/var/distro-trees/CentOS-5-i386/ I looked at the Coobler logs and I am seeing that running, but I am not seeing any errors Tue Feb 28 18:12:49 2012 - DEBUG | API handle initialized Tue Feb 28 18:12:50 2012 - DEBUG | XMLRPC running on 25151 I have looked into the Apache, Spacewalk, and Tomcat logs and don't see any errors. Chuck Payne ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list -- Jonathan DeHaan Linux Systems Engineer ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list Jonathan, I had tried that was well and I am getting a 500 on it too. There something wrong. Thanks, ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Kickstart CentOS 6 Fail Spacewalk
On Tue, Feb 28, 2012 at 10:03:26AM -0700, Jeremy Davis wrote: I actually created a script that adds the group data to the repomd.xml to resolve the no groups error. I will say the difference in the repomd.xml is the checksums and the comps.xml which I add in. The strange thing about Nod. this issue is that V5 boxes use kickstart and work just fine it is only V6. Presumably anaconda behaves differently. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
