Moving Run-time Location /etc/emrajs

We’ve been simplifying the post-install Jaxer environment one folder at a time. With the previous update we were able to get Jaxer working with Vanilla (apt-get) Apache. Which means that the only folder left in the post install directory is the jaxer folder which contains the binaries. Which means if we can move that folder to something like /etc/emrajs we would have something that starts to look like an actual Linux installation. But since we haven’t even looked into /usr/sbin or anything, so maybe let’s not get ahead of ourselves on that one.

Jaxer working with Vanilla Apache

Getting Jaxer to work with vanilla Apache (as in installed from apt-get or yum) is something that I haven’t been able to get working, probably because I’m an idiot. After the failure of not being able to register our compiled version of Apache to Systemd, I figured I might as well try getting vanilla Apache to work with Jaxer, and if it doesn’t work I can always go cry in a corner.

Jaxer Maintenance Blog -Systemd Jaxer

So now that we’ve managed to separate Apache from the runtime environment by using Nodejs, that means we were able to simplify the start and stops scripts directory to remove the scripts related to Apache. And now that we only need to start and stop Jaxer, that means it should be considerably easier to register Jaxer as a service to systemd. So after a little bit of trial and error we were able to get the service to work.

Apache Emulation Part 3

In our previous post we started to analyze the relationship between Apache and mod-jaxer by capturing the packets that were exchanged between these two processed. We found that first some handshake bytes were exchanged followed by headers and the content of the file being handled by Apache. As this looks like the main functionality we will have to replicate, in this blog post we will take a closer look at the header data sent by Apache.