Re: IPFire 2.27 - Core Update 164 is available for testing

Re: IPFire 2.27 - Core Update 164 is available for testing

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

Hi All,

Just tested out CU164 on my vm testbed system.

The update went without any problems. You see the pakfire log status again on the wui page during the update.

OpenVPN RW setup ran without any issues. Connection successfully made.

IPS has the multiple providers option successfully in place. I eventually found the Force Update of rules button, which was very useful for my vm testbed as it is not running all the time and so the rules were a bit out of date.

As far as I can tell everything is working fine on it. No issues detected.

I will let it run over the next few days during the daytime and see how things go.

Regards,

Adolf.


On 20/02/2022 18:35, IPFire Project wrote:
> IPFire Logo
> 
> there is a new post from Michael Tremer on the IPFire Blog:
> 
> *IPFire 2.27 - Core Update 164 is available for testing*
> 
>     It is time to test another release for IPFire: IPFire 2.27 - Core Update 164. It comes with a vastly improved firewall engine, a new kernel and various security and bug fixes. Please help us testing this release and if you would like to support us, please donate.
> 
> Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing>
> 
> The IPFire Project
> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe>.
> 

Re: IPFire 2.27 - Core Update 164 is available for testing

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

Hi All,

One thing I have noticed is that the help button on the Intrusion Prevention System page take you to the IPS Logs wiki page and not to the IPS setup wiki page. I will submit a patch to fix that but it's not an issue to do specifically with CU164.


Regards,

Adolf.

On 21/02/2022 16:01, Adolf Belka wrote:
> Hi All,
>
> Just tested out CU164 on my vm testbed system.
>
> The update went without any problems. You see the pakfire log status again on the wui page during the update.
>
> OpenVPN RW setup ran without any issues. Connection successfully made.
>
> IPS has the multiple providers option successfully in place. I eventually found the Force Update of rules button, which was very useful for my vm testbed as it is not running all the time and so the rules were a bit out of date.
>
> As far as I can tell everything is working fine on it. No issues detected.
>
> I will let it run over the next few days during the daytime and see how things go.
>
> Regards,
>
> Adolf.
>
>
> On 20/02/2022 18:35, IPFire Project wrote:
>> IPFire Logo
>>
>> there is a new post from Michael Tremer on the IPFire Blog:
>>
>> *IPFire 2.27 - Core Update 164 is available for testing*
>>
>>     It is time to test another release for IPFire: IPFire 2.27 - Core Update 164. It comes with a vastly improved firewall engine, a new kernel and various security and bug fixes. Please help us testing this release and if you would like to support us, please donate.
>>
>> Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing>
>>
>> The IPFire Project
>> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe>.
>>

Re: IPFire 2.27 - Core Update 164 is available for testing

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

Hi All,

On 21/02/2022 16:08, Adolf Belka wrote:
> Hi All,
>
> One thing I have noticed is that the help button on the Intrusion Prevention System page take you to the IPS Logs wiki page and not to the IPS setup wiki page. I will submit a patch to fix that but it's not an issue to do 
> specifically with CU164.
>
The problem is related to the fact that ids is listed twice in the manualpages file, once for ids.cgi and the second time for ids.dat for the log page but the manualpages script doesn't differentiate between .cgi or .dat

I will probably raise this as a bug.

> Regards,
>
> Adolf.
>
> On 21/02/2022 16:01, Adolf Belka wrote:
>> Hi All,
>>
>> Just tested out CU164 on my vm testbed system.
>>
>> The update went without any problems. You see the pakfire log status again on the wui page during the update.
>>
>> OpenVPN RW setup ran without any issues. Connection successfully made.
>>
>> IPS has the multiple providers option successfully in place. I eventually found the Force Update of rules button, which was very useful for my vm testbed as it is not running all the time and so the rules were a bit out of date.
>>
>> As far as I can tell everything is working fine on it. No issues detected.
>>
>> I will let it run over the next few days during the daytime and see how things go.
>>
>> Regards,
>>
>> Adolf.
>>
>>
>> On 20/02/2022 18:35, IPFire Project wrote:
>>> IPFire Logo
>>>
>>> there is a new post from Michael Tremer on the IPFire Blog:
>>>
>>> *IPFire 2.27 - Core Update 164 is available for testing*
>>>
>>>     It is time to test another release for IPFire: IPFire 2.27 - Core Update 164. It comes with a vastly improved firewall engine, a new kernel and various security and bug fixes. Please help us testing this release and if you would like to support us, please donate.
>>>
>>> Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing>
>>>
>>> The IPFire Project
>>> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe>.
>>>

Re: IPFire 2.27 - Core Update 164 is available for testing

[Jon Murphy]

[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]

Wow!  Nice find!

There is the same issue with "urlfilter" also.

#	Network menu
urlfilter=configuration/network/proxy/url-filter

#	Logs menu
urlfilter=configuration/logs/url-filter

> On Feb 21, 2022, at 9:28 AM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> On 21/02/2022 16:08, Adolf Belka wrote:
>> Hi All,
>> 
>> One thing I have noticed is that the help button on the Intrusion Prevention System page take you to the IPS Logs wiki page and not to the IPS setup wiki page. I will submit a patch to fix that but it's not an issue to do specifically with CU164.
>> 
> The problem is related to the fact that ids is listed twice in the manualpages file, once for ids.cgi and the second time for ids.dat for the log page but the manualpages script doesn't differentiate between .cgi or .dat
> 
> I will probably raise this as a bug.
> 
>> Regards,
>> 
>> Adolf.
>> 
>> On 21/02/2022 16:01, Adolf Belka wrote:
>>> Hi All,
>>> 
>>> Just tested out CU164 on my vm testbed system.
>>> 
>>> The update went without any problems. You see the pakfire log status again on the wui page during the update.
>>> 
>>> OpenVPN RW setup ran without any issues. Connection successfully made.
>>> 
>>> IPS has the multiple providers option successfully in place. I eventually found the Force Update of rules button, which was very useful for my vm testbed as it is not running all the time and so the rules were a bit out of date.
>>> 
>>> As far as I can tell everything is working fine on it. No issues detected.
>>> 
>>> I will let it run over the next few days during the daytime and see how things go.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> 
>>> On 20/02/2022 18:35, IPFire Project wrote:
>>>> IPFire Logo
>>>> 
>>>> there is a new post from Michael Tremer on the IPFire Blog:
>>>> 
>>>> *IPFire 2.27 - Core Update 164 is available for testing*
>>>> 
>>>>     It is time to test another release for IPFire: IPFire 2.27 - Core Update 164. It comes with a vastly improved firewall engine, a new kernel and various security and bug fixes. Please help us testing this release and if you would like to support us, please donate.
>>>> 
>>>> Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing>
>>>> 
>>>> The IPFire Project
>>>> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe>.
>>>> 

Re: IPFire 2.27 - Core Update 164 is available for testing

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]



On 21/02/2022 18:44, Jon Murphy wrote:
> Wow!  Nice find!
I found it because I clicked on the help link to see if the wiki page had been updated or not for the multiple providers new option and found that I had been directed to the IPS Logs section.
> 
> There is the same issue with "urlfilter" also.
> 
> #	Network menu
> urlfilter=configuration/network/proxy/url-filter
> 
> #	Logs menu
> urlfilter=configuration/logs/url-filter
Well spotted. I'll include that info also in the bug report.

Regards,
Adolf.
> 
>> On Feb 21, 2022, at 9:28 AM, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi All,
>>
>> On 21/02/2022 16:08, Adolf Belka wrote:
>>> Hi All,
>>>
>>> One thing I have noticed is that the help button on the Intrusion Prevention System page take you to the IPS Logs wiki page and not to the IPS setup wiki page. I will submit a patch to fix that but it's not an issue to do specifically with CU164.
>>>
>> The problem is related to the fact that ids is listed twice in the manualpages file, once for ids.cgi and the second time for ids.dat for the log page but the manualpages script doesn't differentiate between .cgi or .dat
>>
>> I will probably raise this as a bug.
>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>> On 21/02/2022 16:01, Adolf Belka wrote:
>>>> Hi All,
>>>>
>>>> Just tested out CU164 on my vm testbed system.
>>>>
>>>> The update went without any problems. You see the pakfire log status again on the wui page during the update.
>>>>
>>>> OpenVPN RW setup ran without any issues. Connection successfully made.
>>>>
>>>> IPS has the multiple providers option successfully in place. I eventually found the Force Update of rules button, which was very useful for my vm testbed as it is not running all the time and so the rules were a bit out of date.
>>>>
>>>> As far as I can tell everything is working fine on it. No issues detected.
>>>>
>>>> I will let it run over the next few days during the daytime and see how things go.
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>>>
>>>> On 20/02/2022 18:35, IPFire Project wrote:
>>>>> IPFire Logo
>>>>>
>>>>> there is a new post from Michael Tremer on the IPFire Blog:
>>>>>
>>>>> *IPFire 2.27 - Core Update 164 is available for testing*
>>>>>
>>>>>      It is time to test another release for IPFire: IPFire 2.27 - Core Update 164. It comes with a vastly improved firewall engine, a new kernel and various security and bug fixes. Please help us testing this release and if you would like to support us, please donate.
>>>>>
>>>>> Click Here To Read More <https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing>
>>>>>
>>>>> The IPFire Project
>>>>> Don't like these emails? Unsubscribe <https://people.ipfire.org/unsubscribe>.
>>>>>
> 

Core Update 164 (testing) report

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Hello development folks,

Core Update 164 (testing; see: https://blog.ipfire.org/post/ipfire-2-27-core-update-164-is-available-for-testing)
is running here for about three days by now without any major issues known so far.

While the updated kernel should fix XHCI issues affecting a relatively small fraction
of our userbase pretty badly (see #12750), I was unable to confirm it does, as I do
not have physical access to the only board affected in my environment. Also, I am not
aware of any community feedback on this, too. Let's hope we'll hear about this soon...

Although not mentioned in the testing announcement due to ${reasons}, this update
contains the "multiple IPS ruleset providers" by Stefan, also working fine. Thanks for
that, too!

While the DROP_HOSTILE stuff works well and I have not yet read any complaint about it,
there is a decent amount of apparently legitimate packets being logged (and subsequently)
dropped as conntrack INVALIDs. Other users notice this as well.

I do not really see this as an issue: We now _know_ conntrack is dropping substantially
more packets than we expected it to do, and can investigate on why it does this. Yay.

Tested IPFire functionalities in detail:
- PPPoE dial-up via a DSL connection
- IPsec (N2N connections only)
- Squid (authentication enabled, using an upstream proxy)
- OpenVPN (RW connections only)
- IPS/Suricata (with Emerging Threats community ruleset enabled)
- Guardian
- Quality of Service
- DNS (using DNS over TLS and strict QNAME minimisation)
- Dynamic DNS
- Tor (relay mode)

I am looking forward to the release of Core Update 164.

Thanks, and best regards,
Peter Müller

Core Update 186 (testing) report

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hello development folks,

Core Update 186 (testing; see: https://www.ipfire.org/blog/ipfire-2-29-core-update-186-is-available-for-testing)
is running here for a couple of days by now without any major issues known so far.

During the update, I merely noticed dracut complaining:

> dracut: Skipping program /bin/loginctl using in udev rule 71-seat.rules as it cannot be found

However, this does not appear to have any noticeable impact whatsoever.

The updated Lynis version now outputs significantly fewer warnings about deprecated
grep parameters, which previously made output hard to read sometimes.

Tested IPFire functionalities in detail:
- PPPoE dial-up via a DSL connection
- IPsec (N2N connections only)
- Squid (authentication enabled, using an upstream proxy)
- OpenVPN (RW connections only)
- IPS/Suricata (with Emerging Threats community ruleset enabled)
- Guardian
- Quality of Service
- DNS (using DNS over TLS and strict QNAME minimisation)
- Dynamic DNS
- Tor (relay mode)

I am looking forward to the release of Core Update 186.

Thanks, and best regards,
Peter Müller

Re: Core Update 186 (testing) report

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 9883 bytes --]

Hello,

Just to update this thread I can only say that there must be some minor bug here. Searching through the recent commits in the kernel Git repository, there have not been any changes that I would obviously connect with this. So the most likely explanation is a rare race condition that might have been newly introduced or long existing. We don’t know.

That Suricata then starts running in a loop eating all the memory until it is finally killed is obviously a bad thing. So I suggest you report both problems to the respective upstreams and we see what we hear back from them. I don’t think that this should be a release blocker.

Best,
-Michael

> On 19 May 2024, at 16:37, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> I'm afraid I spoke too soon: Today, for unknown reasons, Suricata triggered the OOM killer:
> 
> May 19 11:49:26 maverick kernel: Suricata-Main invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
> May 19 11:49:26 maverick kernel: CPU: 3 PID: 5196 Comm: Suricata-Main Tainted: G      D            6.6.30-ipfire #1
> May 19 11:49:26 maverick kernel: [   5196]   101  5196   280087   115466  1634304    72864             0 Suricata-Main
> May 19 11:49:26 maverick kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=Suricata-Main,pid=5196,uid=101
> May 19 11:49:26 maverick kernel: Out of memory: Killed process 5196 (Suricata-Main) total-vm:1120348kB, anon-rss:461608kB, file-rss:256kB, shmem-rss:0kB, UID:101 pgtables:1596kB oom_score_adj:0
> 
> Attached to this e-mail is the memory consumption graph, which corroborates that, starting
> at around 10:40 AM, something was eating up an extraordinary amount of memory. The following
> might be related:
> 
> May 19 10:41:22 maverick kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
> May 19 10:41:22 maverick kernel: #PF: supervisor instruction fetch in kernel mode
> May 19 10:41:22 maverick kernel: #PF: error_code(0x0010) - not-present page
> May 19 10:41:22 maverick kernel: PGD 0 P4D 0 
> May 19 10:41:22 maverick kernel: Oops: 0010 [#1] PREEMPT SMP PTI
> May 19 10:41:22 maverick kernel: CPU: 0 PID: 1585 Comm: tor Not tainted 6.6.30-ipfire #1
> May 19 10:41:22 maverick kernel: Hardware name: <redacted>
> May 19 10:41:22 maverick kernel: RIP: 0010:0x0
> May 19 10:41:22 maverick kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
> May 19 10:41:22 maverick kernel: RSP: 0018:ffffc90000433900 EFLAGS: 00010246
> May 19 10:41:22 maverick kernel: RAX: 0000000000000000 RBX: ffff88814cd371c0 RCX: 0000000000000000
> May 19 10:41:22 maverick kernel: RDX: 0000000000000000 RSI: ffffc900004339d8 RDI: 0000000000000000
> May 19 10:41:22 maverick kernel: RBP: 0000000000000218 R08: 0000000000000000 R09: 0000000000000000
> May 19 10:41:22 maverick kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000218
> May 19 10:41:22 maverick kernel: R13: ffff888101cf2d00 R14: 0000000000000040 R15: ffffc900004339d8
> May 19 10:41:22 maverick kernel: FS:  0000722d08168740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
> May 19 10:41:22 maverick kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> May 19 10:41:22 maverick kernel: CR2: ffffffffffffffd6 CR3: 000000010a9ee000 CR4: 00000000001006f0
> May 19 10:41:22 maverick kernel: Call Trace:
> May 19 10:41:22 maverick kernel:  <TASK>
> May 19 10:41:22 maverick kernel:  ? __die+0x23/0x80
> May 19 10:41:22 maverick kernel:  ? page_fault_oops+0x171/0x4e0
> May 19 10:41:22 maverick kernel:  ? nf_queue+0x18/0x50
> May 19 10:41:22 maverick kernel:  ? exc_page_fault+0x42c/0x730
> May 19 10:41:22 maverick kernel:  ? asm_exc_page_fault+0x26/0x30
> May 19 10:41:22 maverick kernel:  ? tcp_schedule_loss_probe+0x123/0x200
> May 19 10:41:22 maverick kernel:  ? tcp_write_xmit+0x1eb/0x1330
> May 19 10:41:22 maverick kernel:  ? tcp_sendmsg+0x2b/0x50
> May 19 10:41:22 maverick kernel:  ? sock_write_iter+0x15e/0x190
> May 19 10:41:22 maverick kernel:  ? vfs_write+0x3ab/0x450
> May 19 10:41:22 maverick kernel:  ? ksys_write+0xc3/0xf0
> May 19 10:41:22 maverick kernel:  ? do_syscall_64+0x5a/0x90
> May 19 10:41:22 maverick kernel:  ? exit_to_user_mode_prepare+0x1a/0x140
> May 19 10:41:22 maverick kernel:  ? syscall_exit_to_user_mode+0x2e/0x50
> May 19 10:41:22 maverick kernel:  ? do_syscall_64+0x66/0x90
> May 19 10:41:22 maverick kernel:  ? exit_to_user_mode_prepare+0x1a/0x140
> May 19 10:41:22 maverick kernel:  ? syscall_exit_to_user_mode+0x2e/0x50
> May 19 10:41:22 maverick kernel:  ? do_syscall_64+0x66/0x90
> May 19 10:41:22 maverick kernel:  ? vfs_write+0x3ab/0x450
> May 19 10:41:22 maverick kernel:  ? exit_to_user_mode_prepare+0x1a/0x140
> May 19 10:41:22 maverick kernel:  ? syscall_exit_to_user_mode+0x2e/0x50
> May 19 10:41:22 maverick kernel:  ? do_syscall_64+0x66/0x90
> May 19 10:41:22 maverick kernel:  ? exit_to_user_mode_prepare+0x1a/0x140
> May 19 10:41:22 maverick kernel:  ? syscall_exit_to_user_mode+0x2e/0x50
> May 19 10:41:22 maverick kernel:  ? do_syscall_64+0x66/0x90
> May 19 10:41:22 maverick kernel:  ? __hrtimer_run_queues+0x141/0x2b0
> May 19 10:41:22 maverick kernel:  ? __pfx_read_tsc+0x10/0x10
> May 19 10:41:22 maverick kernel:  ? ktime_get+0x43/0xb0
> May 19 10:41:22 maverick kernel:  ? lapic_next_deadline+0x2c/0x50
> May 19 10:41:22 maverick kernel:  ? clockevents_program_event+0x8d/0x100
> May 19 10:41:22 maverick kernel:  ? hrtimer_interrupt+0x12b/0x250
> May 19 10:41:22 maverick kernel:  ? exit_to_user_mode_prepare+0x1a/0x140
> May 19 10:41:22 maverick kernel:  ? entry_SYSCALL_64_after_hwframe+0x78/0xe2
> May 19 10:41:22 maverick kernel:  </TASK>
> May 19 10:41:22 maverick kernel: Modules linked in: esp4 tun act_mirred act_connmark em_ipt act_gact cls_basic ifb sch_ingress xt_layer7 cls_u32 sch_htb xt_NFQUEUE nfnetlink_queue xt_MASQUERADE pppoe pppox ppp_generic slhc 8021q garp xt_time xt_set ip_set_hash_net xt_REDIRECT xt_connlimit nf_conncount xt_multiport ip_set xt_owner xt_hashlimit xt_mac xt_policy xt_TCPMSS xt_conntrack xt_comment ipt_REJECT nf_reject_ipv4 xt_LOG xt_limit xt_mark xt_connmark nf_log_syslog iptable_raw iptable_mangle iptable_filter vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio i915 ax88796b intel_rapl_common drm_buddy intel_powerclamp ttm coretemp drm_display_helper kvm_intel drm_kms_helper sch_cake i2c_algo_bit kvm snd_hda_intel snd_intel_dspcfg snd_hda_codec at24 iTCO_wdt regmap_i2c snd_hda_core iTCO_vendor_support asix mcs7830 snd_hwdep snd_pcm phylink usbnet snd_timer snd irqbypass mii i2c_i801 r8169 lpc_ich intel_xhci_usb_role_switch roles realtek i2c_smbus soundcore pcspkr mfd_core rfkill_gp
> May 19 10:41:22 maverick kernel: o rfkill
> May 19 10:41:22 maverick kernel:  intel_int0002_vgpio lp parport_pc parport efivarfs crct10dif_pclmul crc32_pclmul polyval_generic i2c_hid_acpi i2c_hid ghash_clmulni_intel sha512_ssse3 drm sha256_ssse3 sha1_ssse3 i2c_core video wmi dm_mirror dm_region_hash dm_log dm_mod btrfs blake2b_generic xor lzo_compress zstd_compress raid6_pq
> May 19 10:41:22 maverick kernel: CR2: 0000000000000000
> May 19 10:41:22 maverick kernel: ---[ end trace 0000000000000000 ]---
> May 19 10:41:22 maverick kernel: RIP: 0010:0x0
> May 19 10:41:22 maverick kernel: Code: Unable to access opcode bytes at 0xffffffffffffffd6.
> May 19 10:41:22 maverick kernel: RSP: 0018:ffffc90000433900 EFLAGS: 00010246
> May 19 10:41:22 maverick kernel: RAX: 0000000000000000 RBX: ffff88814cd371c0 RCX: 0000000000000000
> May 19 10:41:22 maverick kernel: RDX: 0000000000000000 RSI: ffffc900004339d8 RDI: 0000000000000000
> May 19 10:41:22 maverick kernel: RBP: 0000000000000218 R08: 0000000000000000 R09: 0000000000000000
> May 19 10:41:22 maverick kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000218
> May 19 10:41:22 maverick kernel: R13: ffff888101cf2d00 R14: 0000000000000040 R15: ffffc900004339d8
> May 19 10:41:22 maverick kernel: FS:  0000722d08168740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
> May 19 10:41:22 maverick kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> May 19 10:41:22 maverick kernel: CR2: ffffffffffffffd6 CR3: 000000010a9ee000 CR4: 00000000001006f0
> May 19 10:41:22 maverick kernel: note: tor[1585] exited with irqs disabled
> 
> I'm not sure what to make out of this, but it suggests that Core Update 186 needs a closer
> look before it is ready to be released.
> 
> Thanks, and best regards,
> Peter Müller
> 
>> Hello development folks,
>> 
>> Core Update 186 (testing; see: https://www.ipfire.org/blog/ipfire-2-29-core-update-186-is-available-for-testing)
>> is running here for a couple of days by now without any major issues known so far.
>> 
>> During the update, I merely noticed dracut complaining:
>> 
>>> dracut: Skipping program /bin/loginctl using in udev rule 71-seat.rules as it cannot be found
>> 
>> However, this does not appear to have any noticeable impact whatsoever.
>> 
>> The updated Lynis version now outputs significantly fewer warnings about deprecated
>> grep parameters, which previously made output hard to read sometimes.
>> 
>> Tested IPFire functionalities in detail:
>> - PPPoE dial-up via a DSL connection
>> - IPsec (N2N connections only)
>> - Squid (authentication enabled, using an upstream proxy)
>> - OpenVPN (RW connections only)
>> - IPS/Suricata (with Emerging Threats community ruleset enabled)
>> - Guardian
>> - Quality of Service
>> - DNS (using DNS over TLS and strict QNAME minimisation)
>> - Dynamic DNS
>> - Tor (relay mode)
>> 
>> I am looking forward to the release of Core Update 186.
>> 
>> Thanks, and best regards,
>> Peter Müller
> <getrrdimage.svg>