On 01/06/13 01:26, Bruno Gonzalez wrote:
I'll also need to forward some ports for XMPP, is that right? Which one/s is
it? According to netstat output, I think prosody is using 5269, 5275 and 5222,
should I forward the three of them?
No. Assuming a normal setup (the ports you've mentioned are the xmpp
defaults)
5275 is the component port, this is how wiab hooks into prosody.
5222 is the xmpp client port, which is redundant for wiab installs (so
just ignore it)
5269 is the server-to-server port. This is the port that prosody is
listening on for incoming messages from other servers.
So 5269 is the only one that needs to be forwarded from your firewall.
This needs to be the same port as appears in your SRV dns record. (as
your is)
so, if my server is trying to talk to yours, I first look up the SRV
record for your domain, fetch the host and port number from there, and
then open a connection to your machine.
The firewall of this LAN (the router) has dynamic IP. In order to handle
that, I have a dyndns subdomain "1ksurvivor.dyndns.org", with an A record
that points to the actual IP xxx.yyy.zzz.ttt of my home network. I cannot
do anything else with that dyndns subdomain, only modify the A record.
To work around that, my idea was to re-use the stenyak.com domain that I'm
already using for hosting my personal website in a shared host of a 3rd
party server. To do that:
- The stenyak.com A record is pointing to my shared server on the net,
where my personal website resides. I don't intend to change that, it should
still point there at any time, and not to my home network in anyway.
- I've created a wave.stenyak.com subdomain.
- I've created an SRV record in stenyak.com domain: _xmpp-server._
tcp.example.com. 86400 IN SRV 10 0 5269 wave.stenyak.com.
- Due to using google apps in my stenyak.com domain, I had a CNAME alias
of "wave" pointing to google server at "ghs.google.com". I didn't like
that, so arbitrarily decided to make "wave" point to "1ksurvivor.dyndns.org"
instead. I have absolutely no idea if this is correct or if it will break
things.
afaik, this should all be fine.
- The federation docs talk about "XMPP disco" (discovery?). I'm not sure
if I should do anything about it?
disco is how one xmpp server finds out what extensions the another
server supports. So your prosody uses disco to announce that it
supports the wave - in addition to basic xmpp. I've not used prosody,
but it seems to support disco. If so, you basically shouldn't need to
do anything.
In my case, the results were:
$ dig +short -t A stenyak.com
74.220.220.29
$ dig +short -t A wave.stenyak.com
1ksurvivor.dyndns.org.
77.228.34.76
The first IP is the IP of the shared host where I serve my personal
website. The second command outputs the dyndns subdomain, and the current
IP of my home network. Does it all look ok, or will there be problems as it
currently stands?
I'm no expert, but my understanding is that this should be fine. If not,
it would sound to me like a defect...
Finally, regarding the wiab configuration files:
- The xmpp_component_name is "wave" by default, but the prosody
configuration file ended up having a component named "wave.stenyak.com". Is
that ok, or should I change one of those names?
- In the docs, it seems to be mentioned that SSL is necessary for
federation. However, the wiab config file has enable_ssl=false. Is that
correct?
- Should I set to "false" these two variables too?
waveserver_disable_verification, waveserver_disable_signer_verification
- I think I recall reading about federation problems when using lucene,
should I swtich from lucene search to memory search?
I have to pass on these. I'm using openfire, and I have the component
name as "wave" in wiab and openfire - the others I've made the same
assumptions as you.
- The xmpp_server_secret is the same pass word used in the
component_secret in prosody configuration, and not some xmpp-server-wide
password, right?
Yes, it's the password that wiab uses to authenticate itself as a
component in prosody.
Dave
