Another week is gone and this one was special – we (all student participants of GSoC) had our midterm evaluations this week. So, I needed to show the working discourse website to my mentor, Paul.
The aim of the project I am doing is to create a StackOverflow like platform for sugar where users and developers can easily collaborate together to create a knowledge database for the sugar desktop environment and its activities. Also, since sugar is often employed in areas without any connectivity, we need to make sure that social help is easy to set-up on a server. The problem however is this: Discourse is a Ruby on Rails app that requires several different services (sidekiq, postgres, redis …) to work effectively. Couple that with all the different tools and gems required by the ruby based runtime environment along with version issues and you’ve got a headache for even the best sysadmins. There’s just too much stuff to install – I had quite a few problems because of this (since by distro is somewhat old) when I first installed discourse on my local machine. Top this off with the usual deployment problems with any rails app and you’ve got a true headache on your hands (or in your head? Idk).
Discourse devs saw this, though. So, they use Docker based images to make deployment easy. Now, this option works like a charm – I tested it myself. However, since I had made a few changes to the development version of discourse, I could no longer install from the official image that discourse devs provide. So, I spent quite a bit of time reading over Docker – I swear it was like learning git all over again with a completely different architecture. Anyway, once I was sufficiently comfortable with docker, I decided to create a new image for my customized version. A few looks at the official docker installers for discourse disabused me of any such notions – creating a new image would be a very long task. So, it was best if I did something else. I decided to ask the discourse devs and a somewhat long discussion ensued. Initial responses were somewhat vague and it was I who ended up suggesting a possible approach – that of editing Dockerfiles which the devs concurred with. I tried that – I really tried it – to no effect. After a few variations, I was ready to tear my hair off my haid. Fortunately, the final response from the devs saved me from a bald head.
So, in the end, all I needed to do was to edit the pups templates, not the Dockerfiles. That I did. And, it worked! (Sure, I had a couple of 502 Bad Gateways to deal with on the nginx first but let’s not spoil the fun).
Then, there was a the problem of emails to be fixed. See, discourse is a highly email reliant system – it just won’t work well. So, I tried the tested route – I just used the google’s smtp server via my gmail account. Google, however, had different ideas than my own. I got a bunch of mails telling me of suspicious login attempts. I tried several times to dissuade Google of its protective notions of my online identity all to be left with more suspicious-activity mails. Meh! So I decided to use a local smtp server and to this end, I set-up postfix. It seemed to be working well for a few python scripts so said, what the heck… let’s just use this and be done with it. Alas, discourse seemingly doesn’t play well with postfix – the mails sent my discourse never even made it to the postfix server. I checked the logs only to be receiving blanks. What can I say except for this: Arghhh. So, I sniffed around a bit on meta.discourse.org to see what other people were using. The name Mandrill popped up a few times and I decide to give it a try. And voila! It worked. I could have danced if only I wasn’t sitting in a public tourist viewing spot on the edge of a spectacular cliff. Oh well.
So, I’ve got a method to deploy this custom version of discourse pretty easily and a working email. I mailed Paul and he’s also set-up an account over on the ec2 instance. Anyway, this just means a lot less work towards the end of the coding period when we’ll be working to deploy social help on the public sugar server. For this next week, I will start working on the DB migration issues and hopefully we’ll be able to come up with a simple solution for that as well. This will just mean that whenever we have to set-up a localized social help in areas without internet connectivity, we can just shift the entire main server’s information onto the newer server, no problem. See you next week!