I have a very strange issue on my local development environment. I have a couple of Docker containers that run a couple of different environments, but both fronted with Apache. Both are connected to the same bridge network and one has port 80 exposed and the other port 8010. When the containers are running I can connect using telnet as follows:
telnet localhost 80
or
telnet localhost 8010
However, from the browser, nothing happens and in the end, it just times out. In the logs on the Docker contains there is nothing to show an inbound connection.
From the Docker containers shell, I can access the HTTP server using curl without issue.
I tried deleting the bridge network and adding it again but that didn't help.
I've tried turning the macOS firewall off but that doesn't help.
If I stop the docker containers and then try the above telnet command it errors with "Connection refused" as would be expected, so the telnet command is definitely connecting to the docker container.
Also, this setup has been working fine for sometime until today.
I'm lost as to what to try next and have found nothing similar Googling.
Any ideas of how to resolve this would be gratefully received.
To resolve this I did:
docker-compose rm -f
docker images --no-trunc --format '{{.ID}}' | xargs docker rmi
and then rebuilt the images / containers.
Be careful with the above as they are destructive commands.
Related
When I'm teleworking, I need to access some internal web servers. I use ssh -f -N -D 4000 someserver.mywork.com on my home computer to setup local dynamic port forwarding. Then, I configure my web browser to use localhost port 4000 as a SOCKS host, and everything works great, even with HTTPS.
The problem is that the proxy stops working every couple of days. When this happens, the ssh process prints messages like the following:
accept: Too many open files
In this scenario, I have to kill the ssh process and restart it in order to get it working again. Based on my research into this error message, I could increase the limit on the number of open files, but that doesn't seem like a permanent or an ideal solution.
I was hoping autossh might be able to monitor the connection and restart it automatically. Is that possible?
I have tried the following command:
autossh -f -M 0 -N -D 4000 someserver.mywork.com
But it didn't work. The proxy stopped working, and autossh did not restart it. Any suggestions or alternative solutions to automatically restarting my ssh proxy?
We have an application which uses SSH to copy artifact from one node to other. While creating the Docker image (Linux Centos 8 based), I have installed the Openssh server and client, when I run the image from Docker command and exec into it, I am successfully able to run the SSH command and I also see the port 22 enabled and listening ( $ lsof -i -P -n | grep LISTEN).
But if I start a POD/Container using the same image in the Kubernetes cluster, I do not see port 22 enabled and listening inside the container. Even if I try to start the sshd from inside the k8s container then it gives me below error:
Redirecting to /bin/systemctl start sshd.service Failed to get D-Bus connection: Operation not permitted.
Is there any way to start the K8s container with SSH enabled?
There are three things to consider:
Like David said in his comment:
I'd redesign your system to use a communication system that's easier
to set up, like with HTTP calls between pods.
If you put a service in front of your deployment, it is not going to relay any SSH connections. So you have to point to the pods directly, which might be pretty inconvenient.
In case you have missed that: you need to declare port 22 in your deployment template.
Please let me know if that helped.
I'm working with Docker to create AEM (Adobe Experience Manager) images on the basis of the following repository https://github.com/AdobeAtAdobe/aem_6-1_docker
I just can't figure out how to open a debug mode for AEM.
I have tried adding a port to EXPOSE EXPOSE 4502 30311 and adding a start file with the new JVM_OPTS CQ_JVM_OPTS="-debug -Xnoagent -Djava.compiler=none -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=30311,server=y,suspend=n ${CQ_JVM_OPTS}"
and I have also tried changing the START_OPTS START_OPTS="${START_OPTS} -debug 30311"
I'm not really comfortable with Docker yet so I'm not sure what I'm missing to startup the debug mode. Do I need to open a port in Docker via ENV or RUN?
You have to bind your host ports to container ports.
So, in your docker run add flag -p 4502:4502 -p 30311:30311
I have used these instructions for Running Gui Apps with Docker to create images that allow me to launch GUI based applications.
It all works flawlessly when running Docker on the same machine, but it stops working when running it on a remote host.
Locally, I can run
docker --rm --ti -e DISPLAY -e <X tmp> <image_name> xclock
And I can get xclock running on my host machine.
When connecting remotely to a host with XForwarding, I am able to run X applications that show up on my local X Server, as anyone would expect.
However if in the remote host I try to run the above docker command, it fails to connect to the DISPLAY (usually localhost:10.0)
I think the problem is that the XForwarding is setup on the localhost interface of the remote host.
So the docker host has no way to connect to DISPLAY=localhost:10.0 because that localhost means the remote host, unreachable from docker itself.
Can anyone suggest an elegant way to solve this?
Regards
Alessandro
EDIT1:
One possible way I guess is to use socat to forward the remote /tmp/.X11-unix to the local machine. This way I would not need to use port forwarding.
It also looks like openssh 6.7 will natively support unix socket forwarding.
When running X applications through SSH (ssh -X), you are not using the /tmp/.X11-unix socket to communicate with the X server. You are rather using a tunnel through SSH reached via "localhost:10.0".
In order to get this to work, you need to make sure the SSH server supports X connections to the external address by setting
X11UseLocalhost no
in /etc/ssh/sshd_config.
Then $DISPLAY inside the container should be set to the IP address of the Docker host computer on the docker interface - typically 172.17.0.1. So $DISPLAY will then be 172.17.0.1:10
You need to add the X authentication token inside the docker container with "xauth add" (see here)
If there is any firewall on the Docker host computer, you will have to open up the TCP ports related to this tunnel. Typically you will have to run something like
ufw allow from 172.17.0.0/16 to any port $TCPPORT proto tcp
if you use ufw.
Then it should work. I hope it helps. See also my other answer here https://stackoverflow.com/a/48235281/5744809 for more details.
This might just be my rookie knowledge of Docker,
but I can't get the networking to work.
I'm trying to run a Mule-server via the pr3d4t0r/mule repository.
I can run it, hot-swap applications but I can reach it.
I can run a local server without Docker, and it works flawlessly.
But not when I try it with Docker.
When I try to do a simple curl command I get "curl: (56) Recv failure: Connection reset by peer"
curl http://localhost:8090/Sven
I have tried exposing the ports via -P and separately via -p 8090:8090 but no luck.
When the docker is running it blocks the ports (I tried running Docker and the normal server at the same time but the normal one said the ports where already in use).
When I try another Image like jboss/wildfly and I use -p 8080:8080 there's no problem, it works perfectly.
The application in the mule-server will log and respond a simple "hello World", the output says that the application is deployed, but no messages or logging while I try to reach it.
Any suggestions?
In my case it was actually the app that was configured incorrectly. It had localhost as host. It should have been 0.0.0.0 without this it was acting only on localhost aka the docker container but not from outside of it.
You should not need to use -net=host.
So check if there's a configuration
In application.properties need set 0.0.0.0 ip not 127.0.0.0.
error
"curl: (56) Recv failure: Connection reset by peer"
mean that no process in docker image listening to the port. Option -p is bind of port in host system and image.
-p <port in host os to be binded to>:<port in container>
So, check your image, maybe your app in container use different port and you need
-p 8080:8090
if you have this , comment or remove it, server.address=localhost in your application.properties