On Fri, Jul 31, 2015 at 02:28:36PM -0700, Michael Gebis wrote: > Michal, thank you for the quick response! > > This is a great idea, but sadly I left out a relevant detail. All of > the server machines are actually running a collection of services. My > focus is limited to a subset, which is why I forgot to mention the > other services. The stunnel instance on each machine is acting as an > encryption service for *all* of the services on these machines. > (Stunnel is very useful and thus very popular. :) > > The consequence is that if I kill st1 when my service is down, it > fixes the problem for my service, but it causes problems for the other > services on that machine. > > Michael
Well, you could dynamically update its configuration file, disabling a section for a service that is down and reenabling it when the service comes back up... Of course, this has to be done very carefully... I personally shiver a little every time somebody mentions dynamically generating a configuration file, but yes, it can be done safely and reliably. G'luck, Peter > On Fri, Jul 31, 2015 at 2:04 PM, Michal Trojnara > <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi Michael, > > > > One solution might be to run a tiny watchdog script on each of the > > server machines that would periodically test whether S1/S2/S3 is alive > > and start/stop the corresponding st1/st2/st3 service. > > > > What do you think? > > > > I can think of some other solutions, but none of them is remotely as > > simple and flexible as the one described above. > > > > Best regards, > > Mike > > > > On 31.07.2015 20:12, Michael Gebis wrote: > >> Hello. > >> > >> I have a question about a strange stunnel configuration; > >> specifically, I'm like to use 'chained' stunnel instances, and I'm > >> running into an issue. > >> > >> We have a conceptually simple setup: a client that connects to a > >> server. We use stunnel both for encryption and for the failover > >> mechanism. Here's a diagram of our simplest setup: > >> > >> /----S1 / C--st0-----S2 \ \----S3 > >> > >> We have a client that connects to stunnel. Our stunnel > >> configuration lists three connections with "prio" failover mode. So > >> usually, connections go from C thru st and onto Server 1. If S1 is > >> down, st0 fails to connect to S1 and instead tries S2, and all is > >> good. > >> > >> However, sometimes we may place an optional second instance of > >> stunnel in front of the servers. > >> > >> /----st1--S1 / C--st0-----st2--S2 \ \----st3--S3 > >> > >> > >> The failover mode of stunnel does not work so well in this > >> configuration. If S1 is down, st0's failover algorithm does not > >> kick in. Instead, st0 happily connects to st1, which is still > >> alive and running. st1 then detects S1 is down and immediately > >> closes the connection, but st0 does not care. Since the initial > >> connection was successful, it does not initiate the failover > >> algorithm. > >> > >> You may ask "why not change to round-robin mode?" The answer is > >> that S1 is a dedicated machine, and S2/S3 are underpowered backups > >> that have other primary responsibilities. We really want to direct > >> all connections to S1 and only use S2/S3 in emergencies. > >> > >> You may also ask, "Why the second layer of > >> stunnel?"--unfortunately, there are several hairy > >> implementation-specific details that make this hard to change. > >> > >> My question is: is there any stunnel configuration option that can > >> help us out? We would like the failover to work with and without > >> the second layer of stunnel. From looking at the source code, I > >> think I'm out of luck, but I figured it couldn't hurt to ask. > >> Thanks! -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: Digital signature
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
