MerlinAU MerlinAU v1.2.6 - The Ultimate Firmware Auto-Updater (**Thread closed due to age**)

[Tech9]

Maybe one that tags @Tech9 in the forums everytime someone's router successfully updates with the script.

Are you done or you want me to continue sharing my opinion?

 

[ExtremeFiretop]

Are you done or you want me to continue sharing my opinion?

Your free to do as you wish. Buddy
Free world. But I gotta tell ya my popcorn is just starting to pop.

 

[Tech9]

Okay.

I don't see this script as part of Asuswrt-Merlin. If it was really needed it would be there already as an option.

I believe it may not end up in AMTM as well due to low usefulness, associated risk and partially author's behavior.

 

[thiggins]

@Tech9 You seem to be trending back to your old behavior. This has resulted in a ban in the past and will again in the future. Stick to offering help and skip the commentary.

 

[RMerlin]

Feature request: As soon as a new firmware is available, trigger a URL to post a useless “First!” or “Let’s Go!” reply to the release thread on the forum.

Just kidding, of course.

You forgot liking the empty "Reserved" post.

 

[Tech9]

@Tech9 You seem to be trending back to your old behavior.

Negative. The concerns in post #73 are valid. There was no need to continue this conversation after my "Good luck". This was the end of it on my side. I'm not a "buddy" and not interested in "popcorn". People rely on IoT devices and they are not limited to lights and power plugs. Firmware upgrade failure is not uncommon regardless of the method used. Unattended firmware upgrade is always a risk. Unexperienced readers of this thread have to be aware of pros and cons.

 

[thelonelycoder]

You forgot liking the empty "Reserved" post.

That‘s a mystery to me too.

 

[ExtremeFiretop]

• GT-AXE11000 (Tested)
• RT-AX88U_PRO (Tested)
• RT-AX88U (Tested)
• RT-AC86U (Tested)
• RT-AX86U (Tested)
• XT12 (Tested)

To bring the topic back on track, I updated the tested devices list. Thank you @KevTech much love for your efforts!
I'll be updating the Github list shortly once I get back to it... I've submitted a PR for the upcoming changelog review with specific key phrases.

And I'm going to be starting on the next PR hopefully tonight for the beta configuration options brought up by @Ranger802004

Hopefully have this completed by sometime this weekend
Thanks again everyone for the insights, keep the feedback coming with the great ideas!

 

[kuki68ster]

You've shared it enough over the last 3 threads I've been apart of on this topic.

I'm not sure why you keep following if your opinion is what it is. First thread you told everyone the idea was dumb. Then second thread you wanted to share how dangerous and impossible this was to make safe.

Now that it is safe and functional, in this thread you want to tell everyone how you won't use it anyways. Look, good for you.

I handle all feedback the same, I as I've said many times my opinion of the usefulness of this tool wont change. It streamlines my job of handling many routers as I've mention (friends, family, inlaws) down to just reviewing changelogs

If you have actual opinions about what you'd like to see in the tool, then please share, if your just following to share your opinion of how you won't use this. My recommendation is simply move on and forget it exists. Life is simpler that way.

Thanks again! Wishing you luck as well!

Not taking sides,

I understand Tech9 concerns, so i will say that i don't have fire, flood, smoke sensors on their on my network...But, I do like to review all the feedback before installing anything on my routers...

Saying that, the script is useful for me, so I am engaged in testing it, and see if it serves its purpose...

I am an amateur in terms of scripting and all that, so this for me is a learning experience, and I very much appreciate it...

 

[nlurker]

So I'm gonna go with a triple pronged approach to this problem.

1. I'm implementing a passive changelog verification in dev as found below:

View attachment 55877

This will do a few things for us.

It will give us a little piece of mind that if someone is completely clueless and not paying any attention at all, that it will check for very obvious red flags and advise.
This will prevent users from claiming they "didn't know what they were getting into" with any given update.

The red flags phrases it will search for are:

- features are disabled
- factory default reset
- break backward compatibility
- must be manually
- strongly recommended

I've selected those phrases as I've identified a pattern in the general language used in the changelogs as found here: https://www.asuswrt-merlin.net/node/10
and here: https://www.asuswrt-merlin.net/node/11

If you do a control + F search on both these pages for the phrases above, you'll find it's very specific in every case, and usually something the user should be aware of before flashing.
Why am I using whole phrases? Because I don't want to be too restrictive, the script won't care about specific words like "strongly" or "recommended" it cares about "strongly recommended"

Finally, it will give RMerlin some passive control over this script. (if he so chooses...)
If I implement something like "strongly recommended" RMerlin may decide to actively use it as a feature if he knows it exists. Worst case is he doesn't, then it's just a passive listener in the changelogs incase he uses the same language someday. (Like he as in the past.)


2. Martinski extended the Default Delay Cycle

As documented in PR: 86 Martinski has increased the maximum number of days to postpone new F/W updates from 30 days to 60 days. (Incase you plan to go on a month long vacation).
And he has also set the default to 15 days for new installs from 7 days.

This should give users more time in case they want to review/check change logs, or read SNB Forums posts related to the specific new F/W version.
If someone wants to review & check the change log every time before deciding whether or not to go ahead with a F/W update, they can set the delay to 30 days, which allows plenty of time for them to do what they need to before deciding to accept or stop the update.


3. Remind everyone this tool is to streamline your job, not replace it.

My personal preference as I've done already:




Remind everyone to check/review the changelog, this script is made to streamline and make your job easier, you no longer need to stay up at night or do the steps manually yourself, but the research should still be done by you before-hand.
Set the delay to the maximum number of days so you can make a decision based on your comfort level.


You can trust the script to update your network perfectly fine every time, what you really need is to trust yourself that you know when to stop it.

For now by default, if after 15 days, the user has not stopped the F/W update, it becomes a tacit approval to go ahead.
Remember you can simply disable it at anytime to stop any update and it's manual going forwards:

View attachment 55878

We can make it as dummy proof as possible, but at the end of the day, it's to each of you to determine your comfort level and specific network environment.
Your network is still your responsibility no matter how good the tools become. Make your own educated calls and use with discretion.

For example, I always read the changelogs and check for any changes that may affect my network setup. That's why I have set up a delay of 7 days for my own router, and 30 days for my parents & in-laws routers.
This allows me time to review & prepare for any possible changes and get a chance to disable it if something potently problematic comes up in the logs.

Keep in mind that as @Jumpstarter mentioned above, it's very rare on it's face this would be an issue, most of the time you can upgrade merlin firmware without a concern or thought in the world.
But if somehow there is a reset needed or a feature changed, and you didn't catch it, the script didn't catch it, and the delay didn't catch it, and you still flashed and got caught off guard by a change... Well at that point it's on you and I won't even take responsibility for that, we've done all we can.

Even in a worst case were you needed to fully reset and reconfigure, as long as you have a backup as we recommend, that takes what? Minutes of time?
Compare that to how much time you'll save for every successful flash in comparison.

Thank you, I am satisfied with how you are addressing my concerns.

 

[ExtremeFiretop]

@Martinski is a wizard.

As documented in PR: 88

The request for email notifications is completed:

Assuming a user has setup email credentials in AMTM, how about an email notification after an update?

And also before...

"Starting flashing firmware..."
If we don't receive the "update done" email after a couple of minutes, we know that something went (terrible) bad

 

[ExtremeFiretop]

Oh boy has it been a week.. I won't link each one but you can go find them if you want to review them.

PR: 87 for changelog verification was completed
PR: 88 for Email notifications was completed.
PR: 91 to stop entware services if running before flashing.
PR: 92 for Backupmon integration
PR: 95 for allowing MerlinAU.sh Upgrade from Beta to Release versions.

And a bunch of little visual improvements and bug fixes along the way.
Today I'm running the entire thing through it's paces again:

1. Test an upgrade situation from our current production version.
2. Do an fresh uninstall and install of the script, check to make sure it's all clean.
3. Test all the new settings while upgrading firmware in both interactive and non-interactive modes.
4. Retest with all addons installed.

As long as no issues are identified the next release will be version 1.0
Thanks again everyone for all the major feedback! It's much appreciated

 

[ExtremeFiretop]

Version 1.0.0 released. Off to bed now.

Updated the feature list and readme's. Enjoy the new release everyone!!

 

[ExtremeFiretop]

Version 1.0.1 released.

What's Fixed?

1. Fixed a bug in the LED Blink Function
2. Fixed a bug in the USB Unmount Function
3. Fixed a bug in the changelog verification Regex

I highly recommend everyone update which has it manually installed
Thanks! That's it for today

 

[aex.perez]

Does it always add it to cron, when you update? Guess I can hit No.

Before:
Cron job name Min Hour DayM Month DayW Command
amtm_RouterDate 45 */6 * * * /jffs/addons/amtm/routerdate cron
amtm_LEDcontrol_on 0 9 * * * /jffs/addons/amtm/ledcontrol -on
amtm_LEDcontrol_off 0 22 * * * /jffs/addons/amtm/ledcontrol -off
RunBackupMon 30 5 * * * sh /jffs/scripts/backupmon.sh
amtm_ScriptsUpdateNotification 10 7 * * Sun /bin/sh /jffs/addons/amtm/sc_update.mod -run
MerlinAU 0 0 * * 0 sh /./jffs/scripts/MerlinAU.sh run_now

For the Upgrade:

So hit N and it show as CRON job was disabled, but listing the CRON jobs it shows up. Like it does above, so guessing if you set a custom schedule and hit Y, does the default schedule overwrite your custom one?

 

[ExtremeFiretop]

Does it always add it to cron, when you update? Guess I can hit No.

Before:
Cron job name Min Hour DayM Month DayW Command
amtm_RouterDate 45 */6 * * * /jffs/addons/amtm/routerdate cron
amtm_LEDcontrol_on 0 9 * * * /jffs/addons/amtm/ledcontrol -on
amtm_LEDcontrol_off 0 22 * * * /jffs/addons/amtm/ledcontrol -off
RunBackupMon 30 5 * * * sh /jffs/scripts/backupmon.sh
amtm_ScriptsUpdateNotification 10 7 * * Sun /bin/sh /jffs/addons/amtm/sc_update.mod -run
MerlinAU 0 0 * * 0 sh /./jffs/scripts/MerlinAU.sh run_now

For the Upgrade:
View attachment 56103

So hit N and it show as CRON job was disabled, but listing the CRON jobs it shows up. Like it does above, so guessing if you set a custom schedule and hit Y, does the default schedule overwrite your custom one?

Were you on the "pre-release" version of 0.2.54? If so that explains it as the cron was updated and is likely not being recognized.
My recommendation would be to cleanup the old cron and let the script re-create (enable) it again.

 

[aex.perez]

Does it always add it to cron, when you update? Guess I can hit No.

Before:
Cron job name Min Hour DayM Month DayW Command
amtm_RouterDate 45 */6 * * * /jffs/addons/amtm/routerdate cron
amtm_LEDcontrol_on 0 9 * * * /jffs/addons/amtm/ledcontrol -on
amtm_LEDcontrol_off 0 22 * * * /jffs/addons/amtm/ledcontrol -off
RunBackupMon 30 5 * * * sh /jffs/scripts/backupmon.sh
amtm_ScriptsUpdateNotification 10 7 * * Sun /bin/sh /jffs/addons/amtm/sc_update.mod -run
MerlinAU 0 0 * * 0 sh /./jffs/scripts/MerlinAU.sh run_now

For the Upgrade:
View attachment 56103

So hit N and it show as CRON job was disabled, but listing the CRON jobs it shows up. Like it does above, so guessing if you set a custom schedule and hit Y, does the default schedule overwrite your custom one?

Oops, this was at startup, it worked slightly differently for the upgraqde, but I didn't catch it as I was trying to observe what was going on, sorry

 

[ExtremeFiretop]

Oops, this was at startup, it worked slightly differently for the upgraqde, but I didn't catch it as I was trying to observe what was going on, sorry

No worries, let me dig up the old PR, do let me know if you were on the pre-release version though!

 

[aex.perez]

Were you on the "pre-release" version of 0.2.54? If so that explains it as the cron was updated and is likely not being recognized.
My recommendation would be to cleanup the old cron and let the script re-create (enable) it again.

I was on 1.0, and I hit No and then renabled it, on the first node I hit Y and it was also on 1.0.
Waiting on the next Alpha/Beta/Release cycle to instal it on the Router

 

[ExtremeFiretop]

so guessing if you set a custom schedule and hit Y, does the default schedule overwrite your custom one?

And sorry, I totally missed this question.
Yes if you hit custom schedule it updates/overwrites the existing cron