In preparation to including the manalyzer into MIDAS, I split it into a separate
repository and included it into ROOTANA as a git submodule.
This will cause a minor difficulty and require a manual adjustment next time you
do a "git pull":
- check that (a) manalyzer directory is empty or (b) it only has .o and .exe
files, in both cases delete it
- run "git submodule init; git submodule update", you should see it clone the
I cut a release branch and tag for rootana-2020-03. This release is meant to be used with
midas release 2020-03.
More recent versions of midas have several incompatibilities with ROOTANA, and I will
be working on resolving them:
- new incompatible data bank format in midas .mid files. (to fix the 64-bit misalignment bug)
- renaming of MIDAS TID_xxx types
- renaming of MIDAS data types in XML ODB dump files.
When we tag the next midas release, we will tag the compatible ROOTANA release and going
forward hope to have MIDAS and ROOTANA releases done in lock-step.
In mu3e we use cmake to build our software,
and as rootana does not use cmake build system it is
very difficult to integrate it in our software.
I have posted pull request
that implements cmake build for rootana.
It is tested standalone on several systems
and also as part of mutrigana-base repo
(which is also used in online repo of mu3e).
Tests and comments are welcome.
> In mu3e we use cmake to build our software,
> and as rootana does not use cmake build system it is
> very difficult to integrate it in our software.
> I have posted pull request
> that implements cmake build for rootana.
> It is tested standalone on several systems
> and also as part of mutrigana-base repo
> (which is also used in online repo of mu3e).
> Tests and comments are welcome.
Thank you for contributing this. I will be working on MIDAS and ROOTANA soon and I
hope to add cmake support. The main issue it to finish the split or mvodb, midasio
and manalyzer into separate git submodules.
I would like to have the possibility to add different options when I create a THttpServer. At the moment the manalyzer.cxx only adds the port:
2840: sprintf(str, "http:127.0.0.1:%d?cors", httpPort);
But there are more options which one can use https://github.com/root-project/jsroot/blob/master/docs/HttpServer.md.
> I would like to have the possibility to add different options when I create a THttpServer.
I would like to know your "use case". What different options do you want to use in addition to what's already there?
I must ask because some options are insecure (i.e. exposing the webserver to external connections) and
while I have no problem with others shooting themselves in the foot, I think they should be warned
before they do it and I do not want to read it in the news that they did it using a gun I built.
> At the moment the manalyzer.cxx only adds the port:
> 2840: sprintf(str, "http:127.0.0.1:%d?cors", httpPort);
this is by design. it is only safe to bind thttpserver to localhost, exposing to external connections is not safe. (until somebody
can review the security situation with the version of civetweb, an antique clone of mongoose, inside ROOT).
same situation with mhttpd, it is not safe to expose it to external connections, it should always live
behind a password protected https proxy.
> But there are more options which one can use https://github.com/root-project/jsroot/blob/master/docs/HttpServer.md.
yes, I see there is more options now that there used to be before.
which ones do you want to use? and which ones you think are generally useful in what we do?
- threads - I am not sure what the latest thread-safe situation is on ROOT. is it useful to increase number of threads beyond 10?
- top=name - yes, useful, but I think jsroot overrides that.
- auth_file, auth_domain - digest authentication .htdigest file stores passwords effectively as plain text, if you steal the .htdigest file, you
can login into the web server (as opposed to stealing /etc/passwd, you cannot login anywhere with it, not until you crack the hashes).
- loopback - this is what I want to enforce
- debug - could be useful, but is it?
- websocket - does this do anything useful for us?
- cors=domain - same as in midas mhttpd, I think we respond with CORS "*", is some other reponse useful?
- readonly - (is the default?)
- readwrite - I think should be *our* default
- global - (is the default, I agree)
- noglobal - any use case where we may want this?
- anything else?
For general use, I want maximum security configuration: bind to localhost, cors enabled, user can specify tcp port number, plus anything else from
the list above?
For maximum flexibility we should probably have "--insecure-thttpd" to specify
the complete THttpServer() constructor argument. But it would be silly to force everybody
to use that just to set the "debug" option.