I *love* Spacewalk. I really do. There is no *but*. In a past life, I deployed Satellite for RH at customer sites, so the fact that I'm still using the codebase years later says a lot about how I feel about it.
Here are some things that I've found recently... Kickstart... I recently had a situation where I was testing kickstart profiles. I created 10 DNS entries for the hosts, and was creating/destroying them at will. I found some interesting things out... 1. If the VM doesn't have the XML file on the virtualization host, but the filename used by the profile DOES exist, the kickstart will fail. Silently. (I had some NFS issues, where the files were owned by root:root, so deleting them from virt-manager didn't actually work, so this may be a libvirt issue in that it reports deleted even though it's not.) 2. I had to put in a custom begin script to generate the hostname/IP address for static entries (more on that later). But it still registers with the name localhost.localdomain. 3. After the packages are installed and the post section has completed, the node usually reboots, and I see the checkbox in the "Register System to Spacewalk" section. But it doesn't get past that. Initially, I thought it was stuck at "Deploy Configuration Files", but I've since kickstarted with the option to sync a package profile from another host, and it never gets there... Not sure what's happening there. (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] #011 insert 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] #011 values 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... Back to the custom begin script - all it does is parse /proc/cmdline to get the hostname, look it up in DNS, and if it's found, use that hostname/IP, with the current netmask and default route. If it's not found, use the address that it picked up from DHCP. It's not in any way pretty, error-checking is minimal, and it isn't very generalized, so I'm somewhat reluctant to share it... (plus the fact that it's a little ugly!) ;) Other random stuff... 4. When using SW 1.6 with PostgreSQL on CentOS 6.2 (just trying to be specific here...), every night the "Show differences between profiled configuration files and deployed config files scheduled by (none)" job runs. This drives the load through the roof. I'm talking about in the upper 40's here. Eventually it calms down, but the box gets slammed. Is there something that I can do to mitigate this? 5. Even with selinux in permissive mode (and targeted policy) on both the Spacewalk VM and the virtualization host, I keep getting s0 at the end of the security labels on files that I've deployed from configuration channels. I redeploy, then they come back. Not sure what's happening here. I suppose I could always relabel all of the nodes via 'touch /.autorelabel' and reboot them, but I'd rather not... Just some food for thought... -Ian _______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list