We are implementing a 3-node openstack cloud using glusterfs for storage solution. 3 nodes : controller compute and network are peers in gluster. We need to add another compute node as a peer in gluster but it is showing the following error :
[root#newcompute2 ~]# gluster peer probe 192.168.10.3
peer probe: failed: Probe returned with Transport endpoint is not connected
where 192.168.10.3 is the IP of controller node. Logs are also showing the same error.
Please suggest what may be the reason for this and the required solution.
This indicate that their is no port open for proper communication Node1 and Node2 host.
For that you need to fire these commands on servers
1) firewall-cmd --zone=public --add-port=24007-24008/tcp --permanent
2) firewall-cmd --zone=public --add-port=24009/tcp --permanent
3) firewall-cmd --zone=public --add-service=nfs --add-service=samba --add-service=samba-client --permanent
4) firewall-cmd --zone=public --add-port=111/tcp --add-port=139/tcp --add-port=445/tcp --add-port=965/tcp --add-port=2049/tcp --add-port=38465-38469/tcp --add-port=631/tcp --add-port=111/udp --add-port=963/udp --add-port=49152-49251/tcp --permanent
5) firewall-cmd --reload
Then try again
command => gluster peer probe x.y.z.n (IP)
peer probe: success.
Please check and revert if any other query.
You must be sure that glusterd service has been started on the probed node. you can use the following command to start the glusterd service:
sudo service glusterd start
or you can restart the service with the following command:
sudo service glusterd restart
I have had this error come up when I have GlusterFS configured to use SSL and there is a problem with loading the certificates as well (expired cert, etc.) You can check this by removing the file: /var/lib/glusterd/secure-access. If this file does not exist, then you probably do not have SSL configured and need to look for the issue elsewhere.
I know its very late but I too got stuck with this problem and somehow solved it. So for others facing this issue, one reason could be that once the cluster is formed new nodes can be added only from one of the trusted nodes.
The quick start doc very clearly says
Note: Once this pool has been established, only trusted members may probe new servers into the pool. A new server cannot probe the pool, it must be probed from the pool.
for example:
node-1 and node-2: part of the trusted cluster group
node-3: needs to be added to this cluster
then from either node-1 or node-2 write
sudo gluster peer probe <node-3>
This is because of firewall issue.
peer probe: failed: Probe returned with Transport endpoint is not connected
You need to run the following command in all of your peers.
systemctl stop firewalld
iptables -I INPUT -p all -s 192.168.10.3 -j ACCEPT
(accpet rom one and the second
it works on my machines :)
it is on instruction -> http://gluster.readthedocs.org/en/latest/Install-Guide/Configure/
From link, https://docs.gluster.org/en/latest/Quick-Start-Guide/Quickstart/
below step should solve problem.
Step 4 - Configure the firewall
The gluster processes on the nodes need to be able to communicate with each other. To simplify this setup, configure the firewall on each node to accept all traffic from the other node.
iptables -I INPUT -p all -s -j ACCEPT
Turn off firewall on both the nodes.
systemctl status firewalld.service
Related
I'm running an instance of Debian on Amazon EC2 with Node.js installed. If I run the code below:
http = require('http');
http.createServer(function (request, response){
response.writeHead(200, {'Content-Type':'text/plain'});
response.end('Hello World\n');
}).listen(80);
console.log("Running server at port 80");
I get the output below which tells me there's another process listening at port 80:
Running server at port 80
events.js:72
throw er; // Unhandled 'error' event
^
Error: listen EACCES
at errnoException (net.js:901:11)
at Server._listen2 (net.js:1020:19)
at listen (net.js:1061:10)
at Server.listen (net.js:1127:5)
at Object.<anonymous> (/home/admin/nodetests/nodetest.js:6:4)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
Now when I check to see if there's a process (as root in case anything is hidden) listening on port 80 using:
netstat -tupln
I get the below output, which tells me theres nothing listening at port 80:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1667/sshd
tcp6 0 0 :::22 :::* LISTEN 1667/sshd
I should note that the debian has port 80 open as an inbound rule if that makes a difference.
My question is: What am I doing wrong? How come I can't identify the process listening to port 80? Why is it blocked in Debian? What steps should I take to get the code running correctly?
The error code EACCES means you don't have proper permissions to run applications on that port. On Linux systems, any port below 1024 requires root access.
Instead of running on port 80 you can redirect port 80 to your application's port (>1024) using
iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000
This will work if your application is running on port 3000.
Short answer: You can allow node access to that port using:
setcap 'cap_net_bind_service=+ep' /path/to/nodejs
long answer
Edit:
May not work on new node versions
Note that if you have apache running, you can create a reverse proxy on a vhost. If your node is running on port 8080:
<VirtualHost 127.0.0.1:80>
ServerName myLocalServer
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
</VirtualHost>
Of course, add server to /etc/hosts:
127.0.0.1 myLocalServer
You will need to enable the relevant apache modules:
sudo a2enmod proxy_html
sudo a2enmod proxy_http
sudo a2enmod proxy_connect
sudo a2enmod proxy_ajp
sudo service apache2 restart
...and now you can connect to http://myLocalServer.
For those looking for a quick and easy solution for a development environment, port forwarding via ssh can be a nice alternative:
ssh -L 80:localhost:3000 yourusername#localhost -N
This forwards port 80 on localhost to port 3000 on localhost.
It needs to be run as root (privileged port). To cancel it, simply hit ctrl-c in the terminal. (You can add the -f flag to have the command run in the background, but then you need to find it again to kill it).
This solution requires you to have an ssh server running locally. It can be done quickly, but please bear in mind the security implications if you are on a shared network. You might want to apply at least some level of additional security (disable password & root login).
I personally only ever use this on my local machine. I'm not sure how it affects the processing speed of your requests if you run this on production, maybe someone has an idea. Anyway, you would need to make sure this command keeps running all the time, which introduces more headaches. For production environments, I suggest using a reverse proxy like nginx.
the hexacyanide answer is right. but is there any solution to make this work?
the answer is yes.
how?
you can use a reverse proxy for example run a nginx reverse proxy on port 80 and pass the proxy to destination ip:port that node use it.
you can set this up using docker container that makes life even easier. this is the official build of nginx in docker hub that you can pull it.
there's even more benefits in using reverse proxy that you can google it.
I have got the same error and I tried running my application using sudo and it worked for me.
without sudo
mansi#mansi:~/NodePractice$ node myFirst.js
events.js:141
throw er; // Unhandled 'error' event
^
Error: listen EACCES 0.0.0.0:80
at Object.exports._errnoException (util.js:870:11)
at exports._exceptionWithHostPort (util.js:893:20)
at Server._listen2 (net.js:1224:19)
at listen (net.js:1273:10)
at Server.listen (net.js:1369:5)
at Object.<anonymous> (/home/mansi/NodePractice/myFirst.js:6:4)
at Module._compile (module.js:410:26)
at Object.Module._extensions..js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
and with sudo
mansi#mansi:~/NodePractice$ sudo node myFirst.js
^C
The error code EACCES means you don't have proper permissions to run applications on that port.
On Linux systems, any port below 1024 requires root access.
Run the program with sudo permision.
Run sudo su command before running the program.
Following official documentation, I'm trying to deploy a Devstack on an Ubuntu 18.04 Server OS on a virtual machine. The devstack node has only one network card (ens160) connected to a network with the following CIDR 10.20.30.40/24. I need my instances accessible publicly on this network (from 10.20.30.240 to 10.20.30.250). So again the following the official floating-IP documentation I managed to form this local.conf file:
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
PUBLIC_INTERFACE=ens160
HOST_IP=10.20.30.40
FLOATING_RANGE=10.20.30.40/24
PUBLIC_NETWORK_GATEWAY=10.20.30.1
Q_FLOATING_ALLOCATION_POOL=start=10.20.30.240,end=10.20.30.250
This would lead to form a br-ex with the global IP address 10.20.30.40 and secondary IP address 10.20.30.1 (The gateway already exists on the network; isn't PUBLIC_NETWORK_GATEWAY parameter talking about real gateway on the network?)
Now, after a successful deployment, disabling ufw (according to this), creating a cirros instance with proper security group for ping and ssh and attaching a floating-IP, I only can access my instance on my devstack node, not on the whole network! Also from within the cirros instance, I cannot access the outside world (even though I can access the outside world from the devstack node)
Afterwards, watching this video, I modified the local.conf file like this:
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
FLAT_INTERFACE=ens160
HOST_IP=10.20.30.40
FLOATING_RANGE=10.20.30.240/28
After a successful deployment and instance setup, I still can access my instance only on devstack node and not from the outside! But the good news is that I can access the outside world from within the cirros instance.
Any help would be appreciated!
Update
On the second configuration, checking packets on tcpdump while pinging the instance floating-IP, I observed that the who-has broadcast packet for the floating-IP of the instance reaches the devstack node from the network router; however no is-at reply is generated and thus ICMP packets are not routed to the devstack node and the instance.
So, with some tricks I created the response and everything works fine afterwards; but certainly this isn't solution and I imagine that the devstack should work out of the box without any tweaking and probably this is because of a misconfiguration of devstack.
After 5 days of tests, research and lecture, I found this: Openstack VM is not accessible on LAN
Enter the following commands on devstack node:
echo 1 > /proc/sys/net/ipv4/conf/ens160/proxy_arp
iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
That'll do the trick!
Cheers!
I have created a virtual machine instance from snapshot taken the production server. SSH key is set. But I am unable to ssh into instance both from the putty and google cloud ssh option from browser.
I have search around and find out that the issue new release which does not set the
default IP gateway for the instance. I have set the IP gateway and restart the instance but instance still showing the same error .
I have also check the Firewall rule and port 22 traffic allowed to the instance.
All other instance in same zone are working on SSH other than instance newly created using snapshot.
After looking into the logs from the serial port ifup: failed to bring up lo
Image of the error
#Patrick answer helps me get to answer, explanatory steps
1) Serial Console.
Go to you instance detail and enable serial port.
Connect to your instance using serial port and login with the user and password
If you do not have user create one by following script as a startup-script
#!/bin/bash
sudo useradd -G sudo user
sudo echo 'user:password' | chpasswd
sudo systemctl status networking.service to check networking status
Remove the /etc/network/interfaces.d/setup file then edit your /etc/network/interfaces
auto lo
iface lo inet loopback
Restart networking service by running sudo systemctl status networking.service
2) Following startup script also work for me
#!/bin/bash
sudo dhclient eth0
It seems the issue here is that the network interface of your new instance is not coming up. You can try one of two steps:
1) try connecting through the serial console. This does not connect through port 22 or use SSH. However, if the network card is not coming up at all, this may also fail.
2) Add a startup script to the instance which will run the commands you need to configure the network card
I could connect to coreOS through Putty in Windows10.
But after changing DHCP to static IP in coreOS,
I suddenly became unable to use SSH through putty(cannot connect to coreOS through putty in Windows10).
I wonder why this happened, and how I could solve this problem.
I investigated status of ssh in coreOS. and it says inavtive.
What should I do to solve this problem?
If anyone knows please help me.
I have no clue... TT
If your sshd is inactive, you might be able to restart it. I'd be interested whether you used networkd (as documented here) when you changed from DHCP to static IP, as I think that should have been picked up automagically by CoreOS.
If you are seeing that the following command shows sshd as "inactive (dead}":
sudo systemctl status sshd
You can start sshd with:
sudo systemctl start sshd
And just in case you need it here is documentation on how to customize the ssh daemon.
Are you sure that your network unit was formatted correctly as is being accepted?
Did you restart networkd afterwards if you added the network unit manually? sudo systemctl restart systemd-networkd
Are you using cloudconfig to add the network unit? See if there is anything in the journal: journalctl _EXE=/usr/bin/coreos-cloudinit
You can also validate your cloud-config here: https://coreos.com/validate/
I am installing cloudera manager on local machine.
When trying to add new host getting following error
Installation failed. Failed to receive heartbeat from agent.
Ensure that the host's hostname is configured properly.
Ensure that port 7182 is accessible on the Cloudera Manager server
(check firewall rules).
Ensure that ports 9000 and 9001 are free on the host being added.
Check agent logs in /var/log/cloudera-scm-agent/ on the host being
added
(some of the logs can be found in the installation details).
i checked the logs,it shows like hostname differs from canonical name
So I also changed the hostname from /etc/resolv.conf
But still getting sam error
I had the same error for a simple mistake in the file /etc/hosts :
Have you checked you have DNS and reverse DNS ?
Then to check if your port is open 7182, you should do a telnet IP 7182 (replace IP by the host of Cloudera Manager Server).
If there are still some problems, maybe you have forgotten to deactivate the firewall (iptables).
Regards, K.
To resolve this issue you need to check first all port opened on your server service listing to the port no, use command: sudo netstat -lpten
Check if any thing is running on 9000 or 90001, mostly java services required for set up is running on port 9000, and cloudera-scm-agent listner also runs on port 9000. to over come this issue you can re-configure theports as well in /etc/cloudera-scm-agent/config.ini by changing as below:
--------------------------------------------------
## It should not normally be necessary to modify these.
# Port that the CM agent should listen on.
listening_port=9001
-------------------------------------------------
and then restart the cloudera-scm-agent service by command:
service cloudera-scm-agent restart
To verify this port is not activated for other sshd service check Ports opened in /etc/ssh/sshd_config.
I hope this resolution will work for others too.
Cheers,
Ankit Gupta