powered by Jive Software

Another Server To Server Question

I am a little confused on how the server to server thing works. Do I need administrative access to both servers? Is it possible for my server to sync with another server that I do not have administrative access to?

What are the requirements for Server to Server connection?

Is there some documentation on this that I overlooked?

Hey Rich,

Server-to-server is the way servers connected between them to exchange packets. This feature let users from a server to send packets to users of any remote server that supports s2s. Each server will have a different domain so users of each server will have different accounts. In other words, this is not clustering where you may have many servers sharing the same domain. Each server is managed by its admins.

Server-to-server requires port 5269 to be opened (i.e. not filtered by a firewall) and to have the server name registered in the DNS server so that SRV lookups return the address of the server so that other servers can connect.

Could you tell us a little more about the things you want to keep in synch between the servers?

Regards,

– Gato

Thank you for the quick response!

One of the servers is a public server, that I do not have administrative access to. The other server is setup on my DMZ that I have full access to. In order to have s2s setup, would I need administrative access on both servers?

I would want to avoid creating multiple accounts (one on each server for each user). Having seperate domain names is not an issue, as long as it was transparent from the clients/users.

Message was edited by: ooky

Hey Rich,

Ideally, I would like to allow users from one server

to be able to communicate to the users of another

server.

That is what s2s is all about.

I would want to avoid creating multiple

accounts (one on each server for each user).

Having seperate domain names is not an issue, as long

as it was transparent from the clients/users.

Hmm, I think that you are looking for clustering then. Do you want to let the same user connect with the same account[/b] to any of the servers? Having a different domain in each server is not transparent for end users since the domain of the account is going to be different.

For instance, if you have a server with server name “server1” and another server with server name “server2” then user accounts on “server1” will be of the form "johndoe@server1.com" while user accounts on the other server will be of the form "noname@server2.com". And any packets that you want to exchange between those accounts should use the correct JID (e.g. "johndoe@server1.com") thus making it explicit to the final user that you have 2 servers.

However, if your users are going to be usually connected to one server which could be the case for branches of a company then it would make sense to use different domains for each branch and make it explicit to users that each account belongs to a specific branch.

Regards,

– Gato

For instance, if you have a server with server name

“server1” and another server with server name

“server2” then user accounts on “server1” will be of

the form "johndoe@server1.com" while user accounts on

the other server will be of the form

"noname@server2.com". And any packets that you want

to exchange between those accounts should use the

correct JID (e.g. "johndoe@server1.com") thus making

it explicit to the final user that you have 2

servers.

I apologize, I should be more specific. This would be fine if the user only had to sign up for a single account on one of the servers to communicate with a user on the other server. Thats what I meant my ‘‘transparent’’. In other words there would be no need to sign up for an account on both servers to have to communicate with both users.

How does this work on public servers? If I setup my server (server1) to connect to another server (server2), does that other server (server2) need to be setup to connect to mine (server1)?

Thanks again for the quick response.

How does this work on public servers? If I setup my

server (server1) to connect to another server

(server2), does that other server (server2) need to

be setup to connect to mine (server1)?

as i understand the primary question, so… Server2 has to accept s2s. That’'s all. But, it may have some whitelists, so maybe your server should be added to this list. If this Server2 is configured to accept any s2s so there is no need to configure something on that side. Just config your server and try to add contact from server2 to your roster.

I’‘m not using s2s myself, so maybe i’'m mistaken a little

Server to server has some security attached to it in the administration console. If you look in the administration console of your own server, you’'ll see that you can configure the server to enable/disable the feature, select who is allowed to connect to your server (anyone, or white list), and what servers are not allowed to connect (this only applies if ‘‘allowed to connect’’ is ‘‘anyone’’).

If you are using a white list, you must add the other server to your allowed list. If your server is set to allow anyone, then all you need to do is ensure you have the service enabled and the remote server will allow your server to connect to it.

The server on the other end has the same type of options - if they’‘re using a white list, then they need to add your server to it’‘s list. If it’'s a public server, it may allow any server to connect (though not necessarily - ‘‘public’’ may refer to who can connect with a client, not necessarily with a server).

Unless you plan to let any server connect to yours, I recommend using a white list. For my money, I don’'t like to allow just anyone out there to connect to a machine I administer - especially in a server to server type capacity.

As for the sharing of users, that’‘s not exacly how server to server works. Your server has it’‘s own local users, and the other server(s) have their own local users. When a user on one server wants to communicate with a user on another server, the initiating server will try to establish a connection to the remote server (if it’‘s not already established) and deliver the message. You won’‘t see a list of the other server’'s users on your server anywhere (unless you create a group and add remote users to the group by hand).

Clients, however, can add remote users to their rosters (their list of users they talk to), and your server will reach out to the remote servers when a user requests communication with the remote user or the local user signs on and presence requests go out to remote servers so online/offline/away status can be retrieved.

I hope that helps.

. . . That’'s all. But, it may have some whitelists, so maybe your server should be

added to this list. If this Server2 is configured to accept any s2s so there is no need to >configure something on that side. Just config your server and try to add contact from

server2 to your roster.

I see, . . . after testing I found that I was able to communicate with users on one server and on another server I was unable to communicate at all (probably uses a whitelist, as you described- which my server was not on).

As for the sharing of users, that’'s not exacly how server to server works. Your server has

it’'s own local users, and the other server(s) have their own local users. When a user on

one server wants to communicate with a user on another server, the initiating server will

try to establish a connection to the remote server (if it’'s not already established) and

deliver the message. You won’‘t see a list of the other server’'s users on your server

anywhere (unless you create a group and add remote users to the group by hand)

I understand. I think in my origional confusion, I thought that you needed to explicitely specify which servers you wish to communicate with. Which you CAN configure this through the server to server interface, although recomended, it isn’'t necessary.

I see now that jabber works much like email, where usernames include a domain name which helps the message get to its destination.

I would like you all for your patience and assistance you have provided.