search

nudj / nudj-backend

Nudj - Backend (Archive)
0 stars 0 forks source link

Moving to the new chat servers #12

Closed shtukas closed 8 years ago

shtukas commented 8 years ago

@richardbuckle Could you please point the dev mobile app to use the chat server at 134.213.136.205 and tell me how it goes. Cheers,

richardbuckle commented 8 years ago

A quick smoke test was successful: chat sent and received correctly. I will test further later today.

Will you be changing existing DNS entries for the chat servers? If so, feel free to reduce the TTL on them in advance so that they propagate quickly.

shtukas commented 8 years ago

Awesome. re DNS: probably yes, but later on. There are few other things I need to do first :-)

richardbuckle commented 8 years ago

Strongly recommend you reduce the TTL now so that it can time out while you work. Otherwise you'll have to wait 24 hours after you finish work for it to propagate ;)

shtukas commented 8 years ago

Ok, moving on to the next step. This post is only for your information.

We now have separated production network and development network.

Production:

Development:

shtukas commented 8 years ago

@richardbuckle You can hardcode chat-dev.nudj.co in the dev mobile app as the name for our dev chat server. I will move to the next step in few days (after the nightly build has reached Robyn and you both have time to test it).

richardbuckle commented 8 years ago

I'm seeing different behaviour with the raw IP address 134.213.136.205 and the hostname chat-dev.nudj.co. I have confirmed that the hostname is resolved correctly at this end by pinging it.

If I use the raw IP address then I can connect to chat rooms and see their contents, whereas with the hostname I get nothing. Possibly because the jabber IDs for all theses entities are based of the form {id}@{domain} and the server hasn't been told its hostname?

shtukas commented 8 years ago

I think I have just understood what one of the lines in the ejabberd config file is for. Can you please try again ?

richardbuckle commented 8 years ago

That's now working normally with the DNS name, good. It doesn't appear to be using TLS though, is that to be expected?

richardbuckle commented 8 years ago

Starting with tonight's nightly build (56), dev and production builds will use the appropriate chat server.

shtukas commented 8 years ago

It doesn't appear to be using TLS though, is that to be expected?

Yes. I decided to make it easy for me and do this one step at a time, by introducing complexities one at a time. For instance I instantly diagnosed this afternoon issue, because I made it so that if after the switch to domain name it were to fail, there was only one place I needed to look at :-)

shtukas commented 8 years ago

I have just activated an enforced client connections on TLS. Let me know how it goes.

Note that the certificate was generated by ejabberd itself during installation and has not been signed by anything, therefore the client must allow non-strict certificate checks (otherwise the user might get a "trust certificate" prompt, or something...)

richardbuckle commented 8 years ago

Cool. I shall test that and then set chat-dev up with a proper certificate from Let's Encrypt later this morning.

shtukas commented 8 years ago

Let's Encrypt

I will do it. It's on the list :-)

richardbuckle commented 8 years ago

Ok. Just be careful not to trigger their rate limiting like I did the first time ;) https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 https://community.letsencrypt.org/t/testing-against-the-lets-encrypt-staging-environment/6763

richardbuckle commented 8 years ago

It turns out that Apple are clamping down on self-signed certs in iOS apps and it will be easier for me to just wait until you have the Let's Encrypt certs in place before testing. Just let me know when ready.

shtukas commented 8 years ago

Um... this might then explain why the original ejabberd server didn't use encryption (even though they might just have thought it wasn't that important). I will start now...

shtukas commented 8 years ago

So.....

The good news is that I only wasted one afternoon and I didn't even consumed all our quota.

The bad news is that ejabberd doesn't work with Let's Encrypt certificates. In fact as far as my understand goes Let's Encrypt is geared towards supporting HTTP servers. Quick Google search showed that I am not the only one with that problem....

Note: Because I do not want to run apache on the chat servers. I ran letsencrypt-auto with the --standalone switch. The certificates were correctly generated, so I don't think this was a problem. I mention it because that's not the way you did it when you were dealing with setting up certificates for HTTP servers.

Anyway, I could move one step backward and disable enforcing connections with TLS, but this would rely on the iOS client not making a fuss about self signed certificates, which I understand won't happen. So I am taking two steps backwards and disable TLS on the ejabberd...

... for the moment.

richardbuckle commented 8 years ago

Wow, that's rather disappointing. I had today revised the client to request a TLS connection too, so I shall revert that for now.

I shall see if I can find another solution - short of getting one of the more expensive EV certificates.

richardbuckle commented 8 years ago

I'm finding various indications that ejabberd requires the certificate and private key to be concatenated:

https://community.letsencrypt.org/t/cant-seem-to-use-symlink-fullchain-pem-file-with-ejabberd/3887/2

Does that shed any light?

shtukas commented 8 years ago

Interestingly I was having similar thoughts... Let me have a look.

shtukas commented 8 years ago

The referenced ejabberd documentation https://www.ejabberd.im/tuto-install-ejabberd is pretty much what I needed (if it works). Give me two secs.

shtukas commented 8 years ago

I can see that it works. You are really the hero we need : )

shtukas commented 8 years ago

Let me know how it goes for you...

richardbuckle commented 8 years ago

SUCCESS!

<UI> ChatModels.swift xmppStreamDidSecure[222]: "Chat stream secured"

Well done!

I guess you'll need to enhance the renewal script to do this concatenation every time the Let's Encrypt certificate updates. Do please be careful about the rate limiting when you test it ;)

shtukas commented 8 years ago

I guess you'll need to enhance the renewal script to do this concatenation every time the Let's Encrypt certificate updates. Do please be careful about the rate limiting when you test it ;)

Perfect!

shtukas commented 8 years ago

Ok, let's make another baby step. I have just moved the DNS record for chat.nudj.co from 162.13.187.75 to the new server 162.13.154.59. (The propagation is already done.)

Unlike chat-dev.nudj.co there is no TLS activated at chat.nudj.co (as to not break existing production mobile apps), but the advantage for me right now is that I can generate a certificate for it and prepare it for when it will be time to activate TLS on that server (around the time the next version of the mobile app goes live I guess...).

Cheers,

richardbuckle commented 8 years ago

It is OK to activate TLS on the production chat server, the production build in the App Store is ready and waiting for TLS and will opt in seamlessly.

shtukas commented 8 years ago

It's done. chat.nudj.co has TLS activated and requires it. I have scheduled the termination with prejudice of the old chat server to after the release of the next mobile app version. If you see anything wrong in production tell me and I will dis-activate TLS requirement.

shtukas commented 8 years ago

Tomorrow, I will take another baby step and actually connect the new chats server to the api server :-)

... and now I can see things happening in your mind; and the answer to your next question is that as of now, the token you send to the chat server to authenticate doesn't matter. I bet with myself that you would not have noticed that :)

In fact I am sure that if I try to chat with you on your phone using Adium on my laptop I am pretty sure it would work :-)

richardbuckle commented 8 years ago

Hmm. That doesn't surprise me in hindsight.

The more I think about this whole business of (ab)using Apple's Push Notification Service token for our own authentication the less I like it. In the future I want to reimplement that, but it is probably best done as part of a migration away from Laravel/PHP.

From my point of view this issue can be closed. Strengthening the chat authentication so that it honours the supplied password would be a new issue.

Thanks for all the work on this: we now finally have all our connections secured by TLS, which is a huge result.

richardbuckle commented 8 years ago

PS I tested the App Store build and it does indeed seamlessly connect using TLS to the new production chat server.

richardbuckle commented 8 years ago

I think this one can be closed now?

shtukas commented 8 years ago

Um......................... ok.