@jjakob https://github.com/vyos/vyos-1x/pull/376

I have extracted this question to T2380 alone!

Do they appear in the journal? sudo journalctl -f
I think logs go to systemd-journald first, then are forwarded to rsyslog,
which logs them to files. I've said some time ago, ever since 1.2 moved
to Buster and journald came in, that we should move more to native
journald logging away from rsyslog. I enable persistent journal storage
in /etc/systemd/journald.conf after every upgrade just because of this,
the rsyslog config is buggy/broken, it doesn't log half of what it
should, it stays in journald, so I just use journalctl to look at all
logs. I don't know if journald supports logging to separate files like
rsyslog though, by default it uses its own binary format, I think that
can be changed and maybe rsyslog file behavior moved to journald.

At present, relevant functions are normal after virtual machine test! New bug found, see T2379 for details

If this happens to you, you don't need to delete and re-add the members in the config, you can run sudo ip link set dev ethX master brX to add the eth interfaces back to the bridge.

We ave no RPKI filtering active yet, so https://github.com/FRRouting/frr/issues/5458 seems not related.

Thanks for confirming this.

660 is not enough as the created file is already 660 root:root, which
means just root has the rights to write to it. The failing script isn't
run as root while in a config session (validate-value.py). I'm not
exactly sure which user (vyos or vyattacfg), but as this is a debug log,
it's not security critical and can be set to 666. Otherwise it'd need to
be owned by a group into which all the writing users must be put into,
and can stay 660.

The file should have been 660 and it should have worked .. I will check

sorry, i'm not a hacker, so i dont know any attach vector. :( But it does not mean that it does not exist.

All that's needed is to chmod 666 the file after creation - I did that
after I found the error and all scripts could write to it fine.

Yes, I also have a patch ... somewhere .. which prevent to change any of the /config files on the system (so that a user can not make damage to the system).
I also need to add a check to only use the file if the user and permission are what is expected. I will do it :-)
The file should be created as group vyattacfg tho with rights allowing both the user and root to write to it.

@jjakob There is no need to check if an interface exists before creation, the code has always tried to find the interface and use it if there, otherwise it will create it.

Please test with a image built after April 23 20:44 (no image is built yet, the next one should have the fix for T2362 included)

Fixed by T2362

@jjakob yes, what you propose to check if an interface exists is good. If you know the type (as defined in the class which as the same name as the "set interface" section such as ethernet) you can use Section.interfaces('ethernet') to only get what you want.

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

PR https://github.com/vyos/vyos-1x/pull/374
Possible commands:

vyos@R1-VM# set service pppoe-server authentication protocols 
Possible completions:
   pap          Allow PAP authentication [Password Authentication Protocol]
   chap         Allow CHAP authentication [Challenge Handshake Authentication Protocol]
   mschap       Allow MS-CHAP authentication [Microsoft Challenge Handshake Authentication Protocol, Version 1]
   mschap-v2    Allow MS-CHAPv2 authentication [Microsoft Challenge Handshake Authentication Protocol, Version 2]

I'm still seeing this in VyOS 1.3-rolling-202004170117

In T2366#61424, @runar wrote:

"This is fine if used in conf_mode scripts that'll create it after that anyway" if the intention of the code was not to create the interdace this is not fine if you ask me. :)

"This is fine if used in conf_mode scripts that'll create it after that anyway" if the intention of the code was not to create the interdace this is not fine if you ask me. :)

thats correct @jjakob , when a mac is changed on a interface the ONLY place to find the original mac address for a interface is using the hw-id, this is because the kernel does not hold track of the original mac anywhere. for now on saving the config it reverts back to the original hw-id mac when the mac node is deleted witch should be quite fine to do. When the old boot interface mapping code is rewritten these pointers also need to match the new scripts. but thats another storry :)

is if iface in Section.interfaces() the correct way to check if the interface already exists?

Actually, if an interface doesn't exist and if we try to get its properties (for example if mac != BridgeIf('br0', create=False).get_mac():) that raises an exception. I'm not sure what the best way to do here is. Use create=True anyway? This is fine if used in conf_mode scripts that'll create it after that anyway, but what if we're checking another interface that we don't know if it exists or not? First do an existence check? How do we do that?

Bug: if I create '/config/vyos.log.debug' with contents '/config/vyos.debug.log', /config/vyos.debug.log is created as root:root rw-rw-r--, and later scripts that use call() but aren't root, don't have the permission to write to it, and fail. For example any validator like mac-address fails as if the value is invalid, but if we turn on its debug flag, we see the real error is [Errno 13]: Permission denied: '/config/vyos.debug.log' because 'src/helpers/validate-value.py' uses call(), but it isn't ran with root privileges. The debug log should be probably created with 666 permissions or its group changed so that all scripts, even non-root, can write to it.

Oh, I see what that's supposed to do - if there was a 'mac' set to change the interface's mac address, it sets that back to the real factory mac. In that case, that's fine (it's done every time if no 'mac' node is there, which is rather pointless, but shouldn't harm anything), the bug with interface renaming is a separate bug that's not applicable here.

@c-po looking at your commit d80398b6, I don't think that's how the hw-id node was supposed to be used. It was never used as a way to change the interface's mac address, rather it was used to rename the interface with the matching mac address to the name it has in config.boot. This is done by some vyatta scripts at boot time. If we later set the same mac on the interface that it should already have (as it was renamed by the vyatta scripts), that's pretty pointless to do IMO.

@jjakob detect_if_systemipv6_is_disabled just an idea, but looking to interfaces-openvpn.py, it's easy:

PR https://github.com/vyos/vyatta-cfg-vpn/pull/30

Disabling IPv6 on the system is something not mainlined in VyOS - there are open PRs on GitHub which needs to be approved by @dmbaturin. As Disabling IPv6 would also require the CLI to disable all IPv6 inputs dynamically which is something not possible at the moment.

Looks good. Is detect_if_systemipv6_is_disabled() already a
system function? If so, It can be incorporated (by you if you wish, or by
me). The last line is missing += by the way.

This code doesnt break if ipv6 is disabled by system wide:

Yup that did it. Thanks!

The form will be made consistent with other commands, using an explicit 'op' (show|generate) and 'path' as list of strings. For example:

First, I thought you had merged the patch, as you did not, there is no duplication ATM.

This may possibly be the cause of some bugs?

If the interface exists, it is perfectly harmless: it was the previous behaviour. The example where it can cause issue when a interface name is used and does not exists as it will create it. So really op_mode commands.

There are places in the code where operational commands are still ran without create=False, for example:
https://github.com/vyos/vyos-1x/blob/675f400bacb03ae93be928e7270f89205d1036b9/src/conf_mode/interfaces-bonding.py#L242

Fixed in the latest rolling.

Fixed.

Fixed in the latest rolling

sever@r11:~$ show vrrp 
VRRP is not running
sever@r11:~$ show vrrp detail 
VRRP is not running
sever@r11:~$ show vrrp statistics 
VRRP is not running
sever@r11:~$

I prefer the first one as it is proven to work since VyOS 1.2.x