Re: [Spacewalk-list] Another issue with Cobbler
On Mon, Mar 12, 2012 at 03:41:42PM -0400, themaster001 wrote: On Mon, Mar 12, 2012 at 11:27 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Fri, Mar 09, 2012 at 07:09:30AM -0500, themaster001 wrote: I am trying to remove to a system, my spacewalk system. The web hangs then I get an error message System profile 1010 could not be deleted. Check cobbler service. I have checked it is running 3163 ? S 0:00 /usr/bin/python /usr/bin/cobblered --daemonize /var/log/cobbler/cobbler.log show no error Thu Mar 8 22:00:37 2012 - DEBUG | API handle initialized Thu Mar 8 22:00:38 2012 - DEBUG | XMLRPC running on 25151 Thu Mar 8 22:04:16 2012 - DEBUG | API handle initialized Thu Mar 8 23:01:58 2012 - DEBUG | API handle initialized Thu Mar 8 23:01:58 2012 - DEBUG | XMLRPC running on 25151 Is there anything in /var/log/tomcat*/catalina.out? Is there any AVC denial in /var/log/audit/audit.log? -- 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 Jan, Here is what catalina.out shows Mar 12, 2012 7:39:46 PM org.apache.jk.core.MsgContext action WARNING: Error sending end packet java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) at java.net.SocketOutputStream.write(SocketOutputStream.java:153) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:538) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:281) at org.apache.catalina.connector.Response.finishResponse(Response.java:478) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:154) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:679) Mar 12, 2012 7:39:46 PM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 There has to be something before or after that. This is just a timed out connection to the httpd which couldn't be the reson you see the System profile 1010 could not be deleted. Check cobbler service. message. -- 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] Bare Metal Provision Through Proxy
On Mon, Mar 12, 2012 at 08:26:56PM +, Wojtak, Greg (Superfly) wrote: I'm trying to set up bare metal provisioning through a spacewalk proxy, but I'm running into a little trouble. I guess it really all boils down to the fact that in the kickstart file, all of the URL's reference http://spacewalk, my spacewalk server which is not reachable by the servers I am trying to provision. Is there a way to change all of these references in the kickstart file? Is there any documentation that details how to do this? The Proxy - Spacewalk interaction will do that automatically for you. IOW, when you view the kickstart file on Spacewalk's WebUI, it will obviously show Spacewalk's hostname but once you access the bare metal URL via Proxy, it will get transformed to point to the proxy. -- 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] spacewalk-client 1.7, opensuse12.1
Hi, same error on opensuse 11.4: File /usr/sbin/rhnreg_ks, line 33, in from up2date_client import rhnreg File /usr/share/rhn/up2date_client/rhnreg.py, line 14, in import up2dateUtils File /usr/share/rhn/up2date_client/up2dateUtils.py, line 11, in import up2dateErrors File /usr/share/rhn/up2date_client/up2dateErrors.py, line 188, in class SSLCertificateVerifyFailedError(RepoError, Error): TypeError: Error when calling the metaclass bases duplicate base class Error Problem lies within up2dateErrors.py (rhn-client-tools-1.7.14-2.1.noarch.rpm). Changing _class SSLCertificateVerifyFailedError(RepoError, Error)_ back to _class SSLCertificateVerifyFailedError(RepoError)_ seems to work (line 188 in the file). (Error (parameter?) was added here: http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=9b28ded9de35b00d05457c877b8e8bb9d68a37de) Don't know much about python, so can't exactly tell what is happening, but until it's fixed this seems like a usable solution. Regards Ralf ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Bare Metal Provision Through Proxy
That makes sense. I've given it another try and I get to the point in the kickstart where the filesystems are created, then it pulls down the repo information. I get the following error (have to hit Ctrl+Alt+F3 to see it): WARNING : Failed to get http://proxy.fqdn.tld/ks/dist/child/centos-6-x86_64-proxy.fqdn.tld-client/C entOS_6_x86_64-bit/repodata/repomd.xml from mirror 1/1, or downloaded file is corrupt. Apparently here's what's happening - the spacewalk host's name, which happens to be 'spacewalk,' is being replaced in that entire string with proxy.fqdn.tld in all instances. I have verified I can download the repomd.xml by browsing to http://proxy.fqdn.tld/ks/dist/child/centos-6-x86_64-spacewalk-client/CentOS _6_x86_64-64-bit/repodata/repomd.xml I'm not really sure what to do in this case. Do I need to rename the spacewalk-client channel/repo? Is this a bug or expected behavior with the spacewalk server name called spacewalk? Thanks! Greg On 2012-03-13 3:20 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Mon, Mar 12, 2012 at 08:26:56PM +, Wojtak, Greg (Superfly) wrote: I'm trying to set up bare metal provisioning through a spacewalk proxy, but I'm running into a little trouble. I guess it really all boils down to the fact that in the kickstart file, all of the URL's reference http://spacewalk, my spacewalk server which is not reachable by the servers I am trying to provision. Is there a way to change all of these references in the kickstart file? Is there any documentation that details how to do this? The Proxy - Spacewalk interaction will do that automatically for you. IOW, when you view the kickstart file on Spacewalk's WebUI, it will obviously show Spacewalk's hostname but once you access the bare metal URL via Proxy, it will get transformed to point to the proxy. -- 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] Bare Metal Provision Through Proxy
On Tue, Mar 13, 2012 at 01:28:34PM +, Wojtak, Greg (Superfly) wrote: That makes sense. I've given it another try and I get to the point in the kickstart where the filesystems are created, then it pulls down the repo information. I get the following error (have to hit Ctrl+Alt+F3 to see it): WARNING : Failed to get http://proxy.fqdn.tld/ks/dist/child/centos-6-x86_64-proxy.fqdn.tld-client/C entOS_6_x86_64-bit/repodata/repomd.xml from mirror 1/1, or downloaded file is corrupt. Apparently here's what's happening - the spacewalk host's name, which happens to be 'spacewalk,' is being replaced in that entire string with proxy.fqdn.tld in all instances. I have verified I can download the repomd.xml by browsing to http://proxy.fqdn.tld/ks/dist/child/centos-6-x86_64-spacewalk-client/CentOS _6_x86_64-64-bit/repodata/repomd.xml I'm not really sure what to do in this case. Do I need to rename the spacewalk-client channel/repo? Is this a bug or expected behavior with the spacewalk server name called spacewalk? So, does wgetting http://spacewalk.fqdn.tld/ks/dist/child/centos-6-x86_64-spacewalk-client/CentOS_6_x86_64-64-bit/repodata/repomd.xml (as opposed to proxy.fqdn.tld) actually work? -- 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] Another issue with Cobbler
On Tue, Mar 13, 2012 at 3:17 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Mon, Mar 12, 2012 at 03:41:42PM -0400, themaster001 wrote: On Mon, Mar 12, 2012 at 11:27 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Fri, Mar 09, 2012 at 07:09:30AM -0500, themaster001 wrote: I am trying to remove to a system, my spacewalk system. The web hangs then I get an error message System profile 1010 could not be deleted. Check cobbler service. I have checked it is running 3163 ? S 0:00 /usr/bin/python /usr/bin/cobblered --daemonize /var/log/cobbler/cobbler.log show no error Thu Mar 8 22:00:37 2012 - DEBUG | API handle initialized Thu Mar 8 22:00:38 2012 - DEBUG | XMLRPC running on 25151 Thu Mar 8 22:04:16 2012 - DEBUG | API handle initialized Thu Mar 8 23:01:58 2012 - DEBUG | API handle initialized Thu Mar 8 23:01:58 2012 - DEBUG | XMLRPC running on 25151 Is there anything in /var/log/tomcat*/catalina.out? Is there any AVC denial in /var/log/audit/audit.log? -- 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 Jan, Here is what catalina.out shows Mar 12, 2012 7:39:46 PM org.apache.jk.core.MsgContext action WARNING: Error sending end packet java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) at java.net.SocketOutputStream.write(SocketOutputStream.java:153) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:538) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127) at org.apache.jk.core.MsgContext.action(MsgContext.java:302) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.finish(Response.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:281) at org.apache.catalina.connector.Response.finishResponse(Response.java:478) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:154) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:679) Mar 12, 2012 7:39:46 PM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 There has to be something before or after that. This is just a timed out connection to the httpd which couldn't be the reson you see the System profile 1010 could not be deleted. Check cobbler service. message. -- 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 Jan, Thanks for your help, but I am thinking at this point to do a fresh install. I can't delete systesm, I can't set up kickstarts, so there something major wrong. So it be best to start over. Again, thanks for your help. Chuck ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Bare Metal Provision Through Proxy
It does work directly from the spacewalk server. I probably should have been more clear in my previous email about what I'm perceiving the problem to be. The repo name in the URL is having the 'spacewalk' replaced as well. In this case, the repo is called spacewalk-client. I'm guessing that since my spacewalk server is simply called 'spacewalk', there's some sort of regex going on that replaces all occurrences of 'spacewalk' with my proxy name instead of just the domain portion of the URL. So 'spacewalk-client' is becoming 'proxy.fqdn.tld-client' within the URL string. I apologize if I'm restating what I already told you, but I wanted to make sure I was accurately reporting what I was seeing. My last email was a bit ambiguous unless you were really paying close attention to the URL. :) Greg On 2012-03-13 9:51 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: On Tue, Mar 13, 2012 at 01:28:34PM +, Wojtak, Greg (Superfly) wrote: That makes sense. I've given it another try and I get to the point in the kickstart where the filesystems are created, then it pulls down the repo information. I get the following error (have to hit Ctrl+Alt+F3 to see it): WARNING : Failed to get http://proxy.fqdn.tld/ks/dist/child/centos-6-x86_64-proxy.fqdn.tld-client /C entOS_6_x86_64-bit/repodata/repomd.xml from mirror 1/1, or downloaded file is corrupt. Apparently here's what's happening - the spacewalk host's name, which happens to be 'spacewalk,' is being replaced in that entire string with proxy.fqdn.tld in all instances. I have verified I can download the repomd.xml by browsing to http://proxy.fqdn.tld/ks/dist/child/centos-6-x86_64-spacewalk-client/Cent OS _6_x86_64-64-bit/repodata/repomd.xml I'm not really sure what to do in this case. Do I need to rename the spacewalk-client channel/repo? Is this a bug or expected behavior with the spacewalk server name called spacewalk? So, does wgetting http://spacewalk.fqdn.tld/ks/dist/child/centos-6-x86_64-spacewalk-client/ CentOS_6_x86_64-64-bit/repodata/repomd.xml (as opposed to proxy.fqdn.tld) actually work? -- 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] Clients registered with proxy show Offline as of unknown
Here's the situation: * Master Spacewalk server is working fine * Proxy server #1 is also fine, proxied clients are ping-able * Proxy server #2 seems to be working, but clients are not ping-able. Here's what I've tested on proxy server #2: * Clients can register and run rhn_check -vv just fine * TCPdump reveals packets are being sent from the proxy to the master when I run osad on the client * The osad username for the client is showing up in /var/log/messages on the proxy * We are *not* seeing the client's username osad-a88ad541b6 showing up in /var/log/messages on the master server Below is a link to the output of osad -N -v. Any suggestions? http://pastebin.com/iQWCLuV5 ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Clients registered with proxy show Offline as of unknown
Below is a link to the output of osad -N -v. Any suggestions? Forgot to mention; I did try blowing away the jabber databases both on the master and proxy server, restarting osa-dispatcher, etc. but it didn't help. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] RHEL5, 1.5, Oracle to RHEL6, 1.7, Postgres
yea, I'm going to have to do the same thing but from SW 1.0 and oracle express. On Tue, Mar 13, 2012 at 11:57 AM, Jason M. Nielsen jniel...@myriad.com wrote: I am looking for recommendations on how to go about a major system upgrade from: RHEL5 SW 1.5 Oracle 11g to: RHEL6 SW 1.7 Postgres My first thought was: )Upgrade existing system to 1.7 as per the normal. )Shutdown SW. )Dump db for use in postgres. )Backup data(ssl, jabberd etc) again. )NOTE: /var/satellite is an NFS mount. )Shutdown system. )Rebuild system with same name but on updated RHEL6. )Mount the /var/satellite nfs. )Install Postgres )Install SW 1.7 using postgres. )Shutdown SW. )Push the Oracle dump back into posgres by following the OracleToPosgres wiki page. Seems like I would at least have some SSL issues client side with this. Easy enough to solve. What else is busted about that process or is there a better route? ie: Build an entirely new system and somehow sync everything to it while both are live. I considered just trying to upgrade the existing system from RHEL5 to 6 but RH doesnt really support that so I tend to avoid it and opt for clean installs. I would have snapshots of the original system and oracle before the first upgrade. The /var/satellite NFS share though I would not which is a bit dodgy at best. Though I might have a way around this. ___ 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] Clients registered with proxy show Offline as of unknown
On 13.3.2012 17:23, Sean Carolan wrote: Here's the situation: * Master Spacewalk server is working fine * Proxy server #1 is also fine, proxied clients are ping-able * Proxy server #2 seems to be working, but clients are not ping-able. Here's what I've tested on proxy server #2: * Clients can register and run rhn_check -vv just fine * TCPdump reveals packets are being sent from the proxy to the master when I run osad on the client * The osad username for the client is showing up in /var/log/messages on the proxy * We are *not* seeing the client's username osad-a88ad541b6 showing up in /var/log/messages on the master server Below is a link to the output of osad -N -v. Any suggestions? I think you are hitting: https://bugzilla.redhat.com/show_bug.cgi?id=795680 Mirek ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Bare Metal Provision Through Proxy
On 13.3.2012 15:38, Wojtak, Greg (Superfly) wrote: It does work directly from the spacewalk server. I probably should have been more clear in my previous email about what I'm perceiving the problem to be. The repo name in the URL is having the 'spacewalk' replaced as well. In this case, the repo is called spacewalk-client. I'm guessing that since my spacewalk server is simply called 'spacewalk', there's some sort of regex going on that replaces all occurrences of 'spacewalk' with my proxy name instead of just the domain portion of the URL. So 'spacewalk-client' is becoming 'proxy.fqdn.tld-client' within the URL string. Aha. Indeed, we have in code which do the replacement something like: s/fqdn-sw-server/fqdn-sw-proxy/ And we do that replacement in whole kickstart file. Word by word. And if your fqdn of spacewalk server is install or selinux or the same name as your base channel name, then yes bad thing can happen. Please do not do that. Write something which would replace only intended part of kickstart is too hard. It is much easier to name your spacewalk at least spacewalk.localdomain. Mirek ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] spacewalk-client 1.7, opensuse12.1
Ralf, Thanks for this solution. This fixed my issue with the rhnreg_ks command. I was able to re-register my machine and download and apply the available updates. Alan From: spacewalk-list-boun...@redhat.com [mailto:spacewalk-list-boun...@redhat.com] On Behalf Of y...@hush.com Sent: Tuesday, March 13, 2012 5:56 AM To: spacewalk-list@redhat.com Subject: Re: [Spacewalk-list] spacewalk-client 1.7, opensuse12.1 Hi, same error on opensuse 11.4: File /usr/sbin/rhnreg_ks, line 33, in module from up2date_client import rhnreg File /usr/share/rhn/up2date_client/rhnreg.py, line 14, in module import up2dateUtils File /usr/share/rhn/up2date_client/up2dateUtils.py, line 11, in module import up2dateErrors File /usr/share/rhn/up2date_client/up2dateErrors.py, line 188, in module class SSLCertificateVerifyFailedError(RepoError, Error): TypeError: Error when calling the metaclass bases duplicate base class Error Problem lies within up2dateErrors.py (rhn-client-tools-1.7.14-2.1.noarch.rpm). Changing class SSLCertificateVerifyFailedError(RepoError, Error) back to class SSLCertificateVerifyFailedError(RepoError) seems to work (line 188 in the file). (Error (parameter?) was added here: http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=9b28ded9de35b00d05457c877b8e8bb9d68a37de) Don't know much about python, so can't exactly tell what is happening, but until it's fixed this seems like a usable solution. Regards Ralf ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Clients registered with proxy show Offline as of unknown
I thought the same thing at first. Satellite at least would black list your server for checking in too frequently. The best I could come up with in this case was to set INTERVAL=60 (the minimum) in /etc/sysconfig/rhnsd. On 2012-03-13 3:55 PM, Sean Carolan scaro...@gmail.com wrote: I think you are hitting: https://bugzilla.redhat.com/show_bug.cgi?id=795680 Wow, thanks Mirek. I've been sitting here scratching my head trying to figure this one out. In the meantime, do you think putting rhn_check into a cron job every 5 minutes might be a good workaround? ___ 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] Bare Metal Provision Through Proxy
Using the FQDN should be fine in our case. What do I need to go about changing and how do I change it to the fully qualified name? It seems like the SSL certs will give headaches if I do this because they are all signed for the short name (spacewalk server was set up incorrectly from the beginning it seems). Thanks for your help! Greg On 2012-03-13 3:23 PM, Miroslav Suchy msu...@redhat.com wrote: On 13.3.2012 15:38, Wojtak, Greg (Superfly) wrote: It does work directly from the spacewalk server. I probably should have been more clear in my previous email about what I'm perceiving the problem to be. The repo name in the URL is having the 'spacewalk' replaced as well. In this case, the repo is called spacewalk-client. I'm guessing that since my spacewalk server is simply called 'spacewalk', there's some sort of regex going on that replaces all occurrences of 'spacewalk' with my proxy name instead of just the domain portion of the URL. So 'spacewalk-client' is becoming 'proxy.fqdn.tld-client' within the URL string. Aha. Indeed, we have in code which do the replacement something like: s/fqdn-sw-server/fqdn-sw-proxy/ And we do that replacement in whole kickstart file. Word by word. And if your fqdn of spacewalk server is install or selinux or the same name as your base channel name, then yes bad thing can happen. Please do not do that. Write something which would replace only intended part of kickstart is too hard. It is much easier to name your spacewalk at least spacewalk.localdomain. Mirek ___ 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] Clients registered with proxy show Offline as of unknown
On Tue, Mar 13, 2012 at 3:19 PM, Wojtak, Greg (Superfly) gregwoj...@quickenloans.com wrote: I thought the same thing at first. Satellite at least would black list your server for checking in too frequently. The best I could come up with in this case was to set INTERVAL=60 (the minimum) in /etc/sysconfig/rhnsd. Thanks, Greg. We'll use this workaround until the jabber bug is fixed. ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
Re: [Spacewalk-list] Bare Metal Provision Through Proxy
On 13.3.2012 21:17, Wojtak, Greg (Superfly) wrote: Using the FQDN should be fine in our case. What do I need to go about changing and how do I change it to the fully qualified name? It seems like the SSL certs will give headaches if I do this because they are all signed for the short name (spacewalk server was set up incorrectly from the beginning it seems). https://fedorahosted.org/spacewalk/wiki/SpacewalkHostnameRename Mirek ___ 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
1) Allow Errata to be updated on the server. The workflow for this is complex as I think we can only call publish() once for each errata and it is difficult to tell when we are done with a particular errata. A good stopgap approach might be simply to save up all the publishing until the end and use spacecmd to publish all unpublished errata or something. As a bit of a test I'm going to give this a go later next week Before I do - have you put any more thought into dealing with this edge case of c5 and c6 systems - with updates for the same CESA potentially arriving at different times dependant on how the centos build servers go? James ___ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
