Please make proxying airshipd through a web server easier.

[virtadpt]

airshipd can be evoked in such a way as to control the IP addresses it monitors for connections to port 9005/tcp (vis a vis, the --host command line option). However, in environments where the IP address of the server cannot be predicted in advance this poses certain problems when setting up hyperlinks to airshipd.

Specifically, while it is possible to configure a web server to proxy airshipd into the URI space of a website (https://github.com/Byzantium/Byzantium/blob/master/porteus/apache/etc/httpd/extra/proxy-html.conf#L101) functionality is incomplete due to the manner in which /grefs/ links are generated.

127.0.0.1 - - [22/Jun/2013:21:41:08 +0000] "GET /Byzantium HTTP/1.1" 404 207 ... 127.0.0.1 - - [22/Jun/2013:20:23:28 +0000] "GET /grefs/Byzantium HTTP/1.1" 404 213

The drop-down list of channels appears, but no message threads or messages appear. Several days' worth of work and tinkering with airship.js has been fruitless, and frankly I'm not sure where to go from here.

My request is for advice or additional functionality which would make proxying airshipd through Apache easier to accomplish. I'm not certain what form this would or should take at this time.

[richo]

Ok, so I think this breaks down into two issues, one of which is easier than the other.

Mapping the URI space as you said is more or less trivial, although for simplicities sake it'd be nice to be able to tell airship's http server that it's running a bit down the tree (purely to avoid having to screw with rewriting in your frontend server).

The second issue is the way the URL's are generated in the clientside javascript code. I think it should be fairly trivial to fix up. I'll have a play with it this afternoon, but if you're in the vicinity, I figure that the workflow should be:

If airshipd knows absolutely where it'll be rooted, pass that data in at templating time to be bound on the Groundstation object, failing that make an educated guess based on window.location when the DOM readies, and then treat that as a prefix for all future URLs.

[richo]

I hacked on this quickly over lunch. This patch at least doesn't break anything on the root.

I believe it should do the right thing, but honestly I didn't have the time to setup a test environment. Let me know if it works for you, or I'll test it properly tonight.

[virtadpt]

So, here's how we wound up making it work, because we couldn't get mod_proxy_html to do the right thing:

By default, every Byzantium node's DNS zone associates the client interface's IP address with the hostname byzantium.mesh. We added an A HREF to http://byzantium.mesh:9005/ to the service directory's index.html file.

There is a second, more subtle issue - groundstation/groundstation/broadcast_announcer.py tries to broadcast to 255.255.255.255 when it starts up. Which is fine, because most nodes are going to have a default route for 0.0.0.0/255.255.255.255. We don't, so it throws an exception (the one on line 33 causes stationd to ABEND). I fixed this by patching the broadcast address on line 12 of the same file to read 192.168.255.255. However, this is a nasty fix and too specific.

Would it be possible to add an additional command line option to stationd which allows the user to specify the broadcast address to send announcements to?

[richo]

Did you try that patch?

I believe it should have made it do the right thing, however I still haven't tested it very well.

I'm going to be in the US from Wednesday onwards, reckon we could make another time for a hangout to chat about what you're doing?

I can get some tweaks into stationd to keep you guys moving, but I think there's value in chatting a bit more to see if I can fix some of these issues before you run into them.

I'll add that option to stationd now though.

[richo]

Implemented in 06a68b1, it uses $BROADCAST_ADDRESS not a command line flag, for compatibility reasons, a portable argument handler is on the todo list, but isn't more important than some of the other stuff Ive been tackling.

[virtadpt]

I think I did, yes - branch origin/bugs/37?

I noted the changes made to broadcast_announcer.py, but they didn't seem to do anything when I tried them in a live environment. I think a Hangout later this week is a definitely possibility.

I see that an environment variable is involved - that'll work.

[richo]

I didn't get as much time to work this on the plane as I'd hoped. I haven't forgotten about it though.

I'm also going to be in the states for a bit longer than expected, so if you're going to be hacking some weekend soon, let me know and I'll buzz over (if that's ok).

[virtadpt]

I don't know about this weekend, but next weekend we might be getting together for a hackathon to finish things up.

[virtadpt]

Testing new version of this... same problem.

Forgot to add the BROADCAST_ADDRESS environment variable to stationd.sh.

Works now.