Trials and Tribulations of StatusNet with Meteor

I have recently moved this domain to a VPS, and the main reason was so I could speed up my StatusNet site, but a nice side effect to that was that I could add the auto-content-update plugins to my StatusNet site.

I plumped for Meteor, as it was more-or-less the defacto choice (or so it seems at the moment), and went away to follow the instructions at http://meteorserver.org. Having added my meteor server, and knowing that there’s only me that is likely to be using the auto-update plugin, I set up Apache to proxy the meteor connections.

Here’s what I’ve got:

I used the default /etc/meteord.conf, but added at the top of the file the following two lines:

SubscriberIP 127.0.0.1
ControllerIP 127.0.0.1

I started meteor and checked that meteor was running:

# netstat -an | grep 467
tcp        0      0 127.0.0.1:4670          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:4671          0.0.0.0:*               LISTEN

Next, I added a new file to /etc/apache2/sites-available called metor-proxy

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        ServerName meteor.jon.sprig.gs

        ErrorLog ${APACHE_LOG_DIR}/meteor-error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/meteor-access.log combined

        ProxyPass / http://127.0.0.1:4670/
        ProxyPassReverse / http://127.0.0.1:4670/
</VirtualHost>

Then, I used the a2ensite script:

# a2ensite meteord-proxy
Enabling site meteord-proxy.
Run '/etc/init.d/apache2 reload' to activate new configuration!

I ensured my DNS had an entry for this hostname, it does.

Lastly, I added some lines to my StatusNet config.php file:

addPlugin('Meteor', array(
    'webserver' => 'meteor.jon.sprig.gs',
    'webport' => 80,
    'channelbase' => 'statusnet',
    'controlserver' => '127.0.0.1',
    'controlport' => '4671'
));
addPlugin('Realtime');

All looks good so far, right?

I fire up my StatusNet site, and check in firebug – the meteor.js file is being loaded OK, but straight away, it’s loading /poll.html, and not /stream.html, so I’m guessing there’s an issue here…

Head over to the console tab, and what do we see here?

Permission denied to access property 'Meteor'
parent.Meteor.register(this);

AAARRRGGGGHHH!

I’ve fallen foul of the XSS that we were trying to prevent.

But, hang on a second. Perhaps this is because we’ve configured StatusNet to use HTTPS always. ARGH.

Let’s put the proxy lines into the SSL config for apache (inside the VirtualHost *:443 section):

        ProxyPass /poll.html http://127.0.0.1:4670/poll.html
        ProxyPassReverse /poll.html http://127.0.0.1:4670/poll.html
        ProxyPass /stream.html http://127.0.0.1:4670/stream.html
        ProxyPassReverse /stream.html http://127.0.0.1:4670/stream.html
        ProxyPass /meteor.js http://127.0.0.1:4670/meteor.js
        ProxyPassReverse /meteor.js http://127.0.0.1:4670/meteor.js
        ProxyPass /push/ http://127.0.0.1:4670/push/
        ProxyPassReverse /push/ http://127.0.0.1:4670/push/

Edit the meteor.js file (from /usr/local/meteor/public_html/meteor.js) and changing all http:// to https:// and port==80 to port=443, then amending the StatusNet’s config.php to show:

addPlugin('Meteor', array(
    'webserver' => 'jon.sprig.gs',
    'webport' => 443,
    'channelbase' => 'statusnet',
    'controlserver' => '127.0.0.1',
    'controlport' => '4671',
    'protocol' => 'https'
));

OK, that’s looking a lot healthier. Oh, no it isn’t – now, my poll.html requests are going to http://jon.sprig.gs:443/poll.html ARGH.

I’m very confused now.

I’ve commented out the Meteor and realtime plugins while I try to figure it all out :(

JonTheNiceGuy

He/Him. Husband and father. Linux advocating geek. Co-Host on the AdminAdmin Podcast, occasional conference speaker.

6 thoughts to “Trials and Tribulations of StatusNet with Meteor”

  1. It looks like the meteor.js file needs to be patched, and potentially the /plugins/Meteor/meteor.php needs to be amended.

    I’ll probably not get around to this until at least the other side of the weekend now.

  2. Just a thought… should you be referring to your control server as meteor.jon.sprig.gs rather than 127.0.0.1? As you’re using a Named Virtual Host?

    If you’re using Named Virtual Host and you reference 127.0.0.1, it’ll automatically use the first entry in your sites-enabled directory, which is most likely your VirtualHost entry for jon.sprig.gs. I wouldn’t change this!

    But I would try changing your:
    ‘controlserver’ => ‘127.0.0.1’,
    to
    ‘controlserver’ => ‘meteor.jon.sprig.gs’,

    … particularly as your VPS is the only service that actually knows what meteor.jon.sprig.gs means.

    Does that make sense?

  3. So, the main thing is that the control server is where the messages for distribution are directed – think of it as the SMTP server. It’s the web server which directs those responses to it’s clients (the POP3/IMAP equivelent end).

    As such, the control end should be controlled. In a larger environment, they would be on an RFC1918 address, unroutable to the public, but in this position, where the messages are generated locally for delivery, it makes sense to me to effectively firewall them off, by making it so only the processes running locally on the host can see them – hence binding the control server to 127.0.0.1.

    I know you said it’s not relevant, but I just wanted to expand and clarify why it wasn’t.

  4. Of course, and I appreciate it.

    I’m taking the plunge (and the extra £2.40/month) to get the Silver VPS, which gives you extra memory (which I think is going to bite me on the arse at some point) and an extra IP address (which may prevent the issues you’re experiencing above)

    I’ll let you know how I get on.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.