Community Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


doron last won the day on September 20 2020

doron had the most liked content!

Community Reputation

57 Good


About doron

  • Rank


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've built a workaround in the SAS Spindown plugin, when latter is installed in versions 6.7-6.8. The workaround is complex and rather involved, to make sure it's "safe" even if the user reconfigures the syslog settings in the webGui (e.g. includes a background process that waits on modifications to syslog.conf and, when triggered, reconfigures the filters). While it's done and working quite elegantly, I'd not recommend going that path. This is really quite broken right now, so if it can be fixed in 6.9 it would be great.
  2. No it doesn't! My wording may have been confusing - sorry about that, I now see that my text in parenthesis can be read in two different ways... The encryption key does NOT live on the USB by default - the default is to type in it during array startup. IF one does choose to use a keyfile, AND that keyfile is stored on the USB drive - THEN the rest applies. Hope I'm more clear now... No it does not, see above.
  3. If your primary security concern is the USB drive, and your drive encryption key is not stored on the USB (which is the usual Unraid use case), then yes, this method does mitigate that threat. [An ever-so-slightly-simpler way, if you're already keeping a file per program/docker, is to have that file be a script, which will just output the key/passphrase to stdout (as in "echo" or "printf"). Then, you just include it as "... TOKEN=$(/path/to/script) ]
  4. Is there any i/o going on against this drive (look at the read/write counters) during that time? If there's none, we'd probably conclude that this drive/controller combo ignores the spindown command. If you want to triple check, you may want to run this sequence in quick succession - when there's no i/o happening against the drive: sg_start -rp3 /dev/sde sdparm -C sense /dev/sde If the output is the same as in the previous test, then it's settled 😞
  5. It all depends on your threat model. What is the attack (or leak) scenario you are concerned with? Who is the potential attacker? For some scenarios, I can't see why your solution is better than just keeping the secrets on your USB flash (i.e. somewhere under /boot). For yet other scenarios, it might actually be better. Note btw that the way you currently do it, a "ps" command would reveal the secret - try, in your case: ps ax | grep docker This may or may not be a problem (basically if someone is at the CLI level she can peek into your "keys" share) so
  6. Thanks for reporting, @absolute_badger. Might be that this drive / controller combo ignores the spindown command. Right after you spin down, say, /dev/sde, and get the "Spinning down" message from SAS Assist, can you issue, against the same device: sdparm -C sense /dev/sde and post the output?
  7. At any rate, the SAS Spindown plugin is available for 6.9 (rc and final when available), providing the same functionality. It will remain available until unraid provides this organically.
  8. Another data point: I use option "Gmail with TLS" and port 587. Works well.
  9. Yes, this is the dreaded 4/11 state, which basically means the drive is at a state that needs an explicit START command to spin back up, and won't spin up automatically upon i/o. Some combinations of drives (mainly Seagate) and controllers give this - Dell controllers like yours are often (though not always) involved - haven't figured out the exact combos yet. Each report like this one enhances the community knowledge... Yeah, that's painful. This is the holy grail I'm after - which drive/ctrl/firmware combinations end up doing this. Have you checked the f/w version o
  10. Thanks for posting, and for PMing the diagnostics. It appears as if the problem occurs only on drives connected to your second controller (The H221). Is that a correct observation? Have you looked at the firmware of this controller? Unrelated, if you're open to testing something with the array stopped, you may want to run the same "sas-util" with one parameter - "test". If you choose to do that (no pressure...), then please PM me the results.
  11. That makes sense - not in terms of power (HDDs draw surprisingly less power that people think), but in terms of the dreaded 3.3v issue. Local to where? 🙂 Any decent electronics store should have them, or you can buy online (and wait, I know). No it does not. It specifically addresses SAS drives (this is where I experienced the issue, and this is where I had to perform the hack). No. Let's take one step back. (I assume you're using the Cable Matters cable mentioned above - if not, please point to the one you are using.) The SAS connector
  12. @kunfuezion, what drives (models) are connected to this controller? (I presume the 1TB Seagate and 3TB WD are connected via another controller) How do you provide them with power? Any chance they're susceptible to this? (long shot, but worth looking into)
  13. One way to go about this could be to create a share that's dedicated to this DVR, and allocate it on one disk only. The share will presumably be limited to the size of that particular disk. Not exactly what you were looking for but may be close enough to be useful.
  14. I presume you are referring to an ISO file that's on the array. The following is a hack but I don't see a reason why it shouldn't work: In your "go" script, you can drop a script into this folder /usr/local/emhttp/plugins/dynamix/event/disks_mounted/ That script will be executed when the array is started (with encryption unlocked). You can use it to mount your ISO. For completeness, you may want to also drop a script into /usr/local/emhttp/plugins/dynamix/event/stopping_array/ to unmount your ISO.
  15. I'm not sure I understand which hypervisor you are trying to use? Or are you in fact asking which one to use? At any rate, with VMWare (ESXi), which I happen to be using, you can dedicate single drives (slightly complex but workable) or whole controllers (much easier) to Unraid, and it works quite nicely (albeit unsupported by Limetech). You can do similar things with other hypervisors as well, more or less conveniently.