Closed lucapaganotti closed 1 year ago
Hello! I will take a look at the files you shared. Is your TDS instance publicly available by any chance?
Thank you for sending the extra info! From these log messages:
2023-08-31T09:13:08.642+0000 [ 155644][ ] WARN serverStartup: Cannot read wmsConfig.xml: 2023-08-31T09:13:08.643+0000 [ 155645][ ] WARN serverStartup: Connection timed out (Connection timed out)
it looks like the wmsConfig.xml isn't getting parsed due to a connection timeout. This is later causing null pointer exceptions when you try to use Godiva.
I do recommend that you update your wms schema as explained here, however, I don't think your errors are due to that. Otherwise I don't see anything wrong with the files you sent.
Do you have any proxies or firewalls that might be causing connection issues?
Can you test the docker quickstart just to see if that works for you? That should use the default wmsConfig.xml and a simple test catalog and some test datasets. For instance,
docker run -d -p 80:8080 unidata/thredds-docker:5.4
And then try Godiva on one of the example datasets.
Hi @tdrwenski,
I issue this command:
$ docker run -d -p 5902:8080 unidata/thredds-docker:5.4
the container goes healthy after more than 2 minutes.
I have to publish on a specific port 5902 as per specific network rule we have.
Unfortunately I'm getting the same error as with the production setup when I try to use the Godiva3 viewer. In this run I've not yet updated the wms schema as per your instructions.
So then I changed the DOCTYPE of wmsConfig.xml file I use in the production run so to have this line:
<!DOCTYPE wmsConfig SYSTEM "https://schemas.unidata.ucar.edu/thredds/dtd/ncwms/wmsConfig.dtd">
I run the production environement again but I got the same error in the serverStartup.log
file complaining the wmsConfig.xml
could not be loaded because of a timeout error.
To answer to your question:
Yes we have firewalls and we are working behind a http/https proxy.
The box where the thredds container is running has these environment variables defined:
declare -x http_proxy="http://usr:pwd@a.b.c.d:pppp"
declare -x https_proxy="http://usr:pwd@a.b.c.d:pppp"
so I tried changing the compose.env
file for the thredds container adding these two environment variables:
## proxy vars
http_proxy="http://usr:pwd@a.b.c.d:pppp"
https_proxy="http://usr:pwd@a.b.c.d:pppp"
and then run the container again:
after more than 12 minutes the container is still unhealthy ...
was this the correct way to pass proxy variables to the docker compose environment?
Thank you for any answer.
Have a nice day.
Hi Hailey, unfortunately the current server is not publicly available, may be when we will be able to run something significative there will be a public server. For the time being our server is only for internal usage.
Have a nice day.
-- softech s.r.l. email: -- @. -- @. -- https://github.com/lucapaganotti -- sourceforge email: -- @.*** -- skype name: luca.paganotti [image: http://it.linkedin.com/in/lucapaganotti] http://it.linkedin.com/in/lucapaganotti
-- Mistakes are portals of discovery - JAAJ
On Thu, Aug 31, 2023 at 8:00 PM haileyajohnson @.***> wrote:
Hello! I will take a look at the files you shared. Is your TDS instance publicly available by any chance?
— Reply to this email directly, view it on GitHub https://github.com/Unidata/tds/issues/412#issuecomment-1701518510, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOYWHOXW5SGHA6VZQO42MLXYDGMNANCNFSM6AAAAAA4FZ3444 . You are receiving this because you authored the thread.Message ID: @.***>
Hi all,
I think that I may got some the reasons why thredds is behaving this way.
First of all I think that our docker environment has some issues per se. Attaching to the running thredds container I was not able to reach the outside network, a simple curl towards google.com server went in timeout.
So I defined in the docker-compose.yml
the two environment variables http_proxy
and https_proxy
with suitable values and so I got external connectivity. An I also defined suitable dns in docker-compose.yml
file.
Then curling towards the unidata servers that expose the wmsConfig.dtd gave me errors about unsecure certificates and I had to run curl with the -k switch in order to download locally the wmsConfig.dtd
file.
I then changed my wmsConfig.xml file to point to the local dtd file instead of that on the unidata servers.
I finally mounted the two files (wmsConfig.dtd
and wmsConfig.xml
) one by one in my docker compose yaml file after understanding that the wmsConfig.xml file has to be seen by the container inside the /usr/local/tomcat folder. My mount points were somewhere else.
I finally got my example map as this:
Anyway after several minutes I'm still seeing the container as unhealthy
after a docker ps -a
command.
Can you please explain why? I'm reaching the server and the file I have in the catalog but the container is anyway not healthy.
I think that the timeout was caused by tds not reaching unidata server to get the .dtd file and then wmsConfig.xml read went in error. A possible further cause of this behaviour could be also SSL related as curl needed to get the .dtd file using the -k switch. I do not know if I can reach the same results with some suitable thredds configuration files setup. For the time being I'm able to continue my tests.
Thank you all, have a nice day.
Hi, thanks for the extra info and all the tests you performed! Glad to hear you have made some progress!
Glad you found a workaround for the schema issue. There was another maybe similar issue a while back that was also resolved using the same method of using a local schema for the wmsConfig.
About the health check, the default health check is in our Dockerfile:
HEALTHCHECK --interval=10s --timeout=3s \
CMD curl --fail 'http://localhost:8080/thredds/catalog.html' || exit 1
Maybe this could be failing due to your proxy set up. You could try to entering the running container and curling the endpoint above and seeing what error code it returns. If this is indeed the issue, one solution would be to create your own Dockerfile that inherits FROM unidata/thredds-docker:5.4
and overrides the HEALTHCHECK
with a health check that has the correct endpoint. We could also consider making the health check in our thredds-docker parameterizable if this would be useful.
Let us know if you have other questions!
Hi @tdrwenski,
I forgot to define in my docker-compose also the no_proxy environment variable. Letting it to be:
no_proxy=localhost,.my.local.domain,127.0.0.11,127.0.0.1
solved the issue of the container health, no need to change the Dockerfile. Also now the starting of the thredds server is much faster then before.
As to me this issue can be closed. Thank you all for your help.
I will need, starting from the next week, some hints on how to customize the thredds server web interface, for example on how to have a different map provider and so on. I saw that there are some .css files that I can modify. Are the possible customizations described in thredds documentation?
Thank you again, have a nice day.
Glad to hear that!
We have some info here about customizing the TDS with css. Here is some info about OGC/ISO services and for instance the godiva3 viewer that comes with TDS. If that doesn't answer your questions feel free to contact us again!
Providing:
the version of the software with which you are encountering an issue thredds data server 5.4 in a docker environment
environmental information (i.e. Operating System, compiler info, java version, python version, etc.)
a description of the issue with the steps needed to reproduce it I've already opened an issue on unidata/thredds-docker and I was suggested via email to open the same issue here from Tara Drwenski
I'm getting these kind of exceptions everytime I try to use the preview tab and go to the Godiva3 viewer.
I was also asked to provide my wmsConfig.xml file, my catalog.xml file and the .nc files I'm using. Find the two plain files below and attached the .nc files I'm using compressed in a .tar.gz.
wmsConfig.xml
catalog.xml
I've also checked the tomcat serverStartup.log file and found this warnings (I've added *** wrapping them):
saying basicly that wmsConfig.xml is not found, so maybe I'm making mistakes in my docker volume binding paths, but the wmsConfig.xml file is in the same directory as the threddsConfig.xml one, the latter being correctly read. Am I missing something?
I change wmsConfig.xml permissions to 777 getting the same error, I then run my wmsConfig.xml through a XML validator (https://www.w3schools.com/xml/xml_validator.asp) that says me I've no syntax errors.
nc.tar.gz
Then later I checked also the catalina log file getting these warnings:
Thank you for any answer, have a nice day.