Messages

Thanks guys.
Sorry I've not been able to put more time into it, due to things 'IRL'.

Digressing a bit from the OT, but Aarch64 is tier 1 supported since 13.0. Seems reasonable for OPN to leverage this. I have 2x RPi4b 8GB on FreeBSD 13.0 as app servers using jails for failover/redundancy, using dot1q trunk uplinks, all working fine.

After doing a couple of checks under FreeBSD 13.0, I exported the second pool 'tank', and shut the host down.

I then rebooted back into the OPN 22.1 with the patch. The second pool was imported OK at boot time.

I then ran:

Code Select Expand


root@a-fw:~ # zdb -U /etc/zfs/zpool.cache
tank:
    version: 5000
    name: 'tank'
    state: 0
    txg: 206460
    pool_guid: 3111308251436133108
    errata: 0
    hostname: ''
<snip>


The 'hostname is null.

I then exported the pool, reimported it, then checked again:

Code Select Expand


root@a-fw:~ # zpool export tank
root@a-fw:~ # zpool import tank
root@a-fw:~ # zdb -U /etc/zfs/zpool.cache
tank:
    version: 5000
    name: 'tank'
    state: 0
    txg: 206553
    pool_guid: 3111308251436133108
    errata: 0
    hostid: 3119175440
    hostname: 'a-fw.<domain redacted>'
<snip>


The 'hostname' is the FQDN.

I suppose this makes sense as in the first case the hostname has not yet been set when the filesystems are being mounted.

[only on zroot]

Alternatively, is the pool to hostname/hostid association kept on the host (not the pool), and is that in zpool.cache ?

There seem to be two paths in use for this file, /boot/zfs/zpool.cache and /etc/zfs/zpool.cache.

On my host, the former path contains data only on zroot, the second one contains data on both zroot and the second pool. Maybe the wrong path is being used at boot ? !t seems a bit odd there are 2 different files with the same name...

PS. I just booted the host up into FreeBSD 13.0, and its the same there, two different files with the same name, the one under /boot only has the root pool data in it, the one under /etc has both.

Thanks ! To test this patch, I took the following actions:

1. Commented out the 'zpool import tank' in my syshook script.
2. Created new BE, rebooted, applied the patch to the new BE, rebooted.

I noted the following message during boot:

Code Select Expand


Mounting filesystems...
cannot import 'tank': pool was previously in use from another system.
Last accessed by a-fw.<domain redacted> (hostid=b9ead710) at Thu Feb 24 15:46:17 20                                                                             22
The pool can be imported, use 'zpool import -f' to import the pool.


I then just tried a manual import, without -f, this succeeded.

So it still seems to me that problem is due to pool being recognised as being from 'another system', although it is not. It's as if the host doesn't know its FQDN at the point the initial 'zpool import' happens.

Puzzlingly, although 'zdb -U /boot/zfs/zpool.cache' includes the hostname:, neither 'zpool get all' nor 'zfs get all' do (nor do they list the hostid), so I don't know where that's being stored on the pool.

OK, great, thanks !

OK, so my fix for this was:

1. Create new user account via GUI
2. Backup config to XML
3. Delete user account via GUI
4. Edit XML, change value of <uid> to desired UID <n>
5. Edit value of <nextuid> & <nextgid> to <n+1>.
6. Restore edited XML & reboot
7. Account is recreated at startup with desired UID
8. Accounts created subsequently via GUI start as desired at <n+1>.

Is there any drawback to this approach ?

I've searched the docs and forum without a result.

How can I specify the unix UID of accounts created via 'System: Access: Users' ?

The default seems to be to start numbering them from 2000, I'd like to start from 1000, or simply specifiy the UID at account creation.

Ok, so I may be tempted to have another look..

BTW:

Karma: 1024 = 1 KiloKarma !

Nice !

PS. I confess that as a long-term Sun admin during the 90's-00's, I have an almost biological inability to have anything to do with O*****. So I prefer to use docs from the Open* world :)

The simple solution is to just revert to your previous boot-environment and/or config backup, surely ?

Then you can figure out what went wrong at your leisure :)

PS. Oh, soz just saw you fixed it by reverting a change. BTDT ;)

Hmmm... 'If'....

TBH when I was looking at this the other day, I got the impression I'd reached the limit of readily-available documentation and knowledge, and that to go any further, I would risk plunging down a rabbit-hole that I really didn't need to.

I'd love to help improve OPNsense by taking an initiative on 'issues' I encounter, but sometimes you have to say to yourself, 'Lifes too short for that !' (I've just turned 59 :( )


PS. Woohoo ! I'm now a 'junior member' ! I wish I felt a bit junior than I do ;)

FWIW, I chose just to use the available DNS over TLS feature of Unbound, along with a lightly filtered DNS service from Quad9. (Check 'em out, I think they're 'good guys' and warrant support.)

I'd previously been using Stubby/DNSmasq (on OWRT) and Unbound now does the same but with simpler setup, AFAICS.

I've not really looked into the other 'secure' or 'filtered' DNS services available, as they seem to be overkill for my specific needs. The edge devices here are all quite well-managed as regards 'content protection', so going for complex network-based protection isn't really justified. IoT, Android, etc. are all forbidden from my network !

Thx, I'm well aware my workaround is a bit hacky.

However as its likely this will be the only OPN host I'll want to do this on, I can't really justify looking any closer at it right now as there's so many other things still 'to-do'.

Ok, I got a workaround/fix for my 'use case'.

Per: https://forum.opnsense.org/index.php?topic=8753.msg39705#msg39705

Under 'Services:Unbound:General'

Select my new 'Lo1' interface as the only Interface to listen on. This has the effect of supressing the automatic creation of bindings for all Interfaces.

Under 'Services: Unbound DNS: Overrides', I have a binding like <ifname.localpart>.<domainname>  for each Interface.

The only remaining auto-generated binding for the hosts FQDN, is the /32 address I have configured on 'Lo1', in a prefix assigned to this host in the addressing plan, for this sort of purpose.

So OPN is now looking how I want it to :)

I've used a similar approach to interface name binding on numerous multihomed L3 devices over the years, if anyone can think of any drawbacks or potential unintended consequenes, please comment.

I'd like an answer to this too !

The only thing doing name resolution on my host is Unbound, and as you say it seems to be a hardcoded default somewhere to set up a FQDN/address binding on ALL Interfaces.

That's not the way I want my OPN host to look.

I want to have each interface with its own binding (fwd & rev) like <ifname>.<fqdn> so that things like traceroute return more useful info. For the main FQDN binding, I use a new Loopback interface (which is always up).

I've gone through all the Unbound GUI settings and can't see anything relevant.

Can anyone advise ?