Oddly enough, whether I change the service settings or change the default settings of systemd, there are problems.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 4 2020
@c-po The problem was found when upgrading to the latest version, and the reason is not clear.
PPPoE is configured as follows (account password is hidden):
I want to do it and have to re explore the cause of the failure, but I haven't found out why dhcp6c can't start, I have to start it manually.
Changing the systemd defaults is a thing I hesitate to do! It will have a ton of unexpected sideeffects. I guess you have an error in your entire setup as multiple sites of mine work flawlessly
Strange, I found that this service may not have been started at all!
for me it looks like a name lookup error. I have read the forum entry mentioned above. And they fixed it by disabling name lookup.
I found that I had disable-host-validation configured and as soon as I removed it it happened to me, too. Changing task priority.
I have checked with a v4/v6 full table router and VyOS 1.2.5 - each SSH session will consume 7MiB which semms okay for me.
Availible in keepalived, thus kt could be considered for 1.3
This also has a measurable impact on CPU. You can tell exactly when I applied the nsswitch.conf fix.
forwarding { allow-from 192.168.0.0/16 allow-from 2001:470:f1cd::/48 cache-size 1024 domain pve. { addnta recursion-desired server 192.168.0.47 server 2001:470:f1cd::47 } listen-address 0.0.0.0 listen-address :: name-server 2001:470:f1cd::ff00 name-server 192.168.0.254 name-server 202.96.134.33 name-server 202.96.128.86 name-server 114.114.114.114 name-server 1.1.1.1 name-server 1.0.0.1 system }
Oh, in a system like vyos, SSH memory leak appears to be relatively serious. If there is a solution, it should be handled first
Jul 3 2020
To add to this, this link pointed me at the correct solution:
PR https://github.com/vyos/vyos-1x/pull/487 with changed CLI to service ids ddos-protection.
@elianora Email me at [email protected]
Again, please always attach a configuration file
I use myself a "cleanup" function, imagine:
In T2674#69525, @jack9603301 wrote:I wish you success in advance. Porting and compiling has always been a large-scale application project, which may take a lot of time. However, in addition to rewriting and porting related code to a more portable language, we can also try to transplant and cross build the existing old code first. Of course, this is only the first step. If possible, porting the code base has made it easier for the code base to be transplanted Meaningful.
As "ip" is an invalid key in "vif" (as its no VLAN number) it should not be part of the default dict I guess - same for vif_s
There are allready someone trying to make a guide for building vyos on arm and the pi3/4, i myself have made it work on the pi4 some time ago but did not save my work so i dont have all the steps to reproduce..
I wish you success in advance. Porting and compiling has always been a large-scale application project, which may take a lot of time. However, in addition to rewriting and porting related code to a more portable language, we can also try to transplant and cross build the existing old code first. Of course, this is only the first step. If possible, porting the code base has made it easier for the code base to be transplanted Meaningful.
Yes, I'm interested in actually helping on porting it as it would make my ER-X for one, a lot more fun and useful.
porting half of an operating system to a different architecture is far from easy. Right now VyOS still has a lot of the old Vyatta codebase in it. As we are more and more in the process of migrating this to a Python based codebase it will still take some time. To be fair I stater a project some time back to port VyOS on an EdgeROuterPro (https://github.com/c-po/vy-project) and at least "it booted" but I then switched my focus to VyOS first - so by migrating th ecodebase to our own vyos-1x based Python implementation it will become easier in the future to port it to other operating systems as there is less code, less packages to port.
Jul 2 2020
As always, please provide your config and probably a way to reproducs.
EDIT 1: Removing comment after speaking with cpo, I apologize for the confusion
I found that this problem may be related to T2673
Please open a new ticket or move your comment to an appropriate ticket, this ticket is not discussing your consernes.
Also on delete:
Jul 1 2020
Addressed by T2667.
The login banner was always user configurable, see https://docs.vyos.io/en/latest/system/user-management.html?highlight=banner#login-banner
This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.
A banner would be a good thing. At least you would be able to have some sort of legal message on your device. I would recommend no banner by default so users can add one.
Jun 30 2020
Re-reading the entry, I am now unsure what you believe should be different.
Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.
Ok, nice. And how about 1.2? Is it possible to fix this with the 1.2.6 release?