TrueNAS CORE 13.0-U6.3 and 13.3-U1 Are Now Available!

Announcements
41

As a potentially new tmux user this can be a starting point:

1 Like
42

Thanks, but as i said in my first post. TMUX is a constant thing here on my right screen/(maybe the wrong word) TFT/Monitor.

image
image1920Ɨ1188 293 KB

43

Apologies, I neglected to read the quoted post of the post I was quoting.
While you can feature request screen, I highly doubt it will see any traction, especially since CORE development is tapering off.

44

Yeah, you are probably right. I could do some shenanigans as i also did once with vim which i basically sources from an jail. That is currently broken but maybe i get it working again and screen might also play alongā€¦

root@nas ~ # whence -f vim
vim () {
        (
                export JAIL=/mnt/p0/iocage/jails/apt-proxy/root
                export VIMRUNTIME=$JAIL/usr/local/share/vim/vim91
                export PATH=$(print -l $JAIL/usr/{,var/,local/}{{s,}bin,lib}|tr \  :):$PATH
                command vim $@
        )
}

EDIT: it works again :stuck_out_tongue:
EDIT2: with that i get syntax, colour ā€¦ just like at home

2 Likes
45

Iā€™ve been running TrueNAS Core for some years now, without any problems.
A few days a go I installed updates to upgrade Core from 13.0-U6.2 to 13.0-U6.3.
The result had broken the authentication of AD Domain users against the domain controller. The error message pointed to a DNS mis-configuration, but I was unable to find a problem with DNS config (none existed before the uptrade).
I reverted to the previous boot environment, and the problem had gone away.
I would like (and am obliged) to install security updates whenever these become available, so staying on an old version indefinitely isnā€™t an option for me. Iā€™ve been considering migrating to Scale, but that option requires that I upgrade to the latest Core version. Iā€™m snookered. Any ideas?

46

I donā€™t have that problem with 13.0-U6.3. Havenā€™t updated many systems yet but none made any problem so far.

EDIT: and just did another. everything checks out there aswell :+1:

47

There we no AD-related changes in 13.0-U6.3.

48

Did you confirm DNS was working fine??

If you want to troubleshoot, Iā€™d suggest starting a new thread/post and post a link to the thread here.

49

Thank you @Captain_Morgan - my thread is https://forums.truenas.com/t/debugging-a-failed-upgrade-to-core-13-0-u6-3/26954 (I hope I did the right thing?)

50

That thread appears to be brokenā€¦ can you test it and revise.

It is IN FACT a private message and cannot be read. It should have been a new post in general.

Unsolved at this stage.

51

Both are either private or plainly broken/deletedā€¦ because itā€™s the same link.

3 Likes
52

Solved - thereā€™s an un-documented change of behaviour in TrueNAS, seen in both Core 13-0-u6-3 and Scale of the same generation:
TrueNAS will refuse to join (or work with) a local AD domain if thereā€™s a public DNS present in DNS config, even if the public DNS server is just the 3rd entry in the list of DNS servers.

Formerly-working config (no longer works):

 - dns1-local.ip
 - dns2-local.ip
 - dns3-public-ip
2 Likes
53

For any system to participate in an AD domain the list of DNS servers must contain the DCs and only the DCs. This has always been the case.

The DNS server list in almost all resolver libraries is not prioritized but used in round-robin or random fashion.

What are people trying to achieve by entering a public DNS server in addition to one or more local ones, anyway? If you have a single DC and that fails, itā€™s game over until the system is brought back to operation, anyway. No login, no file sharing, no printing. Close office until service is restored. Better have more than one DC.

4 Likes
54

That just isnā€™t true. DNS servers do NOT need to be DCs. There are certain DNS records that must only point to DCs, but any DNS server can serve those records. Here is an article that shows where to retrieve the required records if the external DNS server doesnā€™t support dynamic updates.

55

Extra validation was added in 13.0-U4 because users were setting 8.8.8.8 and such as their second or third nameserver and experiencing intermittent breakage / filing bug tickets. This was done by backporting AD-validation code from SCALE to Core.

The way we check whether a nameserver will work for us is to query kerberos-related SRV records from it. If we canā€™t use the nameserver to find KDCs then we raise an error because itā€™s a broken configuration. We donā€™t go out of the way to check whether it is AD. We simply check whether its suitable for the purposes of kerberos libraries.

3 Likes
56

You are correct. I did simplify a bit.

But look at the documentation you linked - IMHO thatā€™s clearly addressed at network professionals who already know what they are doing, anyway.

You could also configure all mandatory AD zones as secondary on a non-MS server, e.g. for a remote location without a DC, to speed up lookups.

But having DCs and 8.8.8.8 in your list of DNS servers will break things.

Kind regards,
Patrick

1 Like