I created a PR https://github.com/vyos/vyos-1x/pull/4194

I'm back home now, feel free to send them to me and I'll take a look at it today (I have a few minutes now, but likely will need to look at it in about 12 hours).

Update - I cloned the current vyo.vyos changes, created a branch and made the changes that Maxime proposed.

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

sure, ok - I will do needful for it to be tests ready
It does not appear a huge change to me

Maybe ask the author to resubmit against the current?

I believe it was forked a while ago (in March this year) and never refreshed after that - so the fork (and PK) is using older version of the repo

was that after rebasing it onto our current main branch or applying changes directly? Or something else?

Sanity tests are failing pretty much all:
FATAL: The 5 sanity test(s) listed below (out of 34) failed. See error output above for details.
action-plugin-docs
import --python 3.12
pep8
pylint
validate-modules

Yeah, changes are pretty small and also pretty isolated. I’m guessing the merge might be fast, unless there are significant conflicts. However if there are conflicts probably faster to re-apply the change.

Or I may just re-introduce the changes into the working current branch given they are all straight forward

Started to look into this - but it seems to be based on older version of collection (57 commits behind) and failing all the sanity checks.
I will try and refresh that branch and re-test

On it, @syncer

Let’s get tests at least for the changes here before we check it in. It should be trivial to test, especially since it looks like there is no version difference to take into account.

@evgmol can you please review the pull request provided, if ok we should merge it

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

For KEA6 its defined as "The IPv6 address of a TFTP server" with example of IPv6-address:

If its common of this misuse of option66 I would suggest that VyOS would allow for URI characters (@, :, / and what else) but type a warning during re/config like:

@syncer Yeah, it was at the forum:

DHCP option 66 is not intended to carry an HTTP URL. According to RFC 2132, option 66 is specifically designed to provide the TFTP (Trivial File Transfer Protocol) server name, typically used to specify a hostname or IP address of a server from which the client can download a boot file via TFTP, not HTTP.

Interesting interpretation of the standard. Guess it's time to go bare metal again

can be ipv4 or hostname

This is not a bug, this is according to RFC

This is not a bug, this is according to RFC
@Apachez I recall you have cited it but do not recall where it was here or at the forum

PR:
https://github.com/vyos/vyos-build/pull/836

Clarification: this was in fact a consequence of the cleanup here:
https://github.com/vyos/vyos-build/commit/d50707bb295dbd4bc50e3d0301fc8be605448429
not the cleanup of deprecated packages, consequently, the solution is simpler: simply revert the above. As previously mentioned, although this is not used by new installs, the file is expected to exist in a new image, when doing a compatibility-mode update from a system with legacy image tools. If the legacy images are subsequently removed from the system, the new image tools will switch out of compatibility mode, at which point the file is no longer needed.

This has a simple solution, and was an artifact of the much welcomed retirement of the packages vyatta-cfg-system and vyatta-op (T6527). One missing file is needed from the retired packages: since the legacy update tools look for a small number of scripts in the mounted image of the new image, a few need to be available for legacy compatibility. PR in preparation.

fixed as part of https://vyos.dev/T6802
https://github.com/vyos/vyos-1x/pull/4177

Already implemented in https://vyos.dev/T4940

I raised a draft PR (https://github.com/vyos/vyos.vyos/pull/357) to tackle some of the compatibility issues. I will try and finalise it in coming days

technically the limit would be defined by the http header length (and httpd configured allowed header sizes), http basic auth itself has no restrictions in the context of being Base64 encoded.
Often restrictions are from tooling side, not protocol side. I.e Apache htpasswd generated passwords and usernames (under windows) are limited to 255 chars, but again this is a tool limit, not a header limit
(Source: https://httpd.apache.org/docs/2.4/programs/htpasswd.html#restrictions)
256 (255) could be a reasonable value that matches this specific constraint.

In T6870#207379, @Viacheslav wrote:

Check please bug report guidelines https://blog.vyos.io/feature-requests-and-bug-reports-guidelines

When you create a bug, the most important thing is that it should be possible to tell if it's fixed.

You should include the following information:

    A sequence of configuration commands or a complete configuration file is required to recreate a setup where the bug occurs. Please avoid partial configs: a sequence of commands is easy to paste into the console, a complete config is easy to load in a VM, and a partial config is neither! At least not until we implement a "merge from the CLI" feature that allows pasting config file chunks into a session.

Check please bug report guidelines https://blog.vyos.io/feature-requests-and-bug-reports-guidelines