I'm trying to set up a CouchDB 2.0 instance up on my CentOS 7 server.
I've got it installed and running as a systemd service and it responses with its friendly hello world message when I access it from the server using 127.0.0.1 or 0.0.0.0
$ curl 127.0.0.1:5984
{"couchdb":"Welcome","version":"2.0.0","vendor":{"name":"The Apache Software Foundation"}}
$ curl 0.0.0.0:5984
{"couchdb":"Welcome","version":"2.0.0","vendor":{"name":"The Apache Software Foundation"}}
in my local.ini file I've configed the bind_address to 0.0.0.0
[httpd]
bind_address = 0.0.0.0
My understanding was that if I had this bind address I could connect to port 5984 from any ip address open in my firewall
I'm using firewalld for my firewall and I've configured it to open port 5984
This config is confirmed by listing the configuration of the public zone:
$ sudo firewall-cmd --zone=public --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: couchdb2 dhcpv6-client http https ssh
ports: 443/tcp 5984/tcp
protocols:
masquerade: no
forward-ports:
sourceports:
icmp-blocks:
rich rules:
I've also created a service called couchdb2 at /etc/firewalld/services/couchdb2.xml with XML:
<service>
<short>couchdb2</short>
<description>CouchDB 2.0 Instance</description>
<port protocol="tcp" port="5984"/>
</service>
From what I know about firewalld I should be able to receive connection on 5984 now
but when I curl from my laptop my connection is refused:
$ curl my-server:5984 --verbose
* Rebuilt URL to: my-server:5984/
* Trying <my-ip>...
* connect to <my-ip> port 5984 failed: Connection refused
* Failed to connect to my-server port 5984: Connection refused
* Closing connection 0
When I connect to the couchdb instance locally via either 127.0.0.1 or 0.0.0.0 I can see the 200 response in my couchdb log:
$ sudo journalctl -u couchdb2
...
[notice] 2017-06-06T00:35:01.159244Z couchdb#localhost <0.3328.0> 222d655c69 0.0.0.0:5984 127.0.0.1 undefined GET / 200 ok 28
[notice] 2017-06-06T00:37:21.819298Z couchdb#localhost <0.5598.0> 2f8986d14b 127.0.0.1:5984 127.0.0.1 undefined GET / 200 ok 1
But when I curled from my laptop nothing shows up in the couchdb log for the Connection Refused error
This suggests to me that the problem may be the firewall and not CouchDB but I'm not sure about that.
Is Connection Refused always the firewall? Would I be getting some other error if this where the CouchDB instance having a problem?
To the best of my knowledge both CouchDB and firewalld are configured correctly, but its not working like I expected.
Any help would be appreciated, whether you know the problem or whether you can just help me discern if the problem is related to CouchDB or firewalld.
Related
I've set up Redis on a CentOS 8 Stream virtual machine on an ipv4 address. I've installed it, and configured it, but I cannot access it remotely, I've set:
bind 0.0.0.0
I used to have it set to this...
bind 127.0.0.1 0.0.0.0
However this meant that restarting redis would fail.
Now, whenever I check if Redis is running using the systemctl command, it's running, but when running redis-server within the box I get:
Could not create server TCP listening socket *:6379: bind: Address already in use
And I cannot access it remotely with:
redis-cli -h XXX.XXX.XXX.XXX -a mypass
What am I missing?
I just keep getting:
Could not connect to Redis at XXX.XXX.XXX.XXX:6379: Connection refused
I am using elastic cache single node shard redis 4.0 later version.
I enabled In-Transit Encryption and gave redis auth token.
I created one bastion host with stunnal using this link
https://aws.amazon.com/premiumsupport/knowledge-center/elasticache-connect-redis-node/
I am able to connect to elastic cache redis node using following way
redis-cli -h hostname -p 6379 -a mypassword
and i can do telnet also.
BUT
when I ping (expected response "PONG") on redis-cli after connection it is giving
"Error: Connection reset by peer "
I checked security group of both side.
Any idea ?
Bastion Host ubuntu 16.04 machine
As I mentioned in question, I was running the command like this:
redis-cli -h hostname -p 6379 -a mypassword
The correct way to connect into a ElastiCache cluster through stunnel should be using "localhost" as the host address,like this:
redis-cli -h localhost -p 6379 -a mypassword
There is explanation for using the localhost address:
when you create a tunnel between your bastion server and the ElastiCache host through stunnel, the program will start a service that listen to a local TCP port (6379), encapsulate the communication using the SSL protocol and transfer the data between the local server and the remote host.
you need to start the stunnel, check if the service is listening on the localhost address (127.0.0.1), and connect using the "localhost" as the destination address: "
Start stunnel. (Make sure you have installed stunnel using this link https://aws.amazon.com/premiumsupport/knowledge-center/elasticache-connect-redis-node/)
$ sudo stunnel /etc/stunnel/redis-cli.conf
Use the netstat command to confirm that the tunnels have started:
$ netstat -tulnp | grep -i stunnel
You can now use the redis-cli to connect to the encrypted Redis node using the local endpoint of the tunnel:
$redis-cli -h localhost -p 6379 -a MySecretPassword
localhost:6379>set foo "bar"
OK
localhost:6379>get foo
"bar"
Most probably ElastiCache Redis Instance is using Encryption in-transit and Encryption at-rest and by design, the Redis CLI is not compatible with the encryption.
You need to setup stunnel to connect redis cluster
https://datanextsolutions.com/blog/how-to-fix-redis-cli-error-connection-reset-by-peer/
"Error: Connection reset by peer" indicates that Redis is killing your connection without sending any response.
One possible cause is you are trying to connect to the Redis node without using SSL, as your connection will get rejected by the Redis server without a response [1]. Make sure you are connecting through the correct port in your tunnel proxy. If you are connecting directly from the bastion host, you should be using local host.
Another option is that you have incorrectly configured your stunnel to not include a version of SSL that is supported by Redis. You should double check the config file is exactly the same as the one provided in the support doc.
It that doesn't solve your problem, you can try to build the cli included in AWS open source contribution.[2] You'll need to check out the repository, follow the instructions in the readme, and then do make BUILD_SSL=yes make redis-cli.
[1] https://github.com/madolson/redis/blob/unstable/src/ssl.c#L464
[2] https://github.com/madolson/redis/blob/unstable/SSL_README.md
I have searched and I know people have asked this before, but I have been through all settings and double, triple checked everything but I can't get it to work for the life of me. I have not this before with other machines, but I don't know why this isn't working.
*note: numbers have been changed for security reasons
Here is what I have:
Client
Raspberry Pi 3 with IP: 192.168.0.133
manual port in raspberry pi 3 sshd_config file: 1502
Router:
NAT Virtual Server:
External port: 1502
Internal port: 22
IP address: 192.168.0.133
DNS(duckdns.org)
- checked to make sure public IP address points to the domain: testing2#duckdns.org
ssh command that works on client:
ssh -p 1502 client#192.168.0.133
ssh command that doesn't work
ssh -p 1502 client#testing2.duckdns.org
So I'm not sure where it's going on. here is output from ssh -v -p 1502 client#testing2.duckdns.org
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/testing/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to testing2.duckdns.org [188.45.22.61] port 1502.
debug1: connect to address 188.45.22.61 port 1502: Connection refused
ssh: connect to host testing2.duckdns.org port 1502: Connection refused
Any ideas? I really would appreciate any insights.
EDIT: To add some more clarifying information:
When I run the second command listed above, that is failing:
ssh -p 1502 client#testing2.duckdns.org
This goes out to the DNS I have setup (testing2.duckdns.org) and that DNS points to my network's public facing IP address. At that point, it hits the NAT routing rule I have setup on my router that forwards any requests from port 1502 to the internal port of 22 to the IP address of 192.168.0.133.
This is why I don't understand where it is failing, all the rules are there and the route should be open. Is there a setting on the raspberry pi (within the config file) that I'm missing?
So I figured out what was going on, and although I am still not able to connect remotely, I have solved what the original question posed.
The problem was I had changed the port on the raspberry pi (the internal port) to 1502. This meant that the route was forwarding correctly (from external of 1502 to internal of 22) but then the internal port was set to 1502, so it failed to connect.
This also explains why it would connect locally with the above command because the local port was 1502.
I still can't connect remotely because the raspberry pi is running a VPN and this is causing the SSH request to timeout, but that is a separate question.
Thanks for the help everyone!
I have following Security Group attached to AWS instance.
I installed Apache When I try to access it from browser I see This site can’t be reached
following is some useful info to debug what is issue.
root#ip-172-31-31-29:~# netstat -atn |grep :80
tcp6 0 0 :::80 :::* LISTEN
EDIT
Here is updated screenshot of the Security Group.
It looks like you're allowing IPv6 traffic. Is this what you desire? I would change your security group to allow 0.0.0.0/0 for http.
If you do desire IPv6 I would start with running curl locally and see what it tells you
curl -k localhost
From there you then should ensure IPTables is properly configured and that SELinux is properly configured.
I have an .ssh/config:
Host host01 host01.in.mynet
User costello
HostName 1.2.3.4
Port 22222
Which is working fine with plain ssh:
ssh host01
costello#host01 ~ »
But fabric is not using that config:
$ fab deploy:host=host01
[host01] Executing task 'deploy'
Fatal error: Low level socket error connecting to host host01 on port 22: Connection refused (tried 1 time)
Underlying exception:
Connection refused
Aborting.
Why is fabric not using the ssh's configuration? I would really like to avoid duplicating the configuration for fabric or, even worse, change the ssh port of my server.