Sharing extension scripts

Hi all,
Just thought I would put this out there… is there a place where we can share extension scripts etc?

I do firmware updates using a provision. I wanted to be able to set a limit on how many I do per day. I.e I don’t want to have to go through and set a tag on every device I want to update. The provision should run x times. Previously I have run on a schedule starting at 2:00am - but this doesn’t limit how many devices can be upgraded. (could make a smaller time window but still ugly)

I couldn’t find a way to do this in Genieacs so I made an extension script to do it, it’s also idempotent - being that the provision is just a function I leverage the fact that the timestamp remains constant to check if it’s been run before.

Check it out. I had to write it to run on node 6 / ECMA5 as I haven’t update yet (soon)

Counter Gist

Cheers,

David.

1 Like

I’ve been using gist’s to share the code to the forum.

The one problem I can foresee with your ext script is it relies on redis. I’m not a redis expert, but as I understand it redis is designed to be used as a high-speed key/value store cache. So if redis gets restarted for any reason, your counter will be reset. That may be fine in your environment, just thought I would point it out.

Out of curiosity, why do you want to limit the number of f/w upgrades per day? To limit the possibility of taking down your entire customer base in one fell swoop by a bad upgrade/config? If that is your goal, another method that might work and be easier would be to only do f/w upgrades on reboot. I do this with some CPEs when we want to trickle out upgrades, or if I know this CPE is rather finicky and has to be manually rebooted sometimes because it gets in some sort of wedged state.

Hi Dan,

Good point about the Redis counter reset. I thought about doing it with a flat file but didn’t want to go down the road of I/O race conditions and locking mechanisms. In my environment the counter being reset isn’t critical. I find firmware updates quite tricky to work with - mainly the TR069 implementation on the CPE I work with is a bit unpredictable.

I’ve thought about upgrading on BOOT but I’ve always been a bit hesistant to perform upgrades while the end user is nearby; as if they power cycle mid update - they will brick the device. Maybe this is a misconception of mine and I should revisit it.

Where are you based out of interest? If you don’t mind me asking? (I’m from New Zealand)

Cheers,

David.

Hi David!
What brand CPE are you using? We’ve been using the SmartRG’s (now owned by Adtran) with good results. I’ve only had a handful go sideways on firmware upgrade.

I thought about the flat file too, and the race conditions and locking etc etc which is precisely why I didn’t propose it :).

I’m on the opposite side of the world from you up here in Alaska, USA :).

-dan

I think it’s not often that you can find an existing script that you can reuse as is or with minor adjustments to do what you need. A script for firmware upgrade roll out is the only exception that I can think of.

Here’s how I approach this. Ditch your counters and embrace probability :slight_smile: Figure out how many devices in total need to be upgraded, and based on that calculate the probability any given device is to be upgraded during a given night. Here you can exploit the fact that in provision scripts the function Math.random() always returns the same value for a given device (random function is seeded with Device ID by default), so when and how often the device informs during the upgrade time window doesn’t matter. Compare values extrapolated from Date.now() and Math.random() to get your desired probability.

Hope that makes sense. I have the script somewhere. I’ll try to clean it and share it soon.

We’re using Netcomm CPE (Now owned by Casa Systems) If I’m ever over your way would be great to visit and see how others do things!

Hi Zaid,
Thanks for the idea. Great info - would be cool if you shared the script.

Cheers,

David.