maths / stack_util_maximapool

Pooling solution for starting up maxima processes so that moodle-qtype_stack does not need to wait.
10 stars 14 forks source link

use maximalpool to get stack running without shell access to Moodle server? #30

Open martinzw opened 6 years ago

martinzw commented 6 years ago

Hi there,

your installation guide says "Start by installing STACK as normal and make sure that it works with the maxima you have installed."

On our rented Moodle server we do not have shell access. But it was possible to install "Stack" as a Moodle plugin. Yet we can not install maxima to the Moodle server without shell access.

But we have a separate "jobe" (trampgeek/jobe) server running that is used for question type "Coderunner". This one is maintained by us. And i installed maxima on it. Is it possible to use "maximapool" for letting Moodle plugin "Stack" connect to this separate server without maxima installed on the Moodle server at all? If yes, what exactly would be entered to fields like "qtype_stack | maximacommand" in "Stack" config page on Moodle server?

Of course it would be a great gain if "Stack" could use the REST-API of "jobe" anyway. As far as I understand, "jobe" and "maximapool" do similar things - executing small programs in a kind of sandbox on a network server and sending results back to the calling Moodle server. Why not use a common API for these issues?

aharjula commented 6 years ago

Hi, The guide is old and that statement of asking to first try the normal Moodle server side Maxima install is just to make sure that the person following the guide can get the correct impression on what to expect. Actually, installing that Maxima there is not required, just don't tell that to anyone so that we do not drown in support requests.

If I understand correctly Jobe runs tasks it receives from scratch i.e. starts full processes to execute them when it receives requests. MaximaPool does things a bit differently it starts the processes in advance so that we can skip the load time those processes have and dumps the tasks into them when received, in the case of Maxima and STACK that load time is significant (as in majority of time goes to loading as opposed to actual processing) and as there are multiple requests coming from even a single question attempt and we cannot do parallel processing on the PHP side we need that preloading. Basically, MaximaPool and Jobe have different use cases and priorities.

There has been some talk about JSON wrappers for the Maxima I/O, but these have not been high on the TODO-list. Maybe something happens once a JSON parser gets included in the STACKs Maxima libraries.

If you want to use Jobe, all you need is to provide some translator to unwrap whatever structure Jobe places around the requests. Basically, for MaximaPool we send the raw Maxima code to the Pool and the Pool responds with the raw result, so as long as you warp the incoming correctly and unwrap the outgoing you can probably use Jobe simply by giving an url to that translator. You should note that MaximaPool marks timeouts with a special HTTP status code, matching that will be necessary, otherwise you may have trouble in some nasty edge cases.

Or you could include that translator in STACK: If you want to build a STACK-Maxima connector for Jobe you can surely make it yourself, feel free to look here, but changing the way the current connector to MaximaPool works would be inconvenient as it would require all STACK+MaximaPool users to upgrade both to match. I have nothing against common APIs but given that I coded this few years before Jobe and there were no things of similar nature available there really was no API to mimic.

I am sure that Tim could probably explain the differences of Jobe and MaximaPool better as he has worked on both.

martinzw commented 6 years ago

Hi Matti, thank you for that useful part of information. After several hard days and nights I finally managed to get Moodle STACK questiontype running without maxima locally installed on the Moodle server. Unfortunately all manuals I could find (including the one here) take it as granted, that maxima is already installed on the Moodle server. But in my case it was not, because there is no shell access to the server.

A manual for creating a maxima pool server from scratch without having maxima installed/installable on moodle server would be helpful...

My solution is:

Easiest way to get a maximapool running on a separate server is to start with maximapool-docker, a dockerized version of maximapool coming from a German university: https://github.com/uni-halle/maximapool-docker

But the hosted docker image contains only an old version of the maxima scripts belonging to Moodle-STACK plugin, version 2014083000 Our Moodle server, however contains version 2017121800. The dockerfile could create an actual docker image but it also depends on maxima being installed on the moodle server.

My solution was to mount an additional volume named 2017121800 with scripts form STACK-plugin extracted from its repository to the docker container with rw-rights and to connect to the running container with bash. This way I could use the toolchain integrated in maxima-docker container to create a maxima-opitimised file inside 2017121800 folder.

aharjula commented 6 years ago

You may wish to check that whatever maximalocal.mac you are using (or used for image generation) is of the correct form. e.g. matches the one visible on the Moodle side on the healthcheck-script page of STACK-settings. That file has changed somewhat since 2014 (probably old ILIAS port based on the version). Of course if you already built an optimised image following the common guides you should have done that, if not then expect plots to explode.

Just to make it clear MaximaPool does not require that Maxima is installed on the STACK (Moodle/ILIAS/whatever) server, all it needs is for Maxima to be installed on the Pools server. But as the process of setting up even a simple Maxima install with optimised images is a bit involved the guide will probably always start with asking the installer to do (practice) that first (on the STACK server) before mixing servlet-containers to the picture.

martinzw commented 6 years ago

I think getting the correct version of maximalocal.mac is part of the problem. It is neither to find inside the STACK repository nor inside the maximapool repository nor in the sourceforge-repository of maxima.

I can not get it from our moodle server without shell access. I used the one onside the docker container. Nothing exploded :-) But I in fact get an error from the healthcheck concerning plots.: " Plot error: plot_size must be a list of two positive integers. plot([sin(x),x,x^2,x^3],[x,-3,3],[y,-3,3],grid2d) caused by the following error: Plot error: plot_size must be a list of two positive integers." This did not matter too much for me, algebra works. But of course I would prefer getting things right.

That's what I said:
No manual I found shows how to get it done without shell access to the Moodle server.

Moodle and STACK-Plugin, Maxima, Maximapool, tomcat, lisp in various versions ("sbcl" is right, i guess) that forms a quite complex network. There seems no real explanation on how this all works together. For normal users and not usually linux specialized admins this not so easy to understand.

aharjula commented 6 years ago

If you got that error from the Moodle side healtcheck of STACK you should be able to see the contents of maximalocal.mac on that very same page. As it is a generated file it does not exist in the repositories. And no you do not need shell acess to the Moodle server (this has always been like this) as long as you have the Maxima code of the same STACK plugin version available from elsewhere.

I am pretty certain that the install guide had a step of copying that from there during the earlier times, but maybe someone else who wanted to make our guides better thought it to be irrelevant. In any case this software is built by linux/unix admins for linux/unix admins and I have no idea on how to explain all these details at a level understandable by linux novice. Also as long as we don't explain all the magic we can sell our expertise, gotta reap some revard from experience...

Rillke commented 5 years ago

But the hosted docker image contains only an old version of the maxima scripts belonging to Moodle-STACK plugin, version 2014083000

There are newer version now, thanks to some Moodle users. Pull-requests are happily accepted.

I can not get it from our moodle server without shell access. I used the one onside the docker container.

Under https://github.com/uni-halle/maximapool-docker#files-to-monitor-for-changes there are now hints on where you could also collect information from without even running Moodle (because I don't).

I am pretty certain that the install guide had a step of copying that from there during the earlier times, but maybe someone else who wanted to make our guides better thought it to be irrelevant.

More moodle-tight.

Also as long as we don't explain all the magic we can sell our expertise, gotta reap some revard from experience...

Actually, installing that Maxima there is not required, just don't tell that to anyone so that we do not drown in support requests.

Made me smile :-) Love how honest people from northern Europe communicate. Perhaps pools as a hosted service /SaaS would generate some cash?

aharjula commented 5 years ago

Well we tend to try to be direct from the start as our glorious example Linus has failed so spectacularly when he tries to be polite and then snaps if the message does not get through within mere half a dozen tries. So just better to be direct or respond with sufficiently baffling response to end the thing before one needs to say something in a way that might trigger people to get the message through.

Pools as SaaS is a bit difficult business mainly due to the very fact why pools are difficult.

I have intentionally tried to keep the install guides obtuse as if the person installing the thing does not grok in fullness what they are doing they will more than likely create a huge security hole in their systems and therefore the guidance is kept (luckily no one has created too simple versions of documentation so that I have not needed to block the pull requests) difficult enough to weed out most of those that do not understand.

If one were to sell the Pools and just the pools as service then the problem is that they would not control the side that generates the potentially bad commands and would expose their own infrastructure to those security concerns, therefore it is much more likely to get STACK hosting (Moodle/ILIAS/LTI) with MaximaPool in the same package but without direct access to the Pool.

I have nothing against someone trying that SaaS-thing, and I do have ideas about how to correctly contain the Pools and sign client requests, but I would not want to take that responsibility. There just cannot be such a thing as trust in this type of an system if you do not control both ends. Now that the STACK side is finally getting a Maxima-parser it might be possible to port that to the Pool side to include an optional security check also at that end, but as that adds latency the design of its operation might be interestingly parallel, and tie into some upper level container management.