I'm re-purposing this for SledjHamr https://sledjhamr.org/git/docs/index.html

The general structure of SledjHamr is a bunch of servers talking to each
other via Internet (or just local) connections.  One of them is a web
server for assets, world data, and inventory.  Actually most of OpenSim
is just a collection of web servers.

Originally I didn't think using a web based world client was a good idea,
however it might be better to have one, for reasons.  Now I need a web
management console that can do all the things the current tmux console
can, including OpenSim console and commands.  Plus account management for
users.  I can also use a web based Jabber / XMPP front end to chat, IM,
and group chatter, which would run in the normal viewers web browser. 
This provides a doorway into putting SledjHamr stuff in existing viewers
without needing them to support it.  So a web based viewer now makes more
sense, and also means we can get away with not needing a viewer at all.

Toybox itself doesn't include a web server, and I don't think there is
one on the roadmap.  So we have to use an external web server, which was
a design goal of SledjHamr in the first place, using existing mature
HTTP infrastructure, coz that's already solved problems for a bunch of
things that plague OS/SL to this day.  Clear your cache!  Pffft.

So sledjchisl.c will be the "love world server", though initially it just
drives OpenSim_SC in tmux via tmux commands to send keys and read output. 
Later it might run opensim_SC directly and use STDIN and STDOUT to do
everything.  It'll also provide the text management front end that runs
in the left tmux panel of the first window, which is why it's based on
boxes in the first place.  Later still it can take over opensim_SC
functions as I move them out of mono.

We will need a text, web, and GUI version of this management front end. 
Hmmm, maybe don't need a GUI version, GUI users can just run a terminal.

After much research, FastCGI / FCGI seems to be the most portable way of
interfacing with existing web servers.  FCGI protocol closes STDERR and
STDOUT, and uses STDIN as it's two way communications channel to the web
server, so our FCGI module can't be used as the text management front
end.  This is probably a good idea to keep them separate anyway, for
security, coz the web server is exposed to the world, the console isn't.

Currently sledjchisl.c tests to see if it's running in tmux already, if
it isn't it starts up tmux runs itself into this new tmux, then exits. 
So it could also test if it's running from FCGI, and switch to web mode,
then it'll need to find the tmuxed instance to send commands to it. 
Either via nails connection, or sending tmux commands via shell.

FCGI has methods of dealing with auth and templates.  B-)

So for now I think I'll have the text and web management front ends in
sledjchisl.c, and the love world server as well.  I can split them up
later if I need to.


--------------------------------------------------------------------

How to install it.
------------------

It's all still partly written, un-released, and experimental at the
moment.  So these are just rough notes about what is needed.

There are two parts, the OpenSim runner part and the web pages part.  The
OpenSim runner part requjires the rest of opensim-SC to be installed,
which is covered by other documents in this source code repo.  SO the
below only talks about the web pages part.

So far I have only tried this with Apache 2, but it should work fine with
other web servers that support FCGI.  I'm using spawn-fcgi which was
written for lighttpd, and seems to be the proper way to support FCGI in
Nginx as well.

Until I have actually released this, it'll be source code only.  So you
need a C development environment to compile all the C source code.

Some of the dependencies are included, like LuaJIT, qLibc, the FCGI SDK,
and toybox.  Or at least their source code git ropes are cloned during
the build stage.  The other dependencies are the development environments
for MariaDB or MySQL (only tested with MariaDB), OpenSSL, and UUID.  And
spawn-fcgi.  In a Debian based Linux distro, that could be installed by
something like -

apt install libmariadbclient-dev libssl1.0-dev uuid-dev spawn-fcgi

Once you have all of that, you can run the src/BuildIt.sh script to put
it all together.  That script will also actually run the web side of
things.  Often during this early development process, that script will
run things under a test tool like valgrind, so you'll probably need that
to.

You'll need to configure your web server to pass web requests onto
sledjchisl.  I'll add instructions for other popular web servers later,
but for now, this is what to do with Apache 2.

Load the mod_proxy_fcgi module.  Include something like this in your
virtual host definition -

<FilesMatch "\.fcgi$">
  SetHandler "proxy:unix:///opt/opensim_SC/var/cache/sledjchisl.socket|fcgi://localhost/"
</FilesMatch>

Adjust that unix:// path to match if you have installed things elsewhere. 
Also make that directory readable by the web server group.

Copy the files in example/www to where eveqer your web servers document
root is.

Note that the account.html dynamic web page redirects to a HTTPS version
of itself, so you'll need HTTPS to be working.

The current web pages will then be available at something like -

http://localhost/sledjchisl.fcgi/loginpage.html

http://localhost/sledjchisl.fcgi/stats.html

https://localhost/sledjchisl.fcgi/account.html