@MattK provide a simple example of "set" commands to reproduce

We have a decision to leave it as it is.
@c-po closed the task T4487
So close it as wontfix.

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

We don't need append
We should use leafNode type /multi for example https://github.com/vyos/vyos-1x/blob/4c29922cc0baa9c127391b58e82b76f69e1e2dce/interface-definitions/include/bgp/afi-l2vpn-common.xml.i#L43

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

PR https://github.com/vyos/vyatta-op-vpn/pull/38

@fdcastel Thanks for confirming

It is still a bug and was reproduced in T5926

Deleting was described there T3843 and seems steel relevant

I expected the load the image in the background (during the commit), without op-mode.
That's why it was initially opened.
But we must use the load images from op-mode first because otherwise, we have some bugs.

@troggie Add please an example of working config accel-pp.conf wit those options
Otherwise, I'll mark it as wontfix.
Thanks.

Not reproduced
Re-open it with all steps to reproduce, including scripts that generate your config.
The Load is used anywhere and never has issues like this.
Close it for now.

Done

vyos@r4# set high-availability virtual-server serv1 forward-method 
Possible completions:
   direct               Direct routing
   nat                  NAT (default)
   tunnel               Tunneling

Well-known behavior when you use VTI interfaces you have to use set vpn ipsec options disable-route-autoinstall otherwise you can get any unexpected things.

@jack9603301 Feel free to create a PR as do usually do for documentation, the Task is not required.
For example https://github.com/vyos/vyos-documentation/pull/1229

We use the netavark plugin for the containers, which fixes this.

set container name alp01 image 'alpine'
set container name alp01 network NET01
set container network NET01 prefix '100.64.0.0/24'

Fixed in https://github.com/vyos/vyos-vm-images/commit/090e5367dc6df9b49c037e0b60f7adfafdf54a53

@fernando Thanks!

The kernel is not supporting pseudowire/VPLS now
this patch was never merged into the kernel

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

Another bug it that /config/upnp.leases is hardcoded, but there is no script who creates it https://github.com/vyos/vyos-1x/blob/aebb458262072457c6a3840d1b17031fbd780eca/data/templates/firewall/upnpd.conf.j2#L128

Will it work if you manually download the functions? https://github.com/miniupnp/miniupnp/blob/miniupnpd_2_3_1/miniupnpd/netfilter_nft/scripts/miniupnpd_functions.sh

@sempervictus Thanks for the update!

What to do with atop and logrorate?

It seems we already have mfa T3834 but it never was documented
https://github.com/vyos/vyos-1x/pull/1008

vyos@r4# set interfaces openvpn vtun0 server mfa totp 
Possible completions:
   challenge            Expect password as result of a challenge response protocol
                        (default: enable)
   digits               Number of digits to use for totp hash (default: 6)
   drift                Time drift in seconds (default: 0)
   slop                 Maximum allowed clock slop in seconds (default: 180)
   step                 Step value for totp in seconds (default: 30)

@xrobau Could you test it?

Dec 9 13:04:57 vyos charon: 07[IKE] no matching CHILD_SA config found

Do you have several connections from the hosts behind the same NAT external address to the same hub?
It worked in my previous tests, but it was just one host behind NAT to connect to the HUB.
Re-check please and close if it works fine now. Need to update.

@amcmillen Do you have any examples of how to deploy it on Linux / Debian, etc?
Without live examples, we'll mark it as wont fix and task will be closed.

As I understand, there are now ways to implement it natively for sshd
Reopen please if you have/know a solution for it.

@ordex Les us know if you have some ideas
Thanks

@fernando @zsdc @joshua Could you re-check it, or can we close it?

Is it still bug? @sempervictus could you re-check?
We probably need more details

I guess it is already done https://github.com/vyos/vyos-cloud-init/commit/ae74804ede8fb76a7f27ca869f2b880dbe276ca2
@zsdc Can we close it or you are working on it?

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

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

There could be another bug related T5407
I guess we should not Raise config but use the Warning here https://github.com/vyos/vyos-1x/blob/864524ba86b0a4d57ab64d6e9398c3fd5eb2fce4/src/conf_mode/container.py#L405-L408

The first thing could be that the container cannot connect to the registry as it happens before static routing (not sure).

vyos@r4# /opt/vyatta/sbin/priority.pl | match "container|static"
450 container
480 protocols/static
481 vrf/name/node.tag/protocols/static
[edit]
vyos@r4#

Ok the file does not have the Release version in config and migration do anyway
https://github.com/vyos/vyos-vm-images/blob/current/roles/install-config/templates/config.boot.j2

vyos@ci-router1# cat /config/config.boot.2024-01-08-083418.pre-migration 
nat {
    source {
        rule 100 {
            translation {
                address "masquerade"
            }
            outbound-interface {
                name "eth0"
            }
        }
    }
}
interfaces {
    ethernet eth0 {
        address "dhcp"
        hw-id "52:54:00:ff:97:48"
        mtu "1500"
    }
    loopback lo {
    }
}
service {
    ssh {
        client-keepalive-interval "180"
        port "22"
    }
}
system {
    config-management {
        commit-revisions "100"
    }
    host-name "ci-router1"
    login {
        user vyos {
            authentication {
                encrypted-password "*"
                plaintext-password "vyos"
            }
        }
    }
    ntp {
        server "time1.vyos.net"
        server "time2.vyos.net"
        server "time3.vyos.net"
    }
    syslog {
        global {
            facility all {
                level "notice"
            }
            facility protocols {
                level "debug"
            }
        }
    }
}