Controller does not expose SSH Port

[SvenMarcus]

When launching the meta-repository with make start the controller does not expose the port set in CONTROLLER_PORT_SSH to the host, making it unusable over the network. There is a docker-compose.override.yml in _modules/ocrd_controller that exposes this port, but it is not being loaded, since the ocrd-controller service in our base docker-compose.yml explicitly extends _modules/ocrd_controller/docker-compose.yml.

[markusweigelt]

The port is exposed to the default network so every service in that network can reach the OCR-D Controller over port 22 as default (https://github.com/slub/ocrd_controller/blob/master/Dockerfile#L58) without explizit exposing in docker-compose.yml.

Please consider following discussion to the current implementation https://github.com/slub/ocrd_kitodo/commit/02162ad26b49e5db6f8a3accece5e06b714af992#r102298026 Can the ticket be closed?

[bertsky]

When launching the meta-repository with make start the controller does not expose the port set in CONTROLLER_PORT_SSH to the host, making it unusable over the network.

That's intentional. The variable denotes where the Controller can be reached from the Manager. We did not want to expose that port when running the Controller along with the other modules (because it only needs to be reachable from Docker containers, and there's always a risk for clashes with our default ports).

There is a docker-compose.override.yml in _modules/ocrd_controller that exposes this port, but it is not being loaded, since the ocrd-controller service in our base docker-compose.yml explicitly extends _modules/ocrd_controller/docker-compose.yml.

That's by design: the override file is solely read when running docker compose from ocrd_controller standalone.

I don't know any better solution – short of discerning two variables.

[SvenMarcus]

So, if the manager runs on a separate machine, as will probably be the default, considering that not every institution can provide a controller, what would be the proper configuration on the controller host side to enable communication from outside the local or docker network?

[markusweigelt]

The documentation "Integration of OCR-D and Kitodo" describes how to set up an external controller instance and connect the manager. https://slub.github.io/ocrd_kitodo/setup/configure-external/#configuring-an-external-ocr-d-controller-instance

Also feel free to make suggestions if something is not understandable to improve the documentation.

[SvenMarcus]

So the idea is to use the ocrd_controller repository directly? I was under the assumption that the meta-repository was supposed to be able to launch all the possible configurations on its own.

[markusweigelt]

Yes or the native installation ocrd_all with SSH server.

IMO we should separate the native installation in the documentation and not support it, because we can't cover it with our CI.

All further services can then be started via the meta-repository. https://slub.github.io/ocrd_kitodo/setup/enable-disable-modules/ For the external Kitodo.Production it behaves the same way. Only OCR-D Manager and the OCR-D Monitor are mandatory.

[bertsky]

So the idea is to use the ocrd_controller repository directly? I was under the assumption that the meta-repository was supposed to be able to launch all the possible configurations on its own.

Not launch, interoperate with all possible configurations. If a component is to be run externally, it must be launched externally – external just means external is what I'm saying.

[bertsky]

IMO we should separate the native installation in the documentation and not support it, because we can't cover it with our CI.

I say let's keep that variant for now. We also describe how to use native (unmodified) Kitodo.Production. It's not tested, sure – but that's obvious. The purpose of the documentation is to describe how to put our stuff to use, not just what the tests cover. Also, that question frequently came up.

In the future, we'll become somewhat independent of the actual ocrd_all installation I guess.

[markusweigelt]

No need for a fix. If this issue is still present, please reopen.