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

Closed in https://github.com/vyos/vyatta-op/pull/7

Maybe it's interesting to attach the configs to the tested-build data-entry.

Great, I hadn't realized you were showing the selection method, not the script building.

jclendenan, /tmp/eee is just a sample file where installation script could take a list of available configs.
Almost like you describe below:

I like the concept, although I'm less sure about aggigating the config's together into /tmp/eee rather than using a static config.boot file

Tried to compile on sqeeze and got errors so it will only meet .1.2.0.

@hexes Could you update the task and specify which image you use and which error you get in it?

Pluto has changed to charon.

Hello. I want to participate in testing if possible. Thanks.

@mickvav The userspace software is not something that we need in the build.
I have just built it since it's in the packages\repo.
The important thing is the module and the libraries to build them.
I will try to disable the userspace software build and move on from there.

Well, just to make things clear - nDPI is actually a userspace software, that performs DPI analisis of data flow (from pcap-ed interface in real time or from .pcap file). It's interface to netfilter goes through ndpi-netfilter package, which actually opens kernel-userspace socket to forward some packets throug nDPI in userspace. If I am right in brief, we have two important steps:

1. Make userspace software compile and work.

I thing, this should require almost no vyos-specific coding - just original package should be compiled on vyos vuild system into .deb

2. Make netfilter-related package integrate into vyos iptables configuration.

Here we need to create some package like vyos-ndpi-netfilter, which fetches and compiles ndpi-netfilter, handles vyos configuration templates and creates correctly working .deb with all this stuff.
vyos-ndpi-netfilter.deb should depend on ndpi.deb

@mickvav Sorry, I don't have a build environment set up right now. I opened this ticket mostly as a service to the VyOs commmunity since nobody on the quagga side had gotten around to alerting you.

I think the next step for this proof-of-concept is to be tried and validated (setup log rules, tcpdump and send in traffic, manually compare counters to dump) then merged into the regular build-process and finally come up with a CLI syntax.

Could this patch be your solution. I remember there was the duplicate print effect when using DHCP-FO on the entries in the lease file in a specific condition that I've made it to ignore.

It took faster then expected with a help from a friend so:
https://github.com/elico/debian8-dev-ndpi-vel

In order to speed up the build process I want us to work on the VYOS development docker container.
Once we will have this I and others can do things much faster.
I will try to share my build node for debian in two days and then we can move forward from this one step forward towards simple kernel compilation for VYOS in a docker container.
After we will have this we can simply buidl the NDPI modules(which are being used in zeroshell....).

How exactly can we help you?

OK I have just seen that Mikrotik routers have p2p block and it's an iptables level concept.
I have compiled the module for debian but needs some help from others.
Waiting for others to help.

Hi
I think maybe we use openvpn dynamic challenge respons function for two factor auth.
Sms, email. etc.

@dmbaturin this is candidate for 1.1.8 too
@EwaldvanGeffen, as you more aware, any ideas why it happens again?
Thanks!

Here is a sanitised copy of the auth-ldap script. I never wrote it! Its just what we use :) It will need modifying to work

In T173#3019, @fatihusta wrote:

Maybe you can resolve with this method.

I did not test

Sent pull request. This thing is really trivial. @Alexis, would be so kind to that resulting package is ok? My building appliance is somewhat disabled right now and I have only a tiny amount of time to do recreate it, so I will be able to test that everything is ok next week only, sorry.

This is different but might be a little related - FoxPass publishes a one-line tweak to VyOS 1.0 to let them support two-factor authentication for IPSec VPN at https://foxpass.readme.io/docs/vyatta-vyos-ubiquity-vpn-clients
It would be nice to have this change possible via an option.

We do this a lot, having certificate + user auth for OpenVPN. Using this open VPN option, a custom auth script and extra packages:

When doing DHCP-FO it's intentional both machines send out a lease. The duplicate 'lease' issue in the show statements should've been resolved in latest versions IIRC. Which version are you running?

https://phabricator.vyos.net/P14

@EwaldvanGeffen I recall you had tested something similar in terms of setup of DHCP
can you assist here?
Suspecting some issues there

This bug is also present in the last night build

Maybe you can resolve with this method.

@dmbaturin I understand, and I didn't mean to be someone just grousing from the sidelines. My evaluation of that specific patch is the most I can offer at the moment.

@Alexis I wish, with this shortage of contributors, we were really in position to make specific plans regarding the timeframe. ;)
This also applies to the security updates issue. We really need a dedicated security watcher, but, sadly, no one wants to take up this role, so it's always done in a haphazard manner, which is a bad experience for both end users and developers, but that's what we've got.
In a few years of project life, the number of people committed to using VyOS in production grew, but the number of people committed to developing it almost did not, it's still just a few people who have to do everything, and, frankly, it's taxing. At this point, none of us can turn it into a full time job (the commercial support thing @syncer and I started may change it in the future and give some of the maintainers guaranteed N hours a week to spend on it, but it's still a very early stage).

@dmbaturin Oops, started my reply before your second comment was posted.

@dmbaturin I'm glad to hear that you'll be releasing a new version soon.

@Alexis By the way, if you are into the quagga source code, maybe you want to join the work on switching to the upstream or cumulus quagga and "forth-porting" vyatta changes to it?

@Alexis Please don't panic. This bug is only exploitable if RA handling is enabled in quagga, and by default it is not. Setting interface's IPv6 to autoconf doesn't enable it in zebra either.
I agree it should be included in 1.1.8, but it's not urgent. I suppose we'll build 1.1.8 some time next week anyway, there are other issues to be addressed.

1. It's one freaking line

@Alexis, sure, but don't have habit apply everything on first request from internet.

@syncer Did you read what I wrote??

@whiskeyalpharomeo pointed to
https://github.com/jeroennijhof/pam_tacplus
I talked with @dmbaturin and it looks like via PAM we can perform at least something basic.
@dmbaturin can you comment more ?

@mickvav can you see if it something trivial to port in?

@EwaldvanGeffen can you check this one
Thanks!

I have a similar problem, since 1.1.7 PFS in phase 2 is not working.
"Oakley Transform [AES_CBC (256), HMAC_SHA2_256, (null)] refused due to strict flag."
As you can see there is no pfs proposal sent by 1.1.7.
The same with a tunnel between 1.1.7 and pfsense 2.3.2.
When activating PFS on both there is no matching proposal, when disabling PFS on pfSense a proposal is found.

Yes, waiting a bit does not hurt. We are working on version 3 of the patch to accomodate the missing features

Reviewed the discussion there - I think we have to wait at least couple of weeks until it will be at least a little bit tested there...

The Quagga has been provided with a patch to support Large BGP Communities. This patch is for Quagga 1.1.0 but should be easy to backport if needed.

Hmm. Things are afoot.

Hi, I'm new and found my way here via WAR's blog post.
Big +1 for TACACS+ support.
I manage a bunch of cisco routers and now have half a dozen or so vyos routers in the mix too. I need to grant junior admins rights to these while limiting their ability to break stuff and currently use TACACS+ for this with the cisco routers we manage. I would love to do the same for the growing fleet of vyos virtual routers.

@hmkias I think that some kind of a daemon would be required to "coordinate" between the squid machine to the VYOS.
I had an idea about it in the past but never had the chance to actually implement it with vyatta.
However I have seen that in ZEROSHELL there is a very nice feature which test for proxy IP level availability.
How complex would it be to make a condition to the policy based on a lock file?

Why aren't you all discussing this on the Quagga mailing list? More generally, what is the VyOS project policy about work that belongs in upstream?

@amos.shapira Thanks!

Can you test if this happens with SNMP in this particular 1.2.0-beta1 build as well, and maybe in the preview images? I may have just had it happen after rebooting an instance...

Recent dev builds on the current (lithium) branch don't need to be told which port is the console; systemd is able to figure it out, and spawns the correct getty processes.

I've written a handy script to start ntpd manually:

I tried adding this to /config/scripts/vyatta-postconfig-bootup.script:

This hack does work, but it only lasts until you reboot VyOS. When the OS comes back up, you'll need to do this again.

Thanks for report @JBFUK !

Through an early allocation, IANA assigned 30 as the path attribute value for Large BGP Communities.

I'm not sure how much this will help, but I have a branch on a fork of vyos-build to build AMI's from ISO files: https://github.com/amosshapira/vyos-build/tree/make-ami

Same is true for T100

It´s time to build something for Azure
i have an account in Azure for testing and would be glad participate in the coordinated effort

@EwaldvanGeffen The main point is that the basic and working extra modules should be usable to the public since it gives anyone that want's to enhance the existing code.
The main example is blocking windows updates, if you have the sources you can see it's being blocked based couple simple things:
domain name in plain HTTP
domain name in SNI of SSL

I have used nDPI on CentOS 5 in the past with 'fair' results. The problem is that the makers of nDPI went commercial and their old/OSS package is afair not maintained anymore.

@mickvav I do not need it personally since it works for me fine on other systems but I would like to put my efforts in order to have others have some benefit from my work.
I will take a look at the ipt-netflow-code work and with time I will probably practice it.

@elico, have a look at https://github.com/mickvav/ipt-netflow-code - it's my vyos/debian repackage for ipt-netflow - another iptables target module which I've ported (and use in production) on my own vyos repackage. If you take it's "debian/" folder, put in your repo, than we can fork it and maintain as submodule.

@mickvav I learned the debian packaging and produced more then one or these for Squid-Cache but everytime I am sitting on the build it's from 0.
To deploy most of my compiled softwares I am using a tar.xz which can be deployed ontop of the existing system as a 'module' and I found it much simpler for me to work with simple bash scripts then the debian packaging.
Without someone helping me to repackage over and over couple times of packages then it's not being pulled into the box but merely passing from one side to the other...
@dmbaturin gave me couple tips and cleared things for me.
I will try to finish couple things here before we\I can dive into the subject.

Well, I think, I can try to make this thing work on VyOS, especially if the community is interested.
@elico, it seems to me to be that if you have this thing working with ubuntu you already have some debian folder which produces .deb's on dpkg-buildpackage correctly, or you mean that after just "make && make install" on running system, it installs and works?

It can be disabled as will.
It works or not like any other external module which doesn't require kernel changes.( the specific ve21loring version)

It looks interesting and I think QoS is a good application of nDPI. I'm a little nervous about what the performance and stability implications are. Not having looked into it much is it implemented as a module that could be disabled if needed?

@EwaldvanGeffen @rps @jhendryUK @trickv @UnicronNL @afics @dmbaturin
Can this be candidate for inclusion ?
Use case:
QoS subsystem, with nDPI we can add speed shaping for some(or all) protocols supported by nDPI
http://www.ntop.org/products/deep-packet-inspection/ndpi/

I m thinking on two approaches to the problem, WCCP or patching Squid. Ultimately the complexity and time decides the way.