The called code can return 3 - in that case in that case _run should return an empty string

https://github.com/vyos/vyos-1x/pull/422/files

It causes this:

9140 ?        Ss     0:00 /bin/bash /usr/libexec/vyos/init/vyos-router start
 9427 ?        S      0:00  \_ /bin/bash /usr/libexec/vyos/init/vyos-router start
 9428 ?        S      0:00      \_ python3 /usr/libexec/vyos/vyos-boot-config-loader.py /opt/vyatta/etc/config/config.boot
 9451 ?        S      0:00          \_ /opt/vyatta/sbin/my_commit
 9522 ?        S      0:00              \_ sudo sh -c VYOS_TAGNODE_VALUE='eth0' /usr/libexec/vyos/conf_mode/interfaces-ethernet.py
 9523 ?        Sl     0:00                  \_ python3 /usr/libexec/vyos/conf_mode/interfaces-ethernet.py
 9531 ?        R      0:00                      \_ /bin/cli-shell-api --show-active-only --show-show-defaults --show-ignore-edit showConfig

related to T2088 where performance is also being discussed.

waiting for a decision on T2485 before doing this work

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

I have worked and provided a patch for T2485 .. It may be the right place to move it in.

https://docs.google.com/document/d/1pKkxwq5eBm9eSTmyrSluDU1cx8NYqQRkQNdTB1tCSdk/edit?usp=sharing

Every call to /bin/cli-shell-api --show-working-only --show-show-defaults --show-ignore-edit showConfig takes multiples seconds (6?)
/usr/libexec/vyos/conf_mode/system-timezone.py call it twice.
/usr/libexec/vyos/conf_mode/nat.py call it twice
/usr/libexec/vyos/conf_mode/interfaces-loopback.py call it twice ... etc.

0-18 kernel boot
18-41 system starting inc FRR
70-120 the python most of the time is spend/wasted in cli-shell-api - so I would think reading the configuration file. If we can optimise / reduce this number of calls it would be very good.
140-220 is more or less firewall setup with vyatta-firewall / vyatta-upset.pl / ip6tables

I need to double-check (and may not get to it) but if you use a vyos-build to build current and then try to build crux, make iso is not happy. I am now building crux using the command in my post above, the only difference: clean vyos-build install before the git checkout crux.

ediing vyos make iso -r crux -d
https://github.com/thomas-mangin/vyos-hacker-toolkit

Last time I generate crux I used the docker current to do it ...
(but I could not this time...)

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

@runar just created this as I can not create a dev env without a phabricator entry. answer in 20 minutes :-)

The run code could check the command name against a list of known "need sudo" commands and prepend it automagically so the command looks like normal but is auto-sudo'ed

https://github.com/joejulian/xterm/blob/master/resize.c Not complicated to port in the vyos library, replacing the current code and therefore only run when required

Should we trap the signal in vash, set an env value and use it with vyos?

If enable is not clear as a name to say that it adds the feature to the class, it is a class decorator, then please suggest a better name.

I will look into the use case and see if I can think of something.

I have implemented a "validator program" which is an entry point which will locate a named python program and run it. It uses the import mechanism of python at startup so the setup time is very high.

I raised this with the team and the idea of auto-detection does not get much support, which is fine, I just wanted to make sure I was doing the right thing. So I will finish this patch which will prevent some failure case and try to make the error message friendlier. Also, can look at where in the chain of change the MTU is performed to see if it can be rolled back.

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

@jjakob it does nothing about the boot case but it would be much easier to add it to that code than what we do ATM.

It seems that github has special rules for the .github file and that no PR can be done for it:
https://github.com/thomas-mangin/vyos-1x/blob/T2436/.github/workflows/pythonapp.yml

I would also suggest doing the same using github actions so that on push to your local repository to get a warning from github.

Why do we need to remove all addresses from the interface when it is disabled?

Can I throw https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/interfaces-tunnel.py#L32 into the mix?

How this can be implemented in practice was tested with https://github.com/thomas-mangin/vyos-extra

• the program can be installed using pip/setuptools and the "vyosextra.main:main" entry point, generating a "vyos" program.
• the "release" program in the root folder generates a self-contained executable (using the builtin python3 zipapp library) which can be place before in the path, taking precedence over the installed version.
• each feature "vyos ssh", "vyos update" is a single program and could be installed independently using other entry points
• dropping a program in the folder automatically registers it to the main "vyos" program, each program has a "def main()" with a docstring used for the "-h"
• the assets in the data folder are converted into python dict and used when the program is a zipapp.

@jjakob I was going to offer to do so this week if people agreed to give me a chance to show good it could be.

Using shell scripts would be a step back. The biggest part of the python script is the parsing of the vyos code. That's why I am suggesting that vyos command should be sent to a python daemon.
We can connect to it using IPC, and this can be done via a small C wrapper (or even directly in the caller's code to not even fork).

vyos@vyos# time bash -c ""

I was also wondering if we should attempt an auto-detection of MTU on boot and save the result? This is why I was asking if this was the right approach.

Not sure if this is the right approach or not. Feedback welcomed.

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

ack - I will change this to make sure it is safe !

Some code should also be added to detect the parent MTU size and make sure a clan MTU is smaller than the parent

The mtu provided are reasonable and should not fail IMHO. I need to understand why Linux does not want to honour it.. hw limitation or other. If it is a limitation then we should detect it and report it to the user

That would only hide the problem. The MTU bug would still be here.

An issue to change the MTU should not fail the whole interface change but just this one but the code does not not allow this easily. I will try to work on this.

The reason seems to be that when the kernel can not change the MTU when writing to the sysfs, it will raise a OSError with the reason why.

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

https://vincent.bernat.ch/en/blog/2017-ipv6-route-lookup-linux

Marek Isalski Today at 6:31 PM

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

@Merjin is trying this:

sudo sysctl -w net.ipv6.route.max_size=131072

https://serverfault.com/questions/902161/linux-host-randomly-stops-answering-ipv6-neighbor-solicitation-requests
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115

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

@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!

any L2/L3 issue affecting TCP between the BGP speaker will cause this message. Looking forward to a TCP dump of the traffic when it occurs.

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.

@jjakob if you enable debugging and record what is happening to the interface when it drops would be useful.

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