Yubico Forum

I have two instances running and synchronization works as far as I can tell; however, if either of the instance goes down (completely down, things still work if just the other instance's RADIUS service is down), the other will not validate the user. I enabled more debugging in the yubico.pl RLM perl script and the result says that the OTP has been replayed. As soon as the other instance comes back, everything works perfectly. Near as I can tell I setup sync according to the documentation. Both instances are running 3.6.1 - one was a fresh 3.6.1 install and the other was upgraded from 3.5.3 up. Has anyone else seen this behavior or know what I can do to make sync work when there's a failure?

The answer can be found here.
viewtopic.php?f=5&t=881#p3362
I have found that I'm quite happy running the YubiRadius appliances in a group of three. While I don't need that much redundancy, I don't think the sync fully works when there are only two. That and the footprint on these machines is so low I'm not really using up too many resources.

I followed the instructions there and set

$baseParams['__YKVAL_SYNC_DEFAULT_LEVEL__'] = 0;

because I only have to servers, but it still didn't help.

Hello,

You have configured the synchronization after migration of the old instances (i.e. YRVA 3.5.3) which can not be configured with YRVA 3.6.1. If you want to synchronize YRVA 3.6.1 then all the instances of YRVA should be of YRVA 3.6.1

FYI, we do not recommend customers to use only two servers for synchronization because if one server is down all data will be centralized to the remaining server and if that server also fails then there will be data loss. If you still interested in using 2 servers for synchronization, please set the sync level to 0. We recommend you to have four servers and set the sync level to 25% to have each request sync with at least one other server. (And for three servers set the sync level to 33%).

You can set the default sync level required in the validation server(s) but the clients can also tell the servers how much sync they require per request.

For more information about the sync level, please refer the link: http://code.google.com/p/yubikey-val-server-php/

Here are the step by step instructions to set the sync level in YubiRADIUS:

1) SSH to the YubiRADIUS

2) Navigate to the location '/etc/ykval'

3) Open the ykval-config.php file

# vim ykval-config.php

4) Set the $baseParams['__YKVAL_SYNC_DEFAULT_LEVEL__'] value as per your requirement

5) Save the file

6) Restart the ykval sync service

/etc/init.d/ykval-queue restart

If you have further questions, please feel free to write to “support@yubico.com”.

Hope this helps!

Best regards,
Samir.

As I mentioned originally, both instances are running 3.6.1 - one was a fresh 3.6.1 image the other was a 3.5.3 image that was upgraded to 3.6.1 using the upgrade scripts. I also tried cloning the upgraded 3.5.3 image (as suggested in the linked post) with identical results. For our environment 3 instances won't buy us any more reliability than 2 and so I'd like to get it working with just two. As I previously mentioned I tried setting the SYNC value to 0 and that did not help.

There is no in place upgrade.
You can migrate your data from a 3.5.3 to a 3.6.0, then to a 3.6.1. You can't upgrade.
So if you did not make a new appliance, then you are still at 3.5.3.

Leggett,
Let me reiterate. Sync with two is not fully functional. Not everything syncs.
Sync with 3 is.
Use the extra 256 megs of ram, and make a third instance.

Ok, I misunderstood how the upgrade scripts worked and will keep that in mind when the next update comes out.

Independently I set up 2 completely fresh images and configured them to sync between themselves and they don't show this behavior and seem to work perfectly fine, so the answer to all of this is probably my bungling the upgrade process by doing it in place on the same machine.

ronsdavis, Not to be obtuse, but nowhere that I've read in the docs or here says that 2 will not work. It's recommend to run 3 for more availability, but in our environment it really doesn't add any more availability to run 3 other than another machine to maintain and update in the future. It's not about trying to conserve resources. If it's really required to run 3 or more, than the documentation should be updated to reflect this imperative.

Like the documentation tells you how to make it work with 2? or 3?
It doesn't. If you are expecting the documentation for this product to be complete and/or accurate, you haven't been using it much.
When syncing only two I found the OTP counters would move up, but the User-Yubikey mappings were not updated.
Not sure what else was not being updated.

In my fresh test install of 2 3.6.1 instances, the only thing I did differently (suggested by the link here) was change the __YKVAL_SYNC_DEFAULT_LEVEL__ to 0 and I'm not sure that's completely necessary or not. In my tests the mappings and counters all incremented properly including with one instance being down. When the instance was restored the mappings synced almost immediately. I still have a lot more banging on it before I'm convinced that everything is solid (I'd do this even if I was running 3 or more), but so far things are at least working and look promising. Thanks for the help and suggestions.