This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 810908 - When using HA configuration, osa-dispatcher is utilizing real hostname instead of floating hostname and so osad clients not picking up actions
When using HA configuration, osa-dispatcher is utilizing real hostname instea...
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
1.8
All Unspecified
medium Severity high
: ---
: ---
Assigned To: Stephen Herr
Red Hat Satellite QA List
: Patch
Depends On: 797691 834376
Blocks: space18
  Show dependency treegraph
 
Reported: 2012-04-09 11:38 EDT by Stephen Herr
Modified: 2012-11-01 12:21 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 797691
Environment:
Last Closed: 2012-11-01 12:21:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Herr 2012-04-09 11:38:20 EDT
+++ This bug was initially created as a clone of Bug #797691 +++

Description of problem:
Customer has setup a HA satellite as per this guide https://access.redhat.com/knowledge/techbriefs/red-hat-network-satellite-high-availability-guide and the satellite has multiple IP addresses and multiple hostnames, in particular a floating IP and floating hostname.

All satellite services are set to use the floating hostname/IP and everything is working ok with this arrangement except for osa-dispatcher.  osad clients are picking up actions immediately and instead only check-in normally every few hours.  osad clients are set to connect to the floating hostname/IP.

The problem seems to be that osa-dispatcher is not properly picking up the floating hostname and instead is using the real hostname of the HA node.  When osa-dispatcher uses the floating hostname then clients work as expected.

Version-Release number of selected component (if applicable):
Satellite 5.4.1
osa-dispatcher-5.9.38-1.el5sat.noarch

How reproducible:
Always

Steps to Reproduce:
1. Setup satellite with the following example naming scheme:

Physical hostname:
physical.example.com

Virtual hostname:
virtual.example.com
-->aliased to: alias.example.com

This alias.example.com alias is used in all systems that access the satellite.  This alias is also used in all configuration files in the satellite itself, as well as for the certificates.

2. Start satellite services.  All satellite services start ok, including osa-dispatcher
3. Schedule an action on a client running osad.  Client doesn't pickup action immediately and only picks it up when rhn_check runs as per usual every 4 hours.
  
Actual results:
osad clients not picking up actions immediately

Expected results:
osad clients pickup actions immediately

Additional info:
Had client try the following change to /usr/share/rhn/osad/osa-dispatcher.py which worked for them:

--- osa_dispatcher.py.orig	2011-10-25 16:00:46.000000000 +1000
+++ osa_dispatcher.py	2012-02-20 11:25:54.000000000 +1000
@@ -101,7 +101,8 @@
         self._poll_interval = CFG.poll_interval
         self._next_poll_interval = self._poll_interval
 
-        hostname = socket.gethostname()
+        #hostname = socket.gethostname()
+	 hostname = self._jabber_servers[0]
         self._register_dispatcher(c.jid, hostname, port)
 
         c.retrieve_roster()


However proposed solution involves adding an extra configuration option to /etc/rhn/rhn.conf to manually set the hostname, like so:

--- rhn.conf.orig	2012-02-14 16:27:01.000000000 +1000
+++ rhn.conf	2012-02-27 10:28:16.000000000 +1000
@@ -72,6 +72,7 @@
 
 server.jabber_server = alias.example.com
 osa-dispatcher.jabber_server = alias.example.com
+osa-dispatcher.hostname = alias.example.com
 osa-dispatcher.debug = 10


--- Additional comment from mhuth@redhat.com on 2012-02-26 22:17:29 EST ---

Actually, the first patch is unnecessary now.  The osa-dispatcher.hostname option won't exist in rhn.conf by default.  It would only be necessary to add this option if the satellite is being used in a HA environment to allow osa-dispatcher to work properly if the machine has a floating hostname (ie a floating hostname that is different from socket.gethostname()/real hostname).

--- Additional comment from mhuth@redhat.com on 2012-03-01 17:49:54 EST ---

Customer confirmed that the patches resolved the problem for them.

So in summary, the patches allow for the addition of a new rhn.conf configuration option 'osa-dispatcher.hostname' for use in situations where the satellite is being used in a HA environment.  In such a situation, the satellite will have a real hostname and a floating hostname, but currently osa-dispatcher uses the real hostname and not the floating one causing push functionality to not work with osad clients.  Specifying the floating hostname in the 'osd-dispatcher.hostname' option means osa-dispatcher will use this floating hostname instead of the real hostname.  If no 'osa-dispatcher.hostname' is specified in rhn.conf, then it will default to using the real hostname.

Looking for confirmation from engineering that the patch (and the idea for the patch) seem ok and whether the patch will be in the next release of satellite or not (customer would like it to be in the next release).

--- Additional comment from jpazdziora@redhat.com on 2012-03-02 02:45:29 EST ---

Why isn't the patch from comment 0

--- osa_dispatcher.py.orig 2011-10-25 16:00:46.000000000 +1000
+++ osa_dispatcher.py 2012-02-20 11:25:54.000000000 +1000
@@ -101,7 +101,8 @@
         self._poll_interval = CFG.poll_interval
         self._next_poll_interval = self._poll_interval

-        hostname = socket.gethostname()
+        #hostname = socket.gethostname()
+        hostname = self._jabber_servers[0]
         self._register_dispatcher(c.jid, hostname, port)

         c.retrieve_roster()

the preferred one?

--- Additional comment from mhuth@redhat.com on 2012-03-02 15:59:44 EST ---

Hi Jan,

Either patch is ok to use, I just thought the second one might be a bit more 'nicer'/'cleaner'/'more elegant'?  But anyway, the customer has tried both and verified both work so I'll leave it up to your judgement regarding which one makes it into satellite.  I'm ok either way.

Cheers,
Mark

--- Additional comment from sherr@redhat.com on 2012-04-09 11:04:01 EDT ---

I agree with Jan, the osa-dispatcher.jabber_server option that exists in rhn.conf *is* the hostname that the osa-dispatcher is running on, adding another option for osa-dispatcher.hostname is redundant. I will include the patch given in comment 0 (and comment 7).
Comment 1 Stephen Herr 2012-04-09 11:45:18 EDT
Committed to Spacewalk master: 30b06a259d20516c541e509a853cfd3de98255c7
Comment 2 Jan Pazdziora 2012-10-30 15:25:45 EDT
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Comment 3 Jan Pazdziora 2012-11-01 12:21:35 EDT
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18

Note You need to log in before you can comment on or make changes to this bug.