Hi there, the wiki page is ready:
omv8:omv8_plugins:snapraid-aio [omv-extras.org]
The code is sitting in a PR on your GitHub repo of the plugin.
Let me know if you need anything else!
Hi there, the wiki page is ready:
omv8:omv8_plugins:snapraid-aio [omv-extras.org]
The code is sitting in a PR on your GitHub repo of the plugin.
Let me know if you need anything else!
Logged in and changed, thank you!
You have an account on the wiki already.
Strange, I don't have a password for it. I sent a request to reset it, but never received anything. Can you please reset it for me?
Development was completed a couple of weeks ago, since then I've tested the plugin on my real OMV NAS.
No issues to report, will open a PR now on GitHub.
Please let me know how to contribute to the Wiki, I have a draft for that as well.
A quick update.
I've finished adding functionalities: I believe the plugin is feature complete.
I'll be testing the plugin on real hardware for a while, then I'll prepare the PR on the GitHub repo.
I've also prepared a draft documentation for the Wiki.
A couple of highlights:
- Added a "Last Run" column to show last execution result, which is parsed from /var/log/snapraid.log
- Added Apprise test button for notifications and emails.
Why does it bug you? What are you trying to solve? The plugin is using snapraid 12.4 from the Debian repo. https://packages.debian.org/trixie/snapraid
It's just cosmetic, but my script uses it: snapraid -v does not print the snapraid binary version, just prints "none".
I discovered that this issue is actually fixed in Debian Repo for forky which has the 13.0 Snapraid binary.
13.0 is just a bugfix version, we could backport that. Are backports available already?
(14.x is moving quite fast and I would not go on that)
Alright. The script already handles dependencies via apt, so we're covered.
I implemented deletion of /etc/snapraid-aio-*.conf files on package purge.
One side question: how the snapraid binary is compiled for the main plugin? There's a little issue that bugs me that I want to solve, but the "snapraid" repo is archived.
Full steam ahead, I also added some commands.
A couple of questions for you ryecoaaron
- Apprise handling Apprise is needed for service notifications, but not strictly required for a bare-bone run. I know users do use it. Its binary is not in `debian/control` Depends/Recommends; enabling Apprise without it fails mid-run with a cryptic error. Should it be added to Recommends? I believe it's needed.
- postrm cleanup Should we delete /etc/snapraid-aio-*.conf files left on disk after plugin removal?
I wrote a separate plugin for snapraid-aio-script but auanasgheps hasn't had time to work on it more. Once this plugin is complete, it would replace the current diff script included with the plugin (which is old, not really maintained, and not written by me).
As I shared on the other thread: working on it right now
hopefully we can share more updates soon!
Could you please clarify which one is the correct way to proceed when I intentionally deleted files and want to ignore the threshold warning?
I believe my answer is too late to solve your issue, but here it is:
You need to select "Force Sync".
"Force Empty Sync" would be used to force a sync without any data - for example, a new, empty array
Hello, long time no see!
In the meantime I have gained some decent experience with Claude Code, and started working on the plugin.
I use AI for lots of things but it hallucinates with OMV coding quite often.
Heck yes: in the beginning I was spending more time fixing bugs introduced by Claude, rather than being productive.
I found my way out of this madness, by creating a ton of "Project Memory" based on the OMV documentation for developers (grateful for its existence).
I've extended the plug-in a lot, below there's a sneak peak.
I think I'm satisfied with the current UX and functionality. Now I have to validate the configs produced by the plug-in, for this I will need some time.
It's in my github repo, forked from ryecoaaron's. When ready, I'll do a PR.
We also need to decide what is the future of this plugin: will it be standalone, but relies on main SnapRAID functionality for arrays, or we integrate it in the main one, deprecating/removing the old script?
Per-config scheduling
Improved notifications
Cleaner UI
ignore_pattern field is flagged as advanced with a misuse warning.Quality of life
/etc/snapraid/ symlinks) instead of the raw config file path.Bundled script
After a lot of work, I have finally pushed the v3.4 stable release for the AIO script.
I can now take on the task to work on this plugin! Thanks ryecoaaron for the initial work.
Can you please clarify? You expect me to maintain the add-on?
I've never built OMV plug-ins, I'm not a real coder.
I can try, but I will take a long time.
Uhm, a first issue arises during the command line installation for dependencies.
It warns are missing, but are not installed.
root@omv8-test:~# sudo dpkg -i openmediavault-snapraid-aio_8.0_all.deb
(Reading database ... 44687 files and directories currently installed.)
Preparing to unpack openmediavault-snapraid-aio_8.0_all.deb ...
Unpacking openmediavault-snapraid-aio (8.0) over (8.0) ...
dpkg: dependency problems prevent configuration of openmediavault-snapraid-aio:
openmediavault-snapraid-aio depends on bc; however:
Package bc is not installed.
openmediavault-snapraid-aio depends on curl; however:
Package curl is not installed.
openmediavault-snapraid-aio depends on python3-markdown; however:
Package python3-markdown is not installed.
openmediavault-snapraid-aio depends on snapraid (>= 12); however:
Package snapraid is not installed.
dpkg: error processing package openmediavault-snapraid-aio (--install):
dependency problems - leaving unconfigured
Processing triggers for openmediavault (8.0-11) ...
Restarting engine daemon ...
Errors were encountered while processing:
openmediavault-snapraid-aio
Display More
To install, I had to run apt --fix-broken install
Don't know why.
This section of the script actually uses postfix configuration from OMV, so the user doesn't have to configure anything manually.
Since the user has already configured Notification options, I would inherit those values. (simplicity)
Please disable the option and remove it: the user will not be in control of updates since we'll manage them via package updates
Healtchecks UUID and Healtchecks URLs should be grayed out if "Use Healthchecks.io" is disabled, which is by default. If enabled, they are mandatory fields.
The same applies with Apprise: the URL field should be grayed out if the main option is disabled, mandatory if enabled.
I think some options clashed between Apprise and Apprise Notifications.
Can you make two distinct sections?
Use Apprise Notifications
Apprise Attach report
Apprise URL
Apprise Email notification
Use Apprise Notifications
Apprise Attach report
Apprise URL
NOTE: this is an advanced setting, not super relevant to OMV the average user. The main benefit for OMV users is the attachment feature not available in postfix.
These are legacy integrations before I developed the Apprise integration. Please hide them. The Discord integration is very unreliable. Apprise is much superior, I don't want new users to go for these old features.
SMART_LOG_NOTIFY requires SMART_LOG to be enabled first.
SNAP_STATUS_NOTIFY requires SNAP_STATUS to be enabled first.
This should be instead a dropdown menu with a list of the available configuration files.
Please note that the script can be used for multiple configuration files, creating a separate AIO config for each SnapRAID script.
Honestly I don't know how many users do multiple SnapRAID configurations, but since it's a feature, we should probably follow the same approach and make the AIO configurations for each SnapRAID configuration.
Since we removed remote Docker management, now "Manage local Docker Containers" is redundant since the user would have already selected "Manage Docker containers / services".
Can you hide the entry but still enable it if the user enabled "Manage local Docker Containers"?
I will take care of this.
I wanted to test it right now but my testing VM has OMV7 and the plugin requires OMV8. Is there a dirty way to upgrade to OMV8/Debian 13?
I would not do this in real world, it just to get it up and running quickly.
Yes, I think it would make sense to only pull running containers. Those are the ones that need to be stopped/paused.
I also think we can discard the "Remote Docker Management" section, since it's for very advanced uses where SnapRAID and Docker are not running on the same host.
I was really hoping to hand this off. I can help but I don't use snapraid or the script. So, it is really hard for me to test. I also don't really know how the script should be used. Creating this initial plugin was about all of my available time for a while which was much less work than getting the current plugin to stop using the old script and start using the new one.
I really appreciate it.
I've delayed my help for an official integration because I wanted to make changes to the script, but I hadn't had time until recently.
The logic is always the same: automate all SnapRAID routine actions. Some of these things are very specific to the SnapRAID world. However, the description I've added to each field in the configuration file should be enough to explain every option, at least for a SnapRAID user.
In addition to the core SnapRAID actions, the script does some nice things.
An example is the Docker management. When SnapRAID is running, no application should write any data to the array.
To resolve this problem, my script stops or pauses containers during the execution.
Currently, a user has to enter the containers manually. Could we pull containers names so they can be selected with a dropdown list?
Thank you. I will do some tests, I have a VM with random data so I don't break anything.
I'll provide some feedback soon!
Hi ryecoaaron, thanks for the initial effort on this!
Please note that I've been working a lot on the dev branch.
Most of the changes are done, I just need to merge a PR.
I had a quick look and it seems that you used the master as a reference.
Therefore, regarding the configuration reference and descriptions which needs to be exposed in the UI, please refer to this: https://github.com/auanasgheps…ob/dev/script-config.conf
What's the "logic" of the plugin? I would expect it to expose most/all configuration options and push them to the config files. If it's only this, the testing shouldn't be too much hard.
A nice to have would be to install automatically the dependencies. The script handles this automatically, but I think would be best to integrate them in the install phase.
Required:
- curl
- jq
- bc
- python3-markdown
Optional: Pipx + Apprise for enhanced notifications.