Do the devs actually update the plugins?

[danb35]

Ever since iX introduced the Nextcloud iocage plugin, it's been half-baked. It leaves Nextcloud in a half-installed state, requiring the user to log in to the Nextcloud instance, enter some information that's far from intuitive (and there's no good way to retrieve it once the user has closed the "installation succeeded" window), and then the user will have a complete installation.

Resolving this so that installing the plugin results in an immediately-usable Nextcloud installation is trivial, and I submitted a PR nearly two months ago to do just that. There's been zero activity on that PR. Thinking that perhaps the devs weren't notified of PRs, I submitted an issue a few weeks later (nearly six weeks ago) linking to the PR. There's similarly been zero action on that issue (which, frankly, ought to be pretty easy to resolve--such coding as was needed has already been done).

When I combine these facts with the undocumented mess that is the Asigra plugin, it's hard not to think that iX is more concerned about quantity of plugins than with their actually being useful. I'd like to be wrong about that, but I'm having trouble thinking of an alternative explanation for these observations.

 

[Jurgen Segaert]

Similar experience here.

In FreeNAS 11.3 there will be support to install plugins from a custom repo, instead of using the official repo at https://github.com/freenas/iocage-ix-plugins/

I wouldn't be surprised if iXsystems will eventually get out of the plugin business altogether, but just provide the framework and let the plugins turn into a pure community supported effort.

 

[Scareh]

on a ticket about sabnzdb plugin created 02/05/2018: (https://jira.ixsystems.com/browse/NAS-100232 )

dru wrote:
We do want to encourage community involvement.


So in short, unless someone from the community fixes this, submits a pull request and gets it fixed, it won't happen.

All in all the migration from warden to iocage has been a HUGE disappointment. All the promises about having a 1 on 1 migration, easy installation, easy updates were and are BS.
One of the main reasons the pluginsystem was that loved was the ease of installation. Guess thats not so important anymore.

 

[danb35]

So in short, unless someone from the community fixes this, submits a pull request and gets it fixed, it won't happen.

...but in this case, someone from the community (i.e., me) has fixed it and submitted a PR--and it's been sitting untouched for two months (and in other cases much longer).

We do want to encourage community involvement.

They have a strange way of going about it.

 

[Scareh]

thats why i said and gets it fixed :p

No in all seriousness, I read over that part too quickly and missed it.
Not sure what else you can do unless hoping it gets picked up here by @dru Lavigne

 

[danb35]

thats why i said and gets it fixed

Trickier, since AFAIK only iX have write access to their GitHub repos (which I don't want in any event).

 

[Jurgen Segaert]

There are a few success stories also, where plugins was fixed or a new ones were added by the community. You just have to be very patient.

Trickier, since AFAIK only iX have write access to their GitHub repos (which I don't want in any event).

... and that concern is addressed, when you'll be able to switch to a different plugin repo.

 

[miwi]

@danb35 Let me ask you this, once I pull it in how is the user able to set username / password via FreeNAS web interface while I dont want the user to touch the terminal?

 

[danb35]

once I pull it in how is the user able to set username / password via FreeNAS web interface

They're given the admin username (which is "admin", IIRC) and password (which is randomly generated) via the same popup that now gives the database and other information. Once they have that, they can log into the Nextcloud web interface; any further user management for Nextcloud (including changing the admin password) is done there. If they lose that password before logging in, though, they'll need to get it out of one of the files saved in the jail root (just as they would with the current plugin). In no case, with either the current plugin, my PR to the plugin, my scripted installation of Nextcloud, or any other method of installing Nextcloud that I'm aware of, would you be able to manage Nextcloud users via the FreeNAS web UI.

Another possibility would be to use a static admin password rather than to have it randomly generated. Advantage is that we can have a documented default; disadvantage is that it's terribly insecure if the user doesn't change the password. I don't know if it's possible to set the password to "expired" in Nextcloud, such that the user would be forced to change it on login, but that might merit some investigation.

 

[Jurgen Segaert]

@danb35 Let me ask you this, once I pull it in how is the user able to set username / password via FreeNAS web interface while I don't want the user to touch the terminal?

Feel free to upvote the feature request below to provide UI support to tweak the plugin settings from settings.json: :)
https://jira.ixsystems.com/browse/NAS-100457

Also, some improvements were made to iocage, so that the information from that post-install popup doesn't get permanently lost once you close it:
https://jira.ixsystems.com/browse/NAS-100818 (there's an example here)

 

[danb35]

...and now I see my PR won't merge, as changes have been made to the post-install.sh script that now hide all the relevant credentials from the user unless they view the /PLUGIN_INFO file inside the jail. This is not a step forward.

https://jira.ixsystems.com/browse/NAS-100818

This appears to be the reason for that change, but since the GUI doesn't support it yet, the net result is that the GUI never gives the user the info needed to complete the installation.

 

[danb35]

I don't know if it's possible to set the password to "expired" in Nextcloud, such that the user would be forced to change it on login, but that might merit some investigation.

So having done some further investigation, this doesn't appear to be possible. So we could create the admin user with a documented default password, and encourage the user to change it, but there's no mechanism to force them to do so. Advantage: simple, documented, no need for pop-ups. Disadvantage: Quite insecure if the user never bothers to change the default password. Or do what I'm doing now, generate a secure random password, which the user can still change if they want to. Much more secure, but then we need a way to expose that password to the user.

 

[danb35]

it's hard not to think that iX is more concerned about quantity of plugins than with their actually being useful.

It isn't getting any easier.