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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 23 2020
@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.
Apr 22 2020
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.
Apr 21 2020
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:
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'
Apr 18 2020
The code has the concept of options which can be infered from the default dict and thefore should probably be removed for simplication.
Apr 12 2020
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
Apr 11 2020
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 🤕
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)
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:d9:5b:04 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0 valid_lft 78872sec preferred_lft 78872sec inet6 fe80::a00:27ff:fed9:5b04/64 scope link valid_lft forever preferred_lft forever
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
Apr 10 2020
Apr 9 2020
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 :-)
Apr 8 2020
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) ?
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')
from shlex import quote def systemd(self, level, message): msg = quote(message) run(f'echo {msg} | systemd-cat -p {self.level}')
# sudo lsof | grep dev-log I am officially daft .. I thought it was not running !
@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()
Apr 7 2020
Apr 5 2020
Apr 4 2020
I could not tell you why it was decided to be this way.
As indicated, I could not test this patch.
This work is now completed.
@kroy could you please confirm that we can close this issue :-)
@jjakob thank you for the detail. I will work on it.
Apr 3 2020
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).
Mar 31 2020
@cpo is it what you have in mind: