From bd58d3012c26d16150f650c389d1136741d3939d Mon Sep 17 00:00:00 2001 From: onefang Date: Tue, 8 Sep 2020 21:34:54 +1000 Subject: Add the SledjChisl stuff. --- src/sledjchisl/README | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 src/sledjchisl/README (limited to 'src/sledjchisl/README') diff --git a/src/sledjchisl/README b/src/sledjchisl/README new file mode 100644 index 0000000..31a4b30 --- /dev/null +++ b/src/sledjchisl/README @@ -0,0 +1,118 @@ +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 seperate 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 thes 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 - + + + SetHandler "proxy:unix:///opt/opensim_SC/var/cache/sledjchisl.socket|fcgi://localhost/" + + +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 + -- cgit v1.1