Squid

I wonder if we could take this a little further and have an option to autoback up the entire plugin folder right before we decide to delete a plugin? The reason I ask is lets say I accidentally click delete for "user scripts" because I am special, the whole plugin folder would get deleted along with all my custom scripts. That would be a sad day. (This actually just happened to be with the powerdown plugin, all my K00 and S00 scripts got deleted.) Yes, I should probably be taking be making backup....... .... oh that's right community apps already makes backups of my flash drive every month and guess what I just found, my K & S scripts! Well I suppose I will still post this in case it does make since to backup right before you delete a plugin but the CA flash backup did and will continue to do an awesome job of saving any files I need in the future. At least you had a sense of humour and quoted the pic along with the text...

There's just no satisfying you is there Curious though what container its from...

Don't encourage him But yeah, lsio has done some amazing work

I had them as cumulative so that you could go back and reference the old results, but since I always have to force problems to happen, I've never really given it a second thought to re-running it a few times in succession. Painless for me to delete the prior results. Will add it in to the changes for the posts above. Look for it tomorrow ish. But in the meantime, you can delete /tmp/fix.common.problems/extendedLog

lol. please explain for us mere mortals Sparklyballs is just patting himself on the back for the 1M pulls. Egomaniac and all.

This section then listed every single file I have, lol! lol Must have been quite the email notification... Can't test AD integration, so just ignore the error, but I'll look at limiting the results NP

https://cdn.meme.am/instances/29763074.jpg[/img] Added: Selectable delay in days before autoupdating a plugin (defaults to 3) Added: Backup of .plg files prior to updates to support edge-case rollbacks if needed Updated: Manual Delay before updating a plugin is a global setting (within Autoupdate settings), and is tested against every plugin prior to updating it. Setting it to 0 will disable this feature. Backups are based from this thread: http://lime-technology.com/forum/index.php?topic=52164.0 Purely an edge-case scenario to possibly support rolling back of a plugin if the updated version if no good. The folder backed up to is /boot/config/plugins/plugins-old-versions. (All backups are dated versions). This feature should be implemented ideally by the plugin manager itself, as with manual updates no backup will be made. (The folder the plgs are backed up to is the same as my PR request to LT). Roll backs may or may not work depending upon the plugin, but it costs basically nothing to at least give the user the option in the edge-case scenario. If LT accepts the PR to implement this in the plugin manager itself, then this feature will be removed. Note that no-one (including myself) is ever going to implement a "rollback" button to handle a rollback automatically, as the time and energy required for this isn't worth it for how many times it may get used. Rolling back will remain a manual operation of copying the backup to /boot/config/plugins and rebooting the server.

Not 100% sure if this is a defect with Bleeding Edge or with the stock UI (not in the mood to diagnose it properly ) But, it appears that the dynamix webUI update available footer is not honoring the OS version checks. I can manually edit /tmp/plugins/dynamix.plg, bump up the OS version AND the version tags , and I get the footer stating that an update is available for dynamix, when in fact I should not be seeing that.

Old issue. Go to settings - display settings and move the users menu to the settings area Sent from my LG-D852 using Tapatalk

Certainly appears so... gfjardim must have also forgotten to update the template with <MinVer> so the app won't show up in CA, and the changelog within the .plg file, and the threads, and the OP At least he gave you a week before deprecating the plugin for some reason on 6.1.x

Why aren't you guys using the plugin instead?

This day and age there is a ton of other services (docker, vms) that need to be started / stopped that the basic array commands (mdcmd) do not take into consideration. Hence all the bugaboo going on with a replacement for powerdown now.

Will this work on a 6.1.9? or only on 6.2? If it only works for 6.2 and up (i.e. 6.1.9 users like me), should I run the .sh file from http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140 instead? 2 Different things. The plugin has nothing to do with the tunables script. The modified script in the link will work on 6.2 and 6.1.9

Advanced view, extra parameters

Yikes! Probably works though. Might want to appeal to Tom for a return to the simpler mdcmd commands. Eric gave them to me for another plugin thats fallen by the wayside. Its just hitting the webUI to do it. There is no "command" per se to accomplish starts and stops

Beginning the planning stage on this, and there is technically a problem with a delay. Namely that the versions which plugins use is a convention, not a rule. IE: We're using yyyy.mm.dd as a version (with the possibility of alpha suffixes on it) Nothing says you have to. It is still perfectly valid to put a version of say 1.0 followed by 1.2, etc (or version of alpha, beta, stable v1.0, stable v1.1, etc) (or for that matter use mm-dd-yyyy) If the convention holds true, then delays will work. But, if an author decides to go against the grain (and I thought about it once - just to be different) then it'll fail. Odds on, not going to be a problem, but just something that popped into my head. (And can't check the time of when dynamix found the update, because that date will get reset every time checks for updates are run)

Start: wget -qO /dev/null http://localhost:$(lsof -nPc emhttp | grep -Po 'TCP[^\d]*\K\d+')/update.htm?cmdStart=Start Stop: wget -qO /dev/null http://localhost:$(lsof -nPc emhttp | grep -Po 'TCP[^\d]*\K\d+')/update.htm?cmdStop=Stop

Usually, that would mean that the appfeed lost track of sickrage temporarily (out of my control - could be that phaze made a quick change to the xml and there was an error in it). But I just installed sickrage and FCP is working.

Correct Sent from my SM-T560NU using Tapatalk

It's not obvious how to if you're not used to it... http://lime-technology.com/forum/index.php?topic=32900.0 Sent from my SM-T560NU using Tapatalk

Do you have a SSD Cache drive?

Settings - Schedules

Fixes before features... AlwaysTM Fixed: CA under specific circumstances could show as not autoupdating when in fact it would Fixed: Under very specific circumstances, some plugins set to not autoupdate could Fixed: PhAzE plugins would not show up as installed if they were (due to a technical error on the .plg file vs the xml file) NOTE: All auto update settings are going to be reset back to defaults with this update. IE: Both CA and FCP will auto update, and everything else will not. You will have to adjust the settings back to what you feel is correct for your use case.

Actually rather simple, since those lines won't execute from a straight command line either. I'm sure there's a million ways of doing it, such as adding the cron via crontab, or using the AT command, etc. It threw me for a loop when I looked at the post this morning since I thought the problem was with user.scripts, and not with your script itself.

I too have been enjoying this tool, has helped with some testing I've been doing. Thanks! We're getting off-topic though, perhaps it deserves its own thread? Running the latest version - the Total column looks more like an average to me. I would have expected a sum? Is this plugin still around? The link doesn't work... Squid updated it to 6.2 here http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140 Nowhere near as thorough for 6.2 as what the next release by Pauven will do.