Nov 17, 2024

The PR# is re-submitted for review and testing

PR#358 merged

In T4930#208556, @Viacheslav wrote:

@runar btw, we have python script for the priority /usr/libexec/vyos/priority.py

@runar btw, we have python script for the priority /usr/libexec/vyos/priority.py

I don't agree with the 'refresh peer' idea in this script, it would ruin connections with peers with ddns. Also the $IP by digging, it's stupid and it can't handle any CNAMEs.

This script is handed over as an example for how it potentially can be done and not a "this is how you should do it", and yea there are potentials for improvement. but to call digging stupid is not correct in my mind, as it does exactly what its set to do.
as for the issue you noted that can be fixed by using tail -1 instead of head -1, that way you get the last element in the list, eg. the address that the cname points to.

In T4930#208505, @runar wrote:

Hi!

I do not like the concept that this should be done inline while in the middle of a commit.
As this will halt the commit phase for potentially a long time (relative) if dns is not up'n'running.
This in itself is not that critical, but if this is done the same on multiple sub-systems you potentially can have an exponentionall increase of boot time because of this.
And in a time where we are optimising milliseconds of code to get shorter boot and commit times in other subsystems i feel this is not the correct way to do it.

This task can remain closed - I have created a new task instead:

The new package exists at: https://github.com/vyos/vyos-build/tree/current/scripts/package-build/xen-guest-agent

I do not like the concept that this should be done inline while in the middle of a commit.
As this will halt the commit phase for potentially a long time (relative) if dns is not up'n'running.
This in itself is not that critical, but if this is done the same on multiple sub-systems you potentially can have an exponentionall increase of boot time because of this.
And in a time where we are optimising milliseconds of code to get shorter boot and commit times in other subsystems i feel this is not the correct way to do it.

I’d expect the behavior is correct now. There shouldn't be empty nodes. As some of them uses “default values” and system can see it as partly configured,
In any case the check is here https://github.com/vyos/vyos-1x/blob/ec18cc393591052fd1f021c4a62220ab2e537a2e/src/conf_mode/service_ntp.py#L68

Path issues and unit tests resolved

Sounds reasonable! I'm not going to worry about it any more, unless I see any further symptoms. Thanks a lot for the fix and taking the time to respond here!

https://github.com/vyos/vyos-1x/pull/4207

@gadams it may well have been the case that the fragile synchronization before the fix was in fact a cause of the problem, at least in some (all ?) cases. I expected however, that any other config error on boot could also trigger the complaint in vyos-configd, which would consequently drop any useful output. With the original change in T6326 and the fix in T6899, any output (error or otherwise) should now be robust and generally available (notably, through the http-api, which was the motivation to finally fix the output workaround for T6326).

To be clear, the clean-config boot hangs I was seeing were prior to this fix. Since the fix, I have yet to see the hang.

@gadams I agree with 2, as becomes apparent in the current situation: it is misleading and should be changed so as to avoid confusion. If you want to take it up, that would be great; thanks. Regarding 1, if you are seeing boot hangs on a system with the above fix, we will need to investigate: I have not encountered it, so I can try to reproduce with the following information: rolling version; sanitized config; platform (vm or hardware). I suggest opening as a separate task, as the forum reports so far (unless I'm mistaken) have pointed to this one. Thanks again for the info.

For the record, I am seeing the same thing with the same build (but different config commands, since this is a fresh installation, and there's not much in config.boot).

@opswill I suggest closing this task and opening a separate task focused on the specific continuing issue.

This is resolved for rolling, and not applicable to Circinus until backport of T6326.

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

@opswill Yes, those debug messages report that vyos-configd is operating correctly: error_code 1 is 'success' in the enum list. Consequently, the obscuring error in vyos-configd has been resolved, and the root cause of your issue can now be investigated ...

Thank you for your work. I tried upgrading to the latest version 1.5-rolling-202411220007. After the upgrade, I still lost access to the LAN. However, after checking the logs, it seems that the previous exception has been fixed. There are just a few logs: Sending reply: error_code 1 with output. I'm not sure if this is a bug; could you please take a look?

As mentioned above, I'm not sure the Intel drivers actually support hardware flow table offload. I came across a thread on the netfilter development mailing list where the maintainer mentions that the driver needs to implement TC_SETUP_FT and that hw-tc-offload is not sufficient. The thread was discussing the igb driver for the Intel i350, but a cursory search of driver sources I only saw reference to TC_SETUP_FT in Mellanox and Mediatek drivers. It is entirely possible I'm missing something though.

Raised https://github.com/vyos/vyos.vyos/pull/365

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

So yes, that's the idea, and the tools are there for a simple implementation (done in May, rebased now for comparison):
https://github.com/vyos/vyos-1x/compare/current...jestabro:example-property-secret

@sarthurdev i think it can be good idea to those case , what do you think ? @dmbaturin @jestabro

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

Could nodes be flagged as sensitive in XML properties and that flag exposed to op-mode show scripts?

In T6691#207172, @MPStudyly wrote:

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.

This is mentioned in https://github.com/vyos/vyos-documentation/blob/current/docs/changelog/1.3.rst as a fix in upcoming 1.3.9 - but the backport https://github.com/vyos/vyos-1x/pull/3015 had conflicts and was closed.
So, just a question - what is really the status of this in equuleus?

@sarthurdev and need to be in 1.4?

@syncer The fix is present in rolling and circinus branches

@sarthurdev, does this require backporting?

Can be closed as resolved by above PR.

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

The first three PRs above have been merged, and the next in sequence (https://github.com/vyos/libvyosconfig/pull/21) opened for review.

T6899 merged; when rolling available, kindly retest. Thanks !

This will be squashed with https://vyos.dev/T6326 for backport to Circinus, after confirmation.

This will need the fix in https://vyos.dev/T6899 for backport to Circinus.

Issue present in 1.4.0 tested with Supermicro SOL on ttyS1.