152 will not update

I can’t update my system. I’ve checked and it is 152. I copied the output of switching between stable and testing.

Dec 3 14:22:26 firewall pakfire: DOWNLOAD STARTED: 2.25.1-x86_64/lists/server-list.db
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: Host: pakfire.ipfire.org (HTTPS) - File: 2.25.1-x86_64/lists/server-list.db
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: 2.25.1-x86_64/lists/server-list.db has size of bytes
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: HTTP-Status-Code: 500 - 500 Can't connect to pakfire.ipfire.org:443 (Name or service not known)
Dec 3 14:22:26 firewall pakfire: Giving up: There was no chance to get the file 2.25.1-x86_64/lists/server-list.db from any available server. There was an error on the way. Please fix it.
Dec 3 14:22:26 firewall pakfire: DB INFO: packages_list.db is 864373 seconds old. - DEBUG: force
Dec 3 14:22:26 firewall pakfire: DOWNLOAD STARTED: lists/packages_list.db
Dec 3 14:22:26 firewall pakfire: MIRROR INFO: 28 servers found in list
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: Host: mirror.onesystems.ch (HTTPS) - File: IPFire/pakfire2/2.25-x86_64/lists/packages_list.db
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: IPFire/pakfire2/2.25-x86_64/lists/packages_list.db has size of bytes
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: HTTP-Status-Code: 500 - 500 Can't connect to mirror.onesystems.ch:443 (Name or service not known)
Dec 3 14:22:26 firewall pakfire: Giving up: There was no chance to get the file lists/packages_list.db from any available server. There was an error on the way. Please fix it.
Dec 3 14:22:26 firewall pakfire: CORE INFO: core-list.db is 985543 seconds old. - DEBUG: force
Dec 3 14:22:26 firewall pakfire: DOWNLOAD STARTED: lists/core-list.db
Dec 3 14:22:26 firewall pakfire: MIRROR INFO: 28 servers found in list
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: Host: uk.mirrors.fossho.st (HTTPS) - File: ipfire/pakfire2/2.25-x86_64/lists/core-list.db
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: ipfire/pakfire2/2.25-x86_64/lists/core-list.db has size of bytes
Dec 3 14:22:26 firewall pakfire: DOWNLOAD INFO: HTTP-Status-Code: 500 - 500 Can't connect to uk.mirrors.fossho.st:443 (Name or service not known)
Dec 3 14:22:26 firewall pakfire: Giving up: There was no chance to get the file lists/core-list.db from any available server. There was an error on the way. Please fix it.
Dec 3 14:22:26 firewall pakfire: PAKFIRE INFO: Pakfire has finished. Closing.

Hi,

first, welcome to the IPFire community and thank you very much for volounteering to test upcoming Core Updates. :slight_smile:

Your Pakfire output looks like DNS is broken on your machine. Could you please post a screenshot of your DNS configuration here and contents of /var/log/messages containing the word unbound so we can see what is going wrong exactly?

Thanks, and best regards,
Peter Müller

I decided to reinstall IPFire using your latest release. After the install and setup I changed the packfire update to testing and updated the system. Then I installed the needed addons and set up guardian and Intrusion Prevention. Immediately I lost my DNS again. After running some of the commands I found here in the forum I found that the loopback (127.0.0.1) was in use by another program and could not be accessed by DNS. As a temporary fix I added 2 DNS “nameservers” to the /etc/resolv.conf file and now have full access to DNS again. However, I need to determine why 2 programs are accessing the loopback at the same time. I can turn off the intrusion prevention program and that eliminates whatever was blocking my access. Since I need the intrusion prevention that is why I added the 2 DNS nameservers to the conf file as a temporary fix. Hopefully you can help determine why the conflict accessing loopback. Also, I have other issues. They are listed below.

Kernel and Firewall:

 2 Time(s): 8021q: 802.1Q VLAN Support v1.8
 8 Time(s): ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000295-0x0000000000000296 (\SEN1) (20170728/utaddress-238)
 4 Time(s): ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
 2 Time(s): Kernel log daemon terminating.
 2 Time(s): Kernel logging (proc) stopped.
 4 Time(s): i2c /dev entries driver
 1 Time(s): perf: interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 79500
 1 Time(s): perf: interrupt took too long (3138 > 3136), lowering kernel.perf_event_max_sample_rate to 63600
 1 Time(s): perf: interrupt took too long (3955 > 3922), lowering kernel.perf_event_max_sample_rate to 50400
 1 Time(s): perf: interrupt took too long (4959 > 4943), lowering kernel.perf_event_max_sample_rate to 40200
 4 Time(s): r8169 0000:02:00.0 red0: link down
 2 Time(s): r8169 0000:02:00.0 red0: link up
 1 Time(s): r8169 0000:02:00.0 red0: renamed from eth1
 2 Time(s): sky2 0000:04:00.0 green0: Link is up at 1000 Mbps, full duplex, flow control rx
 2 Time(s): sky2 0000:04:00.0 green0: enabling interface
 1 Time(s): sky2 0000:04:00.0 green0: renamed from eth0
 4 Time(s): w83627ehf: Found W83627DHG chip at 0x290
 1 Time(s): xt_geoip: loading out-of-tree module taints kernel.

Any help would be greatly appreciated.

Hi,

that’s bad since I would be interested in logs regarding your first problem.

To Core Update 153 testing, I suppose?

Yes, this seems to be a quirk in Suricata we could not track down further so far.

Could you post a screenshot of your DNS configuration this time?!

Would you please post a link to that source?!

No, not with that exiguous information. Besides, I am pretty sure this is not related to the loopback interface in particular.

Most of them are harmless and part of everyday’s business of a Linux system - have you even looked at them?!

Instead of just dumping all the irrelevant logs here (while omitting the ones I asked you for) and demand other users to google them for you, your issues could be solved much quicker and straight-forward if you just provide meaningful information when asked or referring to.

This is not how support works here.

Thanks, and best regards,
Peter Müller

2 Likes

I tried to reply to your questions. Your web site would not allow. It said 2 posts only. I am a busy person and IT security is not my profession. I will attempt to answer your questions but it will take some time since I dumped all those answers when your website would not allow me to post them.
One question. Will my editing my /etc/resolve.conf file by adding 2 nameservers cause any security issues for ipfire? Right now since I edited it everything is working. DNS in the cgi shows working, pakfire updates everything correctly and all other addons are working.

And thanks for your previous understanding reply.

Hi,

yes, Discourse tries to be smart here and is rate-limiting new users to a certain amount of posts per time to mitigate forum spam. Next time, please try one big post instead… :slight_smile:

Yes: Your firewall is now querying those DNS resolvers (they are not nameservers in technical terms) directly, bypassing security mechanisms we have built in or turned on otherwise (such as DNSSEC, aggressive NSEC, QNAME minimisation, etc. - more on this here).

From my point of view, it would be better to sort out your DNS issue if the IPS is turned on (have you tried switching to DNS over TLS instead?) than tampering with IPFire’s DNS internals.

While I doubt upcoming Core Update 153 will address this problem, it at least comes with an updated version of Suricata (the IPS system we use in IPFire). In case you have a machine available for testing and QA scenarios, could you please upgrade it to the testing version and report if the error persists?

(Please refer to the documentation for further information on how to switch to the testing release.)

Thanks, and best regards,
Peter Müller

1 Like

Hi,

by the way, in case you are going to test Core Update 153, could you please watch out for a significant increase of your machines’ CPU load?

Some developers seem to experience that problem, but some do not. Before downgrading to Suricata 5.x, it would be good to know what issue we are dealing with, and who is affected by it.

Please report your findings on the development mailing list; there already is a thread for this.

Thanks, and best regards,
Peter Müller

When I did the last fresh install I immediately changed the pakfire setting from stable to testing and then told it to update. At first I had issues with the DNS “breaking”. With the release if 153 the issue causing the breaking was resolved. I removed the nameservers I had put in the resolve.conf file and it is now operating as it was designed to. Thanks for the fix…whatever it was. :smiley: I will keep an eye on the cpu load and if I find any significant increase I will post it to the thread you put in your last post. So far I have seen a small increase but not much and I have a large amount of Suricata enabled.
FYI: I have tried several other software firewalls {OPNsense, Untangle, pfSense, and ClearOS} and as long as there are no issues (like with the DNS or similar) I MUCH prefer IPFire. It is a brilliant design. Since I am not a professional at this, I really need to find a way to educate myself on how best to set it up to meet my needs. The wiki isn’t very detailed. But I will continue to look for sources of information.

1 Like

Hi,

thank you for reporting back on this.

To be honest, it is rather unsatisfying not to know what happened here. Based on my
experience, I am tempted to blame Suricata for this DNS issue, since it seems to drop
UDP DNS traffic sometimes (without logging it!), but I have no evidence for that.

Unfortunately, we have had to downgrade Suricata to 5.x again in Core Update 153 (see
this commit and this thread for details), so in case
Suricata 6.x fixed the error you experienced, I am afraid you will observe it again.

As soon as there is a (hot) fix available from Suricata, we will ship it’s latest version,
since it comes with some important security fixes as well. But 25 % idle CPU load is
just too much, especially on smaller systems. :expressionless:

Apart from that, I am glad you like IPFire. :slight_smile:

The wiki isn’t very detailed.

What information were you missing exactly? Or is the navigation through it tricky?

Thanks, and best regards,
Peter Müller