TrueNAS 13.0 BETA Experiences

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Seems like we are on the opposite end of the spectrum here( as in home user vs high level IT )... You have more issues to pick with v6 while im fed up with the shenanigans going on with v4.....

(I also dont have issues when someone calls me out for being wrong.)

Well, not really IT. I'm an Internet infrastructure person, generally tasked with making things work.

I think it's very important for us to understand both the power and the failings of IPv6. One of my favorite issues for many years has been network segmentation, such as the ability to easily create multiple network segments in your home. Perhaps one for lighting controls, one for media streamers, one for wifi clients, one for wired access to PC's, one for security cameras, etc. IPv4 has always been a crapfest here because the strategy for home users has been "shove them behind a NAT" for a quarter of a century now, with stupid design decisions made to facilitate functionality in a nasty inconsistent environment. You don't find many NAT gateways (you might incorrectly refer to them as "routers") that support multiple networks, and when you do, it's often just a single DMZ. You have to go up to something like a pfSense/Vyatta/EdgeOS/RouterOS/etc to get such functionality, and if and when you do, you discover that many devices are incapable of discovering each other when they are on different networks at the same site. We've had attempts to solve this with DNS-SD, various other broadcast or multicast strategies, etc., but IPv4 has really sucked. Most of the time you end up traversing the NAT out to some cloud based pile of poo service orchestrator.

And now we have IPv6, where you can theoretically ask for a prefix larger than /64 from your upstream provider, so, finally, theoretically, there's NATIVE support for multiple networks, and yet it's all broken there too. I have literally heard the words "why would you want multiple networks" from both service providers and app/device designers who grew up with idiot-designed IPv4 uni-networks and think THAT'S GOOD.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Isn't that a defect in the product rather than the protocol?

In Cisco IOS it's simply:
Code:
ipv6 router ospf 1
 area 0 authentication ipsec spi 123 md5 1234567890ABCDEF1234567890ABCDEF

So, your working theory is ... what?

That everybody should go out and buy Cisco routers? Isn't that the broken attitude that visited crap like Cisco PoE on us?

My theory is that if you can get 25 years into a protocol's lifecycle, and FRR is just *now* talking about implementing RFC 7166 (8 years old), what exactly are those of us who'd like to implement it but aren't able to just greenfield it to accommodate idiotic IPv6 design choices to do? Where are my Vyatta options? pfSense? Non-Cisco/non-Juniper routers? It almost seems like RFC 1752 was prescient in predicting what would go awry if this became another famous design-by-IETF-committee exercise.
 

jagdtigger

Explorer
Joined
Jun 3, 2017
Messages
65
So im on rc1 now and today this little message greeted me:
The following system core files were found: htop.core. Please create a ticket at https://jira.ixsystems.com/ and attach the relevant core files along with a system debug. Once the core files have been archived and attached to the ticket, they may be removed by running the following command in shell: 'rm /var/db/system/cores/*'.
IDK about if i should submit it or not...
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
I think they genuinely do want you to submit it so that someone can at least see if there's some significant issue.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,694
So im on rc1 now and today this little message greeted me:

IDK about if i should submit it or not...
Yes, definitely.. its a new version and we need to find issues before RELEASE
 

indy

Patron
Joined
Dec 28, 2013
Messages
287
I have a change that I'm preparing to make that should significantly improve directory listing performance over SMB and potentially many other areas of SMB as well. This will transition the SMB server to using the O_RESOLVE_BENEATH open flag in FreeBSD (new feature in FreeBSD 13) to have kernel prevent any symlink escapes from share's connectpath (rather than implementing same in user-space via stat, realpath, chdir, and getwd). The practical impact of this (if / once it's merged) is that "widelinks" (symlinks outside a share path) will not be possible even if you add auxiliary parameters to the SMB share to enable them (they are not enabled by default and not supported).

If anyone wants to test these changes and give feedback, please send me a PM and I'll provide an update file.
Has this made it into 13.0 as the default or can it be easily tested/enabled?
 

jagdtigger

Explorer
Joined
Jun 3, 2017
Messages
65
Does Anyone else have issues with VM VNC's? No matter what i set as listen port all i see the log is a "ListenOnTCPPort: Address already in use" error on one vm, the other one says its listening but on a different port to what i set. Neither vnc is reachable, tried rebooting the machine but it didnt help....
 
Top