Fri, Feb 9
Tue, Feb 6
Sun, Feb 4
Jan 17 2018
I am very interested in this, has any work been done?
Jan 15 2018
Jan 5 2018
I like the way it works now, but honestly as long as I can get to both the CLI and the OS shell somehow (with a command), I don't really care which is the default.
Jan 3 2018
Dec 18 2017
Thanks for discussion, marking this as wontfix.
Dec 17 2017
You're spot on and I realize how naive my original request was. Pi-Hole isn't something that should be running on an edge device.
Dec 16 2017
Sorry for the unsolicited feedback, but... BUT... ;-) Honestly, I think the way the Pi-Hole stack is put together does not lend itself well to a firmware-like platform like VyOS. In fact, personally I can't even suggest it for anything more than home use. Frankly, it's a bit cludgy on the back-end. Further, it increases the potential attack surface of your router, which is in general bad security practice. IMO the best course, even if by some twist of fate Pi-Hole WAS integrated into VyOS, would be to run Pi-Hole as a separate service. DNS is one of those things that's easy to run alongside routers; there's no compelling reason I can think of to run it ON the router. Buy a $35 Pi, run a tiny VM on existing hardware, etc. and serve that DNS server to DHCP clients via VyOS. That's my $0.02, adjusted for inflation.
Dec 5 2017
Dec 4 2017
trivial patchattached. I am running 1.2.0 "current" with this.
Nov 28 2017
Nov 27 2017
Any updates to this?
Nov 26 2017
Nov 23 2017
Nov 17 2017
First logging into a normal OS shell probably would help with third party tools (like ZeroTier and JumpCloud that I requested as features).
Nov 11 2017
Nov 8 2017
Nov 7 2017
This did the trick. Just build a fresh ISO:
This seems to have done the trick thanks.
@UnicronNL maybe this will fix this issue:
Nov 5 2017
Nov 3 2017
Our nightly builds ships wpasupplicant 2.3-1+deb8u4, according to https://www.debian.org/security/2017/dsa-3999 it's fixed in 2.3-1+deb8u5.
Oct 31 2017
I have not approached any of the Pi Hole team yet, but I do appreciate the realistic feedback.
Oct 28 2017
Oct 26 2017
I'd also greatly prefer unchanged default behavior, but a config option to bring in the new hotness :)
Oct 25 2017
How exactly do you see the two products interact on a single system?
Do you have this request on their ticketing system? Can you link the two?
Does it have to run on a rpi?
Considering JSON's a standard that's quite close to the VyOS syntax, i don't see why maintaining another nonstandard format is needed when JSON is available :)
Oct 24 2017
Oct 22 2017
Oct 18 2017
Oct 17 2017
Oct 16 2017
Oct 11 2017
Comment by @beamerblvd on 2016-01-24:
Oct 9 2017
Oct 3 2017
Oct 2 2017
Oct 1 2017
Sep 27 2017
Hello, is there a way to easy install kernel source/headers for default kernel used by vyos 1.1.x (3.13.11-1-amd64-vyos)?
Sep 23 2017
So it looks like vpp progressing a bit.
Sep 22 2017
It looks like you have this compiled to much newer kernel, 4.4.15 while current kernel in VyOS 1.1.7 is 3.13.11-1-amd64-vyos.
So it looks like i need to compile it by my own, but thanks anyway for sharing this ;)
Here you are -- it expects to be extracted in / directory. But no warranties on any binary compatibility with current version of kernel and iptables. AT ALL.
Ups, seems I was wrong in last comment. I'll collect all the files from .deb and post them here.
Well, I don't have access to development vm, where I did this stuff today (remind me on monday, please), but I do have kernel module (the only file in .deb, actually) compiled against 4.4.15-amd64-vyos kernel.
Is there a chance that ipt_NETFLOW will be included in next release (and if yes, where it is planned to release this version?)
@mickvav Can you share your .deb package please? We need ipt_NETFLOW ASAP. Thanks
Sep 18 2017
Sep 16 2017
Sep 12 2017
Sep 7 2017
@sebastianm In VyConf it's going to be fairly easy (ok, possible at least) to implement different input and output formats, so chances are we can add | display json or | display yaml filters if there's demand for it.
Unless there is a specific advantage to changing the behavior of VyOS the existing behavior should be kept. What is the advantage of going having the linux shell be the default? Also, I like the idea of making it configurable.
Sep 4 2017
I'm all about compatibility with existing behaviour. Looking back over just about every network device I've ever operated, and the bits that annoy me the most is when behaviour is changed in a surprising fashion. I know there's a tension with the ability to actually continue to improve the product, but where there's a choice between 'make it unsurprising', or 'make it cooler', from a user perspective, you want the developers to have exhausted every option to do bother before making it surprising.
Sep 2 2017
That is not something that we need to choose between,
we keep both, but for environments where users comes from AD, LDAP, Radius, etc.
Actually I like the fact to have the users SSH pub key inside the config. This makes it super handy to just copy/paste a users config entry arround VyOS instances.
Aug 28 2017
To my mind... I'd rather keep a compatible syntax than a new one, even if there are benefits in terms of uniformity and parsing.
I say don't change it. I'd consider JSON/YAML though. (I am/was lylylyly on IRC).
Aug 21 2017
There was no interest on this, closing as invalid
Aug 7 2017
Aug 3 2017
Merijn is right in my experience. I think root should get unix and the rest the vyos-cli. If you make it a configurable setting within the vyos-cli it would be bestest for everyone.
Jul 26 2017
The specification has been published as IETF standard: https://tools.ietf.org/html/rfc8092
Jul 25 2017
Jul 24 2017
Jul 23 2017
Jul 4 2017
Jun 28 2017
Seems to be OK.
May 29 2017
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).
May 23 2017
been using the VyOS 1.2.0-beta1