Hello, @MapleWang!
Thank you for pointing our attention to this issue! It is really bad that such simple action as changing hostname in some cases (well, in fact not only this but it is easy to reproduce) leads to the whole router crash.
The problem consists of several parts:

1. In old systemd versions (which is used in Debian Jessie and VyOS 1.2) exists a problem, when during a restart of systemd-journald all pipes between this daemon and systemd services are disconnecting.
2. In vyos-hostsd, which is responsible for hostname and DNS and controlled by systemd we used print() for logging and debug purposed without enough handling of errors.

So, when arises the situation when there is no PIPE connection between vyos-hostsd and systemd-journald, vyos-hostsd not able to print messages and crashes. :(

I tested this morning and I was able to build the vyos-builder:crux and crux iso.

Please try again

This is fixed/was not present in 1.3-rolling.
1.2 is not possible to fix, the bug is in isc-dhcp which would need to be upgraded to a newer version.

Works correct on 1.3-rolling-201912190503

Awesome! Enjoy Testing!

@c-po, there is also third PR in vyos-buid: https://github.com/vyos/vyos-build/pull/69

Found it. Thx

@zsdc is thwre a second PR removing the old implementation?

After some more testing, after a reboot, a tcpdump -n -i interface icmp6 on a client machine shows nothing until restarting the radvd service on the routers.

I was able to build the container, but sudo make iso failed with:

Wow, you did it!!!
I’ll do some tests
But I don’t know to test on a current vyos build so I’ll have to wait until the PR are accepted.
I hope it will accepted asap.

Thanks, @elbuit !
We have prepared PR with full functionality: https://github.com/vyos/vyos-1x/pull/187
It would be great if you will join us and help to test it, find all bugs and fix them. :)

Hello @zsdc
I didn't tested it.

I did some work porting vyatta-netflow to new vyos model

Solved it by importing libyang binary packages onto http://dev.packages.vyos.net/repositories/crux/debian/pool/main/liby/libyang/ which is even better.

@c-po I can't find any usable from vyatta-ravpn now, seem we can archived it and drop from build process.

What services are provided by vyatta-ravpn?

Fixed in https://github.com/vyos/vyos-build/commit/f2d457a9ed089995783207574699ec98c6956291

Also fixed additional issue with multiple snmp script-extensions entry (jinja2 sort)

Hello, @elbuit!
As I see, NAT events can be recorded only by nfacctd, and therefore this is not possible with the current way to capture traffic (by NFLOG + uacctd). Fix me, if I was missed something, please.

In latest rolling 1.2-rolling-201912180217 permission problem solved, but exist one more problem with script path.
CLI allow us to choice script, which stored on '/config/user-data'

Also mention in https://phabricator.vyos.net/T1058

I found a easy way to reproduce.

I got the following error:

Testing now. Will update

Please pull and try again

Hi @max1e6 we are currently migrating the repositories to Debian Buster so there could be some turbulences

I've had no reply. I think we can consider it resolved.
We could always reopen it or open a new one if needed.

Thanks @Dmitry, building it again.

To avoid confusion, this will only be in the equuleus branch:
https://github.com/vyos/vyos-1x/compare/equuleus...jestabro:T1585?expand=1

Initial version for equuleus here:
https://github.com/jestabro/vyos-1x/tree/T1585

Hello @zsdc
I was also porting old style vyatta to a new one.
I've ported interface xml definition and almost finished the conf python script:

MPLS requires Linux Kernel 4.5 or higher (LDPcan be built, but may have limited use without MPLS).
Ref https://readthedocs.org/projects/frrouting-developers-guide/downloads/pdf/latest/

Hello, @elbuit !
We almost ready to release rewritten flow-accounting, and maybe we will be able to include your request into it. Can you describe more detailed what exactly records you want to have? It would be good to see an example pmacct configuration for your case.

PR https://github.com/vyos/vyatta-op/pull/32
Fix "show monitoring" command.

@sento own build 1.2.4 this is 1.2-rolling (branch current), in crux branch all works as expected.

T1350 T1820
Adding mentioned tasks which can solved

@Dmitry I had it once more on the production system - see attached log with the above loggin features enabled.

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

Now it works perfect.

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

patch will be proposed after keepalived.service modification
https://github.com/DmitriyEshenko/vyos-1x/commit/807864242773f482aa1894ca968a4396a3507187

end: sudo sh -c "VYOS_TAGNODE_VALUE='$VAR(../../@)' ${vyos_conf_scripts_dir}/router-advert.py" would have to be in /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/ipv6/router-advert/node.def
I can set that statically, which removes then the benefit for the use of other passes, IPv6 RAs can be sent over quite some interfaces.

Turns out that it might not be a smart move to keep it under interfaces, as it would have to implemented within the ethernet script or if it's a separate one, it needs to be called with VYOS_TAGNODE_VALUE, otherwise there won't be a way to find out what interface needs to be configured. If placed under service or any other path, it can be integrated into the config itself e.g. set service ipv6-ra interface eth0 <more options>, set service ipv6-ra interface eth1 <more options> etc.
That would only required to parse and compare configs for 2 interfaces which can be determined from the config.

https://vyos.readthedocs.io/en/latest/services/pppoe-server.html

https://github.com/vyos/vyos-1x/commit/b55b68f6246329468b4ab3450e127d5bab683bff or tomorrows rolling release will have it included. I keept the default 'replace' and you can chose between deny or disable, while disable removes the option entirely from the accel config, which I wouldn't recommend to do.

The issue can be reproduced by the following configuration:

@leacho Sorry, I didn't have the time to look deeper into that, as far as I know we currently have no workaround for it.