All works as expected; thanks.

redeployed. please try again

Problem is local to crux only

i think, you sould use crux branch for 1.2 build, current branch is 1.3

A fix for this is available in the latest rolling release

Okay, packages have been recreated for Debian Buster and RADIUS login works again (50%)

Reason this is broken is b/c VyOS 1.2 crux uses libpam-radius-auth from Cumulus Linux
ii libpam-radius-auth 1.5.0-cl3u1 amd64 PAM RADIUS client authentication module

Hm, already fixed https://github.com/vyos/vyatta-cfg/commit/8fa0ba1fd39145368f04576323ab3a29f42a508d#diff-fd7ed59d9a74789ca3e1298b38cf4027

@hagbard, thank you! This feature works properly, last value define how many sessions server can to serve

works as expected on 1.3-rolling-202001270217

I also can confirm this works in 1.2.4

PR https://github.com/vyos/vyos-1x/pull/209
also added missing completion help values.

Let me know if you come across any issues.

By default we don't need delay, I think it must be configurable feature.

set service pppoe-server pado-delay delay 100 sessions 100
set service pppoe-server pado-delay delay 200 sessions 300
set service pppoe-server pado-delay delay 300 sessions 1000

and configuration for this

@Dmitry What default delays do you suggest?

When using logrotate we can take full owership about the resources that will be used for number of files and its size - so i think this will be the best approach.

I've attached a simple patch to expose FRRouting's built-in capability of being able to apply a route-map to routes that are submitted to the FIB from BGP to VyOS.

Why we not fix just logrotate config for it?

I've attached a simple patch to expose FRRouting's built-in capability of being able to set a prefix's local administrative distance to VyOS.

I've attached a simple patch to expose FRRouting's built-in capability of being able to match on prefix's BGP local preference to VyOS.

I like the idea, but unfortunately I do not understand why there needs to be a cancel node? If maintenance mode is not activated shouldnt this be enough?

Works in 1.3-rolling-202001150217, propose cherry-pick in to crux.

The described problem exists in stable FRR 7.2, but fixed in FRR master branch by https://github.com/FRRouting/frr/pull/5184
We have tested 7.2 with this PR applied, and the bug was gone, so we can apply this PR to our FRR package and solve the problem.

I was getting a lot missing dependencies even all the vyatta/vyos-* packages were being complained that they were required but weren't being installed. I'd already deleted and re-cloned the build repo and cleaned out my local docker several times so i'm not completely sure what fixed building 1.2 ISOs again. Frustrating but at least it's working for the time being.

@bmhughes For me an issue was that cpio is missing from the docker image

edit:
I can build working images now, I have no idea what's changed over what i've been trying for the last few days.

@bmhughes I tested this on the downloaded lts 1.2.4 iso and it seems to work fine...

Service custom don't support 2 ddns entries now.
It overwrite login/pass to (login02) for each custom service

Please use service custom

https://github.com/vyos/vyos-1x/pull/200
adding CLI commands

Update
The problem was resolved by manually removing the interfaces from the file /config/config.boot (section flow-accounting)

Actually, this seems to be a build issue as a fresh build with the up to date vyos-build repo causes a fresh build of 1.2.3 to suffer the same problem.

I got this on two production systems on the next two I migrated I changed my workflow to:

Same behaviour with compiled uacctd version from pmacct git 1.7.5-git (20191224-00):
packets are arriving correctly to nflog group (tcpdump shows them) but they aren't processed by uacct