Thank you @hagbard. This copies unfortunately only the ssh host keys. Interstingly this also happens in install-image-existing and is likely duplicate code ?

I never had a look into that, however I found something interesting.
https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-get-partition, check out save_old_keys() at line 433.
The script you are looking into is, when vyos is already installed.

The below code does work if inserted at line 254. It does however mess with the ownership of the home dir it's all owned by vyos afterwards even though cp -p i used, resulting ssh key based authn not working anymore until fixing ownership.

Thanks @c-po. I'm not sure though - how does "user creation" matter in that context? I had the impression that preserving home/user will be mostly a matter of adding a few lines of code to https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-image-existing similar to the /etc/ssh block starting at line 240. Am I wrong?

Also user creation is handled in https://github.com/vyos/vyatta-cfg-system/blob/current/lib/Vyatta/Login/User.pm

is it. I can surely extend it quick and dirty to have something working which can then be improved and beautified as needed.

I would start to look into /opt/vyatta/sbin/install-image*, those are the 'install image' scripts, you can see the mounts there since the OS part is a squashfs mount.

If someone could point me to the relevant code files / documentation, I can give it a look.
If it is a simple thing to do I may even be able to create a PR.

We did an upgrade of six running instance with complicated Ipsec configuration ( 10 to 50 peers) from VyOS 1.1.8 to 1.2.current. For 1 time from 6 we had a problem with Charon's install_routes = yes

Sure. The "best" way to visualize flow data is to install nfdump/nfsen:

Hey @aibanez @csalcedo your input here is welcome :)

Hi @panachoi thanks for the info and sharing your config. I was always interested in Netflow (what is it, what can I do with it). I'm happy to look into this but could you tell me any software which I can use to display (graphically would be the best) the flow result?

https://github.com/vyos/vyos-1x/blob/new-vrrp/interface-definitions/vrrp.xml The new syntax draft.

I think we can remove old providers and add options for apn profile like "apn", "user" and "password".

Encrypted passwords depend on the engineID, or lets say it in other words - encrypted passwords are hashed/salted with the engine ID. Migrating the encrypted string to a different machine with a different engine ID will fail.

I was able to copy-paste configuration on latest VyOS 1.2.0 rolling update in my configuration
I also mentioned that my current configuration has not separate set v3 engineid 'id' command as in initial comment,
and it is working without problem.

This script can be removed as soon as we will implement better way for populating AS numbers in netflow configuration.

I'm gonna close 721 since self-assign does now work. I track via the original T696.

I think it's useful for troubleshooting

Hi Guys,

I posted a comment asking Adam over at ZeroTier to see if he could help with this task.
https://github.com/zerotier/ZeroTierOne/issues/418

Thanks ??

That's my punishment for the sin of only testing op mode commands from conf mode.

I just observed that I had these famous "kernel:[ ] Uhhuh. NMI received for unknown reason xx on CPU y." messages on the VM. Seems to be a common problem with the Q35 chipset in KVM. I suspect that this may have also caused the erratic behavior in VyOS. I'm now back on i440 and will close the bug until it occurs again.

Please have a look, I changed some logic compared to the original perl script. I read the real set values, while many are set in the perl script itself. The interface definition and everything else is still pending. My ideas was to have the op stuff implemented first and put in place, since the cfg stuff is separate anyway.
Just copy the script into the vyos home directory and call it from there before it makes its way into the vyos-1x package.
I would really appreciate if anyone with a life config could test it, I just configured 2 VMs and test it.

The host is Debian9 with KVM. I have a few VMs running there, never had a comparable issue.

My guess it that something is wrong with your terminal or you have some weird unprintable characters in it.

May these entries in /var/log/vyatta/vyatta-commit.log be related?

Just had it here

Couldn't reproduce on a fresh VM so this must have been a singular anomaly ;)

Please re-open if issue should occur again

Update: I was now able to set a new host-name. When I logged in from a different machine it miraculously worked and the error message disappeared. Still assuming there is something wrong here, somewhere?

seems to be not best approach

I can confirm that this is now fixed. Tested again VyOS 1.2.0-rolling+201807020337.

@Line2 thanks for retesting.

I just tested with VyOS-1.2.0-rolling+201807010337. I deleted my SNMPv3 config completely and set it again.

@c-po . I just tested on VyOS-1.2.0-rolling+201807010337. And it's fixed! My network monitoring can read the ifalias over SNMP. Thanks for fixing!

Please retest with latest ISO

@c-po problem exists on SPOKE node
1.I have updated to latest rolling
ma@ipsec-dmvpn:~$ sh ver
Version: VyOS 1.2.0-rolling+201806300337
Built by: autobuild@vyos.net
Built on: Sat 30 Jun 2018 03:37 UTC
Build ID: b813533d-49f2-44fb-9b35-9a15e2821f35

@oleksandr.mamenko could you please provide a config snippet?

Problem exists, related to missing options

Just spawn a VyOS 1.1.8 VM and the ifAlias appears on my libreNMS instance.

RFC compatibility settings prevents VRRP from working on Hyper-V because of promiscuous on NICs
Without the RFC compatibility this is working fine.

Option 2 seems best. VRRP version does not need a setting, use VRRP V2 when no vrrp6 block is present for backward compatibility. Use VRRP v3 when it is.

Currently added vrrp health script
we need to think on more complex approach (when monitor can be used from several apps)