Interface: 127.0.0.1, port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0
Interface: 0.0.0.0, port: 5671, protocol: amqp/ssl, purpose: AMQP 0-9-1 and AMQP 1.0 over TLS
$ curl https://localhost:5671 -k
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to localhost:5671
Process <0.993.0> with 0 neighbours crashed with reason: no function clause matching tls_handshake_1_3:
virtualenv
in the Gravity config which should ensure that it is explicitly prepended to the commands
welcome_url
. I have a custom HTML placed in galaxy_server_dir
/static/welcome.html and I configured the same in galaxy.yml. I am serving galaxy with a prefix cos
and using Nginx as reverse proxy. Currently I am testing the setup locally inside a podman container with self signed certificates. When I access the welcome page at https://localhost:8443/cos
, nginx is redirecting https://localhost:8443/cos/welcome
to http://localhost:8443/cos/static/welcome.html
. Notice the change of scheme from HTTPS to HTTP. Does anyone have any idea why is it changing the scheme? I am attaching a screenshot with browser network data. Cheers
Thanks Jennifer Hillman-Jackson , I definitely will need help with "galaxy gunicorn can't connect to socket file". The socket is up and listening, but gunicorn is unable to connect: $ sudo systemctl status gunicorn-galaxy.socket
● gunicorn-galaxy.socket - gunicorn socket for galaxy
Loaded: loaded (/etc/systemd/system/gunicorn-galaxy.socket; enabled; vendor preset: enabled)
Active: active (listening) since Mon 2022-10-17 20:55:47 UTC; 51min ago
Triggers: ● gunicorn-galaxy.service
Listen: /run/gunicorn-galaxy.sock (Stream)
CGroup: /system.slice/gunicorn-galaxy.socket
Oct 17 20:55:47 ip-10-0-1-180 systemd[1]: Listening on gunicorn socket for galaxy.
These are the few things I've tried to get rid of "Can't connect to /run/gunicorn-galaxy.sock" file error:
change ownership of gunicorn-galaxy.sock to galaxy:galaxy => FAIL
app.job_config.get_destination("rnastar")
), modify it locally, then execute my job with the modified JobDestination. So far, I've worked out that return 'rnastar'
sends it to an existing job destination, and return JobDestination(id="rnastar_mod", runner="local")
sends it to a new job destination, but none of the parameters I need are there (unless I build the whole thing from scratch).id
or params
) then execute my job using this modified JobDestination?external_chown_script.py
in cluster jobs. So, galaxy user (the user that is running Galaxy process) will give the ownership of the directory created for the job to the real user, run the job and once the job finishes, galaxy user will take back the ownership of the directory. Is it done to give the real user permissions to create files in the directory? If I have all the real users that use Galaxy in one group, say galaxyusers, and if I set the group ownership of jobs directory to this galaxyusers group with rw
permissions, the real users will be able to write to this directory without any chown
operation. At the same time galaxy user would be able to delete the folder once it finishes the job. Would this approach work? What I am not sure is does Galaxy moves any files to elsewhere once the job finishes before deleting the job directory? Thanks!!
I'm exploring the cli and python lessons in GTN and none of the notebook downloads I've tried want to open in JupyterLab running interactively on usegalaxy.eu - complain of JSON format error, anyone else had this problem?