TrueNAS 13.3 Wishlist

[Kris Moore]

Just to help level-set some expectations here. We're already nearly at code-freeze for the upcoming 13.13, we are not expecting any major new efforts to land, especially items that need any significant UI or Middleware work. Items that can be considered are backend updates, I.E. newer bhyve or other packages which will come in via our normal ports updates, minor bugfixes, that kind of thing.

 

[Kris Moore]

My absolute #1 request:

Bhyve with Ubuntu keeps locking up
<https://ixsystems.atlassian.net/browse/NAS-122108>

(I went as far as rebuilding bhyve from source to get this fix from upstream.)

@morganL can the ticket please please be reopened so it's not lost / forgotten.

A general answer to this is to use KVM on SCALE :) If upstream fixes don't work, we don't intend to do any further investigation into bhyve issues.

We moved our entire iX infrastructure from bhyve and never looked back, it just had too many random issues like this, weird lockups, etc.

 

[seanm]

We want to know which ones are required....so we can decide how we could handle.

@morganL <https://ixsystems.atlassian.net/browse/NAS-127384>

 

[Patrick M. Hausen]

A general answer to this is to use KVM on SCALE :) If upstream fixes don't work, we don't intend to do any further investigation into bhyve issues.

Upstream fixes do work and there is a large momentum in bhyve development atm. If you go to FreeBSD 13.3 I expect most issues to be resolved.

Why don't you join one of the weekly bhyve calls just once?

BTW: did you really remove the shell from the UI for good? Why is it impossible to fix the web UI shell?

 

[Kris Moore]

Upstream fixes do work and there is a large momentum in bhyve development atm. If you go to FreeBSD 13.3 I expect most issues to be resolved.

Why don't you join one of the weekly bhyve calls just once?

Been there, done that. Just don't see a reason to get too excited over Bhyve things these days. It's like being excited that your favorite product has caught up to what everybody else had a decade before. Same old BSD story over and over. "Wifi is almost caught up", "Pkg is almost caught up", "Drivers are almost caught up", it never ends! I'm trying to keep an eye towards the future at whats coming in hot now, and not be stuck waiting 5-10 years later for FreeBSD to "catch up" while the rest of the world has already solved those problems and moved on to another set of more interesting challenges

BTW: did you really remove the shell from the UI for good? Why is it impossible to fix the web UI shell?

Yes, pulling that in from SCALE brings with it a bunch of other depends and further churn that we want to avoid on the UI side. That and we are trying to encourage folks to do less mucking about in the shell in general and use SSH if you really need to. It's better than any web-shell hands down.

 

[danb35]

Same old BSD story over and over.

...and I think that, that more than anything else, tells us what the future of CORE is.

 

[Kris Moore]

...and I think that, that more than anything else, tells us what the future of CORE is.

Yea, believe me, I wish it wasn't so and I could say with a straight face that FreeBSD is on top of staying current and the best place to build with modern technology building blocks. That would have been the easy button for iX, would have saved us a lot of trouble. But sadly it's not the case. And that's not just iX, most other vendors have come to the same conclusion. If you have a very limited scope product, FreeBSD is still a great option though, so no it's not 'dying', just used for more limited scope applications.

 

[Patrick M. Hausen]

Been there, done that. Just don't see a reason to get too excited over Bhyve things these days. It's like being excited that your favorite product has caught up to what everybody else had a decade before. Same old BSD story over and over. "Wifi is almost caught up", "Pkg is almost caught up", "Drivers are almost caught up", it never ends! I'm trying to keep an eye towards the future at whats coming in hot now, and not be stuck waiting 5-10 years later for FreeBSD to "catch up" while the rest of the world has already solved those problems and moved on to another set of more interesting challenges

I can agree in some areas like WiFi but not in general. Still waiting for Linux to catch up in filesystems or containers. No, containerd is no match for jails, technology wise. The networking is a mess, still no IPv6 in reasonable shape ...

Pkg is so much superior to any Linux package system - poudriere is fantastic, getting from source to binary packages on any Linux distro is still a black art. Which Linux distribution allows you to check out *the* source tree, type "make ...", get some coffee and find a ready to boot ISO image with exactly that state you checked out?

Infrastructure, not product!

If I could go back in time I'd love to tell PHK that we need a jail ecosystem with preconfigured images.

Anyway ...

Yes, pulling that in from SCALE brings with it a bunch of other depends and further churn that we want to avoid on the UI side. That and we are trying to encourage folks to do less mucking about in the shell in general and use SSH if you really need to. It's better than any web-shell hands down.

Perfectly agree with this one. We should encourage users to learn SSH basics. Not for daily operation, but if the ... hits the fan, the command line is indispensable for troubleshooting.

Kind regards,
Patrick

 

[danb35]

We should encourage users to learn SSH basics.

...especially since even Windows has shipped with a SSH client for several years now. If you have a terminal window open, it's far faster to ssh user@truenas (particularly if you're using public-key authentication as you should be) than to open the web GUI and navigate to the graphical shell from there. If you don't have a terminal window open, eh, why not? But even then it's quicker.

 

[Arwen]

When comparing FreeBSD kernel to Linux kernel, the thing that bothers me, (and as a Unix SysAdmin actually on the job supporting Linux), is that FreeBSD seems to prioritizes stability. But, Linux goes out of it's way to break kernel interface. This forces a re-compile for out of tree modules on ANY kernel change. Minor number or major number, does not mater.

This Linux kernel instability has bitten us not a few times a year, but a dozen times per year. Year after year. And yes, that is with a PAID version of Linux that is supposed to be Enterprise quality, RHEL. Plus, this is supposed to be a stable kernel distro...

Just in the few years SCALE has been out, we have seen multiple, (as in >10), demands for a newer Linux kernel to support some feature. This is somewhat expected as Debian could be a bit behind from main release kernels.

However, this requirement of new kernels to either support new hardware, or fix bugs, is going to be endless. Even with a Linux kernel less than 6 months old, someone is going to be wanting / demanding a later kernel to support their wizbang dohicky thingabob that won't run on older kernels.


My takeaway from this is that TrueNAS SCALE should count on releasing new kernels at least twice a year. But, probably more likely at least quarterly.

And even then, having to hop on to the kernel upgrade when a serious security flaw, stability bug or data integrity bug is found. Which happens several times a year.

 

[rvassar]

When comparing FreeBSD kernel to Linux kernel, the thing that bothers me, (and as a Unix SysAdmin actually on the job supporting Linux), is that FreeBSD seems to prioritizes stability. But, Linux goes out of it's way to break kernel interface. This forces a re-compile for out of tree modules on ANY kernel change. Minor number or major number, does not mater.

This Linux kernel instability has bitten us not a few times a year, but a dozen times per year. Year after year. And yes, that is with a PAID version of Linux that is supposed to be Enterprise quality, RHEL. Plus, this is supposed to be a stable kernel distro...

Just in the few years SCALE has been out, we have seen multiple, (as in >10), demands for a newer Linux kernel to support some feature. This is somewhat expected as Debian could be a bit behind from main release kernels.

However, this requirement of new kernels to either support new hardware, or fix bugs, is going to be endless. Even with a Linux kernel less than 6 months old, someone is going to be wanting / demanding a later kernel to support their wizbang dohicky thingabob that won't run on older kernels.


My takeaway from this is that TrueNAS SCALE should count on releasing new kernels at least twice a year. But, probably more likely at least quarterly.

And even then, having to hop on to the kernel upgrade when a serious security flaw, stability bug or data integrity bug is found. Which happens several times a year.

I currently work for a large vendor that faces this same problem. The "Enterprise" claiming distro's typically try and provide some kernel ABI stability, but it can be hit or miss at times. The Debian/Ubuntu derived stuff is a complete waste of effort. They drop a new kernel basically once a month, and break any driver you self-compile. Offering support for Ubuntu requires you to work their system to upstream your driver into their kernel. That can take months, and often you get differing levels of acceptance. Ala one distro allows ioctl()'s and another rejects them... This is why you see so much focus on a couple of the big name distro's and even major distro's like Oracle Linux get relegated to tier 3.

 

[mb17]

Windows admin here.... Linux hobbyist at best....

I think Linux can be just as stable as FreeBSD in most situations (I can't speak to the multi million dollar environments). The problem is that Linux is becoming more and more mainstream and dare I say, Windows like. Because it is so mainstream, everyone wants it to run everywhere. You can't maintain ultimate stability and maximum compatibility at the same time, hence my "Windows like" comment.

1. As a product line, Enterprise stability comes with hardware control and testing.
2. As a growing piece of software, especially open source, continuous enhancements and user base are key.

FreeBSD can excel at #1 above but only Linux is able to address both #1 and the fast paced nature of #2.

Feel free to ignore me, just thought I would post my 2 cents.

 

[nasbdh9]

Considering that TC 13.1 has been postponed to the RC version in April 24, samba 4.20 should be a version update worth considering.

 

[ask]

I tried TrueNAS for the first time this weekend, so I installed the latest nightly figuring I could test a "new user experience" that most of you might not try.

I created a new user, and couldn't get authentication to samba to work.

I noticed that `pdbedit` didn't seem to show the expected entries. For example if I set the password for `username` then the user list according to `pdbedit` is:

```
# pdbedit -L
added interface ixl0 ip=...
added interface ixl0 ip=...
added interface ixl0 ip=192.168...
added interface vlan24 ip=192.168....
group:4294967295:username
```
... but no `username:1000:username` entry.

Manually setting the user password with `pdbedit` got the user working.

 

[Patrick M. Hausen]

I created a new user, and couldn't get authentication to samba to work.

Did you check "Windows User" in the user creation form?

 

[ask]

Did you check "Windows User" in the user creation form?

I checked "Samba Authentication", but not "Microsoft Account".

Ask

 

[Kris Moore]

When comparing FreeBSD kernel to Linux kernel, the thing that bothers me, (and as a Unix SysAdmin actually on the job supporting Linux), is that FreeBSD seems to prioritizes stability. But, Linux goes out of it's way to break kernel interface. This forces a re-compile for out of tree modules on ANY kernel change. Minor number or major number, does not mater.

The way we designed the build system for SCALE its been pretty easy for us to pull kernel updates and rebuild only a handful of things to correspond with it. We build from source anyway, so not as huge of a burden as we initially feared.

My takeaway from this is that TrueNAS SCALE should count on releasing new kernels at least twice a year. But, probably more likely at least quarterly.

We follow the LTS releases of the kernel, which means yearly we get one major update and then can do smaller updates in point releases of TrueNAS. This seems the best fit for us right now to ensure we stay on top of new hardware support with kernel updates on a frequent-enough basis. Not too aggressive, but still faster than our pace previously in TrueNAS / FreeNAS history.

 

[morganL]

Sorry, I should have said:

Support better than ssh-rsa keys by default: <https://ixsystems.atlassian.net/browse/NAS-109023>

Changing default behaviour requires very broad community support. There are many production systems using the current defaults. Is that really necessary?

 

[morganL]

@morganL <https://ixsystems.atlassian.net/browse/NAS-127384>

Specifically EasyDNS.... so that other people can vote.
I assume the SCALE ACME DNS works with EasyDNS??

 

[Ericloewe]

I'm not a cryptographer, but my understanding is that RSA (with proper hashes) is thought to be about as good as elliptic curves. The default for RSA is probably sha256, from upstream OpenSSH.