something between 16-00 and 21-00 CEST

Not yet 

Has a time for the meeting been set?

Day for meeting is 1st of August

@EwaldvanGeffen it's not clear to me if and what is implemented.
Can you please describe what is implemented and in what version?

is already implemented. great!

Thanks Amos.

Hi Julian,

Hmmm. Can't reproduce this on v999.20170626 at least.

Pull request sent to fix this one.

Pull request sent to fix this one.

Indeed. Looking at the original script, it looks to aggregate config and log entries into a big pile of output, presumably so that somebody can attempt to diagnose it in a support sense.

@logan.attwood Yeah- I've seen that it's in the source but I'm running a Beta build from a couple of weeks ago and it does not seem to have made it into those builds (unless I'm doing something wrong).

@sirket it does now!

Actually merged year ago.

Merged in october.

Seems to be OK.

This is an incredibly useful feature specifically because of the AWS transit VPC solution mentioned above (it's a great way to create horrible routing problems if you don't know what you're doing- but there are so many other ways to screw up with BGP that I doubt this a deal breaker).

In T266#4603, @amos.shapira wrote:

Just posting here in case someone can help me out -

I manage to create a booting VyOS AMI 1.2.0 but it fails to fetch the ssh key and configure ssh daemon due to (as far as I can tell) "setupSession" aborting on a failed assert(3).

The next two steps I intend to try:

1. Configure the AMI to run sshd outside the VyOS configuration just to let me access the setupSession core file
2. Need to get debug symbols for setupSession to try to understand what the variable it aborts on is supposed to hold.

Any tips to help do this would be welcome.

update squidguard package in 1.2

I added a force-gateway option some time ago. Regardless it's somewhat expected on 1.2, it needs testing and review. I meant 1.1.7 in my previous post (yes, confusion).

Is there any progress on this? Is there any design documents in progress?

been using the VyOS 1.2.0-beta1

I'm sorry for the belated response. This is great. Thanks for your contribution @fatihusta! Once testing checks out I'll add this to my CLI integration todo.

What version have you been using?

@higebu i think we need custom config for waagent
with Provisioning.UseCloudInit=y
This options enables / disables support for provisioning by means of cloud-init. When true ("y"), the agent will wait for cloud-init to complete before installing extensions and processing the latest goal state. Provisioning.Enabled must be disabled ("n") for this option to have an effect. Setting Provisioning.Enabled to true ("y") overrides this option and runs the built-in agent provisioning code.

I think we need to get working some translation of waagent to initial vyos config
it will take a look

I tested VyOS image for Azure with waagent for Debian. But it doesn't work. The installation script for waagent is here: https://github.com/higebu/vyos-build/blob/c53c52c25979a50c20bfc1225a22eae66a9f031a/scripts/packer-scripts/azure.sh

in edgeos each loadbalanced interface has it's ip table set directly at the interface-health section of the loadbalancing config. ex:

https://github.com/vyos/vyatta-cfg-system/pull/56

@Boltsie It should be fixed in this iso: http://dev.packages.vyos.net/iso/current/amd64/vyos-999.201704290958-amd64.iso and next to follow.
Could you please test if this fixes it for you?

Damn!

In T233#5032, @UnicronNL wrote:

:)

This was done:
https://github.com/vyos/vyatta-op/commit/76822101f04681402df67fcb194e8c0fdd71c96d

:)

https://github.com/vyos/vyatta-cfg-system/commit/84a94fd063c27c60f1cdd8902b549d375c02ceb7

https://github.com/vyos/vyatta-cfg-vpn/commit/876cb466c7256973917dc56f81f08bf8364b900d

This is a Debian upstream package, the bug will be fixed when we move to sarge.

It is running on 1.1.7

@MustDie did you try 1.1.7 ?

I tried doing some basic routing with ofp and it seemed to work but the shipped dpdk version does not compile for my kernel (4.10), so I can't test that.

I have tried this and I could not seem to get any data what-so-ever to go over the open fastpath interface, so I don't think it is a viable solution.

Has anyone tried to do something with the howtoforge: https://www.howtoforge.com/tutorial/opendataplane-with-open-fast-path-on-ubuntu/

for now it is set to fixed speed.
please close if agreed on this.
https://github.com/vyos/vyatta-cfg-system/commit/d582bbaf3ad95566de9b90d1572d60e39936a1a7

@EwaldvanGeffen I could agree...

@mdsmds you sure that is not it's intended purpose; scare away people from enabling root on their boxes ;p I'm hoping to have some time soon to do some small stuff like this.

yes, I think so, otherwise allow-root actually has no effect :)

Okay, so maybe we should expand the configuration in that case a little. Let's make it replace whatever value is found and allow all three options in the CLI?

more:
in "/etc/ssh/sshd_config" we must manually locate the line with "PermitRootLogin" and set to "PermitRootLogin yes".

In T167#3350, @EwaldvanGeffen wrote:

That's strange because it's exactly what the code does: https://github.com/vyos/vyatta-cfg-system/blob/current/templates/service/ssh/allow-root/node.def

try on latest nightlies from
dev.packages.vyos.net/iso/current/amd64/

I've been running Tayga on a debian box for the last year or so and have not noticed any performance problems, but I haven't compared Tayga with Jool.

@dsummers jool seems to be kernel-level and tayga seems to be userspace-level. The first one should be faster, and I expect package loss in the second one on high packet rate.

Well, I think I can some day do some things on adding this to CLI, if someone points me to known-working config for this feature. Am I right that this IPv4 - IPv6 NAT can not be implemented by iptables/ip6tables stuff? If netfilter already can do it - it's much better to do this things in kernel (as netflow, in my opinion).

I've just tested TAYGA installed on VyoS 1.2 (Beta) and it seems to work fine even though there is no configuration for it in VyOS.

Any news on this ?

We had some preliminary discuss with @dmbaturin about how to deal with this
and came across an idea that we can use link files to rename devices in correct order via link files
Once we refactor old scripts that rely on old naming scheme(e,g, ethX) we can switch fully to predictable names

@UnicronNL it seems we need to update systemd to 220 or higher to get this working
also, for now we can just disable it before we prepare environment.
But still will be possible to enable it on case by case basis

In T100#4801, @silverbp wrote:

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

I don't know enough to be able to do this in GCE without some help, not sure where to start. I was using the AWS packer image as an example but got stuck. If I have something to go off of, I can use that and work through it and/or ask questions as needed.

Well, I take vyos-kernel, iptables, build them in packages directory, and put ipt-netflow from here: https://github.com/mickvav/ipt-netflow-code as git submodule in the same packages directory, build it there and get working .deb package containing module, crafted for current vyos kernel. I have no CLI integration for it though I use my own firewall-messing scripts. But in general, you jest have to do modprobe the module with right parameters (where to send collected data) and add somewhere in firewall the rule with "-j NETFLOW" to trigger, which packets to take into account.