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 :-)

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

@jjakob thank you for the detail. I will work on it.

I agree: the logs should reflect the actions performed to update the router following the configuration change. As this should be the same each time, we should be able to check a change with a saved replay, as a way to check that all is as should (part of the smoketest testing).

@cpo is it what you have in mind:

@jjakob if what you say is correct then the solution should look like. I can not test it tho (simply as I do not know how to setup OpenVPN and have no lab to make it work).

Thank you for the assignment but I have not looked at or touched the OpenVPN code (and never used OpenVPN myself).
This issue with the op_mode, not config mode, so so it must have been there for a while.
I could change the code to check that the file exist, and prevent this fault but I am not sure it would be the right thing todo.

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

It requires a migration of the VTI interface to python first.

Regarding the reference counter for changes. It can also be implemented by storing in an Interface specific class level dictionary the last know state of the interface.
However, should multiple instances of the class be run by multiple programs then this could become problematic and this limitation should be kept in mind.

The recent change in implementation have changed the code from "if/else" to data-driven.
For example, every class now has a "definition" dictionary which indicates what the interface can/cannot do, for example, be bonded or not or it it supports vlan.

There this three types of functions which as class can have:

• "normal" when the first argument is "self"
• classmethod (using the @classmethod decorator before the function). In that case self replaced from an instance of the class by a reference to the class itself (often called cls, in that case InterfaceClass)
• staticmethod (where the function does not need class data and is jus placed under the class) can be called with InterfaceClass.func()

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

Thanks - understood.

Hi jjakob, AFAICS the patch above should have fixed any problem with the ethtool. If not I will need to understand why.

was this was not already fixed ?
https://github.com/vyos/vyos-1x/commit/8f39784c847801c0b766a0c9289da0976ffd0604#diff-ca1457dc16e0b9a43de02cf08140b65aR123

let me try to put a quick patch for you.

we can fix it in two ways: undo the commit which check the return code of the program, hiding the issue and add a first BIG PRINT warning stage or find the root cause and fix it (harder).

also all calls to start-stop-daemon need to have a --oknodo option added

I believe your default settings are not bad as, in our case, we are part of the ntp pool and our kit will use our own NTP servers :-)

pushed https://github.com/vyos/vyos-1x/pull/261 which should fix the issue.
@lluu131 if you know how to use vi and only if you are sure you can run:

sudo vi /usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py +123

and you change CalledProcessError with RuntimeError

sorry for this oversight.

https://github.com/vyos/vyatta-op/pull/36

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