Yes, but the keyword is resolve to multiple return IP addresses. I don't think your setup is doing that. If it is, then I am wrong and there is a bug.
On Monday, January 7, 2013, Matt Wise wrote:
That's really odd because the man page states that you can use multiple connect statements.connect = address connect to a remote address
If no host is specified, the host defaults to localhost.
Multiple connect options are allowed in a single service section.
If host resolves to multiple addresses and/or if multiple connect options are specified, then the remote address is chosen using a round-robin algorithm.
However, I do think we're seeing the behavior you mentioned...
Sent from my iPadI am pretty sure stunnel uses the final connect string as the connect host. Round robin only works if dns returns multiple addresses. There was a user patch a while ago that provided a different way.
On Jan 7, 2013 12:39 PM, "Matt Wise" <matt@nextdoor.com> wrote:
I've got dozens of clients connecting with Stunnel to a group of 5 servers. Each system has a config that looks like this:
> cert = /etc/stunnel/zookeeper.pem
> key = /etc/stunnel/zookeeper.key
> CAfile = /etc/stunnel/zookeeper_ca.pem
> verify = 2
> delay = yes
> sslVersion = TLSv1
> client = yes
> setuid = stunnel4
> setgid = stunnel4
> pid = /var/lib/stunnel4/zookeeper.stunnel4.pid
> socket = l:TCP_NODELAY=1
> socket = r:TCP_NODELAY=1
> TIMEOUTconnect = 2
> session = 86400
> debug = 5
> [zookeeper]
> accept = 127.0.0.1:2182
> failover = rr
> connect = prod-zookeeper:2182
> connect = prod-zookeeper-1:2182
> connect = prod-zookeeper-2:2182
> connect = prod-zookeeper-3:2182
> connect = prod-zookeeper-4:2182
> connect = prod-zookeeper-5:2182
Essentially the first host is a load balancer, and the next 5 are the actual zookeeper hosts so that we can bypass the ELB if its giving us fits. Now what we're seeing is that almost every connection ends up on prod-zookeeper-5. Over and over and over again, our hosts pick the same system each time. We're running Stunnel 4.52:
> Clients allowed=8000
> stunnel 4.52 on i486-pc-linux-gnu platform
> Compiled/running with OpenSSL 0.9.8k 25 Mar 2009
> Threading:PTHREAD SSL:ENGINE Auth:LIBWRAP Sockets:POLL,IPv6
Any ideas what might be wrong here? Obviously we want the connections to be *roughly* random across the list of hosts... and if one of the hosts goes down, and the connection fails, we want the stunnel service to try again, and randomly pick a new host. It doesn't really seem to be doing that though.
--Matt
_______________________________________________
stunnel-users mailing list
stunnel-users@stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users