Squid

Yeah if docker ps wasn't instantaneous then something bad was going on. Sent from my SM-T560NU using Tapatalk

Ignore ignores errors. Acknowledge on the unclean is because unraid does not tell you about unclean starts (random reboot) because there is no "built in fix" for am unclean start I have to have that in there... Sent from my SM-T560NU using Tapatalk

Depends upon your level of paranoia Sent from my SM-T560NU using Tapatalk

Unraid already has a minimum free space setting natively in the webui, so can't quite work out how you managed to get it down to 270Kb, although, gotta say I'm impressed. The plugin will respect minimum levels. If a file is not able to be created then it will not get monitored. Sent from my SM-T560NU using Tapatalk

If you read the thread he can barely get telnet access...

Get the list of containers: docker ps Stop a particular container docker stop nameofcontainer

Always nice to find an issue before anyone else does In this case, it was possible for dockerMan to create a template for an author that would result in some PHP warnings within CA

Was actually thinking of the imperial march LOL I was subtly trying to steer you away from that since I already use it to signal when UD has finished copying files off a camera card But I can find something else if you decide to use it. It would be pretty appropriate here. Any other than just stick beep beep beep would be selectable Sent from my LG-D852 using Tapatalk

A beep is no big deal to do... But, in case of an attack its not going to be a slowdown in networking speeds to an open stream. It'll drop the stream immediately (minus whatever the client has buffered). The network will be unavailable for up to a minute... Of course, most people will just restart playing over again, but not much I can do about that... This is a good idea, an option to beep out something ominous (taps?) Was actually thinking of the imperial march Sent from my LG-D852 using Tapatalk

A beep is no big deal to do... But, in case of an attack its not going to be a slowdown in networking speeds to an open stream. It'll drop the stream immediately (minus whatever the client has buffered). The network will be unavailable for up to a minute... Of course, most people will just restart playing over again, but not much I can do about that...

It'll never block it from starting (nor from shutting down for that matter), but I started thinking the same thing yesterday. Revamp the starting service script to check if the files already exist and skip creation if they do - especially since with the bait shares as you can easily have 500,000+ files taking up 0 space - if an attack happens to delete one of them, not much difference if there's only 499,999 remaining, and the time savings is huge. Just delays the next rev a bit...

What do you mean by copy over the files? Copying the bait files from the server to your Windows box? Beyond that, there is no SMB setting that is touched prior to it tripping. At time of trip, SMB is stopped, and the Share Configs are modified (no different than doing it yourself via the Shares Tab), and then unRaid automatically restarts the SMB service.

Since you're actively using this, this is what's progressing: (And its RobJ's idea) - User selectable bait shares (multiple -> all starting with a user Selectable Prefix) + a specialized bait share for the plugin's own puposes. - Selectable "width" and "depth" of share folders - Selectable # of bait files per folder - Random selection of file / folder naming (dictionary based - using actual words, random separators between words, randomly also tosses a random date on the file name) - After directory structure created for all the shares (< 1 minute), monitoring will begin automatically while the files are placed (~ 5 minutes per 20,000 files ) - Each share regardless of number of bait files uses < 10 Meg actual disk space. - Because the impact on the file system is minimal, will probably have it regenerate every boot, as its a far, far simpler setup to handle. Spent the yesterday working out placing the hardlinks and how inotify responds to changes on them (and also how Windows through SMB affects them through various different programs (side note: MS Office destroys links, but just about everything else keeps them ), so GUI is the next step... Oh yeah, also dropped the size of the PDF from ~200K down to 9K

Try the update. Absolutely no clue why dockerMan does something with vsftpd, but all references to dockerMan are now removed. (The impact however is that if your appdata is stored outside of the default appdata share, then it will not automatically get excluded)

You can install any docker container multiple times assuming that: You name them differently You change the host port so as to not conflict with each other You leave the container port alone You set them to different appdata locations

See the faq on linking containers Sent from my LG-D852 using Tapatalk

This page shows how to pipe stderror somewhere: https://stackoverflow.com/questions/2342826/how-to-pipe-stderr-and-not-stdout so something like this might let you use logger rather than directly appending to the syslog: inotifywait 2>&1 > /dev/null | logger (my assumption here is that "logger" will automatically strip the line feeds. If not you might have to pipe to "sed 's/\\n/ /'g" first ) Then again, this might not even be a problem Response time. Agreed, this is awesome! VM Startup time. I have the plugin configured to add files to the "Root ony of shares", so it doesn't seem like it should add 2 minutes to the boot time. This feels like a timeout of some kind because the array hasn't started yet, or maybe something to do with vsftp. I'm leaning toward vsftp, since those extra lines appear in the syslog. The specialized bait shares sound like a great idea! Sed is a swear word in my house [emoji1] but thanks for the tip. Bash is a necessary evil for me Like I said I'm going to try removing the dockerMan reference and see if it solves the other issue Sent from my LG-D852 using Tapatalk

Those 2 non-time stamped lines are a direct dump from inotifywait to the syslog. I *could* linux pipe file and then have another process monitor the pipe for changes and then log those lines. However, based upon my experience with the old Checksum plugin, I elected to not go that route as it was a major PITA to get and keep everything working properly. The vsftpd, I have seen that stuff in my syslog also, but the plugin doesn't touch anything at all regarding it (and at the point the plugin installs, it attempts to start its background service, sees that the array isn't started, so promptly aborts). EDIT: Unless its something in the dockerMan dynamix library that's included by the stop routine messing that up. Technically, I'm including my "helper" file (which has all of the various subroutines used by every part of this plugin. The "helper" file also includes a dynamix library because some of the functions require access to docker. I'll try not including the helper file on the stop routine, simply because all I need it for is the logging function and see what happens Response time: Thanks Don't think I can do much better than that (or if I can we're talking miliseconds which won't make much difference at all) VM Startup time. This is because ultimately, the only way to get the plugin into a known state prior to monitoring the files is to delete any old ones that may still be on the array, and then recreate them again. (which can take a number of minutes depending upon how your useCache settings are on the shares, etc) Trouble is that if I start monitoring a file that doesn't exist already, an alert is immediately sent out, and if somehow a file got changed inbetween starts of the plugin, then its already at the wrong md5 and will no longer serve its purpose. When I do the specialized Bait shares next, I was planning on not doing this at all (simply because we're talking about possibly putting 100,000 bait files onto the array which will definitely take a while to do)

Squid, it may be too early yet, but a check on the tunables for reasonable values might be good. The 6.2 series of unRAID releases have a new tunable md_sync_thresh that needs to be either half or very close to the value of md_sync_window, or you can get very poor write performance. It automatically defaults to 192, which is OK for users who haven't made any tunable changes, but if they used the Tunables Tester and raised md_sync_window much higher than its default, then they may see a large drop in performance. There are still only a few reports so far, so you may want to wait a bit, but once confirmed I think it would be a useful check, something users would be grateful for if it fixes a major slowdown. Catch-22 because in theory, all those tunables vary depending upon your hardware (Pauven would know for sure). I would have to state that it is currently too soon for a test like that to be made.

What led up to that? And what does the pop up state when you go into the settings? And the diagnostics would be awesome also... Sent from my LG-D852 using Tapatalk

Talk to CHBMB in the COPS thread. He's the expert... I just use it to browse and transfer to my tablets lol... Never looked at your sig... You beat my secondary server, but my primary did come out ahead of yours (barely)

Yeah, why advertise how crappy your hardware is...

in addition to. Its a very lightweight app to allow you to browse, download, email your book collection (and it also looks far better than Ubooquity)

You've got to type in the path to the books in the shared directory box (in your case, /mnt) I used to love Ubooquity, but have recently switched over to using COPS from lsio (don't like the fact that Calibre forces me to relocate my library, but it is what it is), and since you're already using Calibre, switching to COPS will make sense

Give it a minute and see what happens. I've seen intermittently where unRaid hits some sort of race condition where the tests start running, but dynamix hasn't finished loading the page (and the tests take precedence over the loading). After the initial tests are done you shouldn't have the problem anymore