I have tried the workaround suggested on the Tutor tutorial/installation site with no success (I do not know how to deactivate/reverse now the configuration set with tutor config save --set ENABLE_WEB_PROXY=false --set CADDY_HTTP_PORT=127.0.0.1:81 any ideas?) with no success.
Is there a solution on installing tutor behind a proxy? Do I have to edit another config file to set the proxy server to that that has access to the internet and so for the installation to complete successfully? For example in order to install the tutor package with pip I had to manually export the proxy servers as export http_proxy=http://internet.mycompany.eu:8080 before running the pip command.
Hi @markman8
The ENABLE_WEB_PROXY variable you mentioned specifically relates to the Caddy container which is actually a reverse proxy that handles connection to all the backend services, basically it catches the URL you requested like lms.domain.tld and then fetches the data from the backend service.
It sounds to me like the issue that you’re having relates to the corporate proxy that controls how your devices connect to the internet access. In this case you probably need to configure the Docker Daemon to pass the traffic through your proxy, this documentation is probably most applicable to you:
The tutor installation has been launched with sudo privileges. The proxy settings have been set for docker but it seems that the script cannot execute the docker compose -f /root/.local/share/tutor/env/local/docker-compose.yml -f /root/.local/share/tutor/env/local/docker-compose.prod.yml --project-name tutor_local up --remove-orphans -d
Is it a privilege or again I have stood onto the proxy problem?
overall it sounds to me like a proxy/config issue.
Did you set BOTH the http_proxy and https_proxy? if not then I think this may be required.
it might also be worthwhile to get your network admin to monitor the proxy logs to see if anything stands out as being blocked at the proxy. does your proxy require authentication as well or is it transparent? auth might need you to change the http(s)_proxy value something more like http://user:pass@proxyhost:port
I see you’re running it as root, this is normally discouraged although it can work. Not that i suspect this is your problem, but it is best practice to avoid using the root user for anything other than initial setup of your base system and dependencies.
by the way, are you running this on a dedicated/headless linux server, or are you using docker desktop on your windows desktop/laptop? (just a matter of curiosity, not sure how/if it might relate to your issue)
well I deleted the initial tutor installation on root via pip uninstall and installed it in a venv in the normal user dir. Thank you for mentioning that
I did give privileges to that same user for docker and tried to run docker run hello-world only to get the following:
which is interesting since it matches the previous o/p I posted. Yes I suppose I have an issue with the proxy. The process I followed for setting the docker with proxy is described here
I will look into it on Monday. Thanks for the support
The installation is taking part on an OpenStack VM in a company’s machines behind a proxy server.
Also note that since I have deleted the root privileges installation instance of Tutor, and installed another instance via venv, I can only access tutor commands through that virtual environment with local privileges… as it is not mentioned in the documentation I suppose that this is normal operation, right?
That does sound about right, there are post-installation requirements for Docker that affect it’s privileges but I’m going to make an assumption yours is configured properly if you’ve gotten this far.
In my opinion the issue likely relates to the proxy itself, possibly that its doing TLS/SSL inspection which might break the certificate chain, or perhaps its blocking/rewriting some URLs, sometimes proxies are known to break IPv6 resolution as well. There’s many things it could be, but unfortunately these fall outside the scope of Tutor/OpenEdX so our ability to assist here may be limited. If your corporate IT policies allow it then maybe your network admin can whitelist your host on the proxy server to allow a bypass (even if just temporary for troubleshooting).
