search

olopez32 / ganeti

Automatically exported from code.google.com/p/ganeti
0 stars 0 forks source link

Bind the remote api on the cluster IP #171

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What software version are you running? 

# gnt-cluster --version
gnt-cluster (ganeti v2.4.2) 2.4.2
# gnt-cluster version
Software version: 2.4.2
Internode protocol: 2040000
Configuration format: 2040000
OS api version: 20
Export interface: 0

What distribution are you using?

Debian Squeeze, Ganeti built from source.

What steps will reproduce the problem?
1. Install as usual.
2. nmap -v -A -p 5080 not-cluster-ip-of-the-node

With not-cluster-ip-of-the-node being any other ip of the node not being the 
cluster ip.

What is the expected output? What do you see instead?

Port closed. Port open with an unknown SSL server responding.

What would be more logical is to bind on the ip of the cluster as it will 
anyway move with the primary role. But iustin reminded this on IRC:

iustin: our (long-term) plan was to have the rapi available on all nodes, so 
that you can force failover via RAPI too
 that might conflict… anyway, file the issue, and we'll discuss on it.

Original issue reported on code.google.com by diaere...@gmail.com on 28 Jun 2011 at 12:03

GoogleCodeExporter commented 9 years ago 
You could use iptables to block access to the RAPI port on non-cluster IP 
addresses. What you can also try is to set RAPI_ARGS="--bind 1.2.3.4" (use the 
correct IP address) in /etc/default/ganeti. I don't know if this will work in 
all cases. These are just workarounds of course.

Original comment by han...@google.com on 6 Jul 2011 at 4:51

GoogleCodeExporter commented 9 years ago 
I am sorry, I should have written that I am already using the RAPI_ARGS 
configuration variable in /etc/default/ganeti. I have set it to the cluster IP.

Maybe we could discard this issue and just put a note in the documentation. I 
like the "secure by default" approach, but this is not necessarily always the 
best way.

Original comment by diaere...@gmail.com on 7 Jul 2011 at 12:32

GoogleCodeExporter commented 9 years ago 
Hi,

Trying to see if we can fix this; where in the docs do you think this should 
be? In the installation guide, or in the admin guide?

Original comment by ius...@google.com on 23 May 2012 at 12:16

GoogleCodeExporter commented 9 years ago 
Hi iustin,

for me, I would put it into the administration part of the guide. My reasoning 
is that installation is to go to the point where "it runs" and administration 
is to explore the corner cases and the implications of the system. Putting this 
in the installation part would complicate it and may result in more errors, 
thus more support questions. Better to install then adjust. 

Thanks for considering this issue again and thanks for Ganeti, still using it, 
still really happy :)

loïc

Original comment by diaere...@gmail.com on 24 May 2012 at 12:40

GoogleCodeExporter commented 9 years ago

Original comment by ius...@google.com on 19 Jul 2012 at 2:30

GoogleCodeExporter commented 9 years ago

Original comment by ultrot...@google.com on 3 May 2013 at 9:25

GoogleCodeExporter commented 9 years ago

Original comment by ultrot...@google.com on 30 Jul 2013 at 1:52

GoogleCodeExporter commented 9 years ago 
Move non-critical bugs scheduled for 2.8 or 2.9 to 2.11, as in those versions 
only critical bug fixes will be integrated.

Original comment by thoma...@google.com on 30 Oct 2013 at 9:48