@c-po Thank you for the quick response and especially for the workaround! This was of great value...

@alainlamar your effort and support is tremendous and very much appreciated. I'm also super new to VyOS "development".

Problem is that two new packages (mdns-repeater and udp-bcast-relay) are build on the CI server, but somehow do not show up in the package repository at http://dev.packages.vyos.net/vyos/pool/main/ which is used during build.

@c-po I re-arranged the code and the git commits and hope things are fine now so this ticket may come to its deserved end of life.

@dmbaturin Yes, as time permits. That's my worst constraint.

Hey everyone,

@c-po I did some major work on vyatta-wireless, including the introduction of nested nodes to configure card capabilities. Would you mind to take a look at it and suggest improvements for:

• using a better way than Perl smartmatch to compare strings against arbitrary lists of strings (like in Python if "bar" in ["foo", "bar", "baz"]: print("True"))
• a nicer way to getting rid of mutual exclusions without adding too much responsibility on parsing by wireless-hostapd.pl. Transforming ht and vht from multi nodes into nested directories and then implement a bool node for each capability flag would IMHO require much more parsing in wireless-hostapd.pl but would solve the issue with mutual exclusions which could be implemented as simple multi-choice nodes...

@alainlamar thanks for sharing your thoughts. Regarding your MR, you add a node sshd_option where someone could add ANY option to sshd. I'm not a big fan of those "you can do everything nodes".

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 ..

@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?

Hi folks,

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