come up with a good URI scheme for our demos and systems.

[kohlhase]

We have http://arxivsearch.mathweb.org and others I think we should have a good URI scheme to make things rememberable. How about

• http://search.mathweb.org for the MWS landing page as it it.
• http://XXX.search.mathweb.org for the XXX demo in particular arXiv, OEIS, .... cc: @m-iancu

[kohlhase]

This is something we should discuss and do together with @tkw1536. Once we have a concept, then I can do the DNS

[tkw1536]

In order to find a good structure, can we get a list together where each of the components of the MWS demo(s) are currently running on?

Then we can think we can both think about machine level (what service should run where) as well as domain names (which domain names should be given to which service).

One thing I would recommend in general is to never expose any of the mws instances directly via some (very high) port, but instead run those on the respective localhost interface only and proxy via Apache.

[kohlhase]

For the machine level I think we should have a dedicated MWS VM, which runs one or more index and has various front-ends. Then we can give that machine enough memory. An exception might be pine, which is more integrated with MathHub.info.

I think that the high-port practice was just for experimenting.

[tkw1536]

I have been trying to come up with a (more or less) complete list of (our) MWS instances, backends as well as machines.

@kohlhase feel free to edit this post to add other instances you are currently aware of. @a-hambasan Is it possible to run instances only listening to localhost:9999 (and not 0.0.0.0:9999)? If not, this should be implemented.

URLs

• https://search.mathweb.org -- main site with several instances
  • http://search.mathweb.org/schema/ -- frontend alive, backend dead
  • http://search.mathweb.org/tema/ -- password protected for unknown reason
  • http://search.mathweb.org/temaV2/ -- alive and well
  • http://search.mathweb.org/xl/ -- frontend alive, backend dead
  • http://search.mathweb.org/sentido/ -- frontend alive, backend dead
  • http://search.mathweb.org/zbl/ -- frontend alive, backend dead
• https://oeissearch.mathweb.org/
  • proxies to http://ash.eecs.jacobs-university.de:9999/ -- which is dead
• http://opal.eecs.jacobs-university.de:52839/
  • backend for some instance

Servers:

• ash
  • oeissearch.mathweb.org DOMAIN
  • tema-search:gap -- DOCKER -- dead
  • tema-search:oeis -- DOCKER -- dead
• opal
  • search.mathweb.org DOMAIN
  • schema backend (localhost:11006) -- no DOCKER -- dead
  • tema & zbl backend (localhost:9010) -- no DOCKER -- dead
  • temaV2 backend (localhost:9090) -- no DOCKER -- alive
  • sentido backend (localhost:9001) -- no DOCKER -- dead
  • another unknown backend -- configured in apache, but appears dead
• jupiter
  • localhost:1005 -- unknown backend -- alive
  • has a docker instance, but appears dead
• code4fun.de
  • xl backend (104.28.12.84:9002) -- ??? -- dead

I don't really want to discuss exact server specs on a public github issue.

[kohlhase]

Thanks a lot for the list. I am not aware of more instance, and it shows we really really really need to come up with a maintainable setup and consolidate.

[kohlhase]

I also noticed that the content at http://search.mathweb.org is out of date, and I have no idea how to change it. I guess I probably have to log into opal? This page should probably be somehwhere on GitHub. Probably best to move it to the front page of a MWS wiki (which we had wanted to have for a while).

[kohlhase]

When I think about the URL scheme, I think I like the one we have already started best:

• http://search.mathweb.org for the landing page --> points to the MWS wiki
• http://search.mathweb.org/XXX for the XXX service. We should really just consolidate the servers and move the landing page to github in some way.

[kohlhase]

And then we should make sure that we have a watchdog that makes sure that all the indexes are kept running (and call for help when something goes wrong. And then we document all of this, so that when the next student comes to adopt MWS, we know where things are and what to tell him/her

[a-hambasan]

@a-hambasan Is it possible to run instances only listening to localhost:9999 (and not 0.0.0.0:9999)? If not, this should be implemented.

No, you can also run instances listening to 0.0.0.0:9999

[kohlhase]

I think you misread the query, Tom wants localhost:9999 instead of 0.0.0.0:9999

Michael

On 23.04.17 15:47, Alexandru Hambasan wrote:

@a-hambasan <https://github.com/a-hambasan> Is it possible to run
instances only listening to localhost:9999 (and not 0.0.0.0:9999)?
If not, this should be implemented.

No, you can also run instances listening to 0.0.0.0:9999

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KWARC/mws/issues/101#issuecomment-296444501, or mute the thread https://github.com/notifications/unsubscribe-auth/AD2boiwBJlkL3Pl1c2DKqK2RqBhYpihiks5ry1ZagaJpZM4Ia1Ud.

[a-hambasan]

Ah, sorry for that. Yes, you can also run instances listening to localhost:port. However, there might be some problems if the demo is running within a container (i.e. using docker, panamax or similar). But generally speaking, yes, you can have instances listening to localhost:9999.

[tkw1536]

I would be very much in favour of moving instances as much as possible into docker containers (with appropriate data volumes). This would make it very easy to move them around in the future.

I believe in the docker container it does not matter if it is localhost:9999 or 0.0.0.0:9999, the portforwarding mechanisms should be able to take care of that.

[a-hambasan]

It matters, because you want to listen to all available network interfaces if you are running the demo within the container, not only to the container's interface (that is different from the host interface).