Ripshod
Very Senior Member
Already set the new strategy. 02:15 seems good to me:Change time to 00:30.
a. I'm guaranteed to be in bed
b. It's outside the twighlight zone
Already set the new strategy. 02:15 seems good to me:Change time to 00:30.
but what happens when the clocks roll back? Two backups?
crond
compensates for DST changes.crond
whereby it doesn't compensate for DST changes despite the comments to that effect in the source code. So yes, when the time goes forward one hour's worth of jobs are skipped, and when the time goes backward one hour's worth of jobs are repeated.However, this morning it didn't(?).No,crond
compensates for DST changes.
Didn't for me either two weeks ago... EST timezone.However, this morning it didn't(?).
However, this morning it didn't(?).
*EDIT*
Neither did Diversion_WeeklyStats and uiDivStats_trim.
Strange. I've never had a problem with this myself, but then I'm not using the same custom scripts as you. Perhaps there's a bug in busybox somewhere. Did you see any "time disparity" messages in the syslog at the time the clocks changed?Didn't for me either two weeks ago... EST timezone.
You'd think something likeStrange. I've never had a problem with this myself, but then I'm not using the same custom scripts as you. Perhaps there's a bug in busybox somewhere. Did you see any "time disparity" messages in the syslog at the time the clocks changed?
Compensating for DST changes has been a core function ofcrond
ever since it's inception decades ago. For caveats see the DST section of the man page, although I notice the grace period should "officially" be 3 hours rather than busybox's one hour.
30 2 * * * sh /jffs/scripts/backupmon.sh -backup #RunBackupMon#
would just work... DST or not... agree with you. Could be a bug of some sort. Unfortunately my logs have rolled over long ago... hopefully @Ripshod still has some fresh log data to peek through.2:30 doesn't exist as clocks roll forward at 2:00, directly to 3:00. In the fall, it should not be an issue.You'd think something like30 2 * * * sh /jffs/scripts/backupmon.sh -backup #RunBackupMon#
would just work... DST or not... agree with you. Could be a bug of some sort. Unfortunately my logs have rolled over long ago... hopefully @Ripshod still has some fresh log data to peek through.
curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"
Honestly doesn't show anything related, other than flipping between 01:00 and 02:00 a few times (possibly conflict between the router's ntpd and ntpMerlin)hopefully @Ripshod still has some fresh log data to peek through
Maybe where you are in the world.2:30 doesn't exist as clocks roll forward at 2:00, directly to 3:00. In the fall, it should not be an issue.
So the big news of the day is that BACKUPMON now officially supports NFS! Many thanks to @smarthome-enthusiast for all his help getting this tested and working! Also big changes to the UI to bring it in-line with VPNMON-R3's look & feel! As always, please reach out if I can be of any help...
What's new?
v1.7.1 - (March 24, 2024)
- MINOR: Thanks to a push from @smarthome-enthusiast, BACKUPMON now supports NFS in addition to the standard CIFS/SMB methods of transferring data across a network to an NFS network share to safely store your router backups in case of disaster! All necessary changes to the config menu have been considered in order to handle NFS. When choosing NFS, an additional field will become available that allows you to enter optional "NFS Mount Options", understanding that different NFS implementations may require special mount options/switches, this field allows you to customize your connection based on your needs. Also huge thanks to @Martinski for revamping his mount point selector functionality in order to handle USB, CIFS/SMB and NFS mount points if they exist. Huge shoutout to @smarthome-enthusiast for all the testing he's helped with in getting this NFS functionality over the finishline!
- MINOR: BACKUPMON has been given a complete UI makeover, and is now on par with VPNMON-R3's look and feel. Emphasis has been given on simplifying the UI design, to account for more screen space, less distracting colors, standardizing submenu design, making it more friendly to use across the board.
- PATCH: Found some variable name mismatches under the restore -> secondary backups logic that was looking at variables for the primary backups. This has been fixed!
Download link (or update directly within BACKUPMON or AMTM):
Code:curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"
Significant Screenshots:
Base UI changes to the overall look & feel, bringing it on par with VPNMON-R3:
View attachment 57414
New look and layout for the Setup + Operations Menu:
View attachment 57415
And an example of the configurations menu changes...
View attachment 57416
Example of the standards applied to each submenu item, showing currently selected values:
View attachment 57417
Enjoy!
@Viktor Jaep and @thelonelycoder
The latest update is telling me it's a downgrade Small things but just an FYI incase you didn't notice.
View attachment 57428
Yup, it‘s a case of too many patches and no minors.Hum. Thanks for noticing! I'll have to take a look at the AMTM logic to see why it is determining that!
EDIT: @ExtremeFiretop ... I think I remember @thelonelycoder saying that when it looks at version numbers, that it strips punctuation and such ... which might be why 1514 > 171
EDIT: @ExtremeFiretop ... I think I remember @thelonelycoder saying that when it looks at version numbers, that it strips punctuation and such ... which might be why 1514 > 171
Yup, it‘s a case of too many patches and no minors.
- name: Determine Next Version Tag
id: nextver
run: |
TAG=$(git tag --sort=-v:refname | head -n 1)
if [[ $TAG == '' ]]; then
TAG='v0.1.0' # Start from v0.1.0 if no tags are found
fi
MAJOR=$(echo $TAG | cut -d '.' -f 1 | cut -c 2-)
MINOR=$(echo $TAG | cut -d '.' -f 2)
PATCH=$(echo $TAG | cut -d '.' -f 3)
if [[ $PATCH -eq 9 ]]; then
PATCH=0
if [[ $MINOR -eq 9 ]]; then
MINOR=0
MAJOR=$((MAJOR+1))
else
MINOR=$((MINOR+1))
fi
else
PATCH=$((PATCH+1))
fi
NEXT_TAG="v$MAJOR.$MINOR.$PATCH"
echo "Next version tag: $NEXT_TAG"
echo "tag=$NEXT_TAG" >> $GITHUB_OUTPUT
_ScriptVersionStrToNum_()
{
if [ $# -eq 0 ] || [ -z "$1" ] ; then echo ; return 1 ; fi
local verNum verStr
verStr="$(echo "$1" | awk -F '_' '{print $1}')"
verNum="$(echo "$verStr" | awk -F '.' '{printf ("%d%03d%03d\n", $1,$2,$3);}')"
verNum="$(echo "$verNum" | sed 's/^0*//')"
echo "$verNum" ; return 0
}
_ScriptVersionStrToNum_ "1.5.14"
1005014
_ScriptVersionStrToNum_ "1.7.1"
1007001
That's an ingenious way to approach it! Nice work @ExtremeFiretop!Naturally, when I hear this my first thought is to just follow the standard flow for semantic versioning (semver) scheme (1.5.14 -> 1.6.4) which is what MerlinAU's github workflow uses:
Code:- name: Determine Next Version Tag id: nextver run: | TAG=$(git tag --sort=-v:refname | head -n 1) if [[ $TAG == '' ]]; then TAG='v0.1.0' # Start from v0.1.0 if no tags are found fi MAJOR=$(echo $TAG | cut -d '.' -f 1 | cut -c 2-) MINOR=$(echo $TAG | cut -d '.' -f 2) PATCH=$(echo $TAG | cut -d '.' -f 3) if [[ $PATCH -eq 9 ]]; then PATCH=0 if [[ $MINOR -eq 9 ]]; then MINOR=0 MAJOR=$((MAJOR+1)) else MINOR=$((MINOR+1)) fi else PATCH=$((PATCH+1)) fi NEXT_TAG="v$MAJOR.$MINOR.$PATCH" echo "Next version tag: $NEXT_TAG" echo "tag=$NEXT_TAG" >> $GITHUB_OUTPUT
So for example, our next release after 1.0.9 will automatically be 1.1.0.
However technically speaking @Viktor Jaep doesn't need to change anything since it is generally following semantic versioning (now).
This could be solved in AMTM instead of doing a direct comparison (i.e 1514 > 171) by doing a arithmetic conversion step first before comparison such as:
Code:_ScriptVersionStrToNum_() { if [ $# -eq 0 ] || [ -z "$1" ] ; then echo ; return 1 ; fi local verNum verStr verStr="$(echo "$1" | awk -F '_' '{print $1}')" verNum="$(echo "$verStr" | awk -F '.' '{printf ("%d%03d%03d\n", $1,$2,$3);}')" verNum="$(echo "$verNum" | sed 's/^0*//')" echo "$verNum" ; return 0 }
Which would convert: 1.5.14 into: 1005014
AndCode:_ScriptVersionStrToNum_ "1.5.14" 1005014
Code:_ScriptVersionStrToNum_ "1.7.1" 1007001
So now it compares: 1005014 < 1007001 instead of 1514 > 171
This is how MerlinAU compares the version strings of Backupmon.. since Viktor changed his standard some time ago Hehe.
With this change in AMTM, he could technically use a patch number as high as he wants.. (i.e backupmon version 1.5.96) and it would still compare correctly.
This is why I tagged both @Viktor Jaep and @thelonelycoder just to review the situation incase it wasn't noticed. Just food for thought that's why I said it was only small things.
That's an ingenious way to approach it! Nice work @ExtremeFiretop!
I don't remember where I picked up the reduction method of determining if a version is higher or lower, might be @Adamm 's code from back then.This could be solved in AMTM instead of doing a direct comparison (i.e 1514 > 171) by doing a arithmetic conversion step first before comparison such as:
version_check(){ echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }';}
if [ "$(version_check 1.7.1)" -gt "$(version_check 1.5.14)" ]; then
echo "-->"
else
echo "<--"
fi
I don't remember where I picked up the reduction method of determining if a version is higher or lower, might be @Adamm 's code from back then.
Anyway, no need to get too complicated with version number comparisons, I have all necessary things built into amtm and Diversion. I just don't use it for the update check. Again, I don't remember why I used the simplification method instead of what is already there:
The output of above is expectedly -->Code:version_check(){ echo "$@" | awk -F. '{ printf("%d%03d%03d%03d\n", $1,$2,$3,$4); }';} if [ "$(version_check 1.7.1)" -gt "$(version_check 1.5.14)" ]; then echo "-->" else echo "<--" fi
Done in my dev version:I myself would think it's better to use that than the simplified version we see in the screenshot above.
More or less.Your fast!
(I know you said it was already incorporated so probably a simple copy and paste for you!)
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!