The following adds support into the XML generation but I have no clue about vyatta-cfg how those files get executed.

Presumably a val_help line in the op-mode node.def, too

Tested good - migrating traceroute now

On boot, the existing config file is committed.

Right. In my opinion it would be necessary to change that.

Definition of effective is here:

Enhancement created.
Question to ISC submitted (https://gitlab.isc.org/isc-projects/dhcp/-/issues/104)

@ddiguru
I confirm all the issues that you have observed. I was able to reproduce them in the both our LTS and currect rolling releases.

1. Issue with a wrong giaddr address. This sounds like a bug in the isc-dhp-relay package. Fortunately, those extra packets with a wrong giaddr address could be eliminated in newer versions by using "-id" and "-iu" instead of muliple "-i" options. isc-dhcp-relay allows for this since v4.3.5. I will create a Feature Request to modify the VyOS config syntax and isc-dhcp-relay config file accordingly. In the meantime I will try to confirm with ISC people that this indeed is a bug.
2. Issue with duplicate packets. isc-dhp-relay seems to unnecessarily relay unicast packets (I have no idea why it does so). That's why you see all unicast packets doubled. Looks like another bug :) The good news is that it is more cosmetic issue. I already submitted the ticket for it (https://gitlab.isc.org/isc-projects/dhcp/-/issues/102)

This PR should address this simple usability enhancement

I found that it was due to set_vrf which uses the same master/nomaster commands that bridge uses. I'm adding checks and conditions to all interfaces to prevent that - raise ConfigError if both are set, and only set_vrf if vrf is set. The prior idea I had with re-adding the interface to the bridge at the end isn't necessary in this case, but for other interface types, where the interface itself is deleted and recreated, re-adding it is still necessary. The PR should be ready for initial review tomorrow.

Resolved with T2393

This is solved in both the current LTS and rolling releases.

I had already reported before my refactor of the code that DHCPv6 does not work.
https://phabricator.vyos.net/T2268

http://man7.org/linux/man-pages/man8/start-stop-daemon.8.html

EXIT STATUS

Wrong location of status file - it was moved to /run/openvpn

@jjakob sorry for wasting your time here :-( I will try to replicate.

Nice catch - I was not aware of that show command.

The issue has been solved by the above merge.

They're still broken here. Maybe a different bug. It would be nice to switch to 'status-version' 2 or 3 too for more info.

vyos@rt-home:~$ show openvpn server

How I reproduce it.

To explain the permission for the user/group/world are expressed in octal (3 bits) so 755 is binary for 111 101 101

Successfully tested on 1.3-rolling-202004270117

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

@jjakob can we close this task ?

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

Should a iproute.py wrapper be considered to prevent having calls to "ip" everywhere in the code?
Therefore if at a later date a better solution comes along the calls to binary would not be everywhere in the code ?

Fair enough. I have gone thought the bug tracker of pyroute2 and indeed it does not inspire confidence!

@c-po errors in latest rolling VyOS 1.3-rolling-202004270117

$ show poweroff
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 193, in <module>
    main()
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 188, in main
    check_shutdown()
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 74, in check_shutdown
    dt = datetime.strptime(output['DATETIME'], '%Y-%m-%d %H:%M:%S')
TypeError: 'NoneType' object is not subscriptable

Nope. Before I‘ve invented vyos.ifconfig it was actually based on pyroute2. The problem with pyroute2 was that it lacked required functionality for VyOS which let me to developing our own lib.

If in crux this was just a option string passed to the openvpn process,
quoting or escaping could be used to pass a parameter with '--' to an
openvpn option. I need to have a good long look at how Crux did this and
have some real life examples. For example: openvpn-option '--mssfix --up
"/some/command --param1 --param2"' (I'm not sure if this would've worked
on Crux, the quoting is probably wrong, and the up option parameter too,
but my point remains that this could've been a valid option syntax)

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

I agree but it will be quite some work ... I would happy to work on this as it would remove my of my issues with calling "cmd()" for network interface setting.

@elbandi how should this approach fix the error on image upgrade?