Not the 0.0.0.0, sometimes localhost doesn’t want to work with docker.
I meant NOTE.
Hi Deon,
Yesterday I had to leave just as your message came in, so I couldn’t check anything.
You are brilliant, absolutely brilliant. Suddenly I see output on localhost:80.
I was always looking on port 8042. So docker IS working.
Now I can continue on, knowing one more fact which I didn’t understand.
I would like to ask your opinion on the above point.
There is a positive point about explicitly using port 8042 - then you know you mean to talk just Orthanc, not to something random on default port 80. Then would I use --publish=8042:8042, or just drop the publish command?
Now I can pick up on what I was doing before I was stopped dead in my tracks.
I did in fact manage to learn a lot with all the effort.
Thanks,
Ilan
Hi Iilan
Yes, the first port is the one that gets published to the host machine, the second is the one orthanc is listening on. So I would keep the publish command.
So: 80:8042
80 = Host machine
8042 = Docker container port
It is important to note that the publish command does not make orthanc listen on 8042, that is the orthanc config, but that the publish command says to expose 8042 on port 80 on host.
Now, if you publish on the host machine to 8042, and want to access externally, you must make sure that the external port 8042 is actually open, otherwise you will only be able to do it on localhost.
HI Deon,
I will take your advice and use port 80 and port 104 for DICOM.
I would like to pick your brain just a bit more.
// “RemoteAccessAllowed”: true,
I had trouble with this command using docker-compose up --build (without -d).
So the last time around I left it commented out.
To my TOTAL AMAZEMENT I could access my laptop using my desktop through the LAN.
(and of course I have the user name, password in effect as well)..
I don't know what the default is but I sort of guessed it would be false.
Is there any way to know what the default actually is?
If it is true, all makes sense, but if it is false I don't know how the LAN access could work.
I managed to break my desktop version of Orthanc docker, but now I should be able to fix it with the proper ports of 80, 104. Previously everything was hocus-pocus and so long as I didn't touch it, everything worked.
Meanwhile a couple of DICOM bugs came in for my viewer, so I'll need to look at them.
Thanks again for all your help,
Ilan
This page shows all default values for all configuration: https://osimis.atlassian.net/wiki/spaces/OKB/pages/26738689/How+to+use+osimis+orthanc+Docker+images#Howtouseosimis/orthancDockerimages?-HTTP
This is unrelated to Orthanc; it is contained by the container runtime
and it is the job of that runtime to do the relevant port forwarding.
With Docker, you can specify the network interface address to bind the
forwarder (in addition to the published port).
$ docker container run --detach --publish=80:8042
docker.io/osimis/orthanc:latest
a0e6e6e98d0c3b6e9052b8ef3b51ad1a1c45ea779463a93f5938479c648fc970
$ echo $DOCKER_HOST
sandbox.local:2375
$ http GET sandbox.local/system
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 168
Content-Type: application/json; charset=utf-8
{
"ApiVersion": "1.0",
"DatabaseBackendPlugin": null,
"DatabaseVersion": 6,
"DicomAet": "ORTHANC",
"DicomPort": 4242,
"HttpPort": 8042,
"Name": "",
"PluginsEnabled": true,
"StorageAreaPlugin": null,
"Version": "1.3.2"
}
$ docker container rm --force
a0e6e6e98d0c3b6e9052b8ef3b51ad1a1c45ea779463a93f5938479c648fc970
a0e6e6e98d0c3b6e9052b8ef3b51ad1a1c45ea779463a93f5938479c648fc970
$ docker container run --detach --publish=127.0.0.1:80:8042
docker.io/osimis/orthanc:latest
7a1f99ea92b56420da93093c53c97216731b8171f5cd8c4cc912ccdb3aa0972c
$ http GET sandbox.local/system
http: error: ConnectionError: HTTPConnectionPool(host='sandbox.local',
port=80): Max retries exceeded with url: /system (Caused by
NewConnectionError('<requests.packages.urllib3.connection.HTTPConnectio
n object at 0x7f2262d462e8>: Failed to establish a new connection:
[Errno 113] No route to host',)) while doing GET request to URL: http:/
/sandbox.local/system
$ ssh -t sandbox http GET 127.0.0.1/system
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 168
Content-Type: application/json; charset=utf-8
{
"ApiVersion": "1.0",
"DatabaseBackendPlugin": null,
"DatabaseVersion": 6,
"DicomAet": "ORTHANC",
"DicomPort": 4242,
"HttpPort": 8042,
"Name": "",
"PluginsEnabled": true,
"StorageAreaPlugin": null,
"Version": "1.3.2"
}
Notice the extra prefix in the --publish option. The above demonstrates
that specifying the address of the loopback network interface restricts
access to the local host (sandbox.local) as you seem to expect.
Disabling this will not do what you expect (at least in the context of
this discussion). As I alluded to in another post on this thread, this
Orthanc setting merely configures it to deny requests from anything but
127.0.0.1. In a virtual network such as the Docker bridge networks as
used by default by the Docker container runtime and docker-compose,
this means nothing can access the Orthanc server (except processes you
spawn using `docker container exec`).
This setting is mostly for services running in host networking mode, it
can be safely ignored in 99% of normal operational scenarios.
Sidenote: The name of the setting itself is also misleading (my bad) as
Orthanc doesn't actually allow binding its listening socket on specific
network interface addresses (contrary to what I said in my previous
message). This is a peer socket address check performed on every
request. The next version of the Osimis Orthanc Bundle (likely 18.6)
will contain clarifications.
https://bitbucket.org/osimis/orthanc-builder/pull-requests/40
I would like to thank all who helped me. When I started it was all hocus-pocus.
THE most important feature of orthanc on docker is the ability to handle compressed DICOM files and pass them to the client as uncompressed.
ImageJ can’t read compressed DICOM files and docker running Orthanc solves the problem.
I want one Orthanc server which many clients can access, so having the server handle only 127.0.0.1 means it is useless.
Fortunately Deon pointed out that remote access is enabled by default, i.e. problem solved.
Thanks to all the help, I now have control. Just for testing purposes I have one server setup on my desktop and another on my laptop and each can push or pull studies from each other. The remote access works in fact.