We Want to Hear Your Ideas

[garm]

About this post and voting.

Probably there are 500.000 installations of FreeNAS (I made up that number).

To this post probably 100 users posted their wishes.

10 out of those 100 users voted.

Do you think that these votes represent all 500k users?

I think that ix should take all suggestions and then put it to a vote to ALL users (not just forum). If they really want voting.

Software development is not a democracy... iX should listen to the users that bother to talk to them and then make up their own mind of what is a good product. Then they ship that product and judge success in adaptation. That is the only sane way of running a open source project, comersial project and dating.

 

[Bostjan]

It is still saner to develop what users want opposed to ship a product and judge success in adaptation. See after the fact if your time spent coding was good spend.

 

[Ericloewe]

This thread is not about voting, it's about showing interest.

 

[MrToddsFriends]

As already noted in the U3 Praise thread (that was started after the release of 11.1-U3 with it's unfortunate Samba configuration glitch):

A publicly available document describing the QA testing in detail would be a very nice thing to have. One of the benefits would be that users that are applying -Ux releases quickly would be in a better position to write bug reports in case of an error.

 

[Mike Hathaway]

Lot of good ideas, I think the Plugins need to be cleaned up, Delete Crashplan, they no longer provide a service. Have the community perhaps go through one by one, if a plugin is based on an active opensource project with a real need update it to the new jail system, if its really not used much any more ditch it. Set a standard, such as all plugs must truly click and run, I may be a little more paranoid as CrashPlan was a nightmare to get running and really did not belong in the plugins. Finally, we need duplicati as a plugin, it's really easy to get running as a jail but would compliment freenas as a plugin.

 

[danb35]

Delete Crashplan, they no longer provide a service.

Yeah, they do, it just isn't on such attractive terms any more. If we can have a plugin for Crashplan that actually works (and I think I'd include a web-VNC interface in this definition of "actually works"), then I think it'd be a good thing. Otherwise, as you say, ditch it.

 

[Mike Hathaway]

Yeah, they do, it just isn't on such attractive terms any more. If we can have a plugin for Crashplan that actually works (and I think I'd include a web-VNC interface in this definition of "actually works"), then I think it'd be a good thing. Otherwise, as you say, ditch it.

I am a corporate user of CrashPlan Enterprise. Duplicati would be a better way to go, it supports a host of backup services/storage options. Plus it has an actual web interface and back command database is a cinch to install in a jail which makes it a great candidate to be a pre-made plugin.

 

[danb35]

I'm not in any way trying to compare Crashplan with Duplicati, as I really don't know anything about the latter. But your earlier post said Crashplan no longer provides a service, and that simply isn't the case. It may be a service with a poor value proposition, or a service that's unduly difficult to support in a FreeNAS environment (and I'm certainly willing to believe the latter), but it's a service nonetheless.

I'm not going to complain loudly if the Crashplan plugin goes away, but if it can be made to work, stably, with a decent way to access its GUI (i.e., with a web-VNC arrangement), I'd vote to keep it--even if it isn't my main offsite backup solution any more.

Edit: Though I've looked at Duplicati a little, and it sounds intriguing. It seems that it overlaps the cloud sync functionality that's already present in FreeNAS, though the latter doesn't currently implement encryption (I believe that's on deck for 11.2).

 

[lukyjay]

Would like to see iX use 'agile' change methodology so we have faster and consistent incremental updates.

 

[Johnny Fartpants]

I've noticed that on installing FreeNAS onto new hardware it auto detects my chelsio card needs a newer firmware to match the driver and sorts it automatically for me. Wouldn't it be great if FreeNAS could do this for a few of the more common HBAs?

 

[Ericloewe]

Wouldn't it be great if FreeNAS could do this for a few of the more common HBAs?

It may not be possible due to licensing issues in the firmware. And LSI can't seem to keep the versions straight, much less communicate them properly to outsiders... But it would be a nice thing.

 

[JustinClift]

Would like to see iX use 'agile' change methodology so we have faster and consistent incremental updates.

Would it have to be 'agile' change methodology, or would anything that results in faster and consistent incremental updates be good enough? :)

 

[adrianwi]

I think the 'nightly' train is pretty 'agile' for anyone who wants that ;)

 

[DrKK]

https://www.youtube.com/watch?v=l1yWusiaLCM&list=PLlhwDIJVB-Kr8UVBjAmn4L_M1qNK2_JRP

https://www.youtube.com/watch?v=8RX4rtnRogE&index=3&list=PLlhwDIJVB-Kr8UVBjAmn4L_M1qNK2_JRP

"If planning is taking too long, just have the product owner do all the planning"

 

[FreeZM]

Old versus New UI

... went back to the old UI.

.... the actual UI design is a big step backwards.

... design philosophy of the new UI is wrong.
...
...
Please re-consider the UI design.

...
And last but not least: The new GUI. ... What the new GUI offers is a lot of gadgetry where its not needed in any case. Look at old GUI. It it offering a great overview, no wasted space, not that much of all the white spaces, and no need to scroll.
...
...
Just want to mention that with a more intuitiv GUI could lead to have more people who are not that "tekky".

agree 100%

 

[lukyjay]

I think the 'nightly' train is pretty 'agile' for anyone who wants that ;)

Releasing things frequently is not agile. Breaking down changes in to small increments so they can go to market sooner is agile.

Insteadof releasing a complete feature in 6 months and not knowing what your users want, release a minimum viable product in 1 month, learn how your users use and interact with it. Build data from production use of the product. Then create continuous improvement based on your data and focus on change that your users want (as opposed to what you think they want)

 

[Ericloewe]

Insteadof releasing a complete feature in 6 months and not knowing what your users want, release a minimum viable product in 1 month, learn how your users use and interact with it. Build data from production use of the product. Then create continuous improvement based on your data and focus on change that your users want (as opposed to what you think they want)

That sounds literally like the new GUI.

 

[simp]

I like this in principle, but how do you see it being implemented? The "easy" way to validate domain ownership would require that the server be directly exposed to the Internet, which is strongly discouraged. DNS validation removes that requirement, but only (effectively) works with DNS hosts who have an API, and the APIs are all different. Unless you're thinking that iX would set up a domain like freenasusers.org, let folks register to get subdomains, and provide their own DNS service for that domain...

Letsencrypt provides a DNS plugin ecosystem, Freenas could support the included plugins. See here: https://certbot.eff.org/docs/using.html#dns-plugins

There's also a list of third-party plugins: https://certbot.eff.org/docs/using.html#third-party-plugins

And a way to include custom plugins with pip: https://certbot.eff.org/docs/contributing.html#writing-your-own-plugin

 

[danb35]

Letsencrypt provides a DNS plugin ecosystem

Yeah, I'm kind of familiar with that: https://forums.freenas.org/index.php?resources/lets-encrypt-with-freenas-11-1-and-later.82/

The problem, as I mentioned in the post you quoted, is that many (probably most) DNS hosts don't have user-accessible APIs for this purpose; of the hosts that do, many aren't supported by any of the available ACME clients (acme.sh has probably the best support, but it's still far from universal); and even of those hosts with supported APIs, deploying the API key gives an attacker control over your entire DNS infrastructure in most cases.

Unless iX is going to provide its own DNS hosting service (if only for the limited purpose of validating domain control), I don't see this as being something that's practical to include in the base distro, though (as I also said in the post you quoted), I'd be interested in hearing how you (or anyone else) thinks it could be widely deployed.

 

[simp]

The problem, as I mentioned in the post you quoted, is that many (probably most) DNS hosts don't have user-accessible APIs for this purpose; of the hosts that do, many aren't supported by any of the available ACME clients (acme.sh has probably the best support, but it's still far from universal); and even of those hosts with supported APIs, deploying the API key gives an attacker control over your entire DNS infrastructure in most cases.

The way I see it, as long as it's easy to write a plugin for a new provider, that's good enough. For certbot/acme there's a documented procedure for adding a new plugin. I've done it for certbot, didn't take long.
One could even hit the non-public API endpoints if really needed. As usual, precautions apply here.

The only way DNS providers, some of whom also provide paid SSL certs, are going to get on the letsencrypt/API train is by showing them a viable business case, FreeNAS is one of them :)

One of my local DNS providers provided an API just to support letsencrypt properly. They saw a viable business case there.

Deploying an API key has a risk/benefit calculation that every admin needs to make on their own :)