Parsing drive status and the dialout group.

TL;DR: How can I make permanent changes to the system and where do I parse drive status?

I'm attaching some indicator LEDs to the chassis. The user of the determining script might require the dialout group so I need to know to permanently add a group. I will be using a device that is attached to an internal USB 2.0 header, probably a ESP32. I know OMV salts/hashes after modifications but I don't know how or where/where-not.

Three things I need.

1. Where to parse the drive status data.

2. How to permanently add a script as a daemon without conflict/blocking something else OMV related that is unknown to me. I don't really want to run Docker to keep this 1 thing friendly/isolated.

3. How to permanently add a group, although I don't technically need the dialout group. That said, I haven't used Vanilla Debian in a while, so I might.

Zitat von ryecoaaron

What do you mean by status? Like SMART data or df or ?

Well, does OMV know when a drive has failed and will warn the user of such? If so, the routine I'd like would be what is in that routine. I don't want my device creating ambiguous or false positives relative to OMV's warning system for drives (if it has one).

This might be a bad idea :-/. Maybe I should simply find a way to associate an LED with a drive, I guess that could make the LED a little handy when changing drives.

OK. So if you're writing a plugin or similar, where would you attach a listener of some kind for this report? Is there OMV.broadcast.error.disk() or something I can observe?

I looked at a tutorial once for creating a plugin and it baffled me as everything seemed to be in YAML and not PHP (or whatever OMV is currently using). Is this guide still in whole accurate... ? DIY Plugin Development (Sept. 15th, 2014)

Zitat von ryecoaaron

parse the output of smartctl yourself.

The project has taken longer than I'd like, but I now need logic that associates a disk bay to a LED and I'm basically ready to figure out the OMV GUI specific stuff.

I understand a SATA controller can't be probed for all available connections without drive connections but, is that the same for HBAs? I've tried MegaCLI and StorCLI with my 9300-16i but it doesn't show the individual connections. StorCLI does report "Backend Port Count = 8", but that's not really helpful. Is there no way to probe a HBA for stale/disconnected serial connections? Parsing connected drives isn't an issue, it's when the drive vanishes entirely that the LED association becomes entirely ambigous.

Right now I already have an ESP32, MCP23017, 3 resistors and 16 LEDs. That's not much since all of that is out in the open, but if I start to add sensors for association, then the availability of working room becomes awkward as it would involve soldering to backplanes or something similarly cramped.

In case I never get back to this, the ESP32 code doesn't have tests (yet) however, I've tested the I²C with to 2 devices (32 connections, I only have 2 chips) and I have no reason to believe it wont' work with more. That said, with more than 2 or 3 a MOSFET and alternate power source will probably be required.

The C code is attached (over 10k chars apparently). Also, it's Arduino specific mainly due to "Wire.h", although that's about it.

I've also attached a NON-finished python script I've been using that uses pySerial but I'm not partial to Python or stty or anything really. Again, it's not finished but you want to play with and have nothing... it's better than nothing.

The LEDs I'm using are https://www.digikey.com/en/pro…ht/WP710A10LVBC-D/5177415 They're 2mA and 2.65v (I'm running them at 3.3v like lazy rebel and they're fine).