TrueNAS 13.0 BETA Experiences

[Philip Robar]

Anyone else seeing network connections come and go? I'm used to long running ssh sessions timing out ("client_loop: send disconnect: Broken pipe"), but I've always been able to reconnect as soon as I notice it. Now I lose both ssh connections and SMB (which has never been a problem in the past) and when I try to reconnect the attempt hangs for a long time (pings don't even work), but eventually reconnects. Replugging the network cable on the server seems to also to get things working again. I've only just noticed this so I don't have a better characterization of the porblem.

Client: 2011 iMac using Thunderbolt ethernet adaptor.
Server: Lenovo TS140 with an onboard Intel I217LM NIC.

 

[emk2203]

Does anyone else have an issue with 13.0-BETA and DHCP? The host name is not sent back to the DHCP server anymore. Scratching my head here, I don't even know if it's just TrueNAS or some upgrade of the DHCP server which causes it. Happens only with the TrueNAS server.

When I do

Code:

sudo service dhclient restart bge0

, I get

Code:

'bge0' is not a DHCP-enabled interface
dhclient already running?  (pid=563).

as response. bge0 is DHCP-enabled, though.

 

[freakdude]

If you wait long enough (serveral minutes in my case) your system should eventually finish booting. There are multiple discussions about this in the FreeBSD forums. I've got multiple links opened, but I haven't started reading yet. Just search on the error message. (I see this error on my SuperMicro X8SI6-F, but not my Lenovo ThinkServer TS140.)

Thank you, I have tried your recommendation. I did the upgrade, waited for it to say "Root mount waiting for: CAM", then went to bed. When I woke up 8 hours later it was still saying the same thing and was not accessible. I had to roll back again.

 

[Stranger2.0]

zpool replace ... but!
Never replace a failed drive in TrueNAS with a raw disk device of the new disk. You must create a partition table on the new disk (easiest way is to copy via gpart backup | gpart restore from another device) and then use /dev/gptid/<rawuuid-of-partition> as the replacement disk device.

If you are facing the situation right now, we can help you through the process.

I'm also having this same exact problem (found this thread from google :P), trying to replace a failing drive and the button isn't working, clicking it just throws an error into the browser console, I provided an image below of that error.

If you don't mind, can you guide me through the CLI to get this sorted out? I never used it before so I'm clueless on the process and the chain of commands needed to get to that point :)

 

[Philip Robar]

If you don't mind, can you guide me through the CLI to get this sorted out? I never used it before so I'm clueless on the process and the chain of commands needed to get to that point :)

See this link: https://www.truenas.com/community/threads/cannot-replace-disks-in-pool.91490/post-633958

I would suggest using the rawuuid for each disk in the zpool replace command.

 

[rubydesign]

So i had a new stable install anyway and syncthing didn't work on that so i tried the beta.

And syncthing does not work here either. Same message i saw else where

Install​

Error: sync had a failure Exception: RuntimeError Message: pkg error: - syncthing : Refusing to fetch artifact and run post_install.sh! Partial plugin destroyed

since it is an official plugin i thought i mention it.

 

[jagdtigger]

As a result, IPv4 still remains the de-facto standard.

I think the change is long overdue, maybe its a pain to deal with ipv6 but id get over it sooner rather than later. Especially considering how many isp's cheap out and deploy cgn while they ignore v6. Its one hell of a gory fight to beat a pubic v4 address out of a isp, personal experience sadly. And just to make it worse they tried to switch my connection to cgn silently several times already, just so they can get an unpleasant call from me within minutes.....

 

[Volts]

Its one hell of a gory fight to beat a pubic v4 address out of a isp, personal experience sadly.

That, or they're completely wasteful with them.

 

[morganL]

Does anyone else have an issue with 13.0-BETA and DHCP? The host name is not sent back to the DHCP server anymore. Scratching my head here, I don't even know if it's just TrueNAS or some upgrade of the DHCP server which causes it. Happens only with the TrueNAS server.

When I do

Code:

sudo service dhclient restart bge0

, I get

Code:

'bge0' is not a DHCP-enabled interface
dhclient already running?  (pid=563).

as response. bge0 is DHCP-enabled, though.

This is a known bug and fixed in 13.0-RC1 .. https://jira.ixsystems.com/browse/NAS-115053


Other bug fixes in RC1 can be found here: https://jira.ixsystems.com/issues/?...rsion = 13800 ORDER BY priority DESC, key ASC

 

[jgreco]

I think the change is long overdue, maybe its a pain to deal with ipv6 but id get over it sooner rather than later. Especially considering how many isp's cheap out and deploy cgn while they ignore v6. Its one hell of a gory fight to beat a pubic v4 address out of a isp, personal experience sadly. And just to make it worse they tried to switch my connection to cgn silently several times already, just so they can get an unpleasant call from me within minutes.....

It's not just a pain to deal with, but actually quite difficult. There's just been a long thread on this on NANOG about it, some of which is good reading, some of which isn't (as per NANOG usual). One of the early RFC's for IPv6 noted that it would be best for the new protocol to be as close to a drop-in replacement as possible and for it not to be an opportunity to reinvent large swaths of strategy, or else it would become a problem to implement. This turned out to be prescient, especially in light of people needing to run dual stacks that work somewhat differently. This is what happens when people in ivory towers are allowed to design stuff while being too far away from those of us in the trenches to be able to practically wring their damn necks.

 

[jagdtigger]

It's not just a pain to deal with, but actually quite difficult. There's just been a long thread on this on NANOG about it, some of which is good reading, some of which isn't (as per NANOG usual). One of the early RFC's for IPv6 noted that it would be best for the new protocol to be as close to a drop-in replacement as possible and for it not to be an opportunity to reinvent large swaths of strategy, or else it would become a problem to implement. This turned out to be prescient, especially in light of people needing to run dual stacks that work somewhat differently. This is what happens when people in ivory towers are allowed to design stuff while being too far away from those of us in the trenches to be able to practically wring their damn necks.

I wonder if its really that hard or is it just that ppl are reluctant to learn new things. (No offense but more often than not its the latter in my experience.....) IPv4 at this point is Frankenstein's Monster with all the after the fact additions and band-aids to keep it from shattering, practically its way past its expiration date. We cant keep on adding more and more complexities just because the new version is "different"....

 

[jgreco]

I wonder if its really that hard or is it just that ppl are reluctant to learn new things.

It really is that hard. As an example, OSPF, a popular interior gateway protocol for building autonomous systems (the building blocks of the Internet), has authentication mechanisms for IPv4, and is relatively easy to deploy. However, the asshats that designed OSPF6 designed it *without* authentication mechanisms, on the theory that it should be done via IPsec, but made that decision based on the way they felt the world SHOULD work, rather than what was actually practical. So here we are, many years later, and there still isn't integrated support for a routing protocol engine such as FRR on FreeBSD to set up authentication for OSPF routing on IPv6. If you are going to make things MUCH more complicated and also make that the ONLY choice for how to do things, then you should probably also be required to make sure that support for your complicated scheme is actually widely available and tested, not just something available on a handful of vendor routing platforms.

 

[jagdtigger]

but made that decision based on the way they felt the world SHOULD work, rather than what was actually practical.

How is it exactly practical to develop and maintain your own auth when you have it readily available inside the v6 stack? IPSec is part of v6 from the get-go unlike v4 where it was an afterthought....
Every beginning is hard, im sure there was a predecessor to OSPF and it was a pain to let go of the old....

 

[morganL]

How is it exactly practical to develop and maintain your own auth when you have it readily available inside the v6 stack? IPSec is part of v6 from the get-go unlike v4 where it was an afterthought....
Every beginning is hard, im sure there was a predecessor to OSPF and it was a pain to let go of the old....

The predecessor to OSPF was IGRP.. a proprietary protocol from Cisco.. designed well before the hacking of networks was a major thing.

It took a decade or more to update the user base... in the meantime, Cisco became very large.

 

[jgreco]

How is it exactly practical to develop and maintain your own auth when you have it readily available inside the v6 stack? IPSec is part of v6 from the get-go unlike v4 where it was an afterthought....

It's exactly practical to maintain auth when the work already exists in the protocol that you're starting from and you strip it out.

IPSec may be "part of v6 from the get-go" but that's such an incredibly naive thing to say, because it bears all the hallmarks of the arrogance of the ivory tower idiots who design this stuff without ever having to implement it in practice.

Today's homework assignment for you:

Install FRR on FreeBSD (or, I suspect, Linux).

Configure OSPFv3 (or OSPF6) from the zebra-cli prompt, exclusively, with authentication.

Same thing applies in Vyatta, EdgeOS, etc.

Every beginning is hard, im sure there was a predecessor to OSPF and it was a pain to let go of the old....

Except this has been broken for more than twenty frickin' years (RFC 2740, **1999**). The point here is that we've been "deploying" IPv6 for more than two decades and there are still catastrophic shortcomings in the current implementations that make it very difficult to implement in practice.

RFC 1752 made it clear that the successor "protocol must have a straightforward transition plan from IPv4" and this is clearly and sorely lacking in IPv6, which has served as an experimental playground for vendors, and not particularly well supported in many devices, especially (and catastrophically) including many core networking devices.

If auth were "readily available" in the IPv6 stack, please do explain why access to it isn't actually present in a number of significant contemporary routing protocol stacks.

Please note that I unapologetically call bull$#!+ on stuff said that is clearly bull$#!+, especially where it's caused me pain and problems. I am not blaming you for the status quo. There are enough other people with that on their hands.

 

[morganL]

Except this has been broken for more than twenty frickin' years (RFC 2740, **1999**). The point here is that we've been "deploying" IPv6 for more than two decades and there are still catastrophic shortcomings in the current implementations that make it very difficult to implement in practice.

Even though I'm an IP routing guy from the 1990s.... I think we are officially off topic

TrueNAS 13.0 WILL NOT SOLVE routing authentication issues for IPv6

 

[Volts]

I felt like I was the crazy one for 10+ years, asking why IPSec was welded into IPv6.

Being told with a straight face that in order to avoid nesting and layering violations that the protocol itself should include such violations.

Second-system syndrome is a cancer.

 

[jgreco]

Even though I'm an IP routing guy from the 1990s.... I think we are officially off topic

TrueNAS 13.0 WILL NOT SOLVE routing authentication issues for IPv6

The topic of why IPv6 adoption has been so slow, or why IPv6 support in TrueNAS and so many other products are at best afterthoughts, are surely topical to a product class where two of the three letters in "NAS" are "Network Attached". If networking is nontopical, then wtf.

 

[jagdtigger]

It's exactly practical to maintain auth when the work already exists in the protocol that you're starting from and you strip it out.

IPSec may be "part of v6 from the get-go" but that's such an incredibly naive thing to say, because it bears all the hallmarks of the arrogance of the ivory tower idiots who design this stuff without ever having to implement it in practice.

Today's homework assignment for you:

Install FRR on FreeBSD (or, I suspect, Linux).

Configure OSPFv3 (or OSPF6) from the zebra-cli prompt, exclusively, with authentication.

Same thing applies in Vyatta, EdgeOS, etc.



Except this has been broken for more than twenty frickin' years (RFC 2740, **1999**). The point here is that we've been "deploying" IPv6 for more than two decades and there are still catastrophic shortcomings in the current implementations that make it very difficult to implement in practice.

RFC 1752 made it clear that the successor "protocol must have a straightforward transition plan from IPv4" and this is clearly and sorely lacking in IPv6, which has served as an experimental playground for vendors, and not particularly well supported in many devices, especially (and catastrophically) including many core networking devices.

If auth were "readily available" in the IPv6 stack, please do explain why access to it isn't actually present in a number of significant contemporary routing protocol stacks.

Please note that I unapologetically call bull$#!+ on stuff said that is clearly bull$#!+, especially where it's caused me pain and problems. I am not blaming you for the status quo. There are enough other people with that on their hands.

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.)

 

[Patrick M. Hausen]

Today's homework assignment for you:

Install FRR on FreeBSD (or, I suspect, Linux).
Configure OSPFv3 (or OSPF6) from the zebra-cli prompt, exclusively, with authentication.
Same thing applies in Vyatta, EdgeOS, etc.

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