Important unRAID 6.1 Plugin System Changes


jonp

Recommended Posts

Definitely not a bad idea.  But, this situation is all because of the security changes that took place in 6.1RC series.  Will it happen again? Maybe, and then we'd be in the same boat again.  Not quite sure how much work it would take for LT to incorporate something like that.

Link to comment

I'm not sure the desire for a regular and swift release schedule for UNRAID versions is compatible with an unstable OS basis in which plugins are supposed to work. You can't have the ground shifting under the plugin authors and expect swift rewrites - it just doesn't work.

 

You need to decouple changes and enhancements to the OS and the plugins such that each can go at their own pace. Otherwise people will have to hold off and stay on 6.0 because 6.1 is incapable of running a plugin they require.

 

I'd suggest that there needs to be a 'compatibility mode' where these changes are turned off and existing plugins can continue to run - giving time for the plugin author to change their code. Eventually, when all the plugins have been updated, at the next version, that mode can be removed/reverted to being 'compatible with 6.1'.

Link to comment

I'm not sure the desire for a regular and swift release schedule for UNRAID versions is compatible with an unstable OS basis in which plugins are supposed to work. You can't have the ground shifting under the plugin authors and expect swift rewrites - it just doesn't work.

Which is partially why 6.1 is still in RC stage.  And trust me, I've bitched and bitched and bitched about the changes (either ask sparklyballs about how many praises I sing Tom when a new release comes out or look at this quote: 

 

Just some history here:

 

6.1RC-1 - Reorganized some of the underlying docker files that I rely upon for a dependency.  Update required.

6.1RC-2 - Was the beginning of the security enhancements for the unRaid UI to prevent arbitrary code execution.  Because of the restrictions placed upon where certain dynamix functions could execute from, an update was required.

6.1RC-3 - Relaxed the security restrictions for certain dynamix functions such that it was easier for plugins to operate.  Because the method used to have this plugin operate under 6.1RC-2 now violates best practice (rightfully so), today's update is required(As an aside, today's update basically undoes the changes I was required to make in RC-2)

(And each RC after that has also required an update for CA to work with it).  Especially since I try and ensure compatibility with older versions, which necessitates in my case a bunch of code that checks which version of unRaid the user is running and adjusts the plugin to account.  Trust me when I say this -> it's a PITA)  But, of the changes, the only RC that was (quite simply) a "cluster f***" to support was RC-2.  And thankfully the changes necessitated by RC-2 were rolled back when RC-3 came out.

 

But these security changes are required.  Once I realized exactly what the hole was, I was amazed that I never noticed it before.  Every single unRaid user has seen the hole (whether they realize it or not).  This needed to be patched.  All in all I really can't complain about the changes required.  I can bitch, but I can't complain.

I'd suggest that there needs to be a 'compatibility mode' where these changes are turned off and existing plugins can continue to run - giving time for the plugin author to change their code. Eventually, when all the plugins have been updated, at the next version, that mode can be removed/reverted to being 'compatible with 6.1'.

Effectively what you're doing there is introducing a security hole when you're trying to close them. 
Link to comment

You need to decouple changes and enhancements to the OS and the plugins such that each can go at their own pace.

 

unRAID is distributed as a completely self-contained OS.  Decoupling isn't in the cards.  Plugin authors can absolutely go at their own pace (or let their project's lapse). Let's try to remember, plugins are community enhancements that are not officially supported.  Yes, they can be welcome additions and some are eventually merged into the base OS, but they are not part of the advertised product's capabilities.  We took special care to notify everyone ahead of time and document the required changes.

 

Otherwise people will have to hold off and stay on 6.0 because 6.1 is incapable of running a plugin they require.

 

The FAQ in the OP addresses this pretty directly:

 

Q:  I have Plugins on my 6.0/6.0.1 installed that are in the “Unverified” child board.  How can I upgrade to 6.1 and retain all my functionality?

A:  Much of the functionality that plugins previously provided has either been merged into unRAID OS itself or can be achieved through the use of Docker Containers and/or Virtual Machines.  In the end, users have to make the choice for themselves, but please keep in mind that running a non-current version leaves you unsupported from Lime Technology, so if issues occur, you will be on your own for support.

 

Bottom line, folks will have to decide for themselves what's more important to them.  unRAID is an incredibly capable OS without any plugins installed whatsoever.

 

I'd suggest that there needs to be a 'compatibility mode' where these changes are turned off and existing plugins can continue to run - giving time for the plugin author to change their code. Eventually, when all the plugins have been updated, at the next version, that mode can be removed/reverted to being 'compatible with 6.1'.

 

Appreciate the suggestion, but you aren't asking for something that could be easily implemented nor managed. If we were purely refactoring code for the sake of refactoring code, and it was going to break plugins, that'd be one thing, but we're talking about patching a security hole.  Folks are pushing for us to take security more seriously, and we are doing just that.  What prompted the faster action here also was the fact that multiple folks were disclosing this vulnerability to us via e-mail and as such, to ignore those valid security complaints is just a bad idea.  Security and stability come before functionality.

Link to comment

Definitely not a bad idea.  But, this situation is all because of the security changes that took place in 6.1RC series.  Will it happen again? Maybe, and then we'd be in the same boat again.  Not quite sure how much work it would take for LT to incorporate something like that.

 

I think that min/max version tested cover every scenario, this is a common pattern in software development. And it also free LM to constrains themselves to something. If they want to add big thing for plugins that break compatibility, the min/max version will avoid any issue. It also fix issue in every way: for people running version N and getting plugins updates about version N+1, and people upgrading to N+1 while having lots of N compatible plugin.

 

In both case, system will now knows, and prompt the user about the risks.

 

I'd love to know what jonp think of the suggestion :D

Link to comment
  • 1 year later...

Does that mean that any plugin that worked in 6.1.x is expected to work OK in 6.2 ?

That would be worth pointing out explicitly.

No - that is not the case.  Most plugins will need changes for 6.2.    Not sure why the 6.1 thread is being referenced.

First I've heard of this. We segregated 6.0 from 6.1 plugins due to compatibility but I have never heard of anyone suggesting we do the same for 6.2. Maybe because most current plugin authors stay on top of this and have coded theirs to be compatible with either. And probably depends on what the plugin actually does whether there is any difference between 6.1 and 6.2

 

Maybe someone could spell out the differences for us, possibly a new thread should be started for this.

Link to comment

Odd. The 6.2 release thread points to this thread about 6.1 for plugin support.

 

Does that mean that any plugin that worked in 6.1.x is expected to work OK in 6.2 ?

That would be worth pointing out explicitly.

This thread is about the fundamental security changes that took place between 6.0 and 6.1  On that score, no change is necessary for anything to run on 6.2

 

There are other under the hood changes / new features with 6.2 that do necessitate plugin changes, but as already mentioned, the authors are aware of how those affect their own individual plugins (if at all)

 

By and large, the only plugins that will refuse to run under 6.2 would be those reliant upon linux kernel versions (ZFS), while others would only have minor aberrations that were easily fixed (FCP / CA) due to new features.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.