Can it be done? Add the search service from another server?

Hi Folks,

We have a rather poorly designed AD infrastructure where I work and to make a long story short we’‘ve had to make 9 Wildfire instances running on one SUSE server. Each WF instance points at a different AD server. We configured all of the ports so we’'d have no collisions on the SUSE box and life is grand.

The users have started to use it and are complaining that they cannot search for users who use a different AD server, instead they have to add them manually. The different AD servers each support a different company, there is a plan for a unified meta-directory using Tivoli’‘s TIM/TAM but that is a multi-million dollar endeavour and it won’‘t happen soon. I know that Wildfire offers a search service for it’‘s own users, but is there any way to get one Wildfire instance to also offer the search service from another server or better yet add the users from the other servers to it’'s own search service?

Any ideas would be greatly appreciated.

Hi,

it should work out-of-the-box if you add another search service (like search.otherdomain) within your client you will be able to use it. It should work also for you having all Wildfire servers on one host.

One should also be able to join a MUC / conference room of another server.

LG

it2000, we’‘re using the Pandion client and I can’‘t see anywhere to enter another domain’'s search service.

I tried spark and it defaults to port 5269, none of our servers are running the s2s on port 5269, it’‘d be nice to have the option to specify a port when adding the server. Also the Spark client doesn’‘t remember what servers you’'ve entered from one session to another so you have to keep re-entering the names.

This is what the Smack debug window returns when I try to add the search service from a WildFire 3.0.1 server (both servers are 3.0.1)

As you can see, “feature-not-implemented” is returned. There must certainly be some way to add a remote search service, could it be config problem, but where, as nothing is defined in the XML file?. This same error is returned for clients on either of the two servers. The servers are allowed to connect with eachother and manually adding a user & IM’‘ing between the two remote servers works just fine, I just can’'t add the search service for some reason… Any ideas? Thanks.

Hey digitalz,

As a simple test, could you try using your server and jivesoftware.com? I tested using the search service of jivesoftware.com from jabber.org and it worked fine.

For my test I used Exodus. I pressed F11 to open the discovery browser and entered jivesoftware.com. The browser then displayed the list of services provided by js.com. I right click on User Search and selected Search. Completed the form and everything went fine.

Just a simple verification…is the search plugin up and running in each server?

Regards,

– Gato

Hi Gato,

I did attempt to add “search.jivesoftware.com”, “jivesoftware.com” as well as attempting again to use “search.jabber”, “jabber”, “search.jabber2”, & “jabber2” via the spark 2.0.7 client. All of which returned the same result as my post above (unable to contact search service). I am able to add a second instance of the same search service I already have installed. My WildFire servers are running in a corporate environment so I am certain that I can’‘t add jivesoftware.com due to the firewall & proxy servers. I did run a tcpdump on the WildFire server when trying to add the search service for the other server (jabber2) in my environment… I am able to see that the communication between the servers is working and that they communicated over port 5269. This is what was returned by the remote server for which I was trying to add its search.jabber2 service. Unfortunately the data is trunicated during the capture, maybe this is useless, but just in case it’'s not:

iq type=“error” id="zyb54-32

The search service (version 1.1.6) is installed on both 3.0.1 servers, both servers are virtual servers and the second instance was a clone of the original. My server to server configuration is a whitelist with each server correctly identified. I have not loaded any certs, I am using the 2 certs which are installed by default, but I do have an encryption issue, I don’'t know if this has any realation to the issue? The servers are able to communicate (IM between eachother) via the dialback feature, but cannot use TLS encryption because the root CA is not trusted on the remote server. Both servers log this same error.

Thanks for all your help!

I have to throw mine in as well. attempted to disco to jivesoftware.com… and jabber.org… no love… even tried to hit my old jabberd2 server, which in that case I can ‘‘see’’ the services running, but not allowed to connect…

ANSWER:

This is either entirely undocumented or I haven’'t been reading the right installation guide?

In order to be able to connect to the conference, search services, etc… on a remote jabber domain, DNS must have records registered for the services.

So if you have two jabber servers (jabber domains), which we will call jabber1 and jabber2 and your domain name is company.com, your jabber domains are actually jabber1.company.com and jabber2.company.com. This was where I ran into a problem. I did not have subdomains created for jabber1.company.com and jabber2.company.com configured in DNS. Instead I only had host (A) records configured in DNS for each of the jabber servers (jabber domains) under the company.com zone. So when trying to contact the search service of the remote jabber server (i.e. search.jabber2.company.com), the jabber1 server (which I am logged onto via Spark) is trying to resolve the DNS record for the FQDN search.jabber2.company.com and fails. Therefore subdomains must be created in DNS to resolve the wildfire server & domain as well as aliases for each of the services offered on the wildfire server.

My assumption in this was that the wildfire server was only attempting to contact jabber2.company.com and once connected it was attempting to connect to an advertised service named “search”, which is completely wrong.

This makes me raise the question of how/why the ability exists to connect to the search/conference services of the wildfire server you are authenticated to without DNS records for those services?

When implementing two or more wildfire servers in your organization, make sure to plan DNS accordingly.