TrueNAS 13.3 Wishlist

[Patrick M. Hausen]

There's also the nut-devel port. I just sent the port maintainer an email asking for a recommendation.

 

[Redcoat]

2.8.1 is what I saw in freshports, is that not the version you are talking about?

2.8.1_3 is the latest version

 

[Patrick M. Hausen]

There's also the nut-devel port. I just sent the port maintainer an email asking for a recommendation.

Cy Schubert answered thus:

I update sysutils/nut when upstream publish a new release. nut-devel is
updated either weekly or monthly, depending on my workload here. I'd
recommend nut-devel. It includes drivers and features that will be in the
next release of nut. I use nut-devel here. It's extremely stable.

So it looks like nut-devel ist the port one wants to pick.

 

[morganL]

For the ones that do not have a ticket listed can you elaborate as to which, if any, posts in this thread they address?

The ones without tickets were identified from previous requests iX had received from our customers. They became the "core" of the new release.

 

[morganL]

2.8.1_3 is the latest version

Minor bug fixes are decided by dev team... and can be updated easily. We'd prefer versions that are "released" with notes and have support both on FreeBSD and Linux. If you need any of the specific bug fixes, please identify them here on in the ticket.

 

[morganL]

There are a few requests that have very specific reasons we are NOT doing for CORE

Better security by default would require changes in FreeBSD. Being a pioneer in this area causes us many support hours we cannot afford. We do want to make sure those that are security conscious do have the tools they need. The tools are there.

Webshell is just a nasty problem. SCALE has a whole new UI that is updated. We recommend ssh into the command line.

Boot pool compatibility... we don't think is required on FreeBSD since FreeBSD has better native ZFS support. Let us know if we are misunderstanding a major issue.

 

[victort]

There are a few requests that have very specific reasons we are NOT doing for CORE

View attachment 76148

Better security by default would require changes in FreeBSD. Being a pioneer in this area causes us many support hours we cannot afford. We do want to make sure those that are security conscious do have the tools they need. The tools are there.

Webshell is just a nasty problem. SCALE has a whole new UI that is updated. We recommend ssh into the command line.

Boot pool compatibility... we don't think is required on FreeBSD since FreeBSD has better native ZFS support. Let us know if we are misunderstanding a major issue.

I'm slightly disappointed about the web shell as I use it frequently for small commands in jails. But I suppose my (jail based) Guacamole will have to do for that now.

 

[winnielinnie]

Where in the TrueNAS Core GUI could you upgrade the boot-pool anyways?

 

[Patrick M. Hausen]

Boot pool compatibility... we don't think is required on FreeBSD since FreeBSD has better native ZFS support. Let us know if we are misunderstanding a major issue.

Spot on. If at all that is a documentation issue. I'm willing to assist in improving the documentation in this area as well as for the dreaded jail/bridge setup. As time permits.

 

[Patrick M. Hausen]

Where in the TrueNAS Core GUI could you upgrade the boot-pool anyways?

Nowhere. But I use zpool status in a shell frequently enough to get annoyed by the warning/info message. So I upgrade my boot pools.

 

[Ericloewe]

Or you could lock it down with a compatibility file, I guess. Not a big deal either way, better than GRUB's trainwreck ZFS support.

 

[danb35]

Where in the TrueNAS Core GUI could you upgrade the boot-pool anyways?

Nowhere. But there's a lot of bad information on this very forum telling people to run zpool upgrade -a rather than to do it through the GUI.

 

[morganL]

Spot on. If at all that is a documentation issue. I'm willing to assist in improving the documentation in this area as well as for the dreaded jail/bridge setup. As time permits.

Very much appreciate the constructive approach.... feedback on docs is always welcome.

 

[morganL]

Working through the list. There are a few requests that we have ruled out for SCALE or CORE.

Restore config from the hidden directories would be very messy and unreliable. There are two reliable approaches.. boot environments and TrueCommand. It can also be done manually by saving externally and then restoring. Let us know if we need to improve documentation.

While we would love OpenZFS to succeed on MacOS, we are not prepared to support that and make an ongoing commitment until there is demand and an established process. (Note: anyone from Apple need our help??) We would like to have MacOS experimenters test replication and see where the issues are.

 

[Ericloewe]

Restore config from the hidden directories would be very messy and unreliable.

Can't imagine why. The backups are being made anyway and there's already an option to upload arbitrary config files.

There are two reliable approaches.. boot environments and TrueCommand.

Neither of them addresses the use case: the user does not have a backup that they explicitly made of their config, lost their boot device, and now needs to recover said config rather than start over from scratch.

 

[danb35]

Restore config from the hidden directories would be very messy and unreliable.

Then why are you making them in the first place? You've been keeping daily config backups at 0345 in the .system dataset for several years--at least since FreeNAS 11, and I think longer than that. For what purpose? Implementation of this could be pretty straightforward:

• On pool import, check for a .system dataset.
• If present, check for config backups.
• If those are present, offer to user to restore
  • Should probably list options, maybe at least the last seven days' backups, for versions equal to or less than current
• Warn that this will reset all configuration, users, shares, etc., but won't affect data
• If user agrees, execute

Possible refinements would be in the first step--maybe only do this for the first pool import (i.e., if there isn't already a data pool present), or if the system is unconfigured (though how you'd test for that is a little unclear).

The user could, of course, do this himself--except that the configs-whatever directories are emptied when a pool is imported to a new system.

Oh, and these aren't in hidden directories; they're in /var/db/system/configs-longhexnumber.

 

[dak180]

Boot pool compatibility... we don't think is required on FreeBSD since FreeBSD has better native ZFS support. Let us know if we are misunderstanding a major issue.

The problem comes when one has an upgraded boot pool and then decides to try to sidegrade in place to SCALE.

Or you could lock it down with a compatibility file, I guess.

Which is what I would like, since right now, at least as far as I can tell, the default compatibility files that ship with ZFS are not present (and certainly not in the default locations for such) on Core.

While we would love OpenZFS to succeed on MacOS,

I think this is a misunderstanding, while it would be useful as well for someone who wanted to run zfs on macOS it is also desirable for datasets that will support network shares for macs; the usefulness of it for the zfs on macOS people is just a nice side effect.

 

[morganL]

Thanks for thinking through the issues.

The problem comes when one has an upgraded boot pool and then decides to try to sidegrade in place to SCALE.

That will only occur if the pool is upgraded via CLI???
I don't think it can be done via the UI...

Which is what I would like, since right now, at least as far as I can tell, the default compatibility files that ship with ZFS are not present (and certainly not in the default locations for such) on Core.


I think this is a misunderstanding, while it would be useful as well for someone who wanted to run zfs on macOS it is also desirable for datasets that will support network shares for macs; the usefulness of it for the zfs on macOS people is just a nice side effect.

Has this issue been experienced and reported? It should get its own ticket

 

[morganL]

Can't imagine why. The backups are being made anyway and there's already an option to upload arbitrary config files.

Developers are welcome on Discord... but its not something we thought could be made reliable.

Neither of them addresses the use case: the user does not have a backup that they explicitly made of their config, lost their boot device, and now needs to recover said config rather than start over from scratch.

TrueCommand does this...it collects the config files and simplifies restores.
We have to assume the boot device can fail.....

 

[danb35]

its not something we thought could be made reliable.

So what's the point of keeping them, then? Again, you've been doing this--keeping daily config backups at 0345L in the .system dataset--for a long time, back to the days of FreeNAS 9.3, or about ten years ago. There are discussions of it in these very forums going back at least to 2015 (I know; I just checked). TrueCommand wasn't even a twinkle in the eye at that time, and even today it doesn't use those backups. Was there ever a plan to do anything useful with them? Is there currently a plan to do anything useful with them? Or are they just there to waste space on whatever pool holds the .system dataset? Because right now they're erased when you import the pool, making them pretty much useless for the one case where they'd be needed, unless the user's smart enough to import the pool from the CLI so as to not trigger that.

And while I'll readily admit I'm not a dev, I can't understand how the process I proposed couldn't be made reliable. Checking for one or more .system/configs-longhexnumber datasets on pool import can be done reliably, right? And if so, those datasets can reliably be checked for subdirectories corresponding with TrueNAS versions, right? And then scan those directories for filenames in the form of yyyymmdd.db? Probably even do a few sqlite operations to confirm integrity and that we're actually dealing with TrueNAS config files (I presume you do these already on uploaded config files to verify that they're valid TrueNAS config files)? Present a list to the user, let the user choose, pipe that file into whatever you do with uploaded config files.

TrueCommand does this

To call TrueCommand flaky would be overly kind, to the point of dishonesty. But even assuming it worked perfectly, and it were perfectly reliable, and there weren't any capacity or usage limitations on it, and it didn't need to run on yet another system (because if it runs on the NAS, and the NAS goes down, it goes down)--none of which are true--and that you could upload one of those config backups it makes to a different system (which is unknown, at least to me), you're introducing a massive complication for no good reason. You have to have a second, always-on system just to handle those backups. Any of the many scripts in the Resources area that handle backing up the config would be infinitely better for this purpose than having to deal with TrueCommand. But far better yet would be doing something useful with the backups you've already been making for the past ten years.