Question about Docket Frontend


I sometimes receive support requests via email. While I’m happy to help when I can, we like to encourage the use of these message boards so that others can share. Here is a recent email that I answered.

Hi Derek,

At the moment I am experimenting with Google Stenographer in combination with the Docket REST API. I have installed both Stenographer and Docket on the same CentOS machine. The capturing with Stenographer works and I can use stenoread to query packets. Besides that, the querying from Docket works also. I can query a specific session from the API with curl and download the merged PCAP. But I would like to use the frontend from Docket. The Github documentation doesn’t say anything about how to configure/use the included frontend (/opt/rocknsm/docket/frontend). Could you give me some instructions or directions on how this is supposed to work? Note: I do not have RockNSM installed, just a standalone CentOS server with Stenographer and Docket. Thank you in advance for you time.


That’s a fair question, and I should update those docs. If you haven’t done so, I recommend installing docket via RPM, which you can get from the RockNSM testing repository [1]. You can also connect to that with yum to get access to the other RPMs, if needed. Short of the RPM, you have to build the front end using Node.js. Once the webpage is built, there are only static files to serve. These are packaged in the RPM so you don’t need all the Node.JS dependencies on your server.

In RockNSM we use Lighttpd to serve up Docket, but you could use nginx as well. The lighttpd example config in the repository [2] already has the configuration to serve the static files. In this configuration, we simply pass the request to the backend uwsgi server, which uses an X-Sendfile to tell lighttpd to send the file directly. The key to get that to work is the “static config” section in the uwsgi config [3].

Admittedly, the dataflow of that config can appear confusing, but doing it this way means that uwsgi gets to see all requests, and I found that easier to troubleshoot.

For static requests (the frontend and PCAP files) the dataflow looks like:

Client (request) -> Lighttpd (request) -> uwsgi (response headers) -> lighttpd (response headers + content )-> client

For dynamic requests (using the API to query/submit jobs), it looks like:

Client (request) -> Lighttpd (request) -> uwsgi (request) -> Docket Flask API (response) -> uwsgi (response) -> lighttpd (response) -> client

I hope that is more helpful than confusing. I’ll make a note to update the documentation. If you find some instructions useful and would like to submit them to the Docket repo as a pull request, that would also be very useful.