https://github.com/vyos/vyos-replace/pull/1 awaiting review, I have no commit privs.

• checks now for the existence of variables instead of overwriting the predefined defaults (https://github.com/vyos/vyos-1x/commit/99b2bfc74f30987d00384e384e8caa4fad28528b#diff-393bdd2f2828daf4f3a67bc8b46fcce9)

That is easy.. if level admin is set, the user is propagated into the config.. if the admin don't set it, the user is not propagated, and the user will not be able to login ..

https://vyos.readthedocs.io/en/latest/system/systemusers.html?highlight=login

I think vyos is the default, so I'll weave it into host_name.py as a default if not present in the default config.boot. Not sure why there is that difference, but on the other hand the script should and can handle missing variables.

I agree, however (https://blog.vyos.io/the-operator-level-is-proved-insecure-and-will-be-removed-in-the-next-releases) :
[...]
in the next releases that feature will be removed and operator level users will be converted to admin
[...]

Sorry, I must reopen this task. Absolutely the same situation with multiple "lower" interfaces:

OPTIONS="-6 -l ::%eth1.100-l ::%eth1.102 -u 2001:db8:0:feed::2%eth2.88 -u 2001:db8:0:feed::3%eth2.88 "
                         ^^
                         here

looking at this from a security perspective i would keep level admin, but block users of operator.. then any user is not automatically getting more privileges without the admin notice it….

When a host-name is not present, set the same default as on a newly installed device... router or vyos.. (atm. i don't remember what it says)

Looks like the option level can be removed entirely.

Migration script will be in the next rolling release (vyos-1x). Since level admin is the only level, I think it can be removed from the options tree entirely and set automatically in the config.

if host-name is not set and an IP is given to an interface script causes a an exception - maybe a default hostname could be set if the option is not in config.boot. Happens if you wipe config.boot and reboot. The default one won't have host-name configured and assigning IPs to interface still work but produce that nasty exception.

@gadams can we find your modifications somewhere?

@hagbard This now works; I tested with 1.2.0-rolling+201904010337. Thanks!

I'm interested in using VyOS to replace a Ubiquiti USG, but I absolutely need dhcpv6-pd on ATT Fiber.

noticing this issue in many of our Vyos routers. any clues on when this will be fixed?

We now ship Intel ixgbe 5.5.5 driver, maybe you want to test the latest rolling?

Feel free to add patches that needs testing.
I will report back my findings with my setup (as previously PMed about)

Not sure if the l2tp/vti modification merits inclusion - that depends on personal configuration of which tunnel is inside the other. I think the original config is correct for the more common use case of having l2tp secured by ipsec.

And yea, i feel like the configuration is quite backwards in the curremt implementation... Configuration of the ppp interface should be in its own interface block, and not inside a parent interface like it is today.. the parent is only an attribute on the ppp interface...

PPP supports many forms of transfer, hense the dialer interface on cisco. almost all supported ppp/slip etc. functions are supported by the dialer function in a cisco device. Now, vyos supports PPPoE, but we don't support any other PPP "format".. if we intend to add support for more formats (serial nullmodem, modem, isdn++) then i would favor a new Dialer or Dialup interface type.. if not.. why not call it pppoe?

Cisco has the interface type Dialer which is used to configure a ton of PPPoE stuff. In addition a dialer is later assigned to a physical interface, e.g. ATM line card or an ethernet port. With this type of configuration a physical interface can be moved easily.

Could you tell us the exact modifications? Or even better - send a Pull Request via GutHub so we could include it into VyOS.

That worked, thanks. Had to set it to 901, the vpn node was 900. Added a sed to the preconfig script so it survives updates.

@c-po accel-ppp is a server, the pppoe client in vyos is rp-pppoe, which causes the issue.
ppp works and Acks the IPv6 address:

@c-po, Accel-ppp support next option in [pppoe] section

You can try playing around with the priority in the l2tpv3 node.def files. Higher priority means its executer later. DHCP for instance uses 900-something.

I can confirm that as soon as IPv6 is enabled on pppoe0 the interface is no longer renamed from ppp0 to pppoe0.

I switched to a L2TPv3 tunnel for better performance than OpenVPN, still will not come up at boot if it depends on the vti interface.

That option is no native rp-pppoe option, SuSE provided a patch for that feature in 2014 as far as I found out. I'm still looking for an option avoiding importing it into our repo and solve the issue with a script.

This will be a nice feature, exactly what I needed. Is it hard to implement? I could help testing the ovf deployment to vSphere.

@tomjepp please test

Probably not the most common config, but I already have IPSec tunnels between all my sites, but need the L2 bridge and ovpn's fragmentation for my TV STB to function correctly through a tunnel. Perhaps adding a depends-on-interface option to all interfaces would be the most generic way to resolve this. I will try and see how difficult this is to implement in the config scripts when I have some time in the next week or 2.

@dmbaturin can you explain why we schedule it to the next release and not to 1.2.1 for example? Are there any policies?

Curiously, I can't reproduce it in the latest rolling, even though the code hasn't changed. We need to test in latest crux builds.

The packages were out of sync with reality for some time. Should be fine now.

The packages were out of sync with reality, it should work as expected now.

@tomjepp Could you share the patch or tell us what and where you had to modify?

I want write an follow up.

@trae32566 Please test with http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-system/vyatta-cfg-system_0.20.44+vyos2+current22_amd64.deb or the rolling release March26++

Code is now merged, please test in the next rolling release tomorrow

i've updated the code to handle <, > and probably other special characters. for now its waiting a merge on current/rolling and needs testing when merged