After installed the ClickHouse on Ubuntu 18.04.2 in Hyper-V VM, I use clickhouse-client inside the VM to connect, it works fine.
I used the browser in Host PC to open http://127.27.16.11:8123, it shows ERR_CONNECTION_REFUSED error. Then I edit the /etc/clickhouse-server/config.xml and uncomment the 0.0.0.0 and restart the clickhouse-server. I refresh the browser and it shows OK status.
However, when I use clickhouse-client inside the VM to connect server again, it prompts Connection refused. Is there any way to enable both local and remote connection?
Also tried to enable both IPv4 and IPv6
::
0.0.0.0
ubuntu02:/$ clickhouse-client
ClickHouse client version 19.11.3.11 (official build).
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 19.11.3 revision 54423.
ubuntu02 :) quit
Bye.
ubuntu02:/$ sudo vi /etc/clickhouse-server/config.xml
[sudo] password for panco:
##uncomment
<listen_host>0.0.0.0</listen_host>
ubuntu02:/$ ping ubuntu02
PING ubuntu02 (172.27.16.11) 56(84) bytes of data.
64 bytes from ubuntu02 (172.27.16.11): icmp_seq=1 ttl=64 time=0.015 ms
64 bytes from ubuntu02 (172.27.16.11): icmp_seq=2 ttl=64 time=0.040 ms
^C
--- ubuntu02 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3039ms
rtt min/avg/max/mdev = 0.015/0.033/0.040/0.012 ms
ubuntu02:/$ sudo service clickhouse-server restart
ubuntu02:/$ clickhouse-client
ClickHouse client version 19.11.3.11 (official build).
Connecting to localhost:9000 as user default.
Code: 210. DB::NetException: Connection refused (localhost:9000)
Code: 210. DB::NetException: Connection refused (localhost:9000)
found the answer, I was too focus on those IP that I used is IPv4, indeed, Ubuntu enable IPv6 by default installation. It just simple uncomment this line
<listen_host>::</listen_host>
The problem is solved. Thanks Slesh for your kindly respond anyway.
Try This :
clickhouse-client -h 127.0.0.1
You can to specify few host to listen. Try this configuration:
<!-- Listen specified host. use :: (wildcard IPv6 address), if you want to accept connections both with IPv4 and IPv6 from everywhere. -->
<listen_host>::</listen_host>
<!-- Default values - try listen localhost on ipv4 and ipv6: -->
<listen_host>::1</listen_host>
<listen_host>127.0.0.1</listen_host>
Need to know the port of clickhouse
netstat -tulpn | grep LISTEN
And connect externally IP.
ex.
clickhouse-client -h 1.12.123.45 --port 9020 -u default --password my_strong_pass
Related
I have a brand new IBM CP 3.1.2 cluster up and running. I've deployed my workloads on it, mostly go microservices. The containers can't start and log an error because it can't access an external redis server on port 6379.
The cluster is installed with the firewall mode to false.
I have double checked that the IP, port and credentials are correct.
I have checked that the port on the distant redis server is reachable from the nodes directly. I've checked that the calico policy is in allowed mode for outbound and inbound traffic.
I also have used a throwable busybox container, and it can't telnet the distant redis server either but it can ping it.
From the nodes :
telnet REDIS_SERVER 6379
Trying REDIS_SERVER...
Connected to REDIS_SERVER.
Escape character is '^]'.
From the busybox container, inside the cluster (kubectl run -i --rm --tty busybox --image=busybox -- sh) :
telnet REDIS_SERVER 6379
ping REDIS_SERVER
64 bytes from REDIS_SERVER: seq=0 ttl=59 time=1.415 ms
64 bytes from REDIS_SERVER: seq=1 ttl=59 time=1.376 ms
64 bytes from REDIS_SERVER: seq=2 ttl=59 time=1.674 ms
64 bytes from REDIS_SERVER: seq=3 ttl=59 time=1.705 ms
Is there something that I'm missing ?
The port was blocked because of a missing istio egress policy.
Once I've added the egress policy my pods were able to communicate with the distant REDIS server.
If I understood correctly the telnet failed inside of your pod, is that correct?
You can ping it but cannot telnet?
Does it happens if you go to other pod?
Why can I not successfully connect to jetty?
I have the latest version of jetty 9.x running. I have the jetty_base folder setup and when I drop war files into the folder I see them get expanded into the /tmp folder.
lsof -i :8080
java 26488 jetty 85u IPv6 400595 0t0 TCPlocalhost.localdomain:webcache (LISTEN)
curl 'http://localhost:8080' curl: (7) Failed connect to
localhost:8080; Connection refused
curl http://127.0.0.1:8080 curl: (7) Failed connect to 127.0.0.1:8080;
Connection refused
From the below output of lsof -i:8080
java 26488 jetty 85u IPv6 400595 0t0
TCPlocalhost.localdomain:webcache (LISTEN)
It seems jetty is using ipv6 rather ipv4.
For ipv6, use ::1 as your loopback address. For ipv4, it is 127.0.0.1.
Changes you can make for localhost to work :
If you wish to set localhost to work for both ipv6 and ipv4 you can make below changes to /etc/hosts file.
127.0.0.1 localhost
# ... and below
::1 localhost ipv6-localhost ipv6-loopback
As always, you can test the connectivity using ping6 ::1 for an ipv6 ip and ping 127.0.0.1 for ipv4.
Give a try!
I am running a windows docker container on a Windows Server 2016 host, running default configuration.
When running the docker container using the command:
docker run -it microsoft/windowsservercore powershell
When I run the command:
ping <hostIPAddress>
It just says that the request times out.
I have checked that I can ping 8.8.8.8 and google.com etc... and even other machines on the same subnet. The only one I cannot ping is the host.
I have added '--dns ' to the 'docker run' command but this only allows me to ping the host machine via hostname and not IP.
Has anyone else seen this problem and have a solution?
I found a workaround (I'm not willing to call it a solution):
Windows Container Network Drivers: create a 'transparent' network:
docker network create -d transparent trans
Attach container to this network
docker run --network=trans ...
Important: Please note, that with this network, your container needs to obtain an IP Adress from the Host Subnet and it is directly exposed to it.
maybe related (this is about access the containers from the host):
According to https://github.com/Microsoft/Virtualization-Documentation/issues/253#issuecomment-217975932 (JMesser81):
This is a known limitation in our Windows NAT implementation (WinNAT) that you cannot access the external port in a static port mapping directly from the container (NAT) host.
Hoping this might help somebody.
On Windows 10 when hosting a Linux container on 0.0.0.0:5057 I was able to ping my server from my Windows host (powershell) using the IP address of the vEthernet (Default Switch) NIC found in Control Panel>All Control Panel Items>Network Connections:
In my case I have a corporate managed McAfee firewall running on my Windows host. I could not add any additional rules on the firewall, but fortunately there was a rule that allowed access from 172.16.0.0/24.
I used "docker network create -d transparent trans" and it worked as described, but I was not happy with an IP from my host network assigned to the container.
I did the following:
docker network create --driver=nat --subnet=172.16.0.0/24 br0
Added --network=br0 to my docker run command
I am facing the same issue.
My workaround is to restart docker service, afterwards it works fine. I'm still looking for a permanent solution.
root#a6c40eb25cbf:/# ping xxx.xx.xx.xxx
PING xxx.xx.xx.xxx (xxx.xx.xx.xxx): 56 data bytes
64 bytes from xxx.xx.xx.xxx: icmp_seq=0 ttl=37 time=3.541 ms
64 bytes from xxx.xx.xx.xxx: icmp_seq=1 ttl=37 time=2.643 ms
64 bytes from xxx.xx.xx.xxx: icmp_seq=2 ttl=37 time=1.857 ms
^C--- xxx.xx.xx.xxx ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
This works for me, I hope it works for you.
Currently, you must have WSL or WSL2 installed and have Virtualization enabled to run Docker on Windows.
The installation of WSL from PowerShell is with the following command.
wsl --install -d Ubuntu
Obviously you need to download and install Docker Desktop on Windows. It will be necessary to enable the WSL integration from the Docker desktop settings after installing it.
After configuring WSL and Docker Desktop, you can create/use your containers. Example:
docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
Finally you must identify the IP of WSL, you must open the Linux distribution that you installed in the first step, in our case Ubuntu, this will open your terminal and here we will execute:
ifconfig
and you will identify the ip of eth0. Example: 172.27.123.123
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.27.123.123 netmask 255.255.240.0 broadcast 172.27.127.255
inet6 fe80::215:5dff:fecf:b4 prefixlen 64 scopeid 0x20<link>
ether 00:15:5d:cf:00:b4 txqueuelen 1000 (Ethernet)
RX packets 4389 bytes 299784 (299.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4343 bytes 315643 (315.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Now you can ping from CMD in Windows to this IP.
NOTE: the connection will depend on the port of your container, example: 172.27.123.123:8080.
I have a home network with a raspberryPi and a Windows computer. I want to share files between these two via FTP. So I have downloaded, installed and configured VSFTPD on my raspberryPi. Now I can connect this server locally from rasPi but not from my Windows PC.
Below you can find some more information, command outputs, conf file etc.
****Raspberry Pi****
vsftd.conf
listen=YES
anonymous_enable=YES
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem
user_sub_token=$USER
local_root=/home/$USER/ftp
sudo service --status-all
> sudo service --status-all
[ + ] vsftpd
nmap localhost
> nmap localhost
Starting Nmap 6.00 ( http://nmap.org ) at 2015-12-16 22:55 EET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.029s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 996 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
5002/tcp open rfe
Nmap done: 1 IP address (1 host up) scanned in 4.80 seconds
ftp localhost
> ftp localhost
Connected to localhost.
220 (vsFTPd 2.3.5)
Name (localhost:pi): pi
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
****Windows****
ping 192.168.2.140
> ping 192.168.2.140
Pinging 192.168.2.140 with 32 bytes of data:
Reply from 192.168.2.140: bytes=32 time=1ms TTL=64
Reply from 192.168.2.140: bytes=32 time<1ms TTL=64
Reply from 192.168.2.140: bytes=32 time<1ms TTL=64
Reply from 192.168.2.140: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.2.140:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
ftp 192.168.2.140
> ftp 192.168.2.140
ftp: connect :Connection timed out
Thanks for help.
One possible reason why you can connect locally, but not remotely, is due to which user VSFTPD is accessing the local user account under. Is it ROOT or is it the USER ID you've logged into.
In reviewing your settings, I noted you have:
chroot_local_user=YES
write_enable=YES
local_root=/home/$USER/ftp
I would also add:
allow_writeable_chroot=YES
seccomp_sandbox=NO
And I would execute:
setsebool -P ftp_home_dir on
Should this suggestion fail, I also asked a similar question in Ask Fedora Forums. Link to Question. In this question, I posted several links to articles that discussed setting up VSFTPD. Maybe one of these will give you a hint towards what to look for.
Some of their suggestions are:
allow a global user for VSFTPD full file system access
This is a very dangerous option and breaks many security protocols VSFTPd is trying to help protect you from.
change the read write privileges on /home/$users to a-w
This change is not needed if you add "allow_writeable_chroot=YES", and set the SELinux ftp_home_dir ON.
Hope that this helps.
I have installed Postgres App on my Mac and have a database running.
I am able to connect it from the terminal by using the command psql -h localhost
Now I want to access this server from another machine which is on the same network.
When I do psql -h <hostname> -U <username> from the other machine, I get the error
psql: could not connect to server: Connection refused
Is the server running on host "my hostname" (xx.xx.xx.xxx) and accepting
TCP/IP connections on port 5432?
In the machine that runs the server I did lsof -i | grep LISTEN and I get the following result.
postgres 3196 sudarm 5u IPv6 0x1caf6120 0t0 TCP localhost:5432 (LISTEN)
postgres 3196 sudarm 6u IPv4 0x14678db0 0t0 TCP localhost:5432 (LISTEN)
postgres 3196 sudarm 7u IPv6 0x1caf6a80 0t0 TCP localhost:5432 (LISTEN)
Do I have to do anything else to connect to the server from another machine?
The error message asks the right question: is the server accepting connections on port 5432? The lsof output you provided indicates that no, it is not. PostgreSQL is listening on localhost:5432, meaning it will only accept connections from the database server itself.
Open the server's postgresql.conf, set listen_addresses = '*', and restart PostgreSQL. It will then be listening for connections over all interfaces, thus accepting connections over the network.
From here, the next problem you're likely to run into is authentication. (PostgreSQL will accept connections, but you probably haven't told it what to do once it has a connection from across the network.) Ensure the server's pg_hba.conf has an entry matching your database/user/source address combination -- something like host all all 10.0.0.0/8 md5 is probably appropriate -- and reload PostgreSQL as necessary to apply changes.
The md5 part tells PostgreSQL to attempt authentication using a password, so you will also need to set a password on the user in question if you don't have one set already. From however you normally administer your database (e.g. psql template1 on the database server), say ALTER USER whomever WITH PASSWORD 'your_new_password'.