How to access a port exposed from a docker container? - linux

$ docker container ls --format "table {{.ID}}\t{{.Names}}\t{{.Ports}}" -a
CONTAINER ID NAMES PORTS
ae87d83af7d3 hopeful_engelbart
d13e260c4dec unruffled_bouman
db2c482de210 jenkinsci 0.0.0.0:8080->8080/tcp, 50000/tcp
cd201cbd413e xyz 0.0.0.0:5000->5000/tcp
c64c32ac68b8 pqr
$ docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ae87d83af7d3 442c97a73937 "/bin/bash" 11 minutes ago Exited (0) 9 minutes ago hopeful_engelbart
d13e260c4dec 442c97a73937 "/bin/bash" 27 minutes ago Exited (0) 24 minutes ago unruffled_bouman
db2c482de210 jenkins/jenkins:lts "/sbin/tini -- /usr/…" 3 days ago Up 41 minutes 0.0.0.0:8080->8080/tcp, 50000/tcp jenkinsci
cd201cbd413e 442c97a73937 "bash" 3 days ago Up 7 minutes 0.0.0.0:5000->5000/tcp xyz
c64c32ac68b8 442c97a73937 "bash" 3 days ago Exited (0) 2 days ago pqr
Above outputs show that the port 5000 has been exposed (I hope).
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' xyz
172.17.0.3
Now when I do from the host machine:
wget -c 172.17.0.3:5000
--2019-12-30 16:26:44-- http://172.17.0.3:5000/
Connecting to 172.17.0.3:5000... failed: Connection refused.
What is the way to access that port since it is exposed and the container is running?
$ wget -c localhost:5000
--2019-12-30 16:41:57-- http://localhost:5000/
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:5000... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.
--2019-12-30 16:41:58-- (try: 2) http://localhost:5000/
Connecting to localhost (localhost)|127.0.0.1|:5000... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

First of all, check if you have an application, listening to the port inside your container. Just try to connect to it from your container:
docker exec xyz wget 127.0.0.1:5000
If it'll work then you have a problem with port exposing, otherwise, there is no web server running inside your container.
And the error you get
Read error (Connection reset by peer) in headers.
seems to point to the problem in your web server rather then connectivity issues.

I had this problem running one Quarkus application with Docker.
I found this topic on forum.dockers talking about a similar issue.
In this topic is said:
I was using flask, by default it binds to localhost & 5000, so you have to specify:
app.run(host=“0.0.0.0”)
So, in my case I guess the problem was on my application and not on Docker network.
I added this property on the Java command to start my application on my Dockerfile and everything worked fine:
-Dquarkus.http.host=0.0.0.0

Related

sftp using proxy issue: ssh_dispatch_run_fatal: Connection to UNKNOWN port 65535: Connection corrupted

Our automated script connects to third party server (using proxy), to get some files over sftp.
It usually works fine. On a random day, I got below error. What could be the root cause.?
sftp> mget TR_ACK*.txt
Bad packet length 1131376238.
ssh_dispatch_run_fatal: Connection to UNKNOWN port 65535: Connection corrupted
Connection closed
Edit: FYI- Our script runs every 5min. The above issue occured at 12:05 min. The run at 12:00 min was also failed as the server was down at 12:00. The server was just up just before the time was 12:05 minutes.

How to access administration component in API Platforms distribution 2.4.2?

I tried to set up API Platform on my local machine to explore it.
I tried to performed all the operations according to API Platform's "Getting Started" page. So I downloaded the latest offical distribution which happens to be v2.4.2 (https://github.com/api-platform/api-platform/releases/tag/v2.4.2) and I started it using Docker.
I cannot however access the administration backend at http://localhost:81 receiving "Unable to retrieve API documentation."
I searched for help at https://api-platform.com/docs/admin/getting-started/, but it describes steps that seems to be already done in the distribution
How can I enable the admin component or debug what went wrong?
Edit (2019-04-14)
$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
40a5d5213cfe quay.io/api-platform/nginx "nginx -g 'daemon of…" 45 hours ago Up 6 minutes 0.0.0.0:8080->80/tcp apiplatformdemo_api_1
d53711c0ba0c quay.io/api-platform/php "docker-entrypoint p…" 45 hours ago Up 6 minutes 9000/tcp apiplatformdemo_php_1
2d4eb8d09e3e quay.io/api-platform/client "/bin/sh -c 'yarn st…" 45 hours ago Up 6 minutes 0.0.0.0:80->3000/tcp apiplatformdemo_client_1
abe3e3b41810 quay.io/api-platform/admin "/bin/sh -c 'yarn st…" 45 hours ago Up 6 minutes 0.0.0.0:81->3000/tcp apiplatformdemo_admin_1
4596a7f81cd8 postgres:10-alpine "docker-entrypoint.s…" 45 hours ago Up 6 minutes 0.0.0.0:5432->5432/tcp apiplatformdemo_db_1
c805fc2f11c9 dunglas/mercure "./mercure" 45 hours ago Up 6 minutes 443/tcp, 0.0.0.0:1337->80/tcp apiplatformdemo_mercure_1
Edit 2 (2019-04-14)
It is worth mentioning that although the API component at http://localhost:8080 works, the HTTPS variant at https://localhost:8443 does not. (Connection refused if I try to telnet it.)
Now it turned out it escaped my notice earlier that there is a message in the JS console saying there was a failed connection to https://localhost:8443. (It says about CORS, but I think the real reason is 8443 simply refuses connection). So although I entered the HTTP variant of Admin at http://localhost:81 it tried to access the API via HTTPS. What could be the reason HTTPS doesn't work?
Edit 3 (2019-04-15)
After looking into the logs of docker compose, I see it is relevant the Varnish container failed. h2-proxy depends on it and it is h2-proxy that governs the 8443 port.
cache-proxy_1 | Error:
cache-proxy_1 | Message from VCC-compiler:
cache-proxy_1 | Expected return action name.
cache-proxy_1 | ('/usr/local/etc/varnish/default.vcl' Line 67 Pos 13)
cache-proxy_1 | return (miss);
cache-proxy_1 | ------------####--
cache-proxy_1 |
cache-proxy_1 | Running VCC-compiler failed, exited with 2
cache-proxy_1 | VCL compilation failed
apiplatform242_cache-proxy_1 exited with code 2
h2-proxy_1 | 2019/04/15 08:09:17 [emerg] 1#1: host not found in upstream "cache-proxy" in /etc/nginx/conf.d/default.conf:58
h2-proxy_1 | nginx: [emerg] host not found in upstream "cache-proxy" in /etc/nginx/conf.d/default.conf:58
apiplatform242_h2-proxy_1 exited with code 1
I have solved this error by getting API Platform by cloning the current master and not download the tar.tgz release version (2.4.2)
git clone https://github.com/api-platform/api-platform.git
docker-compose build
docker-compose up -d
Works like a charm !

DBeaver / PostgresSQL fails to connect to remote docker container

I'm trying to access a postgresql docker container through DBeaver, but I can't figure out how to make it work.
Running docker port db_1 returns:
5432/tcp -> 0.0.0.0:5432
So the port should be open to connections.
The postgresql.conf is set to
listen_addresses = '*'
Running docker inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' db_1 returns
172.19.0.2
When trying to connect to the database to either localhost / 127.0.0.1 / 172.19.0.2 / db_1 the Dbeaver log returns this:
2019-03-18 17:22:03.000 - Connect with 'jdbc:postgresql://db_1:5432/test' (postgres-jdbc-169919c23d5-77ac021a71307fee)
....
2019-03-18 17:22:14.815 - SSH INFO: SSH_MSG_SERVICE_ACCEPT received
2019-03-18 17:22:14.824 - SSH INFO: Authentications that can continue: password,keyboard-interactive
2019-03-18 17:22:14.825 - SSH INFO: Next authentication method: password
2019-03-18 17:22:18.432 - SSH INFO: Authentication succeeded (password).
2019-03-18 17:22:18.458 - Connection failed (postgres-jdbc-169919c23d5-77ac021a71307fee)
2019-03-18 17:22:18.459 - SSH INFO: Disconnecting from domain.com port 22
2019-03-18 17:22:18.461 - SSH INFO: Caught an exception, leaving main loop due to Socket closed
2019-03-18 17:22:18.514 - org.jkiss.dbeaver.model.exec.DBCConnectException: The connection attempt failed.
org.jkiss.dbeaver.model.exec.DBCConnectException: The connection attempt failed.
at org.jkiss.dbeaver.model.impl.jdbc.JDBCDataSource.openConnection(JDBCDataSource.java:179)
at org.jkiss.dbeaver.ext.postgresql.model.PostgreDataSource.openConnection(PostgreDataSource.java:363)
at org.jkiss.dbeaver.ext.postgresql.model.PostgreDataSource.initializeRemoteInstance(PostgreDataSource.java:122)
at org.jkiss.dbeaver.model.impl.jdbc.JDBCDataSource.<init>(JDBCDataSource.java:100)
at org.jkiss.dbeaver.model.impl.jdbc.JDBCDataSource.<init>(JDBCDataSource.java:89)
at org.jkiss.dbeaver.ext.postgresql.model.PostgreDataSource.<init>(PostgreDataSource.java:80)
at org.jkiss.dbeaver.ext.postgresql.PostgreDataSourceProvider.openDataSource(PostgreDataSourceProvider.java:97)
at org.jkiss.dbeaver.registry.DataSourceDescriptor.connect(DataSourceDescriptor.java:770)
at org.jkiss.dbeaver.runtime.jobs.ConnectJob.run(ConnectJob.java:70)
at org.jkiss.dbeaver.ui.dialogs.connection.ConnectionWizard$ConnectionTester.run(ConnectionWizard.java:232)
at org.jkiss.dbeaver.model.runtime.AbstractJob.run(AbstractJob.java:101)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.postgresql.util.PSQLException: The connection attempt failed.
at org.postgresql.Driver$ConnectThread.getResult(Driver.java:405)
at org.postgresql.Driver.connect(Driver.java:263)
at org.jkiss.dbeaver.model.impl.jdbc.JDBCDataSource.lambda$0(JDBCDataSource.java:148)
at org.jkiss.dbeaver.model.impl.jdbc.JDBCDataSource.openConnection(JDBCDataSource.java:157)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:140)
at org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:109)
at org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:67)
at org.postgresql.core.PGStream.receiveChar(PGStream.java:306)
at org.postgresql.core.v3.ConnectionFactoryImpl.enableSSL(ConnectionFactoryImpl.java:405)
at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:94)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:192)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195)
at org.postgresql.Driver.makeConnection(Driver.java:454)
at org.postgresql.Driver.access$100(Driver.java:57)
at org.postgresql.Driver$ConnectThread.run(Driver.java:364)
at java.lang.Thread.run(Thread.java:748)
Really clueless on how to make the connection work. The SSH tunnel obviously works, but the connection to the db fails. I have a spring boot application running in another container, and connecting that through the connection string jdbc:postgresql://db_1:5432/test works like a charm.
Any input on this? Could it be that 0.0.0.0 doesn't get mapped to the internal network somehow?
How are you exactly running your container, I suspect maybe you are missing to expose the ports? because I just tried running a postgres instance using the following command in PS:
docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d -p 5433:5432 postgres
Mapping the default postgres container port 5432 to my local 5433 port (because I have a postgres installation locally and didn't want to run into some kind of port-interferance problem) and later on created a database by accessing the docker and running some psql commands as described on this answer and then accesed the DB from DBeaver
and everything worked fine! Hope this helps.

What is etcd looking for in 127.0.0.1:4001?

I'm trying to set up a test cluster using etcd 2.3.7 installed from CentOS RPM on CentOS 7.1. On the Loader 1 I executed:
etcdctl member add loader2 http://10.11.51.231:2380
And received response which confirmed the operation completed successfully.
Similarly:
etcdctl member add loader3 http://10.11.51.231:2380
with all default settings, and here's what I see:
Loader 1 10.11.51.166
systemctl status etcd -ln1
etcd.service - Etcd Server
Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled)
Active: active (running) since Sun 2017-02-19 14:33:18 IST; 28min ago
Main PID: 19009 (etcd)
CGroup: /system.slice/etcd.service
└─19009 /usr/bin/etcd --name=default --data-dir=/var/lib/etcd/default.etcd --listen-client-urls=http://localhost:2379
Feb 19 15:02:03 loader3 etcd[19009]: cannot get the version of member a4803061db803edc (Get http://10.11.51.166:2380/version: dial tcp 10.11.51.166:2380: getsockopt: connection refused)
Tried to see cluster health:
etcdctl --debug cluster-health
Cluster-Endpoints: http://127.0.0.1:4001, http://127.0.0.1:2379
cURL Command: curl -X GET http://127.0.0.1:4001/v2/members
cURL Command: curl -X GET http://127.0.0.1:2379/v2/members
member ce2a822cea30bfca is unhealthy: got unhealthy result from http://localhost:2379
member da05b63349d818dc is unreachable: no available published client urls
cluster is unhealthy
Note how this ignores the two nodes added previously, but sends requests to random port on localhost...
Loader 2 10.11.51.174
At first this machine started OK, but after I saw there was something wrong with Loader 1, I tried adding Loader 1 as a member from this machine, and now I see the same picture on this machine too. I.e. it tries to query this 4001 port, where nobody responds. On all machines:
netstat -tupln | grep etcd
tcp 0 0 127.0.0.1:7001 0.0.0.0:* LISTEN 4507/etcd
tcp 0 0 127.0.0.1:2379 0.0.0.0:* LISTEN 4507/etcd
tcp 0 0 127.0.0.1:2380 0.0.0.0:* LISTEN 4507/etcd
Nobody listens on 4001...
Loader 3 10.11.51.231
On this loader I didn't try to add new members. So it looks like this:
etcdctl --debug cluster-health
Cluster-Endpoints: http://127.0.0.1:4001, http://127.0.0.1:2379
cURL Command: curl -X GET http://127.0.0.1:4001/v2/members
cURL Command: curl -X GET http://127.0.0.1:2379/v2/members
member ce2a822cea30bfca is healthy: got healthy result from http://localhost:2379
cluster is healthy
In other words it still sends requests to random port, but this time it isn't bothered by the fact that nobody replied...
Below is the contents of the configuration files:
cat /usr/lib/systemd/system/etcd.service
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
User=etcd
# set GOMAXPROCS to number of processors
ExecStart=/bin/bash -c "GOMAXPROCS=$(nproc) /usr/bin/etcd --name=\"${ETCD_NAME}\" --data-dir=\"${ETCD_DATA_DIR}\" --listen-client-urls=\"${ETCD_LISTEN_CLIENT_URLS}\""
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
And:
cat /etc/etcd/etcd.conf
# [member]
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
#ETCD_WAL_DIR=""
#ETCD_SNAPSHOT_COUNT="10000"
#ETCD_HEARTBEAT_INTERVAL="100"
#ETCD_ELECTION_TIMEOUT="1000"
#ETCD_LISTEN_PEER_URLS="http://localhost:2380"
ETCD_LISTEN_CLIENT_URLS="http://localhost:2379"
#ETCD_MAX_SNAPSHOTS="5"
#ETCD_MAX_WALS="5"
#ETCD_CORS=""
#
#[cluster]
#ETCD_INITIAL_ADVERTISE_PEER_URLS="http://localhost:2380"
# if you use different ETCD_NAME (e.g. test), set ETCD_INITIAL_CLUSTER value for this name, i.e. "test=http://..."
#ETCD_INITIAL_CLUSTER="default=http://localhost:2380"
#ETCD_INITIAL_CLUSTER_STATE="new"
#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"
#ETCD_DISCOVERY=""
#ETCD_DISCOVERY_SRV=""
#ETCD_DISCOVERY_FALLBACK="proxy"
#ETCD_DISCOVERY_PROXY=""
#ETCD_STRICT_RECONFIG_CHECK="false"
#
#[proxy]
#ETCD_PROXY="off"
#ETCD_PROXY_FAILURE_WAIT="5000"
#ETCD_PROXY_REFRESH_INTERVAL="30000"
#ETCD_PROXY_DIAL_TIMEOUT="1000"
#ETCD_PROXY_WRITE_TIMEOUT="5000"
#ETCD_PROXY_READ_TIMEOUT="0"
#
#[security]
#ETCD_CERT_FILE=""
#ETCD_KEY_FILE=""
#ETCD_CLIENT_CERT_AUTH="false"
#ETCD_TRUSTED_CA_FILE=""
#ETCD_PEER_CERT_FILE=""
#ETCD_PEER_KEY_FILE=""
#ETCD_PEER_CLIENT_CERT_AUTH="false"
#ETCD_PEER_TRUSTED_CA_FILE=""
#
#[logging]
#ETCD_DEBUG="false"
# examples for -log-package-levels etcdserver=WARNING,security=DEBUG
#ETCD_LOG_PACKAGE_LEVELS=""
#
#[profiling]
#ETCD_ENABLE_PPROF="false"
So... what is going on? The error messages given by etcd are the typical mindless nonsense produced by Go built-ins. The HTTP server that etcd uses is again, the Go built-in junk, that produces non-standard and absolutely worthless replies. So I cannot understand what was (if at all) misconfigured / missing.

rsnapshot on Linux fails with "returned 12 while processing"

I thought I had rsnapshot all setup properly, but after checking my logs the next day I found the following:
[05/Sep/2014:10:34:11] /usr/bin/rsnapshot daily: ERROR: /usr/bin/rsync returned 12 while processing john#192.168.0.102:/media/linuxstorage/docs/
What does return code "12" mean?
To see what was going on, I ran it manually and went off to do other things:
raspberrypi $ sudo rsnapshot daily
Well lo and hehold, it had been sitting there waiting for my password.
john#192.168.0.102's password:
Connection closed by 192.168.0.102
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]
----------------------------------------------------------------------------
rsnapshot encountered an error! The program was invoked with these options:
/usr/bin/rsnapshot daily
----------------------------------------------------------------------------
ERROR: /usr/bin/rsync returned 12 while processing bgrissom#192.168.0.102:/medi/linuxstorage/docs/
I had changed the rsnapshot user from pi to root in /etc/crontab and root was not setup the "ssh without a password" keys for the remote host. All I had to do to fix this is:
raspberrypi $ sudo bash
raspberrypi # ssh-copy-id john#192.168.0.102
The fact: return code "12" means there is something wrong with authentication to remote server.
I ran into this also and seems like this is the most common problem for getting that error:
ERROR: /usr/bin/rsync returned 12 while processing .....
Problem: rsnapshot uses rsync under the hood and can't connect because you probably never actually connected to that remote server.
Solution: You have to connect to that remote server at least once manually through terminal from that machine where rsnapshot is running
with: ssh remote_user#remote_server.domain
so that you confirm the connection and then entry can be made to known_hosts!
After that rsnapshot worked for me.

Resources