PR https://github.com/vyos/vyos-1x/pull/2154

Tested after merging T5476 and now we see a proper DHCP release message

It could be incorrect process name name='ddclient - sleeping for 10 seconds' expectedd ddclient, possible bug after commit https://github.com/vyos/vyos-1x/commit/58a20e42087cbb7a1b3b4725fa40fd15a31bb4ed

psutil.Process(pid=2282, name='sshd', started='12:29:23')
psutil.Process(pid=2283, name='vbash', started='12:29:23')
psutil.Process(pid=2625, name='rsyslogd', started='12:30:31')
psutil.Process(pid=9841, name='vbash', started='13:02:24')
psutil.Process(pid=10249, name='kworker/u2:1-events_unbound', started='13:03:58')
psutil.Process(pid=10735, name='kworker/0:1-mm_percpu_wq', started='13:10:42')
psutil.Process(pid=10737, name='kworker/u2:2-events_unbound', started='13:10:42')
psutil.Process(pid=10987, name='ddclient - sleeping for 10 seconds', started='13:12:47')

PR for 1.3.4 https://github.com/vyos/vyos-1x/pull/2153

Thanks @Apachez - closing

In T5160#156049, @Apachez wrote:

If there would never be such then "INVALID" wouldnt exist as an option.

Another update. I noticed that all firewall configuration was gone (apart from the groups) after a reboot.

If there would never be such then "INVALID" wouldnt exist as an option.

PR https://github.com/vyos/vyos-1x/pull/2152

I have attached both files.

PRs:

• https://github.com/vyos/vyos-1x/pull/2151
• https://github.com/vyos/vyos-build/pull/376

In T5160#156025, @Apachez wrote:

2.2: Invalid shall ALWAYS be processed BEFORE established/related/other rules otherwise it will not serve it purpose.

I will suggest to move all arm64 kernel flavour to "arm64-vyos" as "amd64-vyos" in x86_64.
It will be better not to have "LOCALVERSION=-v8" in kernel configs.

Thanks, @jestabro
Zabbix-agent really can include config directory, and if it is set and exists any *.conf file it thinks that those files related to zabbix-agent and expects specific config syntax/options.
I.e. it extends zabbix-agent with custom .confg files.
As it was a wrong format, most likely it can't start at all.

2.2: Invalid shall ALWAYS be processed BEFORE established/related/other rules otherwise it will not serve it purpose.

yes, but it's in process to merge : https://github.com/vyos/vyos-documentation/pull/1035

Now we have this included in the nightly builds, is there any documentation on how these refactored rules should be modified? Just bumped my version and was completely lost

Could you share the full configuration ? so we can analyze what is the source of this problem .

PR: https://github.com/vyos/vyos-1x/pull/2149

2.1:
Suggestion that established/related merges to a single rule such as:

Cannot pass the smoketest in CI

07:19:00  DEBUG - Running Testcase: /usr/libexec/vyos/tests/smoke/cli/test_service_monitoring_zabbix-agent.py
07:19:02  DEBUG - test_01_zabbix_agent (__main__.TestZabbixAgent.test_01_zabbix_agent) ... FAIL
07:19:04  DEBUG - 
07:19:04  DEBUG - ======================================================================
07:19:04  DEBUG - FAIL: test_01_zabbix_agent (__main__.TestZabbixAgent.test_01_zabbix_agent)
07:19:04  DEBUG - ----------------------------------------------------------------------
07:19:04  DEBUG - Traceback (most recent call last):
07:19:04  DEBUG -   File "/usr/libexec/vyos/tests/smoke/cli/test_service_monitoring_zabbix-agent.py", line 34, in tearDown
07:19:04  DEBUG -     self.assertTrue(process_named_running(PROCESS_NAME))
07:19:04  DEBUG - AssertionError: None is not true
07:19:04  DEBUG - 
07:19:04  DEBUG - ----------------------------------------------------------------------

Is not reproduced in the local VM test

vyos@r14:~$ /usr/libexec/vyos/tests/smoke/cli/test_service_monitoring_zabbix-agent.py
test_01_zabbix_agent (__main__.TestZabbixAgent.test_01_zabbix_agent) ... ok

The original task https://vyos.dev/T5080

Still works in VyOS 1.4-rolling-202308140557:

Verified in VyOS 1.4-rolling-202308140557:

Seems to still be happy in VyOS 1.4-rolling-202308140557:

Verified in VyOS 1.4-rolling-202308140557:

1:
Shouldnt set firewall global-options resolver-cache have "enable" and "disable" as options?

Looks like its working as expected in VyOS 1.4-rolling-202308140557:

What is the purpose of:

interesting, as the above diff actually does the same but a bit earlier in the boot process