merged by Daniil. Please assign bugs to me, if any come up. I tested everything multiple times carefully, but you never know, so I take full responsibility :0.

@syncer , @c-po
I can also check from the python script if /etc/rsyslog.d/vyatta-log.conf exists and if it does I remove it, since it's generated anyway.
That file is basically the last item (well and the user implementation) I have to work on.

Hi Guys, @dmbaturin

Syslog rewrite is now almost done, I currently testing everything, so I think if all goes well, I open a pull request next week for it. I'm still not sure how I should handle 'set system syslog user...', the help text states that it logs to the logged in user, but I didn't find anything implemented in the old perl script.

Now I found out the mystery from logrotate, vyatta put the logrotate files into persistent storage since they are triggered by rsyslog itself. I have them currently moved to /etc/logroate.d since they are configured with a size. But this might be prone to a race condition. @c-po I think we need some kind of persistent storage for vyos as well if we want to decom /opt/vyatta at one point. Would be also good for T741.
I'm going to be busy with testing and work this week and I know you are busy as well, so no rush on an answer.

If anyone wants to view the progress, here is the link to the devel version.
https://github.com/hagbard-01/vyos-1x/blob/devel/src/conf_mode/syslog.py

status set to resolved. git repo needs to be merged.

Yup, that's what I think too.

I'd go for /etc/logrotate.d

@dmbaturin such configs must be placed where?

@syncer, @c-po /opt/vyatta/etc/logrotate/global is generated as well (logrotate for syslog files), where should I place the new one just under /etc/logrotate.d? It's going to be generated via the cli config, so an image update wouldn't do anything bad.
Also, I'm going to created different config files, rather than 1 global one. That way, we could later drop in database logging support and the such. As far as I have seen, you can currently only log to a remote host.

Sounds good, I experimented already with it. I can drop in certain functions into the same nodes. So the existing ones will still work. However the implementation of it will take a few weeks, primarily testing will be crucial.
The other option which I think might be a good one, is to implement everything which does currently exist and shift the new functions in for each update. That way rollbacks should be way easier and the overview might be better too.
I really like the functions I read about and played with them already in VMs, you can actually download a file and kill 1 firewall which doesn't affect your connection. So, multiple sync interfaces should be the way to go anyway.
I gotta think about it a bit more, op-mode is way easier :).

I think new version should still be able to sync with the old versions, since people will be upgrading routers in their HA pairs one by one, and loss of functionality during upgrades isn't a very nice situation.

I implemented the hack I proposed, in my tests it did work quite well. Let me know if there are still issues.

to give you an idea what I have in mind:

@hagbard Migration scripts are no longer that much of a problem (though they still need to be carefully written). See http://blog.vyos.net/writing-migration-scripts-and-manipulating-vyos-config-files-outside-vyos-just-got-easier

Oh there is more stuff, like the different modes and IPv6 which I think need to be implemented as well. My concern is if I change the nodes and all that stuff for the cli, it requires migration scripts, otherwise it will break configs from people who update.
How do you usually deal with that stuff?

My interest is sync over multiple interfaces in unicast mode (but multicast also) among other things

Making progress. There is a ton of options not implemented (e.g. multicast with more than 1 interface for HA etc.), if I implement it now I suppose I will need to write migration scripts?
According to https://manpages.debian.org/testing/conntrackd/conntrackd.conf.5.en.html, there are really nice features which I think become very handy once implemented, but I would also have to change the cli interface, probably putting sections in.
e.g.
set multicast default interface ...
set multicast ha1 interface ...
set multicast ha2 interface ...

vyatta deployed their own and modified dhcpd, their modification is to set the shared-networkname in the lease file (https://github.com/vyos/vyatta-dhcp3/blob/lithium/server/db.c#L135), which is parsed by get_active() (/opt/vyatta/share/perl5/Vyatta/DHCPServerOpMode.pm).
It's possible to set variables on a lease event (more events like release are possible as well, or executing scripts on a lease etc.). However, since there are multiple new features available, I think the best is to rewrite the dhcp-server (ipv4) stuff first.

Due to the newer dhcp-server package in jessie, the entries in dhcp.leases have changed and shared-network is not exposed in there, that is where the vyatta parser module fails ( /opt/vyatta/share/perl5/Vyatta/DHCPServerOpMode.pm ) in function get_active().

I can replicate it, looking into it.

All right. op-mode should be ready to go, but I haven't request a pull yet. I'm going to do still some tests and then moving onto cfg-mode.

Same reason as T188 & T154

... and also working with latest rolling version VyOS 1.2.0-rolling+201806300337. Please note there was a time with a "bad" StrongSWAN version, maybe that's what you have.

I can confirm it was working with Version: VyOS 1.2.0-rolling+201806050337

I also tested it on latest rolling and it is not working. It however does change something because when i enable it i can no longer ping from the Vyos router to the gateway.

yes, still an issue in the latest rolling. (VyOS 1.2.0-rolling+201806251824)

@c-po I've rebuilt those newer packages from source (typically by using apt-get source). Due to different libc and all they indeed cannot be installed directly.

Wireguard is only available from Debian unstable (https://www.wireguard.com/install/). @dmbaturin managed to install packages from newer Debian releases IIRC. Maybe he can assist b/c last time I tried, I failed.

@c-po please add wireguard package (maybe from stretch better)
After we can start work on CLI
Thanks!

Appears to work fine now.

nuviso@ubuntu:~/vyos/build-iso/pkgs/vyatta-wirelessmodem$ cat 0001-T701-LTE-interface-dosen-t-come-up.patch
From 00a04474535ec0eb2b17fe1d4368abff7f3aae46 Mon Sep 17 00:00:00 2001
From: Subramonia Pillai <subbu@nuviso.com>
Date: Wed, 20 Jun 2018 10:57:53 +0530
Subject: [PATCH] T701: LTE interface dosen't come up

I could see that T656 was already created, as a result of https://forum.vyos.io/t/inconsistency-in-wirelessmodem-wlm-interface-behavior-could-be-bug/1492.

it was not included in 1.1.8 iso
and not applies to 1.2
OVA for 1.1.8 contain manual fix

@tmartinson will continue here

here is github link
https://github.com/snar/bgpq3

@mrjester can you test on latest rolling ?