For clarity, I do not believe the rewrite in the parent task is the root of the issue, as the behaviour on configuration was not changed. The code was restructured but the action logic remained the same. The same commands/actions will be run now as were run before the patchset. If something changed it will be in the conf mode interface code and not ifconfig AFAICS

Yes the code always does down / up. It is something @cpo and I discussed and it was deemed safer when performing changes. There could be a way to indicate that a change occur which should cause a trigger in another section. Something all sections should run on every change. This would be a major design change as we would not anymore apply everything, would need to decide what part of the change trigger this update process and implement a new section and make sure it is run !

@jjakob this is the wrong phabricator entry to discuss it but I got your point ;-)

This is correct.

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

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

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.

@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

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.

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

https://github.com/vyos/vyos-1x/pull/372 will now not display tunnel (but gre-bridge) as options for bridge. Still not preventing them to be used.

works if run as root (or sudo) but not as it.

/sys/class/ieee80211 does not exist on VirtualBox perhaps the interface configuration should fail it is missing ?

So the commands were not on crux under the tunnel section and trying to use either ip link or brctl is failing:

For all the bridge issues, I wanted to see what was happening on crux, taking T2356 as reference:

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

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

Works for me ..

[ interfaces tunnel tun0 ]
DEBUG/IFCONFIG cmd 'ip tunnel add tun0 mode gre local 127.0.0.1 remote 1.1.1.1 dev eth0 ttl 255 tos inherit'

The code has the concept of options which can be infered from the default dict and thefore should probably be removed for simplication.

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

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

could you please try this patch. if it still fails, can you remove the 'mtu' from the 'options' line and try again ?

diff --git a/python/vyos/ifconfig/tunnel.py b/python/vyos/ifconfig/tunnel.py
index 0506066..46900ce 100644
--- a/python/vyos/ifconfig/tunnel.py
+++ b/python/vyos/ifconfig/tunnel.py
@@ -141,8 +141,8 @@ class GREIf(_Tunnel):
     default = {'type': 'gre'}
     required = ['local', ]  # mGRE is a GRE without remote endpoint

with T2238 interface can be listed using their feature definition (broadcast, bonding, bridge ...).

@zsdc asked if we could find out a better API for the command and there is an issue where it seems that the environment dict passed to Popen() is not working as expected.

on any equipment with many interfaces, you would expect "port 0" to be "eth0", etc. As vendors are likely to give incremental mac addresses to their interfaces, could the hardware mac address be used at boot to order the interfaces? adding new interfaces may cause a re-numbering but it would give stability on if the hardware does not change.

Naming convention seems fine.

It is a useful feature .. please do not kill, This patch will fix things until it can be looked into 🤕

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

fingerprint = cmd(fingerprint_cmd, shell=True, stderr=DEVNULL)

I have converted this to

fingerprint = cmd(fingerprint_cmd,  stderr=DEVNULL, input=input=host_key)

ok will add the feature once the current set of patch waiting approval are in to not have to deal with rebasing etc :-)

The works also include the migration of template to separate files as per T2230

It will not intercept what is printed by executed programs. I could add an option for the functions to have stderr intercepted and printed by VyOS (causing program errors to go to logs)

Everything sent to stderr will both go to the screen and syslog.
If you raise it auto-magically format the raised exception to the user (the traceback is sent to stderr and thefore goes to syslog)

This naive patch fixes the issue but I am not sure it is correct and will let @jestabro decide how to handle it (as git gives him as the author of the file)

diff --git a/python/vyos/remote.py b/python/vyos/remote.py
index f8a21f0..a69537e 100644
--- a/python/vyos/remote.py
+++ b/python/vyos/remote.py
@@ -140,10 +140,18 @@ def get_remote_config(remote_file):
                 print('HTTP error: {0} {1}'.format(*val))
                 sys.exit(1)

Yes, it is missing, nothing to do with me but the fact the code does not yet find what is what from the interface data as we discussed.
https://github.com/vyos/vyos-1x/commit/bbea850ea5f8ff0402cd276ab63963ece7e0c763#diff-667867449bff9faf1ac285125ceada77

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

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

It let you know ufo could not be changed, but your interface will work :-)

Yes, it is as you have as file in /tmp/vyos.interface.debug' which turns on this debugging :-)

There is an issue with storing the state of the interface and then applying it in bulk. For some interface we want to admin it down before performing change and then bringing it back up.
If we store this then only the change and the up command will be applied, this is not going to work.

@cpo should another task be created to make sure we exclude the interfaces themself from source-interface (s) ?

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

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

thanks to @runborg .. my own initial attempt to syslog failed (facility level ??)
This works

import logging
import logging.handlers
my_logger = logging.getLogger('MyLogger')  # logger is singleton
my_logger.setLevel(logging.DEBUG)
handler = logging.handlers.SysLogHandler(address='/dev/log', facility="auth")
my_logger.addHandler(handler)
my_logger.critical('this is critical')

@dmbaturin I was aked on slack to report the information via syslog. However the syslog server is not listening on on UDP port 514 on localhost. How would you like to proceed ?
should it be opened (I am not sure where this should be configured) or should the log be written on the drive using the python logging module (as I currently have implemented).

@cpo AFAIU the patches are not right as the code making use of Config() in the verify() section and AFAIU this is against the separation between get_config()

I could not tell you why it was decided to be this way.

As indicated, I could not test this patch.

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

This work is now completed.

@kroy could you please confirm that we can close this issue :-)