Issues with HOSTS while upgrading from 139 to 144

1

Hi,

although already solved for me, but for the records, I’m posting this here:

Yesterday I’ve upgraded from core 139 to core 144. I’m using HOSTS entries alot, configured within WebIF. The website stores those entries here in an intermediate file : /var/ipfire/main/hosts.

After modifying or adding a new entries, IPFire generates the final hosts file based upon this file and automatically adds some PTR-records, if needed.

With core 139 the intermediate file looked like this, at least on my machine and I did not edit it manually so far, some example lines:

on,172.18.0.100,Dreckspatz,
on,172.18.0.103,HandySamsungS3Mini,
on,185.60.216.19,static,xx.fbcdn.net,

After rebooting IPFire as soon as core 144 update finished, I noticed that DNS was not working at all.
I tried to reboot IPFire again, and since this did not help either, I restarted unbound in a shell session. I noticed that unbound threw many errors then, e.g. complaining about the word static or similar undefined things.
Soon, I knew the source of those errors and deleted the file /var/ipfire/main/hosts and restarted unbound. Guess what? No problems occurred :smile:

Now, that the source of the unbound issue was found, I added a new host entry from within WebIF and had a quick look into the resulting file /var/ipfire/main/hosts.
I noticed that IPFire added a new keyword to the end of this entry which was not there before core 144, e.g:

on,172.18.0.100,Dreckspatz,off

You noticed the word off at the end? So far this keyword was missing, see above. This word corresponds to the WebIF option PTR. This one forces unbound to create a PTR-record for resolving IP-addresses (I’m not the expert here, but read about this). Resolving IP-addresses perfectly worked before the upgrade, so I assumed unbound creates such a record anyway - at least while on core 139.

Back to topic again: I manually edited the backed up /var/ipfire/main/hosts and added the keyword off at the end of each line.
Afterwards, I forced IPfire re-create the final host file by using the command

/usr/local/bin/rebuildhosts

and restarted unbound again

/usr/local/bin/unboundctrl restart

Since then, no issues with DNS and of course no issues. Task solved and everyone is happy again at home :grin:

Michael

2 Likes
2

Hi,

interesting topic that motivated me to have a look at my system. I had always set the PTR check box for each entry. In the hosts file I noticed for all entries done before core 137, there was no entry at the end of the lines. For all entries after that there was the entry ‘on’. I went through some entries in the web interface where ‘on’ was missing and did an ‘edit’ and ‘refresh’. Then I had a look a the hosts file. The entry at the end was there on the respective lines but it was ‘on’ not ‘off’. Which seems rather logical to me. So it seems to be ‘on’ not ‘off’ as you describe.

Cheers

Gremlin

3

Hellfire,
I agree that this looks an interesting topic. I also agree with the view that PTR might be better set to the default of ‘on’. Amongst other uses, it might be required for DNS SD, which is now the default on many systems for locating printers.

I have CUPS installed and printers are being located. But I also discovered that IPFire Backup no longer backs up /var/ipfire/cups/ppd, with the result that printers don’t initially work on a restored system. I’ll investigate further, with a view to lodging a ticket.

4

Adding my 2 cents, I have 3 static hosts, all pingable by name but the second one does not have ‘on’ at the end. In the GUI, all have PTR button checked. Is there some inconsistency on the last field ?? Restarted unbound, no change.

on,10.0.0.1,ipfire,lan,on
on,10.0.0.5,pve5,lan,
on,10.0.0.6,ipf6,lan,on
5

Hi *,

thanks for the discussion. This seems to be a bug indeed, however, as the master-of-desaster
behind this PTR feature, I did not quite get what went wrong here exactly.

(I am pretty sure it did not show up that error in the first place, but as far as I am aware,
there were no significant changes on the corresponding CGI meanwhile.)

Could somebody please open a ticket for this and assign it to me?

Thanks, and best regards,
Peter Müller

6

Just a short recap:
Before and with core 139, I had no issues with unbound, DNS resolution and/or restarting IPFire, at least not with those existing entries in /var/ipfire/main/hosts. I did not had to care about those (missing) trailing on/off values, nor does IPFire, as expressed in my initial posting.

Soon, after updating to core 144, I encountered those DNS issues, obviously caused by misconfigured entries in file /var/ipfire/main/hosts while unbound tried to start. Those issues resulted in webpages to be not reachable. To be precise: NONE where reachable at all, from the clients in LAN nor from IPFire console using PING or DIG, for example.

I just checked messages and found those error lines that may show the issues DHCP or unbound had, right after updating on 30. April:

Apr 30 09:18:16 ipfire dhcp[17404]: Could not parse line: ,185.60.216.19,static,xx.fbcdn.net
Apr 30 09:18:17 ipfire dhcp[17404]: Could not run unbound-control local_data UniFiEG.ourhome.guest 60 IN A 172.18.0.101, error code: 1:
Apr 30 09:18:17 ipfire dhcp[17404]: Could not run unbound-control local_data Galaxy-S9.ourhome.guest 60 IN A 172.18.0.103, error code: 1:
Apr 30 09:18:17 ipfire dhcp[17404]: Could not run unbound-control local_data UniFiOG.ourhome.guest 60 IN A 172.18.0.106, error code: 1:

As far as I remember, while restarting unbound on console, some slightly different messages where show. I guess when modifying /var/ipfire/main/hosts and remove those trailing values again, I would expect unbound to have the same troubles again.

As a sidenote: Beore and with core 139, reverse-lookups using Python functions in some scripts, worked perfectly well. Hence, I guess the missing parameter on/off, nevertheless caused a PTR-address to be created. So I assume that the missing value is set equal to the value ON.
Don’t know for sure of course, I just can express my observations here.

OTH, I was just about opening a ticket but as usual I’m having troubles about finding the correct component. I looked for HOST, unbound and similar, to no avail. This is not the first time I’m lost while creating a ticket.

Michael

7

Ticket created: 12397 using component DHCP…

8

Obviously I’m not alone with this issue: https://community.ipfire.org/t/hostnames-on-green-network-not-recognised/2202