Migration to Kea
-
As I understand it you can just edit your
/etc/hosts
file as required. It should be populated with information from the last time you ran ISC but clearly it is stale data or, for a clean install, completely blank. It should be in a similar format to this:[23.09-RELEASE][admin@Router-7.redacted.me]/root: cat /etc/hosts 127.0.0.1 localhost localhost.redacted.me ::1 localhost localhost.redacted.me 192.168.1.1 Router-7.redacted.me Router-7 2a02:xxx:xxxx:3:xxxx:efff:xxxx:e706 Router-7.redacted.me Router-7 10.0.1.1 Router-7.redacted.me Router-7 10.0.1.2 Switch-24P.redacted.me Switch-24P 10.0.1.3 Switch-24X.redacted.me Switch-24X 10.0.1.4 Switch-5P.redacted.me Switch-5P 10.0.1.5 AP-Study.redacted.me AP-Study 10.0.1.6 AP-Lounge.redacted.me AP-Lounge 10.0.1.7 AP-Kitchen.redacted.me AP-Kitchen 10.0.1.8 AP-Gallery.redacted.me AP-Gallery 10.0.1.9 AP-Guest.redacted.me AP-Guest
๏ธ
-
I did face the same issue after moving to 23.09 and activating KEA.
Before browsing through the forum, I spent some time trying stuff on my own, until I figured out that the radio button to activate Static DHCP mappings was missing from the KEA DNS gui.
So what I ended up doing is:
- Go back to ISC
- In the DNS Resolver screen, the Static DHCP setting was unchecked, so I checked it
- Applied the setting
- Switched back to KEA
And then static DHCP DNS mappings started working again. Now, bear in mind that I'm still unsure if this will survive a reboot, but I'll find out soon enough (next week-end).
Here is a screenshot from the DNS Resolver GUI under ISC:
Here is a screenshot of the DNS Resolver GUI under KEA:
Hope this helps,
-
@RobbieTT said in Migration to Kea:
As I understand it you can just edit your /etc/hosts file as required.
You can try
Check the time stamp of that /etc/hosts file : it's created , and maintained (recreated) by pfSense.
Your own edits will be lost very soon. -
-
@RobbieTT said in Migration to Kea:
Really? Didn't seem to change at all when I ran Kea...
pfSense (and the vast majority of all its packages) stores configuration information in the
config.xml
file and dynamically writes the data out to an appropriate text-based conf file on the filesystem when you click Save in the GUI and/or when services are started. Things are generally not persisted on the physical file system (as in write it once and then done). If they were, you could not quickly restore any previous configuration by simply importing aconfig.xml
backup. The restore of the singleconfig.xml
file works because pfSense will read that data and rewrite all the necessary conf files in/etc/
or/usr/local/etc/
and elsewhere as necessary.Lots of folks with old-school Linux or BSD type experience make the mistake of thinking they can just edit the xxxx file directly to solve some issue. That change will be short-lived as @Gertjan pointed out.
-
The /etc/hosts file is gerenated here /etc/inc/system.inc
The function system_hosts_generate() is called from :
/etc/inc/pfsense-utils.inc: in the famous function reload_all_sync() - the main pf firewall reload - this happens very often..
/etc/inc/services.inc: : both in services_unbound_configure() and services_dnsmas_configure() - so when the unbound or dnsmasq config changes - or when unbound or dnsmasq starts. -
@Gertjan I didnt mean to come this so late, Somehow I am not getting notifications of post... meh... LOL
I am talking about Netgates own statement here:https://www.netgate.com/blog/netgate-adds-kea-dhcp-to-pfsense-plus-software-version-23.09-1
and quote
Note: If you have assigned hostnames to devices on your network using static leases, or rely on dynamic lease registration in DNS, switching to Kea DHCP results in those hostnames being ignored. The static lease configuration is kept, so switching back to ISC DHCP will restore the functionality.
-
@ffuentes said in Migration to Kea:
The static lease configuration is kept, so switching back to ISC DHCP will restore the functionality.
I think that's because Kea ignores that file for now, so there is nothing changed. When switching back to ISC DHCP it will just write what it already had in there back, so effectively no change. Also, when they say "static lease configuration is kept", they mean the content in
config.xml
is not modified nor removed. Thus it is there and ready to be written back out again to the file when ISC DHCP is reactivated.This will not be the case once Kea fully supports this feature. It will then write its own stuff to that file (or perhaps use an entirely different file ???).
If you would like to learn a bit about how this
config.xml
business works, open up the file and read through it -- but DO NOT change anything!!!The file can be viewed by choosing DIAGNOSTICS > EDIT FILE and then navigating to
/conf/config.xml
. Look through the file and you will find every single piece of user-configurable information for your firewall stored in the various sections. The data stored there is decoded and written out to the various conf text files on the filesystem when you save a change. -
@bmeeks said in Migration to Kea:
Lots of folks with old-school Linux or BSD type experience make the mistake of thinking they can just edit the xxxx file directly to solve some issue. That change will be short-lived as @Gertjan pointed out.
My thoughts and observations were for Kea as currently utilised in pfSense. In an ideal world you would be correct but Kea isn't quite there yet.
๏ธ
-
@ffuentes said in Migration to Kea:
Note: If you have assigned hostnames to devices on your network using static leases,
I have !
A boat load of the:
I can find them all in the /etc/hosts.
Unbound uses this /etc/host file to create its /var/unbound/host_entries.conf
So unbound knows about my static mac leases host.
Btw : kea uses the dhcp static mac leases list.
Check for yourself ( ! ), here is the kea config file /usr/local/etc/kea/kea-dhcp4.conf
I see :so kea is dhcp static mac lease aware (and don't listen to Netgate, the coders are working faster as the ones that keep up with the documentation )
-
@Gertjan said in Migration to Kea:
Unbound uses this /etc/host file to create its /var/unbound/host_entries.conf
No, it doesn't. The backend creates both of those based off the contents of the configuration.
@Gertjan said in Migration to Kea:
so kea is dhcp static mac lease aware (and don't listen to Netgate, the coders are working faster as the ones that keep up with the documentation )
Nope, it's not in Kea yet. What you see in
/etc/hosts
and/var/unbound/host_entries.conf
is remnants of the ISC DHCP config, not Kea.Edit a static mapping in Kea and save/apply and so on, you'll see it's not updated in those files.
-
Actually I take that back it does seem to update if it was already enabled before switching to Kea, and only for static mappings, and even then it only updates when Unbound updates its config, not when changes are made in the DHCP config.
So while it may sort of half function I wouldn't rely on it yet as the behavior is still undefined.
-
That is / was my situation : before switching to kea I had most of my principal LAN devices listed on a "DHCP Static Mappings" list.
Because they are on that list, the host (device) names I gave them are 'DNS honored' = these are the ones I saw in the /etc/hosts file. The are the ones that get also used to create /var/unbound/host_entries.conf
Directly from the main config.xml, not indirectly, from /etc/host = I stand corrected here, and that is actually, IMHO, even better.I isolated my own PC, called 'burea2' (see image above), zapped the 'preferred' LAN IP that it wants to obtain from the kea pfSense DHCP server, and it still got the "DHCP Static Mappings" listed IP : 192.168.1.2. This is the only (I guess) thing that matters to me.
The config file of kea (DHCPv4) listed bureau2's MAC and IP, so the 'code' was using my staticy DHCP listed devices.
That as all I wanted to know : does kea honor the list below "DHCP Static Mappings". For me, after some testing, I saw it did.
@jimp said in Migration to Kea:
Edit a static mapping in Kea and save/apply and so on, you'll see it's not updated in those files.
Before adding another one, I'll switch to DHCP first.
Add a new entry into "DHCP Static Mappings".
And then switch back to keaor : Plan B :
Without switching back to DHCP mode first, I add "DHCP Static Mappings".
I'll add a host over ride on the Resolver settings page.
This will also take care of DNS visibility.Adding an entry in "DHCP Static Mappings" for my main LAN is actually a rare event. I'm not adding new devices every day or so, maybe one or two or zero a year.
Non trusted devices are on the my trusted networks, my main LAN.
For devices on the non trusted networks I don't care about DHCP mapping, devices names etc.Btw : will saving the resolver settings page, and the DHCP LAN settings page several times, I saw what is described here : KEA service stopping through the day : kea was in the stopped state.
The DHCP log told me that the presence of its 'lock' file of a previous instance was blocking the startup.
Said to myself : it can't be that easy, can it ? and zapped the file. kea started fine afterwards.