Add an extensionpoint for notifications

[framps]

As of now Slack (#551), Pushover(#550) and Telegram(#205) notifications are integrated. Discord notification (#602) is published as a user provided extension by @Tytouc even it's a wrapper because of missing features in raspiBackup to be published as an extension.

Add an extension point for notifications not provided by raspiBackup to allow raspiBackup users to create and share any other notification target. Possible targets are PushBullit, twitter, ... facebook, ...

[framps]

I just created a branch where I added initial notification support to current master. Use

curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | bash -s -- master_612

to download the the current code.

Then copy the notification sample extension from extension directory into /usr/local/bin and add sample to DEFAULT_EXTENSIONS in config.

Then invoke it with sudo ./raspiBackup.sh.

If there is anything missing just comment :wink:

[p1r473]

Heres a good list to use: (from healthchecks.io integration page)

Im using Gotify, Pushover, Pushbullet, Telegram, Signal, ntfy..

[framps]

Im using Gotify, Pushover, Pushbullet, Telegram, Signal, ntfy..

:+1:

Do I get you right you now want to write notification extensions for Gotify, Pushbullet, Signal and ntfy and give me feedback :smile:

[p1r473]

If I find the time I can. No promises! 😄

[framps]

No hurry. Take your time. I plan to add this extension in next release which I expect to be published in 3rd quarter this year. So you have plenty of time :laughing:

[Tytouc]

Hi, tested the sample notification extension: works well and provides access to the message file and return code of raspiBackup. I didn't port the Discord wrapper to this extension as I'll do it once this version is released.

In addition, I've worked on another notification : Ntfy (using simple curl command). Why? because notifications on Discord are not always received immediatly. for example, whe the message is sent during the time the phone is powered off, once I turn on the phone, the notification only arrive when I launch Discord app. This is not a that big issue for backups, but for other systems it is (ex: intrusion detection). This is the reason why I went to Ntfy. The problem w/ Ntfy is that the messages are not secret: the 'channel' name is the secret... so this name shall be hard to guess... and 'security' is based on this only! So, take car not to send confidential information on Ntfy.

Thanks for the job @framps ! Eager to see that version to be released!

[framps]

Hi, tested the sample notification extension:

:+1: Thank you very much for your test. If there is something you still miss please let me know. As long as the extension point is not final I can modify the interface or add missing features. If it's published in next release it's much more difficult. As long as raspiBackup exists all changes were backward compatible :wink:

In addition, I've worked on another notification

Sounds interesting. Would be great if you write an extension for raspiBackup for Ntfy when the beta for next release is out. That way there is still some room to add missing functionality :smile: And maybe also to collect some good practices to write a notification extension.

For example I don't have a good idea where to place any configuration stuff for the extensions. I see following alternatives: 1) Hard code them in the extension code 2) Use a dedicated config file for every extension 3) Use a common config file for all extensions 4) Use the raspiBackup config file

As of now I prefer (3). That way raspiBackup can make sure this file is read only by root as it's done with the raspiBackup config. That's required because the notification extensions use access credentials which shouldn't be world readable :flushed:

[Tytouc]

You're welcome! I do not think something else is needed for notifications as the message file contains all details. Yes, I can publish an extension for Ntfy. I'll do, but cannot say when because I'very busy at the moment. As for the config file, I agree with you for option 3, this would be the one I select. As you sais for securoty reasons and to separate from raspiBackup config file. Hard coded values are bad, except for default values. The other advantage is to keep the format unchanged for any extension. Easy for users. In the config file, I'd suggest to adopt a format with sections, so that each extension has its own section with the key, valie pairs in it. With this, a key can be used several time in different sections. Something like: [EXTENSION_1] VAR1=VAL1 VAR2=VAL2 [EXTENSION_2] VAR1=VAL1 VAR3=VAL3

[framps]

I'd suggest to adopt a format with sections, so that each extension has its own section with the key, valie pairs in it

I see your point. Unfortunately this requires some parsing of the config file. raspiBackup.conf is just sourced.

Therefore I prefer to use following naming convention: <extensionname>_<any_config_name>="any value" The extension name has to be unique and therefore there will be no naming clashes between different extensions.

[Tytouc]

Yes, why not. But the config file will only be accessed by extensions. And each extention can use it with parsing instead or sourcing. So, there is no link with raspiBackup sourcing and format.

[Tytouc]

Advantage of sections is that there will be no mix of paramter in the file such as: Ext1_param1... Ext2_param3 Ext1_param2 ... With sections, all parameter of each extension is grouped.

[framps]

So, there is no link with raspiBackup sourcing and format.

But this delegates the burden to parse the config file to the extensions. As of now all extensions are written in bash. json can be parsed with jq in bash. But json is not a user friendly config language. I just don't remember the name of the config language you propose ... but do you know if there is a tool available which can be used in bash like jq for json?

[Tytouc]

I'll find it... web servers are usually using this format which is *.ini like (windows) But I do not agree with what you say: JSON is for me user friendly ;) It is easy to read, write, undertand and is multi-language/platform. See https://github.com/DevelopersToolbox/ini-file-parser

[framps]

JSON is for me user friendly ;)

If you know JSON it's developer friendly. But a user not familiar with json has serious problems to get the json syntax right and the file can be parsed with jq without any errors.

I just found out the name of this config format: TOML. And there exists a tiny parser. But I'm still not convinced it's a good idea to use TOML ...

[Tytouc]

JSON is for me user friendly ;)

If you know JSON it's developer friendly. But a user not familiar with json has serious problems to get the json syntax right and the file can be parsed with jq without any errors.

Quite true... I have to say, but, the extension will provide sample config file, where the documentation will say which value shall be changed to match the user's context

I just found out the name of this config format: TOML. And there exists a tiny parser. But I'm still not convinced it's a good idea to use TOML ...

Why? I'll try to find another mean. I am maybe too 'organized' I mean, i like to find things easily and let less liberty to others to do things like they want... to be understood in development context only! I mean that if you let developers do as they want, by just giving naming conventions, you may have to handle many requests because someone didn't follow the rules... overwriting someone's paramter for example.... I need to think about it more seriously, but I tend to select languages, formats etc that gives less permissions to developper's errors...

[framps]

Merged into development branch

[framps]

Detected some issues during integration for next release

[framps]

Merged d_612 into development branch