add apprise and ntfy support for notification, scrub logic reworked, & some misc changes

[1024mb]

I have made some changes in the script and improved the structure.

Support for Ntfy and Apprise

I have added support for sending notifications using Ntfy and Apprise. Ntfy will always send the report as an attachment, Apprise depends which service is used. Apprise supports entering multiple services/URLs separated by a semicolon. Both support entering the path to a config file.
Also if the user has a configuration file ntfy will use it, which is helpful in that the user doesn't have to store their token/password in the plugin's config files.

I needed this because as I'm hosting a mail server on the same machine OMV's email notification doesn't work. But besides it still is a fun addition, Apprise itself adds support for several of other services and even email.

The user will need Apprise and Ntfy installed in their machines. And make them accessible in PATH.

Scrub logic reworked

As it was, the logic for the scrub execution was not working well because the current implementation assumed the script was executed daily: It read a counter file, the counter was increased on every run, then that counter was compared with the frequency in days, so if we ran the script once a week and set the frequency to 7 days, it would need 7 weeks to run a scrub again.

The new way takes this approach:

• When the script is executed for the first time since the update the logic starts from scratch, unfortunately the previous progress won't be continued.
• The last scrubbing date is stored on a file, this date is compared with the current day, the result (the number of days between them) is compared with the scrub frequency setting. If it's less than that the scrub is not executed. This helps in that if we use 14 days frequency and the script is executed once every week, we don't relay in script execution but instead we compare the dates.
• The accumulated days is also stored and used to make SnapRAID not scrub the previous scrubbed data.

Assume we run the script 5 times every 3 days, we set: FREQ: 6 days, PERC: 10%, so past 60 days all data must be scrubbed from the start.

Initial run: first day of the month

run	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22
day	01	04	07	10	13	16	19	22	25	28	31	34	37	40	43	46	49	52	55	58	61	64
perc	10%	--	20%	--	30%	--	40%	--	50%	--	60%	--	70%	--	80%	--	90%	--	100%	--	10%	--
acc	06	--	12	--	18	--	24	--	30	--	36	--	42	--	48	--	54	--	60	--	06	--

*porc is total percentage of scrubbed data
*acc is the minimum file age for scrub for the next run, day 00 of table has a perc and acc of 00.
*-- means scrub not executed

This reads, first day accumulated days is 0 which means no file is skipped so 10% of the total data will be scrubbed, the accumulated days (meaning the number of days data already scrubbed will be skipped) is set to the frequency, then the second run no scrub is executed. The third run, because 6 or more days have passed, the scrub is run skipping the data that has been scrubbed in the past accumulated days (6 in this case) so 20% of the total data will be scrubbed, the accumulated days is increased now to +frequency, meaning 12, rinse and repeat until the 21th run, where the script will detect the accumulated days is greater or equal than the max days and because of this all data is scrubbed from the start, meaning it will scrub 10% of the total data and the next run the files that has been scrubbed in the past 6 days will be skipped.

The max accumulated days is calculated using 100 * DAYS / PERCENTAGE, if not exact then the value is rounded to +1, which in this case will be 60. Every run the script first calculates how much days have past since last scrub, if is less than the frequency then the scrub is not run, if is equal or greater then another check is made, if the accumulated days is greater or equal than the calculated maximum then the scrub is started from 0, meaning it will not skip any files, if the accumulated days is less then the scrub is executed and the accumulated days is increased by the frequency amount.
This way, even if the user changes the scheduled cron job it will not matter because the dates will be compared and then the accumulated days.

Reestructured code

I have made some refactoring, in a nutshell every mayor piece of code has been moved to their own function.
The debug logging is more readable now
Also there were some parts where the script should have exited but there was no exit command. I have also added a check to only run scrub if sync command is successful.

I have also added some more stuff which will be listed here taken from my last commit msg:

• add ntfy and apprise support
• store PREHASH option in diff conf file
• add option to send SnapRAID commands debug logs as attachments in the Apprise and Ntfy notifications (Ntfy will always be a separate notification, Apprise depends on the service used)
• add option to always send the notifications even if no changes were detected by the diff command
• renamed options
• reworked _log() function to always print WARN messages and only print INFO or DEBUG msgs if DEBUG is set to true, and always append the message to the main log file
• fixed some logic
• simplified code by storing command arguments in variables instead of duplicating the line
• removed duped notification prefix

Notes

I haven't extensively tested this, even so I haven't tested the script with more than one array and more than one parity drive, it should work with both but I can't really say I've tested the changes with them.

Also, is totally possible I have made some errors, there is not much documentation available about plugin development.

• Is the migration script file correct?
• Is the webui components correct? I would have liked to make the apprise and ntfy CMD fields conditional to their checkboxes but I don't actually know if it's possible and how.

I would also like to understand something else: If we use omv_config_get %PATH% as far as I understand by checking the code we are reading the actual XML file, but doesn't the XML file contain non-applied changes too? Or I'm misunderstanding this, I thought changes made on the webui are saved directly to the XML file, then they are displayed as pending changes and after applying them they are then saved to their correct location in the system, isn't this how is done? If so then we shouldn't use omv_config_get, right? Because we may be retrieving wrong info that the user has not confirmed/applied.

[votdev]

I do not like the solution how Apprise/Ntfy support is implementation here. In this case ONLY this plugin has support for that service, other plugins AND the core system do not benefit from that.
Please note that it IS essential for the core system that there is a Postfix instance running, otherwise Linux userland apps are not able to send notifications. I am not sure if Apprise can replace Postfix in OMV because there is much more than simply sending the email. OMV is using Postfix for header manipulation etc.

[ryecoaaron]

@1024mb I appreciate the work and effort on this one.

I agree with @votdev on this one. People will want to use one of those notification systems for more than just this plugin. I don't use them and don't want to maintain config for them in multiple plugins.

Another issue is that there has been discussions moving to this script - https://github.com/auanasgheps/snapraid-aio-script from @auanasgheps.

Unfortunately, I don't use snapraid so any major changes would need testers.

[auanasgheps]

That's why my script simply reuses postfix/mailx configuration from OMV, but also has an option for additional services.

@ryecoaaron the reason I haven't started a proper discussion with you is always the lack of time, but we'll get there!

[1024mb]

I think I'm not understanding the issues. I just checked the linked script and it has options to send notifications to other services as well and uses curl for this.

I'm not replacing the mail notification that is already included in the plugin, I'm, as the linked script, adding additional notification services to the plugin/script. It may or may not be used to send mails, the goal was not to replace anything, in fact I haven't removed any old feature at all, I've merely added stuff on top.

People will want to use one of those notification systems for more than just this plugin. I don't use them and don't want to maintain config for them in multiple plugins.

Right, but why would you have to do that? Does OMV always implements every feature that is requested? I don't see how people are entitled to features found on other plugins, if anything at all.

[votdev]

Right, but why would you have to do that? Does OMV always implements every feature that is requested? I don't see how people are entitled to features found on other plugins, if anything at all.

It is all about maintenance and usability. If you spread this code across thousand plugins, then you need to maintain all of them if there is something to improve or fix and the user has to configure every plugin.

I am thinking about adding a plugin for Apprise, but it will take some time.