Thanks for the help so far. Today I could devote some time to it again, this is my progress so far: - Created all certificate files via startssl. - Installed and configured prosody. - Partially set up DNS records. - Configured everything through ant .... -Dfoo=bar
So here's the questions: 1) Is there some big step I'm missing? I can't seem to find a step-by-step guide on federation, I'm stumbling upon links, following them, and hoping I haven't overlooked some other important page. 2) I'm unable to register an account at wave.eezysys.co.uk in order to test stuff with myself. Could you please enable it so that I can log in there? 3) I'm not so sure I've set up the DNS records correctly. I guess I'll find out when I have access to the aforementioned wave server, but meanwile I'd like to check some settings and review the general configuration of my systems. Please bear with me, this is a bit long... The idea so far is to have a single wiab server, running in my desktop pc at home. This desktop pc is natted/firewalled. So far I've forwarded port 9898 (the wiab web interface port), but I'm guessing 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? 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. - The federation docs talk about "XMPP disco" (discovery?). I'm not sure if I should do anything about it? As a summary about DNS records, there's only two lines that mention wave: that SRV record line I pasted above, and the CNAME record. After doing these changes, I waited for a while for DNS to propagate. Then I run the checks shown in the docs. These: $ dig +short -t A example.com 72.148.43.48 $ dig +short -t A wave.example.com 72.148.43.48 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? 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? - 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? Phew, I think that's all for now. Any help is much appreciated, I've never really fiddled with DNS or certificates stuff so please be patient :-) On Thu, May 30, 2013 at 12:29 PM, Ali Lown <[email protected]> wrote: > @Bruno: > >> > I'm attempting again to make my wave server federable, and have some > >> > questions that I hope someone can answer: > >> > 1) Is there any wave server out there that will accept self-signed > >> > certificates? I'd like to test this first, before I try ca-issued > >> > certificates (because I'm guessing it may be more difficult to achieve > >> that > >> > and I want to start simple, though I may be wrong). > >> > >> None currently. I can make one available if needed, but the effort to > >> get a certificate from StartCom is significantly less than the effort > >> to make it all work together anyway. > >> Neither route is any more difficult. > >> > >> Understood, I'll go with signed certs then. Any existing wiab servers I > > could use for federation tests, my server having a ca-issued cert? > > I have made my server available for testing at wave.eezysys.co.uk. > (It took me >1h this morning to get it setup again in a way that I > think should make it federatable) > > >> > 2) The check-certificates.sh script seems to be outdated, it assumes > >> that > >> > either run-config.sh or run-config.sh.example exist, but none of them > >> exist > >> > anymore (I'm in git master branch). Can I simpy comment out those > checks > >> in > >> > check-certificates.sh and go ahead, or is something important really > >> > missing if I did that? > >> > >> The problem with removing the run-config.sh check is that the rest of > >> the script depends on the values it got from that. (In short the > >> script is pretty much useless now). > >> > >> Remove or fix? > >> > >> Would it be appropriate to include those checks at the start of the > > "run-server" ant target? > > They seem to automate part of the checks outlined here: > > http://www.waveprotocol.org/federation/certificates > > Hmm. We would need to determine whether they had federation enabled > before trying to run the checks there. > > >> 3) The initial setup I'm aiming for is this: use my own desktop pc > >> (running > >> > debian sid), forward whatever ports are necessary in the router (so > far > >> > I've forwarded 9898 tcp incoming), and assume people can access my > wiab > >> > server through my dyndns subdomain (which is in the form " > >> foobar.dyndns.org"). > >> > Is this setup enough for testing federation, or would I need to > >> > purchase/use a domain that *I* fully control (e.g. "foobar.com") in > >> order > >> > to configure it in ways that dyndns may not allow? > >> > >> To allow XMPP communication to work, you need to be able to setup TXT > >> records detailing which port to use for the wave service. I don't know > >> if dyndns allows you to do this. > >> > > > > Just checked this, it looks like for free accounts you can barely do > > anything. > > > > Fortunately I have some regular domains that I could use (e.g. > stenyak.com). > > By reading the docs, it looks like I could set a "wave" SRV record that > > points to my dyndns subdomain (foobar.dyndns.org) on port 9898. That > dyndns > > subdomain has the A record that actually points to my home network IP, > > where the 9898 port is forwarded to the relevant computer in the lan. > > > > Is this plan correct? Would wave addresses then be [email protected], > > [email protected], etc? > > Yes. That sounds correct. > > > If so, does all of this mean that I can only have one wave server on the > > stenyak.com domain, or could I have several, for example a server on > > wave1.stenyak.com and another one on wave2.stenyak.com? (I might try > this > > for testing federation in a controlled environment, before I try to > > federate with 3rd party servers) > > You can have one wave server per domain-thing. So you can have one at > mydomain.tld. One at sub1.mydomain.tld etc. > And since you specify port in the SRV record, you can have them all at > the same IP if you really wish to. > > Also, I _strongly_ suggest using Prosody, rather than OpenFire as the > XMPP server, simply because OpenFire is a huge package with a > confusing set of configuration options, whereas Prosody just has the > one config file to debug when it doesn't work. :) > > The instructions on the wiki for it look correct. > > @Angus: > Thanks for moving those documents across. You are correct with those > TODOs (and missed one where the certificates document was referring to > the old run-config.sh script, which is now server.federation.config). > The console client was also removed a while ago. > > If I get some time, I might attempt to tidy up some of those TODOs, > but I am trying to get a release handled as well here, so if you can > work on them (just ask about any questions directly on the list), that > would be great. > > Thanks. > Ali > -- Saludos, Bruno González _______________________________________________ Jabber: stenyak AT gmail.com http://www.stenyak.com
