[rancid] Throttling per-host (odd situation)

[heasley]

Tue, Jun 20, 2017 at 11:06:56PM +0100, Howard Jones:
> I have a homegrown script for grabbing individual configs from a 
> multi-tenant firewall. It works in conjunction with a small hack to 
> bin/rancid and bin/control_rancid, so that I can have a "host" called 
> firewall1[TENANT1], and it knows to take the part in [] off, and use the 
> remains as a hostname, and also not smash the case of the filename.

is there a way to collect those configs from a single login?

> The upshot of this though, is that I have many connections to the same 
> device as part of a rancid run. The device has a limit on the number of 
> incoming ssh sessions, and even if it didn't I don't really want to DOS 
> it with rancid. I know I can change PAR_COUNT so that it's less than the 
> number of allowed connections, but then a complete run takes over an 
> hour (there are plenty of other devices here) instead of the 
> already-quite-long 30ish minutes with a PAR_COUNT of 10.
> 
> So - is there any convenient way to have rancid throttle connections for 
> particular devices, groups, or hostnames matching a pattern? Or is it 
> just a case of turn the timeouts up, and the retries up and let it grind 
> through? (each attempt will get connection refused until a slot is open 
> - so I suppose I'd need num_tenants/max_sessions retries, at least, 
> which itself would be dynamic.
> 
> I realise this is not at all a standard situation, but maybe someone 
> else has similar? Or, e.g. something with access via a serial console 
> server that has similar limitations?

no; multiple groups, # connections per-device per group?

> Without re-engineering the guts of rancid too much, I'm thinking about 
> something like a pool of lockfiles that clogin (or rancid before it 
> starts clogin) waits on...

you could alter that one script to remove the [] portion of the
device name and use that for a lock name.  so long as the par could
was large enough to avoid all the proc blocking on one device, ...

> Thanks in advance for any pointers...
> 
> Howard
> 
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-discuss at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss