improve ykval sync about yubikey-val

[dainnilsson]

How about a new command, ykval-full-sync (or similar), which sends a new type of request (perhaps piggybacking on the existing 'sync' URL) causing the remote server to create queue entries for all of its known YubiKeys?

This would allow the administrator to selectively choose the best suited server out of the pool to sync against, and shouldn't cause any surprises.

EDIT: There's of course a bit of overhead using an HTTP request per YubiKey, but seeing as this is something that probably wouldn't be run very often, I think the benefit of re-using the existing queue system may outweigh this downside.

[dainnilsson]

I just discovered ykval-resync.php which basically does this, but for a single YubiKey. It has it's own list of allowed IPs in ykval-config, and as far as I know, it's not called by any of our other scripts. The only way to invoke it seems to be by manually creating and sending the request (using curl for instance) from an allowed YKVAL server.

We could extend this to optionally queue all YubiKeys instead of a specific one, as well as add a command to invoke it easier.

On a related note, I'm not sure I see the need for a configuration for allowed IPs for resync (YKRESYNC_IPS) separate from the allowed sync pool (YKVAL_ALLOWED_SYNC_POOL).

[dainnilsson]

I've made some changes based on my earlier comments:

ykval-resync.php now handles ?yk=all, queuing all active YubiKeys for synchronization.
I've added ykval-synchronize which can be called from a new server installation, to send the request to an existing servers ykval-resync.php, and I've updated the documentation with instructions under Installation.
Lastly I've updated the default ykval-config file to re-use the IPs in YKVAL_ALLOWED_SYNC_POOL for YKRESYNC_IPS, as I imagine this is most commonly desired.

[jas4711]

Great! I think a separate command is better than having the sync daemon be able to do this.

Let's test this a bit and then close this issue.