+++ 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 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 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 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 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 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).
Committed to Spacewalk master: 30b06a259d20516c541e509a853cfd3de98255c7
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18