There you go: http://www.mybll.net/vyos-1.2.0-rolling+201808230337-amd64.iso

Do you have a copy of 1.2.0-rolling+201808230337 to share? I'd like to get wireguard working, but need L2TP working as well. It's no longer on the download page.

/etc/logrotate.d/frr exists.

my ISP supports PD, and I'm also willing to test. Can't help too much on the coding side. I'd love to have PD working.

fixed: https://github.com/vyos/vyos-1x/pull/50
(VyOS 1.2.0-rolling+201809082151)

T836 will fix that, which is currently being rebuild in ci.

After a successfull connection I see the spawned process:

root      2595  0.0  0.0   4332   124 pts/1    Ss+  22:58   0:00 /usr/sbin/xl2tpd
root      2868  0.5  0.2  26108  2484 pts/1    S+   22:59   0:00  \_ /usr/sbin/pppd passive nodetach 10.255.255.0:172.16.222.1 refuse-pap auth name VyattaL2TPServer debug file /etc/ppp/options.xl2tpd /dev/pts/1

Okay, I narrowed it down even further:

Thanks! Sounds like a proper fix to me.

Ok, so the issue with using messages is that it is defined in rsyslog.conf, which overrules then rsyslog.d/*.conf. I'm gonna get that fixed, back then I wasn't sure how to handle it and when I asked, I never got an answer. I'm going to implement your proposal and /var/log/messages will the global default (tail uses it via monitor too). The file vyos-rsyslog will be removed.

Yes and no. The /var/log/messages config is generated somewhere, I was asking about that while implementing. The problem was as far as i recall, that your settings in the cli aren't applied when you reboot. If you change something in the syslog config it will be accepted and then restart rsyslog and all is well. Then I got distracted with the wireguard implementation:).
I have a look today, thanks for letting me know.

Issue was introduced between those two images:

Thanks for fixing! Took me half a day today to figure this out :)

I guess then it was "broken" all the time

Yes, in some situations this is resolvable eg in the service broadcast-relay example. Here the owner parameter could be moved to the "top-node" for that block. the problem with interfaces is that every config block is a tagNode, so we can't do that trick without moving it to the interfaces node that catches all interfaces., and not just interfaces of the type you want.

In "broken" mode, no, as clients will refuse to sync to an unsynchrinized server. That's how I stumbled across this in first place.
In "fixed" mode, once NTPd is synced again, clients will fetch time from VyOS. On my testbed, I have this (now working) config:

Does downstreaming work when you configure set system ntp allow-clients address?

Can we add this functionality as planned?
need it for 1.2
so we can deploy it with ovftool

Why not doing it via NNTP group or mailing list? I live pretty close to the 'edge' of the world (UTC -8) but would be interested to stay up to date on what your guys decide. @c-po was so far my mentor here and I asked him to get some ideas how you do things here.
Just my two cents.

@c-po @dmbaturin this one is old

I think it's best done at the same time with IPsec CLI rewrite.

New pull request with Linux specific changes:
https://github.com/vyos/vyos-build/pull/24

I misunderstood the issues @mtudosoiu was talking about. Disregard the above pull request.

I created the following pull request to simplify the docker build process:
https://github.com/vyos/vyos-build/pull/23

Even happens without any argument:

cpo@LR1# sudo /usr/sbin/lldpd -d
2018-09-01T20:12:53 [WARN/lldpctl] unknown command from argument 1: `#`
2018-09-01T20:12:53 [WARN/lldpctl] unknown command from argument 1: `#`

Happens too when started by hand, where 172.16.254.35 is the management address

IPv6 DHCP

@mpoublon please confirm is same in 1.2
not likely that we going to fix it in 1.1.x

Just tried your configuration and adopted it to my LAB. I can't reproduce your issue.

I think that was fixed

Done!

That is for dhcp server, right?

Done https://github.com/vyos/pmacct/commit/22b9be62d8e1eba71db8391fe86ad95181645887

I had the exact same problem for the service broadcast-relay code. I did a cleanup on the youthful folly. Resulting in this issue going away (https://github.com/vyos/vyos-1x/commit/fd1eabe72862ec364643a61cb94b21c330a385f5#diff-e27a1d5bf8f371aae9da8bbd36e674d0).

It just died with this log:

You could also alter the file /etc/default/uacctd and add -d into DAEMON_OPTS and restart flow-acounting

@Line2 @begetan I added both of you as you seem to use SNMP (probably with v3). What's your opinion on this?