Everything posted by NAS
-
Preclear plugin
- Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array
That is certainly not the case here. I have never seen anything other than "Stop". For example this is what I see this now:- Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array
Polite bump- Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array
Apologies if this is covered but this thread is too long to review. When you use preclear, once complete you are left with two confusingly contradictory options: "Preclear Finished Successfully!" and "Stop preclear". Should the "Stop preclear" Red X still be available when preclear is no longer running? Or is the nature of what "Stop preclear" means different after it completes and the wording is just confusing in that context.?- ISCSI Support
You guys have me convinced now. The Blizard and FreeNAS posts sealed the deal on the argument for me.- Preclear plugin
Apologies if I missed the reply, this is a popular thread. How do I opt out of this permanently.- Ability to remove drive from array without having to destroy parity
Just curious if this is being worked on or at least actively considered. I raise it again as I am currently embarking on a new disk refresh and upgrade (3rd since we started discussing this) and it still maintain that this would both be a genuinely useful / time saving feature but also a Unique Selling Point that your competitors simply cant offer (due to the nature of the RAID they use) should be grabbed with both hands IMHO- Preclear plugin
How do I permanently opt out of : Preclear Disks Install Statistics Plugin This plugin is used to send statistics anonymously using Google Forms and TOR. Don't worry, you will be asked before sending every report. so that it is not installed by mistake?- snmp
given how far unRAID has come I have to say I strongly agree.- SSDs as array drives question
Superb summary. Can I suggest that in the interim including some easy indicator in emHTTP as to which of the 3 states ("DX_TRIM" or "DZ_TRIM" or "Unsupported") should be added ASAP. This will raise visibilty in the community and start the natural process of recommendations and more importantly removals- Release Methodology
Now that 6.2 is out we need to complete this methodology ASAP. especially in light of the fact 6.2 already is missing one CVE (Curl CVE-2016-7167). Crazy as it sounds the 6.2.1 release clock is already T plus 2 days- Release Methodology
There is no more 'call home' starting in 6.2.0-rc5 unless you are using a Trial key. Trial will always require internet access in order to validate. If you want to stay on "stable" releases, you won't have to do anything: the built-in "unRAIDServer.plg" file will trigger updates whenever a new stable release is available. We will also create a post in the Announcement board for new stable releases. If you want to use the latest and greatest development, you will install the "unRAIDServer-next.plg" file. This will trigger updates whenever a new development release is available. We will typically not post announcements for these releases. We will provide more details upon release of 6.2 stable. I would have preferred that we iron out the final wording before 6.2 but I accept that not everything can be the top of the todo list. Lets put a pin in this until 6.2 is released but at that point it has to becomes a priority and certainly needs completed before 6.2.1.- Clear all notifications button.....
nice work that man- Release Methodology
I strongly agree with all of above but at the same time I think if we keep focusing solely on previous mistakes without suggesting specific fixes (preferably in terms of methodology wording changes) then we are doomed to be ignored here and nothing will be fixed. We have made big progress by getting some commitment to change so we should captialise on this and just be more positive to make this a positive toned thread and not a negative one. However feel free to cry havoc if we continute to repeat past mistakes, I plan to but that cant happen until at least 1 month after the first post 6.2 release CVE. To that end I quote my initial comments which we havent addressed yet and a further issue I want to point out again though that since the conversations were split from the RC thread in an endeavour to clear the air and make progress we have made no appreciable difference to any policy. I am happy to help but this has to be a two way street. I wont continue to waste effort talking to myself in the hope someone answers me one day.- Release Methodology
We really need to start making moves on firming up and expanding this Release Methodology and the privacy policy. These IMO should be roadblocks for the 6.2 release and not independent "at some future date" deliverables. Currently we are not making any progress at all. I understand everyone is busy but that is not going to change any time soon and if we dont do it we can expect the same kind of upswell as we seen over the last few weeks in the 6.2 release discussions which will sour what should be a big event.- Release Methodology
Seems sensible. You might as well think about the "call home" wording now because it is going to be asked soon since all definitions so far have been for beta and RC (which no longer exist so the wording becomes invalid). You are also going to be asked how the community will test all their eclectic setups and hardware if there is no beta cycle.- Release Methodology
As spotted by other users here http://lime-technology.com/forum/index.php?topic=51605.msg495311#msg495311 the actual defitnion of RC for unRAID is non standard and needs defined.- Release Methodology
Indeed but let me reword.... RC5 could simply be RC4 without the call home. This would IMHO be the current best compromise for those that want the security fixes but dont accept the call home. On that note the release methodology does not contain any call home provision so we need to add that to be clear when it will and wont be used.- Release Methodology
I agree in an ideal world 6.1.10 should happen but we have to realistic and pick the battles we can win, it is simply not viable at this point to ask for a second parallel beta cycle (because a 6 month cumulative security update that includes many core packages and more than one kernel bump is too big a change to release as stable directly) . The time for 6.1.10 was months ago, in fact we should be on about 6.1.16 now. RC5 without the call home within a week is the battle we should fight.- Release Methodology
Then we have no choice but we release 6.2 as soon as possible (warts and all) as the fix the the 6.1 series security holes. I do like where we are going in terms of long term methodology fixes but we cant forget that we are in a terrible position today.- Release Methodology
I am hoping I will no longer be a lone voice in the wilderness.- docker compose?
+1 It is pretty unusual we dont have it now. Could this be part of nerd tools?- Release Methodology
No one on this forum has been more vocal for updating 6.1.9 with security releases than me but we have to be pragmatic. I see this post as a confirmation of what will happen form 6.2 onwards were we can start with a blank slate and get it right. Its not ideal but its a reality even I can live with. Keep in mind it is highly likely this process will be put to the test with days and certainly not more than a few weeks from the 6.2 release. As far as I am aware there has not been a single month in 2016 that a SSA has not been release that would require a new unRAID. The downside of this is that the current plan means that no one will have an uptime greater than one month ever again.- Release Methodology
Clear, concise and on thorough. Few suggestions: 1. You likely plan to do this anyway but once you are happy, these words need promoted to the website and away from the forum 2. You need a private means of reporting security issues so that you have a reasonable chance of closing the 0-day before it is made public. Otherwise the risk of user breaches is much greater and the pressure on you to fix faster is unnecessarily high. I drafted an example for you... wording similar to this would probably cover it: If you discover a security issue in an Limetech LLC product or service, we ask that you report it to us confidentially in order to protect the security of our users and services. Please email the details to [email protected]. On receipt we will respond directly to acknowledge your report and if necessary open a dialogue to better understand the details. From here we will plan the mitigation and set a timeline for a new release or patch. As is ethical we will credit the security report to the individual/group/researcher within any news items and also the release notes. 3. You are mixing security policy words and release methodology although given how clear and related they are I like where it is going. 4. You need a means to inform users. Currently unless you have notifications set there is a large chance you will not see a new release. Also there is no urgency levels on these notifications and also as we have seen many users have unRAID specifically setup with no internet. You dont need to force users into any type of scheme but one should exist. 5. It is not clear yet how and when packages are updated i.e. https://lime-technology.com/forum/index.php?topic=51308.msg494236#msg494236 I have no strong preference here as all options have pros and cons, we just need to decide on one so users know what to expect. On a general note though I have to say that whilst the 6.1 line was being patched both the time line and the release notes were very good. I dont see any need to do more than this and this push to tie up and formalise the process get a huge thumbs up from me.- Disable auto array start when there's a disk missing
The shares not being up is the only universal notification you know users have and we should always defer to that safest default. To go beyind this actions like this need to be taken in the context of notifications being setup per install. We should not assume users here represent the actual userbase, most wont have more the the very basic setup. - Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array