FYI: Hooking Wildfire 3 admin interface into apache

Openfire Openfire Support
1

Hi,

Since Wildfire 3.0 doesn’‘t support the servlet option any more, I’'ve looked into other ways of hooking wildfire into my HTTP-server, without opening another port on the firewall.

I’‘ve suceeded by using mod_proxy, mod_proxy_http and mod_proxy_html (Note that this is in Apache 2.0, I don’'t have any experience for the dated version 1.2.x). My configuration is as follows:

LoadFile /path/to/libxml2.so

LoadModule proxy_html_module modules/mod_proxy_html.so

RewriteEngine On

ProxyPass /wildfire/ http://myserver.com:9090/

ProxyPassReverse /wildfire/ http://myserver.com:9090/

RewriteRule ^/help/(.*) /wildfire/help/$1

SetOutputFilter proxy-html

/code

mod_proxy_html is not part of the default distribution. Information on how to download, compile and include it are available on http://www.apacheweek.com/features/reverseproxies[/url]. It is required because the web interface uses absolute URLs all over the place (which is very unfortunate).

The /help/-rule is required, because the help button at the top right uses javascript to link to /help/…, which mod_proxy_html doesn’‘t handle by default. Enabling the support for search/replace in javascript causes some other issues (like replacing the comment tags // with /wildfire//wildfire/), so I don’'t use it.

I don’‘t have any issues right now, but maybe I’'ve missed something (like I nearly missed that help-link issue). Any feedback would be nice!

Note that wildfire doesn’'t allow the admin interface to listen on 127.0.0.1 only (JM-724), you have to use the same IP the XMPP-service is listening on there.

2

Note that it should be / w i l d f i r e > in the config-file in the Location-tag, I don’‘t know why it’'s displayed incorrectly here, the source is definitely ok (I checked twice).

3

Hi Andi,

what a confusing title. It seems you are just refering to the web console which is running on port 9090. A jar file is indeed no offerd by Jivesoftware and that a bad news for Wildfire 3.0 but one can still fetch the source and compile and create wildfire.jar.

Note that wildfire doesn’'t allow the admin interface to listen on 127.0.0.1 only (JM-724), you have to use the same IP the XMPP-service is listening on there.

One can of course bind Wildifre to 127.0.0.1 and then use one of the famous connection managers on the same physical server to make the XMPP ports worldwide reachable. The file transfer proxy and server-2-server connections will be broken anyhow.

LG

4

I’‘m sorry for the confusion, I’'ve edited the title to be more precise.

I’‘ve been told by the jivesoftware staff that the servlet is deprecated, and should not be used. That it’'s still lurking in there is probably just because nobody was annoyed enough by it to actually remove it.

5

Hi,

I’‘ve been also told that the jar file is deprecated but for me it make no sense to run Java applications standalone if one can deploy them in an application server. I can’'t understand this decision as it makes the product less interesting for big companies where every product must run in an application server and standalone application have little chance as there the overhead for installation and updates is much higher.

LG

6

There were some issues with plugins and other stuff. I guess they simply didn’'t care enough about it to get it fixed, so they deprecated it.

Everything by jivesoftware looks to me like self-servicing (Wildfire works best in only the exact situation where jivesoftware itself uses it, Smack only works fine as long as you’‘re using it in exactly the same way as Spark does, etc). I’‘m glad they’'re offering all the code as open source, but the best way to get stuff fixed by them is to get them to need it, too.

Anyways, for me personally, the solution I posted here is better, because I no longer have to run tomcat for it (plus mod_jk). Binding the admin interface to localhost only would be a big plus, though.

7

I do agree it would be nice if I could run the admin interface behind mod_proxy. I’‘m not sure, how easy it is to convert everything to using a relative paths. I guess there should just be a system property with a path-prefix, so that you can prepend “/wildfire” to all the URL’'s in the console.

Maybe someone could file an issue in Jira for that?