It would be nice if this was available in the next release. Happy to receive any feedback if I need to improve the patch.

I pushed the priority changes I had to do on my T132 branch.

In T128#2209, @UnicronNL wrote:

As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.

As it is now it can not break the config, that is why "wontfix".
If we block it then configs that have non existent interfaces in them (due to breakage or removed and forgot to remove from dns forwarding) will fail at boot.

In T128#2194, @dmbaturin wrote:

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

But what's worse, is that making it a commit fail will break the configs of those people who carelessly left a nonexistent interface in their DNS forwarding config, it will fail to load at boot time after upgrade.

As much as I hate generating configs that make no sense, leaving those people with potentially inaccessible systems after they upgrade (DNS loads before SSH AFAIR) is not an acceptable cost of somewhat tidier generated configs.

As @UnicronNL says, lines about nonexistent interfaces have no effect on dnsmasq functionality.

https://github.com/vyos/vyatta-vrrp/commit/86a3e32d367c6936fe424d6aace06ea7262f4300

@dmbaturin is about unsaved changes indication
@jeffbearer system loads last saved config

Can you push your recent changes to github?

Changing the priorities, I managed to make it work and it's loaded fine on reboot.

You need "create" section in your templates/policy/route-map/node.tag/rule/node.tag/set/src/node.def to make things survive reboots, I think.

Ok, so the main issue is that the route-map is only applied to routes installed _after_ it's been setup ... so you have to remove / readd all the static routes which obviously doesn't work when you reboot :(

This is my attempt :

vyos@r1-80001# run sh ver

@higebu seems correct.
It will be a good start

We need this? https://github.com/hiroyuki-sato/vyos-cfg-zabbix-agent

confirmed, works just fine of free esxi

I think we can choose how to implement it. We can apply it as a default entry in one of the vyos chains or let the user-decide. The advantage with the latter is that both implementations can co-exist for a while. With the former solution I would remove the old implementation to not confuse the user.

Hm, as ipt-netflow is actually a firewall target, it looks like it's configuration logic should be slightly different from pmacct's one.
Looks like there should be some service level config tree, specifying module load parameters, like

@afics thanks, i merged it to this one

Related/duplicate: T33.

I had to disable dkms there
https://github.com/mickvav/ipt-netflow-code
And if anyone is interested - I also have xtables-addons compilable against vyos kernel (it has several interesting firewall features - such as geoip and ipmark) - https://github.com/mickvav/xtables-addons

Well, I have ipt-netflow on self-rebuilt vyos kernel, no problems with performance. But I have no vyos-related scripts for interaction with this module.

These should be gone now.

And some more, on the machine with working config:

Ok, now works, but I've got some strange notices on "show vrrp" :

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

Makes code simpler and easier to read. Makes kernel a bit smaller (leave out floppy module)
Makes booting a little bit faster.

Why should we remove support for obsolete features, which do not break anything?

@dmbaturin can you take a look and merge this patch ?

I already have a working patch for my own setup, I attached it:

Changing this to wishlist,
@dmbaturin please comment your view of this
Thanks

Hello,
we considering a possibility to add DNS recursor,
however, for now, there is no ETA for that functionality.

@dmbaturin this should be not hard to implement, correct?

About systemd there is another point - if you look into systemd default setup (/lib/systemd/system/[email protected]), you can find that it's default setup is rather clever - it takes advantage from agetty's ability to automatically select console baud rate. But current vyos configuration scheme insists on some fixed baud rate. So, we also have options:

1. (simple) Remove speed option or ignore it. + allows usage of upstream systemd configuration
2. Alter systemd configuration to use fixed speed from config.
3. Modify speed to accept list of possible speeds, e.g.

speed "9600[,38400...]"

For the jessie branch, we are likely staying with systemd, so systemd-related code will have to be added anyway.
Whether to remove the inittab-related code or not, not sure. I don't think we should implement both right away, but if we leave some room for extending it to support other init systems, it should be fine I think.

Looks like this simple patch is ready for production. Backing idea - quagga has route-map to filter routes, going to be installed from ospf into kernel table, but we had no way to install it in vyos config. This patch creates 'router ospf route-map NAME' vyos configuration command, which maps into 'ip protocol ospf route-map NAME' quagga configuration mode command. The development was discussed under Q26.

@mickvav exactly, we looking to provide some support in that direction
@aopdal, I understand your concerns, but also don't find limiting users as something good,
@UnicronNL ported 1.2 to clearfog pro device, NFS server will be a good addition there for example,
we also talked about SIP functionality, all that Network Functions.
It does not about create multi-purpose distro, more like provide ability to build customized images

Well, I think that anyone, who really needs some specific feature set, nfs server, samba server, whatever, can make and maintain his own fork of vyos-build and it has (almost) no problem to build a speific iso himself.

Why would anybody want to use a router as a "small server"? General Linux distributions have everything you need for a small server.

Looks like it's closed mostly.

@EwaldvanGeffen
i will be happy to have ability add nfs/nettalk/cifs
for that type of home appliances, not sure how we should handle such deviations
I believe we should not be restrictive in this matter

I think its outside our scope. vyos is a network appliance. it provides services to transfer network traffic or services essential to transfer traffic (dns, dhcp). nfs does touch this aspect at all. Neighter would a radius service but that would enable pppoe-server or hostapd,... to move traffic. Nfs is not a requirement for any deamon to move traffic. ergo outside thhe scope.

In T49#768, @mickvav wrote:

In T49#766, @mickvav wrote:

I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need nfs client and I'll double check, whether it's enabled in my branch tomorrow...

In T49#766, @mickvav wrote:

I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need nfs client and I'll double check, whether it's enabled in my branch tomorrow...

I think Reukke will answer himself, but as for me - typical use-case is a small server, acting as all-in-one solution for small linux workgroup. E.g. a router, ldap-authentication server, common files storage and a web site ;). It would be hard to maintain and keep secure, but it's possible.
N.B. Persomally I need mfs client and I'll double check, whether it's enabled in my branch tomorrow...

Could you give an example of an use-case? Because I think this choice was very much by-design.

Where is the updated vyatta-quagga packages ?

It is normal. In the debian way of doing things, debian/control of the kernel package is produced by running "debian/rules debian/control" (sic!), as it's architecture-dependent.

If this will be included, someone has to make deep testing of quagga vrf-related patchset. Looks like it's described here: http://permalink.gmane.org/gmane.network.quagga.devel/11770 but I'm not sure, whether it's included in upstream quagga or not.