Yeah. I ignored T141 by purpose for two reasons:

• I do not know enough about what proper AAA support would exaclty mean.
• Maybe doing this one step at a time would make incorporating changes easier instead of trying to achieve it all in one run?

I think T141 also wants to achieve something similar but with proper AAA. Unfortunately my network has not reached the critical mass to go for a TAC server. But we should keep this in mind!

I propose to introduce config nodes to create AllowUsers, AllowGroups, DenyUsers and DenyGroups settings in sshd_config. Additionally, I propose to introduce a sshd-option config node.

thanks for the advice! My Git skills suck, but I'll try to catch up quickly. I cloned your repo, checked out branch z507-sshd and did a git diff c5e11462769bea9769335944f0f8a8f5411d027e > t507_c-po.patch which is the last commit prior to T507 commits. Then I ran diff on that patch file and the one I created before. No difference, which means, your commits are nicely done!

Dissecting your patch .. I come up with those commits: https://github.com/c-po/vyatta-cfg-system/commits/t507-sshd

@alainlamar thanks for the contribution.

T419 also needs this capability.

Okay, the proof of concept worked on the console

IMHO the whole serial part should be re-written.

Upon add system image vyos-xxxx.iso, serial speed arguments in Kernel boot parameters are set statically to 9600 baud, no matter what /config/config.boot states.
The culprit seems to be in file /opt/vyatta/sbin/install-image-existing lines 262 to 280, where templates from /opt/vyatta/etc/grub/default-union-grub-entry is used to set up the new grub.cfg. Within the latter file, serial speed is statically set to 9600 baud.

In T452#10768, @c-po wrote:

@alainlamar Kernel Updated and Rebuild triggered on CI server.

Uhmm, I guess, we may have a hard row to hoe here:

@alainlamar Kernel Updated and Rebuild triggered on CI server.

Today, I had a look into the vyatta-wireless package to see if I could hack something up to work with the new Kernel changes via VyOS CLI.

dnsmasq is good, but it's still need servers forward to
so i was thinking about powerdns recursor that can be used directly or via forwarder

@UnicronNL lithium branch @ https://github.com/vyos/openvpn

Please correct me if I‘m wrong but is the integrated dnsmasq insufficient for your needs?

Implemented in https://github.com/vyos/vyatta-cfg-system/commit/c5e11462769bea9769335944f0f8a8f5411d027e

DNS forwarding is done via dnsmasq.

Triggered Jenkins build https://ci.vyos.net/job/vyatta-cfg-system/281/changes, will be in the next nightly build

@syncer I'm doing almost daily installs for testing in an ESXi environment. No problems. I think this one can be closed ..

Found inside the Linux Kernels source code:

@carl.byington Thanks! Pushed to https://github.com/vyos/vyatta-cfg-qos

maybe it can have something to do with old vyatta appliances, not sure.
i agree with you @c-po, in case we may need something like that, we can reinvent the wheel later.

A FAT16 partition is created that is not formated? As It's also broken in 1.1.8 and nobody knows what it does I opt for removal of this "feature"

Pushed here for review: https://github.com/c-po/vyos-kernel/commit/0456e0acdcc5b9545723f57ebf489f2a1801a864

@c-po here you go:

@carl.byington Thanks! Pushed to https://github.com/vyos/vyatta-cfg-qos

Jenkins up and running again: https://ci.vyos.net/job/vyos-kernel/115/changes

@syncer will be "automatically" fixed by 1.3 as it uses Debian Stretch. So we don't have to do anything :)

@syncer looks like finished, but can't edit

VyOS 1.2.x ships ISC DHCP server version 4.3.1-6+deb8u integrated in Debian Jessie.

@syncer can be set to finished?

maybe we just move it to 1.3 instead?

@syncer looks like "Wontfix"

Current VyOS 1.2.x uses OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 26 2017.
We now install latest Debian Jessie security Updates inside every ISO. Going for 2.4.x will cause a lot of headache in VyOS 1.2.x...

Also see T71

@alainlamar thanks for your effort! Could you please regenerate your patch against arch/x86/configs/x86_64_vyos_defconfig which is used for the CI builds?

Yes, i'm ok with that
@dmbaturin @UnicronNL any objections?

@syncer: To recap, are you OK with the following changes:

Adjusted generated GRUB configuration to the one from Debian Jessie.

i will propose to use dst-vtep instead of destination

The VXLAN RFC states:

What would be a filter that is not working?

Please wait for todays build and test again. Thanks for your support!

IPv6 address in scp://<user>:<passwd>@[IPv6-address]/<dir> looks like not properly escaped. Should be \[IPv6-address\].

@syncer
Use the configurations I provided and observe the packets the router is sending out.
In the nightly build the router is sending out using the IPv6 group address
Up to 1.1.8 the router is sending out using the IPv4 group address
This makes upgrades impossible
Using VRRPv2 with both IPv4 and IPv6 virtual addresses in the same VRRP instance is only possible due to a bug in the 1.2.19 keepalived

On two debian 8 test VM I compiled keepalived 1.3.9 without any errors. It may be a good thing to get this latest version for our new implementation.

@aopdal can you please provide relevant information and not just bunch of already known info?
We need description of problem and how to reproduce it, not comments from captain obvious

The current implementation is working on keepalived 1.2.19 (from 2015.07.07). In 1.2.20 (from 2016-04-02) a lot of bugs are fixed and the possibility to use IPv6 in VRRPv2 is gone.
When implementing IPv6 / VRRPv3 we should probably base the implementation on a newer version of keepalived.

Testing on

Please test latest nightly builds and report back

@c-po i should get router with v6 and snmp
will ping you once it up