On Fri, Aug 05, 2011 at 11:11:50PM +0300, Piavlo wrote:
> >It's not a matter of config option. You're supposed to run haproxy
> >inside a chroot. It will then not have access to the resolver.
> There are simple ways to make the resolver work inside chroot without
> making the chroot less secure.
I don't know any such simple way. If you're in a chroot, you have no
FS access so you can't use resolv.conf, nsswitch.conf, nor even load
the dynamic libs that are needed for that. The only thing you can do
then is to implement your own resolver and maintain a second config
for this one. This is not what I call a simple way.
> > I could ask the question the other direction : why try to resolve a
> >name to IP when a check fails, there is no reason why a server would
> >have its address changed without the admin being responsible for it.
> I don't agree that admin is supposed to be responsible for it directly
> at all.
So you're saying that you find it normal that a *server* changes its IP
address without the admin's consent ? I'm sorry but we'll never reach
an agreement there.
> Say backend server crashes/enters bad state - this is detected and new
> ec2 instance is automatically spawned and autoconfigured to
> replace the failed backend ec2 instance- which is optionally terminated.
> The /etc/hosts of all relevent ec2 instances is auto updated (or DNS
> with 60 seconds ttl is updated - by the way the 60 seconds ttl works
> great withing ec2). There is no admin person involved - all is done
> automatically.
That's what I'm explaining from the beginning : this *process* is totally
broken and does not fit in any way in what I'd call common practices :
- a failed server is replaced with another server with a different IP
address. It could very well have kept the same IP address. If servers
in datacenters had their IP address randomly changed upon every reboot
it would require many more men to handle them.
- you're not even shoked that something changes the /etc/hosts of all of
your servers when any server crashes. That's something I would never
accept either. Of course, the only reason for this stupidity is the
point above.
- on top of that the DNS is updated every 60 seconds. That means that
any process detecting the failure faster than the DNS updates will
act based on the old IP address and possibly never refresh it. Once
again, this is an ugly design imposed by the first point.
I'm sorry Piavlo, but I can't accept such mechanisms. They are broken
from scratch, there is no other word. A server's admin should be the
only person who decides to change the server's address. Once you decide
to let stupid process change everything below you, you can't expect
some software to guess things for you and to automagically recover from
the mess.
> >Also, in your case it would not fix the issue : resolving when the
> >server goes down will bring you the old address, and only after
> >caches expires it would bring the new one.
> If /etc/hosts is updated locally the is no need to wait for cache
> expiration.
1) /etc/hosts is out of reach in a chroot
2) it's out of question to re-read /etc/hosts before every connection.
3) if you don't recheck before every connection, you can connect to the
wrong place due to the time it takes to propagate changes.
> And if /etc/hosts is auto updated by appropriate tool - going one more
> step of restarting/reloading haproxy is not a problem at all - but this
> is what I want to avoid.
If you want to avoid this mess, simply configure your servers not to
change address with the phases of the moon.
> If instead for example i could send a command to haproxy control socket
> to re-resolve all the names (or better just specific name) configured in
> haproxy - it would be much better - as since /etc/hosts is already
> updated it would resolve to correct ip address.
It could not because it's not supposed to be present in the empty chroot.
> BTW afaiu adding/removing backends/frontends dynamically on the fly
> through some api / socket - is not something that is ever planned to be
> supported in haproxy?
At the moment it's not planned because it requires to dynamically change
limits that are set upon startup, such as the max memory and max FD number.
Maybe in the future we'll be able to start with a configurable margin to
add some servers, but that's not planned right now. Changing a server's
address by hand might be much easier to implement though, eventhough it
will obviously break some protocols (eg: RDP). But it could fit your
use case
Regards,
Willy
