[Spacewalk-list] Spacewalk notification
Is there some way to send a notification of when spacewalk is All done patching a system? I'd like to automate as much as possible, perhaps utilizing our NOC even. I want to schedule a full update for a certain time (easy), and when all packages are updated, have the noc get some sort of notification and proceed to reboot the system. The Schedule reboot function in spacewalk is time based, so that's not very helpful in this instance. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] centos-errata.py and announcement list format changes
I was able to process the 2012-January file using the 0.2 version of the errata script. Few steps required. I changed my channel type to sha256 for both my base and update channel, I did a simple `sed -ie 's/CentOS 6/CentOS 6 x86_64' 2012-January.txt` So there isn't a valid reason why spacewalk search can't work. On 1/18/12 10:54 AM, David Nutter dav...@bioss.ac.uk wrote: On Wed, Jan 04, 2012 at 08:54:16PM +, David Nutter wrote: Hi folks, As some of you may have noticed the format of the centos-announce messages has changed, thus breaking my script that creates errata for them (http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/) I am working on a fix but unfortunately the changes required are fairly involved so it may be a day or two before I have a release ready and tested. Apologies for any inconvenience you may experience in the meantime. Hi folks, A new release is now available (finally): http://www.bioss.ac.uk/staff/davidn/spacewalk-stuff/ Due to format changes in the centos-announce mailing lists, the parsing logic has been completely rewritten. It's still horrible though :) Also, you will now have to use the dir package search strategy as the other two strategies spacewalk and satellitedir both rely on obtaining the md5sum from the centos-announce mailings. Since upstream now sends sha256 checksums these techniques can't work. I note with interest various discussions on the CentOS lists about making errata available in a more useful form. Hopefully my script won't be required for too much longer. Regards, -- David Nutter Tel: +44 (0)131 650 4888 BioSS, JCMB, King's Buildings, Mayfield Rd, EH9 3JZ. Scotland, UK Biomathematics and Statistics Scotland (BioSS) is formally part of The James Hutton Institute (JHI), a registered Scottish charity No. SC041796 and a company limited by guarantee No. SC374831 ___ 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] Spacewalk Proxy 1.6 and non-self signed certificates
After applying the change described here, I now get 500 Error in the GUI, and this error in error_log [Wed Jan 25 09:45:29 2012] [error] Execution of /var/www/html/network/systems/details/proxy.pxt failed at Wed Jan 25 09:45:29 2012: RHN::Exception: User '1' attempted to access proxy interface without permission.\n Sniglets::Servers /usr/lib/perl5/vendor_perl/5.8.8/Sniglets/Servers.pm 150 RHN::Exception::throw\n PXT::Parser /usr/lib/perl5/vendor_perl/5.8.8/PXT/Parser.pm 160 Sniglets::Servers::proxy_entitlement_form\n PXT::Parser /usr/lib/perl5/vendor_perl/5.8.8/PXT/Parser.pm 72 PXT::Parser::expand_tag\n PXT::ApacheHandler /usr/lib/perl5/vendor_perl/5.8.8/PXT/ApacheHandler.pm 500 PXT::Parser::expand_tags\n PXT::ApacheHandler /usr/lib/perl5/vendor_perl/5.8.8/PXT/ApacheHandler.pm 103 PXT::ApacheHandler::pxt_parse_data\n PXT::ApacheHandler /usr/lib/perl5/vendor_perl/5.8.8/PXT/ApacheHandler.pm 103 (eval)\n main -e 0 PXT::ApacheHandler::handler\n main -e 0 (eval) On 1/16/12 4:15 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Tue, Jan 10, 2012 at 02:13:40PM -0500, Scott Worthington wrote: On Tuesday, January 10, 2012 10:33:54 AM, Jan Pazdziora wrote: [...] The error is [error] acl fail: user_role(org_admin); system_feature(ftr_proxy_capable); org_channel_family(rhn-proxy); child_channel_candidate(rhn-proxy) at /usr/lib/perl5/vendor_perl/5.8.8/PXT/ApacheAuth.pm line 141. in /var/log/httpd/error_log. Mirek, can you investigate? Since the Spacewalk Proxy successfully activated to Spacewalk, I assumed all was go. Yes, your Proxy should be good to go, you just won't be able to see it on the WebUI. Any idea where else I should look to find out why I am getting a permission error? It's a .pxt page, so under /var/log/httpd. Yes, just as you said, I found the errors the /var/log/httpd/error_log as: acl fail: user_role(org_admin); system_feature(ftr_proxy_capable); org_channel_family(rhn-prdidate(rhn-proxy) at /usr/share/perl5/vendor_perl/PXT/ApacheAuth.pm line 141 Could you please apply the following patch to /etc/httpd/conf.d/zz-spacewalk-www.conf, restart httpd and see if it fixes the problem for you? diff --git a/spacewalk/config/etc/httpd/conf.d/zz-spacewalk-www.conf b/spacewalk/config/etc/httpd/conf.d/zz-spacewalk-www.conf index cde64a3..33fcaeb 100644 --- a/spacewalk/config/etc/httpd/conf.d/zz-spacewalk-www.conf +++ b/spacewalk/config/etc/httpd/conf.d/zz-spacewalk-www.conf @@ -161,7 +161,7 @@ PerlModule PXT::ApacheAuth Files proxy.pxt ForceType text/pxt SetHandler perl-script - require acl mixin RHN::Access::System user_role(org_admin); system_feature(ftr_proxy_capable); org_channel_family(rhn-proxy); child_channel_candidate(rhn-proxy) + require acl mixin RHN::Access::System user_role(org_admin); system_feature(ftr_proxy_capable) or system_is_proxy(); org_channel_family(rhn-proxy) or system_is_proxy(); child_channel_candidate(rhn-proxy) or system_is_proxy() /Files Files activation.pxt -- 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
[Spacewalk-list] Problem setting up proxy
Hey all, Using the latest version of spacewalk and following the steps on the wiki, I am able to install a proxy, but when I click on the Proxy button under Details of my host, I get Permission Error You do not have the appropriate permission set to access the requested page. You may have reached this error page in one of several ways: 1. Your login session has expired. For security reasons, Red Hat Network terminates your login session after 15 minutes of inactivity. To sign in again, click herehttps://spacewalk.usa.tribune.com/. 2. You've found an error in our site. Please contact your Support representative with details of how you received this message. 3. Your browser does not have cookies enabled. The Red Hat Network requires cookies in order to function; if you have disabled them, please re-enable them to use the site. 4. You've done something naughty. Stop it. The logs are somewhat useless, any one have a hint? ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Solaris Management
Sorry for the late chime in. Here are my observations with Spacewalk on Solaris. After some mucking around with some of the pm scripts to understand the new format, I was able to apply cluster patches to my test systems. However, I ran into difficulty when I started using spacewalk on production systems, as they included Zones and ZFS, which require steps outside of the cluster installer. Very odd, because pkgadd/patchadd will work with zones online, but installcluster wants your zones down. Secondly, I had to manually upgrade my Zpools, which is not a shortcoming of Spacewalk, rather, installcluster. But if you don't have Zones or ZFS, Spacewalk works great. On 7/13/11 7:02 AM, Cliff Perry cpe...@redhat.com wrote: On 07/13/2011 08:34 AM, Wojtak, Greg wrote: I put newest solaris stuff to http://spacewalk.redhat.com/solaris/ and fixed links on spacewalk wiki to point to new location. This is great, thank you. Does anyone know what the future of Solaris support in Spacewalk looks like? I was talking with some Satellite guys from Red Hat (I'm not sure if they were support or engineers) and they indicated that Solaris support was broken around version 1.1/1.2 of Spacewalk. Is that not an accurate statement? For Greg and Josh emails on this thread. The Solaris management within Spacewalk worked - up too a point. The installation of solaris patches and packages for Sparc Solaris 8, 9 10 worked. The installation of Solaris patches and packages for Intel Solaris 9 10 worked. What did not work was the installation of patch clusters for Solaris 9 and 10. This was due to structural changes made recently (past year) within the patch clusters. We have addressed the patch cluster installation issues we are aware off and Michael just posted new packages online. I hope this clears things up for folks. Cliff Thanks! Greg ___ 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 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Trouble patching Solaris systems
Hello list, After initial early success patching Solaris SPARC and i386, I am running into theses errors now: smart.Error: Unable to create channel of type 'solaris_rhn' Traceback below. Any help would be appreciated bash-3.00# rhn_check Doing checkNeedUpdate Traceback (most recent call last): File /opt/redhat/rhn/solaris/usr/sbin/rhn_check, line 317, in ? run_local_actions() File /opt/redhat/rhn/solaris/usr/sbin/rhn_check, line 77, in run_local_actions (status, message, data) = run_action(method, params) File /opt/redhat/rhn/solaris/usr/sbin/rhn_check, line 137, in run_action (status, message, data) = rhn.actions.do_call(method, params) File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/actions/__init__.py, line 18, in do_call return apply(func, params) File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/actions/solarispkgs.py, line 189, in checkNeedUpdate return refresh_list() File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/actions/solarispkgs.py, line 197, in refresh_list exitdata = iface.run(command) File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/smart/interfaces/up2date/interface.py, line 159, in run pkglist = self.getPackages() File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/smart/interfaces/up2date/interface.py, line 50, in getPackages if reload: self._ctrl.reloadChannels() File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/smart/control.py, line 285, in reloadChannels self.rebuildSysConfChannels() File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/smart/control.py, line 258, in rebuildSysConfChannels channel = createChannel(alias, data) File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/smart/channel.py, line 167, in createChannel raise Error, _(Unable to create channel of type '%s') % type smart.Error: Unable to create channel of type 'solaris_rhn' ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Server Name Change
Try spacewalk-hostname-rename https://fedorahosted.org/spacewalk/browser/utils/spacewalk-hostname-rename On 1/10/11 9:46 AM, Wojtak, Greg gregwoj...@quickenloans.com wrote: I ended up changing the name of my spacewalk server, and everything seems to be working okay with the exception of jabberd. I think it has to do with the certificate not matching the hostname. Osa-dispatcher attempts to connect but fails because of TLS. Can I just create a new certificate for jabber manually? What are the steps to do this? Thanks! Greg ___ 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
[Spacewalk-list] No relevant errata in spacewalk 1.2?
I have two spacewalk servers, one is running 1.1, the other is 1.2. I initially registered my systems on the 1.1, then I built a new server running 1.2... When I re-registered all my clients, all my errata show up as NONE RELEVANT.. Snip from satellite-sync: Downloading: - complete 16:14:29Retrieving / parsing errata data: centos4-base (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos5-updates-i386 (25) Downloading: - complete 16:14:29Retrieving / parsing errata data: centos5-base-i386 (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos4-updates (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos5-updates-x86_64 (227) Same systems, same packages, same erratum... Any thoughts? ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] No relevant errata in spacewalk 1.2?
Perhaps related, this error message comes up when I run centos-errata.py : Failed to process message. Reason: Fault 2901: 'redstone.xmlrpc.XmlRpcFault: Error communicating with search server' Traceback (most recent call last): File ./centos-errata.py, line 802, in process_msg if not errata_prepare_packagelist(session,options,erratum,extra_info['package_dir'],errataMsg.get_payload()) is None: File ./centos-errata.py, line 769, in errata_prepare_packagelist pkg_info = search_spacewalk_server(session,options,pkg_filename,pkg_checksum) File ./centos-errata.py, line 922, in search_spacewalk_server return session.findPackageByNameAndChecksum(pkg_name, pkg_checksum) File ./centos-errata.py, line 521, in findPackageByNameAndChecksum result = self.server.packages.search.name(self.rhnSessionKey,pkg_name) File /usr/lib64/python2.4/xmlrpclib.py, line 1096, in __call__ return self.__send(self.__name, args) File /usr/lib64/python2.4/xmlrpclib.py, line 1383, in __request verbose=self.__verbose File /usr/lib64/python2.4/xmlrpclib.py, line 1147, in request return self._parse_response(h.getfile(), sock) File /usr/lib64/python2.4/xmlrpclib.py, line 1286, in _parse_response return u.close() File /usr/lib64/python2.4/xmlrpclib.py, line 744, in close raise Fault(**self._stack[0]) Fault: Fault 2901: 'redstone.xmlrpc.XmlRpcFault: Error communicating with search server' On Dec 16, 2010, at 4:33 PM, Lopez, Abel wrote: I have two spacewalk servers, one is running 1.1, the other is 1.2. I initially registered my systems on the 1.1, then I built a new server running 1.2... When I re-registered all my clients, all my errata show up as NONE RELEVANT.. Snip from satellite-sync: Downloading: - complete 16:14:29Retrieving / parsing errata data: centos4-base (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos5-updates-i386 (25) Downloading: - complete 16:14:29Retrieving / parsing errata data: centos5-base-i386 (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos4-updates (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos5-updates-x86_64 (227) Same systems, same packages, same erratum... Any thoughts? ___ 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] No relevant errata in spacewalk 1.2?
Nevermind, I figured it out... In the rhn-search logs, I found ELFCLASS 32 conflict errors... Uninstalled oracle-instantclient-basic.i386 and did rhn-search cleanindex... Fixed. On Dec 16, 2010, at 5:27 PM, Lopez, Abel wrote: Perhaps related, this error message comes up when I run centos-errata.py : Failed to process message. Reason: Fault 2901: 'redstone.xmlrpc.XmlRpcFault: Error communicating with search server' Traceback (most recent call last): File ./centos-errata.py, line 802, in process_msg if not errata_prepare_packagelist(session,options,erratum,extra_info['package_dir'],errataMsg.get_payload()) is None: File ./centos-errata.py, line 769, in errata_prepare_packagelist pkg_info = search_spacewalk_server(session,options,pkg_filename,pkg_checksum) File ./centos-errata.py, line 922, in search_spacewalk_server return session.findPackageByNameAndChecksum(pkg_name, pkg_checksum) File ./centos-errata.py, line 521, in findPackageByNameAndChecksum result = self.server.packages.search.name(self.rhnSessionKey,pkg_name) File /usr/lib64/python2.4/xmlrpclib.py, line 1096, in __call__ return self.__send(self.__name, args) File /usr/lib64/python2.4/xmlrpclib.py, line 1383, in __request verbose=self.__verbose File /usr/lib64/python2.4/xmlrpclib.py, line 1147, in request return self._parse_response(h.getfile(), sock) File /usr/lib64/python2.4/xmlrpclib.py, line 1286, in _parse_response return u.close() File /usr/lib64/python2.4/xmlrpclib.py, line 744, in close raise Fault(**self._stack[0]) Fault: Fault 2901: 'redstone.xmlrpc.XmlRpcFault: Error communicating with search server' On Dec 16, 2010, at 4:33 PM, Lopez, Abel wrote: I have two spacewalk servers, one is running 1.1, the other is 1.2. I initially registered my systems on the 1.1, then I built a new server running 1.2... When I re-registered all my clients, all my errata show up as NONE RELEVANT.. Snip from satellite-sync: Downloading: - complete 16:14:29Retrieving / parsing errata data: centos4-base (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos5-updates-i386 (25) Downloading: - complete 16:14:29Retrieving / parsing errata data: centos5-base-i386 (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos4-updates (NONE RELEVANT) 16:14:29Retrieving / parsing errata data: centos5-updates-x86_64 (227) Same systems, same packages, same erratum... Any thoughts? ___ 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 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Spacewalk Client Install on Solaris 10
Try this: export PATH=/opt/redhat/rhn/solaris/bin:/opt/redhat/rhn/solaris/usr/bin:/opt/redhat/rhn/solaris/usr/sbin:$PATH I was having the same issue because the scripts were calling the native python. Once I put the redhat directories first in my path, it worked fine. I put this in a file that I source only when I'm going to work with rhn on solaris. --Abe On Oct 6, 2010, at 12:30 PM, spo...@sympatico.camailto:spo...@sympatico.ca spo...@sympatico.camailto:spo...@sympatico.ca wrote: Hi I've installed the spacewalk client on Solaris 10, but attempts to register to the spacewalk server fail. Hopefully someone will tell me what very small thing I have to do to make this work. Here are the details 1 a)The error registering the Solaris10 client # rhnreg_ks --force --serverUrl=http://myspacewalkserver/XMLRPC --activationkey=1-TestKey Traceback (most recent call last): File /opt/redhat/rhn/solaris/usr/sbin/rhnreg_ks, line 28, in ? from rhn.client.translate import _ File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/__init__.py, line 11, in ? import rpclib File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/rpclib.py, line 14, in ? import transports File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/transports.py, line 24, in ? import connections File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/connections.py, line 14, in ? import SSL File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/rhn/SSL.py, line 15, in ? from OpenSSL import SSL, crypto File /opt/redhat/rhn/solaris/lib/python2.4/site-packages/OpenSSL/__init__.py, line 11, in ? import rand, crypto, SSL, tsafe ImportError: ld.so.1: python: fatal: relocation error: file /opt/redhat/rhn/solaris/lib/python2.4/site-packages/OpenSSL/crypto.so: symbol PyUnicodeUCS4_Decode: referenced symbol not found 1 a)Just for reference this registration works from my RHEL5 client #rhnreg_ks --force --serverUrl=http://myspacewalkserver/XMLRPC --activationkey=1-TestKey This system is not subscribed to any channels. RHN channel support will be disabled. [ 2)The effective path for the registration session #echo $PATH /usr/sbin:/usr/bin:/usr/local/bin:/usr/local/samba/sbin:/usr/local/samba/bin:/usr/ccs/bin:/opt/redhat/rhn/solaris/bin:/opt/redhat/rhn/solaris/usr/bin:/opt/redhat/rhn/solaris/usr/sbin 3)The effective library paths #crle -c /var/ld/ld.config Configuration file [version 4]: /var/ld/ld.config Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib:/usr/sfw/lib:/opt/redhat/rhn/solaris/lib Trusted Directories (ELF):/lib/secure:/usr/lib/secure (system default) Command line: crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib:/usr/sfw/lib:/opt/redhat/rhn/solaris/lib 4)Supporting packages installed #pkginfo SUNWzlib SUNWgccruntime system SUNWgccruntime GCC Runtime libraries system SUNWzlib The Zip compression library # pkginfo |grep -i openssl utility RHATposslpyOpenSSL 0.6 application SMCossl openssl system SUNWopenssl-commands OpenSSL Commands (Usr) system SUNWopenssl-include OpenSSL Header Files system SUNWopenssl-librariesOpenSSL Libraries (Usr) system SUNWopenssl-man OpenSSL Manual Pages system SUNWopensslr OpenSSL (Root) 5)Spacewalk packages imailto:installedr...@winfrasol1 #pkginfo|grep RHAT utility RHATposslpyOpenSSL 0.6 utility RHATpythnpython 2.4.1 utility RHATrcfg rhncfg 5.1.0 utility RHATrcfgarhncfg-actions 5.1.0 utility RHATrcfgcrhncfg-client 5.1.0 utility RHATrcfgmrhncfg-management 5.1.0 utility RHATrhnc rhnclient 5.1.0 utility RHATrhnl rhnlib 1.8 utility RHATrpushrhnpush 5.1.1 utility RHATsmartsmartpm 5.1.1 6)The server uname -a SunOS myservername 5.10 Generic_142901-10 i86pc i386 i86pc ATT1..txt ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
[Spacewalk-list] Solaris patching pitfall
Hello all,
I've just began playing around with spacewalk, and my first attempt to patch a
solaris 10 sparc system seems to have stalled.
It's been stuck at 0% for quite a while now - Any thoughts?
r...@xx# /opt/redhat/rhn/solaris/usr/sbin/rhn_check
Installing patch cluster: [[['patch-cluster-solaris-10_Recommended',
'20100928', '1', 'sparc-solaris-patch-cluster', 'sol10-sparc'], {}]]
Updating cache... [100%]
Updating cache... [100%]
Updating cache... [100%]
Computing transaction...
Fetching packages...
-
rhn://sol10-sparc/.../patch-cluster-solaris-10_Recommended-20100928-1.sparc-solaris-patch-cluster.zip
patch-cluster-solaris-10_Reco.. [100%]
Committing transaction...
Installing patch-cluster-sola.. ( 0%)
ps and truss
ps -ef | grep rhn
root 3162 1 0 Oct 01 ? 0:00
/opt/redhat/rhn/solaris/usr/sbin/rhnsd --interval 240
root 3867 3866 0 10:54:41 pts/1 0:00 unzip
/opt/redhat/rhn/solaris/var/lib/smart/packages/patch-cluster-solaris-10_R
root 3866 3841 0 10:54:41 pts/1 0:00 sh -c { unzip
/opt/redhat/rhn/solaris/var/lib/smart/packages/patch-cluster-sola
root 3841 3840 0 10:52:54 pts/1 0:26
/opt/redhat/rhn/solaris/bin/python /opt/redhat/rhn/solaris/usr/sbin/rhn_check
root 3962 3870 0 11:28:14 pts/2 0:00 grep rhn
r...@lauxsc05# truss -p 3867
read(0, 0xFF339C48, 1024) (sleeping...)
___
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Solaris patching pitfall
More details
spacewalk server 1.1 on CentOS 5.4
Solaris 10 system using rhn-solaris-bootstrap-5.1.1-3-sparc-sol10
On Oct 4, 2010, at 11:29 AM, Lopez, Abel wrote:
Hello all,
I've just began playing around with spacewalk, and my first attempt to patch
a solaris 10 sparc system seems to have stalled.
It's been stuck at 0% for quite a while now - Any thoughts?
r...@xx# /opt/redhat/rhn/solaris/usr/sbin/rhn_check
Installing patch cluster: [[['patch-cluster-solaris-10_Recommended',
'20100928', '1', 'sparc-solaris-patch-cluster', 'sol10-sparc'], {}]]
Updating cache...
[100%]
Updating cache...
[100%]
Updating cache...
[100%]
Computing transaction...
Fetching packages...
-
rhn://sol10-sparc/.../patch-cluster-solaris-10_Recommended-20100928-1.sparc-solaris-patch-cluster.zip
patch-cluster-solaris-10_Reco..
[100%]
Committing transaction...
Installing patch-cluster-sola.. (
0%)
ps and truss
ps -ef | grep rhn
root 3162 1 0 Oct 01 ? 0:00
/opt/redhat/rhn/solaris/usr/sbin/rhnsd --interval 240
root 3867 3866 0 10:54:41 pts/1 0:00 unzip
/opt/redhat/rhn/solaris/var/lib/smart/packages/patch-cluster-solaris-10_R
root 3866 3841 0 10:54:41 pts/1 0:00 sh -c { unzip
/opt/redhat/rhn/solaris/var/lib/smart/packages/patch-cluster-sola
root 3841 3840 0 10:52:54 pts/1 0:26
/opt/redhat/rhn/solaris/bin/python /opt/redhat/rhn/solaris/usr/sbin/rhn_check
root 3962 3870 0 11:28:14 pts/2 0:00 grep rhn
r...@lauxsc05# truss -p 3867
read(0, 0xFF339C48, 1024) (sleeping...)
___
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] Solaris patching pitfall
This appears to be hitting a catch-22
Creating the mpm on the spacewalk server works fine with the new format of
Solaris cluster patches. However, the client side (installed from
rhn-solaris-bootstrap-5.1.1-3-sparc-sol10) is looking for the old filenames
(i.e. install_cluster not installcluster).
Furthermore, attempting to create the mpm using the workaround detailed in bug
559092 causes solaris2mpm to fail.
[r...@spacewalk-test sol]# zip -q -r 10_Recommended.zip 10_Recommended
solaris2mpm --tempdir=/tmp/ 10_Recommended.zip
Opening archive, this may take a while
Error creating mpm for /root/sol/10_Recommended.zip:
It sounds like newer versions of rhn-solaris-bootstrap need to be made
available.
On Oct 4, 2010, at 12:08 PM, Lopez, Abel wrote:
More details
spacewalk server 1.1 on CentOS 5.4
Solaris 10 system using rhn-solaris-bootstrap-5.1.1-3-sparc-sol10
On Oct 4, 2010, at 11:29 AM, Lopez, Abel wrote:
Hello all,
I've just began playing around with spacewalk, and my first attempt to patch a
solaris 10 sparc system seems to have stalled.
It's been stuck at 0% for quite a while now - Any thoughts?
r...@xx# /opt/redhat/rhn/solaris/usr/sbin/rhn_check
Installing patch cluster: [[['patch-cluster-solaris-10_Recommended',
'20100928', '1', 'sparc-solaris-patch-cluster', 'sol10-sparc'], {}]]
Updating cache... [100%]
Updating cache... [100%]
Updating cache... [100%]
Computing transaction...
Fetching packages...
-
rhn://sol10-sparc/.../patch-cluster-solaris-10_Recommended-20100928-1.sparc-solaris-patch-cluster.zip
patch-cluster-solaris-10_Reco.. [100%]
Committing transaction...
Installing patch-cluster-sola.. ( 0%)
ps and truss
ps -ef | grep rhn
root 3162 1 0 Oct 01 ? 0:00
/opt/redhat/rhn/solaris/usr/sbin/rhnsd --interval 240
root 3867 3866 0 10:54:41 pts/1 0:00 unzip
/opt/redhat/rhn/solaris/var/lib/smart/packages/patch-cluster-solaris-10_R
root 3866 3841 0 10:54:41 pts/1 0:00 sh -c { unzip
/opt/redhat/rhn/solaris/var/lib/smart/packages/patch-cluster-sola
root 3841 3840 0 10:52:54 pts/1 0:26
/opt/redhat/rhn/solaris/bin/python /opt/redhat/rhn/solaris/usr/sbin/rhn_check
root 3962 3870 0 11:28:14 pts/2 0:00 grep rhn
r...@lauxsc05# truss -p 3867
read(0, 0xFF339C48, 1024) (sleeping...)
___
Spacewalk-list mailing list
Spacewalk-list@redhat.commailto:Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list
___
Spacewalk-list mailing list
Spacewalk-list@redhat.commailto: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
