The key point being I think the use of the quay.io/bgruening/docker-jupyter-notebook:ie2 image.
Ok! Progress 
Did you set galaxy_infrastructure_url, this can be important for the commands to connect to the galaxy server.
Dont think so. Where would I set that, and what should the value be?
Ah, configuration option, right, lets see…
So, I set
galaxy_infrastructure_url: http://localhost:8000
since I see in our nginx setup:
[root@galaxy-hepp config]# cat /etc/nginx/conf.d/galaxy-gie-proxy.conf
server {
# Listen on port 443
listen 443 ssl;
(.... various ssl settings)
client_max_body_size 2G;
proxy_intercept_errors on;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
#Proxy all requests to the GIE Proxy application
location / {
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Host $host;
#proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://localhost:8000;
}
}
But in the galaxy.conf I see:
[root@galaxy-hepp config]# cat /etc/nginx/conf.d/galaxy.conf
server {
listen 443 ssl;
server_name galaxy-hepp.hpc.uio.no;
.....(various settings)
location / {
uwsgi_pass 127.0.0.1:8080;
uwsgi_param UWSGI_SCHEME $scheme;
include uwsgi_params;
}
}
Which would be the correct to use?
I read from the config doc pages that the default is http://localhost:8080
With the http://localhost:8000 the same error message occurs as the one in the screenshot above.
@hxr do you have some advice on what would be the expected galaxy_infrastructure_url based on our nginx setup?
In the tool wrapper for the interactive tool there is 
entry point port 8888 and galaxy_web_port 8080. Should I be using any of these for galaxy_infrastructure_url?
Thanks!
Maiken
Hi @maikenp sorry for the delay, too many things going on.
Infrastructure url should really be the address you access galaxy at, I see listen 443 in your nginx settings, so for example EU sets it to
galaxy_infrastructure_url: 'https://usegalaxy.eu'
Then the container will use the external address to contact galaxy’s API which is a lot more reliable than trying to figure out the internal networking path to reach galaxy (what it initially tries within the container)
Thanks a lot for getting back to me, and yes, understand completely the delay.
Ok, I understand, thanks. Will give that a try once we have our system up and going again (going through some reinstallations!)
Ok, unfortunately that did not help at all. Exact same error now using
galaxy_infrastructure_url: https://galaxy-hepp.hpc.uio.no
What else could be wrong?
Could there be some
- selinux issues?
- firewall issues?
- docker argument issues?
I have tried looking for hints in various log files, but not really finding anything of interest. So not at all sure where I should be looking.
If it is relevant: the galaxy server sends the job via slurm to a compute node, and jupterlab runs inside the docker container on this compute node.
Also not that (not sure if it is a hint or not) that in the docker container I see:
root@d8087e912320:/storage/galaxy/jobs_directory/001/1251/working/jupyter# curl https://galaxy-hepp.hpc.uio.no/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Hi again, sorry to use the ping, but we would love to get the put() and get() working @hxr
Could the issue be related to some missing docker options? We have this currently in our job_conf.xml
The container has a DEBUG option, I believe, I should have thought of that sooner. If you set that environment variable, then the get/put commands will print out additional logging information that might help you diagnose the issue.
I think you’ll need to set that in the tool xml.
Try adding something like <environment_variable name="DEBUG">True</environment_variable>
xref galaxy_ie_helpers/galaxy_ie_helpers at master · bgruening/galaxy_ie_helpers · GitHubinit.py#L12
Yes thanks, did that actually manually in the container. But where is actually this logged to? I.e. where should I be able to find the log file?
it should log inside the notebook, whenever you run the command. If not, you can try running the get command in a terminal inside jupyter
Right, I see no logging output at all in the notebook, only the exception.
In the running container I did:
root@f0557899417c:/storage/galaxy/jobs_directory/001/1252/working/jupyter# echo $DEBUG
true
In addition I manually edited the init.py :
#!/usr/bin/env python
from bioblend.galaxy import objects
from bioblend.galaxy import GalaxyInstance
from bioblend.galaxy.histories import HistoryClient
from bioblend.galaxy.datasets import DatasetClient
import subprocess
import argparse
import re
import os
from string import Template
import logging
DEBUG = os.environ.get('DEBUG', "False").lower() == 'true'
#if DEBUG:
# logging.basicConfig(level=logging.DEBUG)
#logging.getLogger("bioblend").setLevel(logging.CRITICAL)
logging.basicConfig(level=logging.DEBUG)
log = logging.getLogger()
And I have added some more log.debug messages in the code. I see no trace of the logging output in the notebook though.
This is how it looks, you see the printout of the code where I added log.debug message, but the logging message is not actually shown in the notebook:
try put -h in the terminal
1 Like