I just went through the Getting Started document to get Shinyproxy up and running. The only bit of information which was not clear was the Docker configuration and I followed the instructions on Docker which said:
sudo mkdir /etc/systemd/system/docker.service.d
sudo vi /etc/systemd/system/docker.service.d/docker.conf →
Hi Carlos, Thanks for your message and for providing details on how to configure docker on RHEL7. We’ll update the docs based on this! Regarding your question: did you restart the docker daemon successfully after updating the configuration? Were you able to pull the openanalytics/shinyproxy-demo image and / or to run it independently from ShinyProxy (just using docker run)? Did you start ShinyProxy java -jar shinyproxy-0.0.1-SNAPSHOT.jar
successfully? Do you know whether the firewall on the RHEL machine allows for traffic on port 8080? When you navigate to 8080 on the machine do you get to see anything at all (error message within ShinyProxy) or can’t you connect at all? To be sure: are you using Java 8 to run ShinyProxy?
I’ve restarted everything succesfully: docker and java. I docker run the shinyproxy-demo without any trouble. But, when I navigate to the port 8080 I fail to connect at all. I get a time out error. Maybe that port does not allow connections but it would be strange …
Can Shinyproxy and Shiny Server run on the same machine at the same time? Maybe that is part of the problem …
In any case, this is the information you wanted after I started docker, java and docker run the demo app:
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7367b1cb92dd openanalytics/shinyproxy-demo “R '-e shinyproxy::ru” 13 minutes ago Up 13 minutes 3838/tcp distracted_mccarthy
it is not needed to run any docker commands prior to starting ShinyProxy
once you start ShinyProxy no docker containers will be launched, they are only launched when a user clicks on an application link (e.g. the 01_hello app or 06_tabsets app)
Can you maybe post the output of
java -jar shinyproxy-0.0.1.jar
when you run it on the console and then try to connect to see whether there is any output related to connecting?
Regarding iptables, I don’t see anything in your OUTPUT table and I think you’d need both
# iptables -A INPUT -i enp2s0f0 -p tcp --dport 8080 -m state --state NEW,ESTABLISHED -j ACCEPT
# iptables -A OUTPUT -o enp2s0f0 -p tcp --sport 8080 -m state --state ESTABLISHED -j ACCEPT
(enp2s0f0 being your interface name). Maybe you can try to flush iptables using
After running your iptables commands, I’m now able to connect to port 8080. It asks me for a username and password and it does not take my normal login credentials so I’m guessing I need to look at the shiny proxy configuration. But, we are making progress
After rereading the information on the webpage I was able to get in using the tesla user. When I click on either of the apps I get the following error:
Message: Failed to start container:
org.apache.http.conn.HttpHostConnectException: Connect to localhost:2375
[localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection
refused
Cool! If you did not change anything to the application.yml file, you should be able to log in with user name “tesla” and password “password”. For more information have a look at the configuration page http://www.shinyproxy.io/configuration/
Under the Apps header you will see there are different LDAP groups (scientists and mathematicians); scientists (e.g. tesla) have access to both example Shiny apps and mathematicians (e.g. gauss) only to the 01_hello app.
Just wanted to let you know that we released version 0.0.2 yesterday and that it offers much more flexible LDAP configuration. In the mean time I documented how to authenticate against a standard IPA instance here since IPA is RHEL’s default.
System info: Red Hat Enterprise Linux Server release 7.2 (Maipo)
Kernel: 3.10.0-327.36.3.el7.x86_64
Docker: Docker version 1.12.3, build 6b644ec
I have problems restarting the docker service after adding the line ExecStart=/usr/bin/docker daemon -H fd:// -D -H tcp://0.0.0.0:2375
This results in an error message:
Job for docker.service failed because the control process exited with error code. See “systemctl status docker.service” and “journalctl -xe” for details.
To be more exact → sudo service docker status
Redirecting to /bin/systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2016-10-31 18:45:15 UTC; 2min 17s ago
Docs: https://docs.docker.com
Process: 19647 ExecStart=/usr/bin/docker daemon -H fd:// -D -H tcp://0.0.0.0:2375 (code=exited, status=1/FAILURE)
Main PID: 19647 (code=exited, status=1/FAILURE)
Oct 31 18:45:15 c1 systemd[1]: Starting Docker Application Container Engine…
Oct 31 18:45:15 c1 docker[19647]: time=“2016-10-31T18:45:15.881843893Z” level=fatal msg=“no sockets found via sock…stemd”
Oct 31 18:45:15 c1 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Oct 31 18:45:15 c1 systemd[1]: Failed to start Docker Application Container Engine.
Oct 31 18:45:15 c1 systemd[1]: Unit docker.service entered failed state.
Oct 31 18:45:15 c1 systemd[1]: docker.service failed.
My /lib/systemd/system/docker.service file looks like:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target
[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/docker daemon -H fd:// -D -H tcp://0.0.0.0:2375
ExecReload=/bin/kill -s HUP $MAINPID
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
# Uncomment TasksMax if your systemd version supports it.
# Only systemd 226 and above support this version.
#TasksMax=infinity
TimeoutStartSec=0
# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes
# kill only the docker process, not all processes in the cgroup
KillMode=process
[Install]
WantedBy=multi-user.target