@c-po thanks a lot, I was thinking first I have to add it to the rules and do it via configure, the control file is way easier of course. I'm off next week and try to enjoy summer before the rain comes, but try to get the first stages going.

@dmbaturin When I rebuild the iso, I'm currently using the ./configure switch you recently introduced to get the wireguard packages added. How am I supposed to to it for the pull request then? Where would I have to define the modules to load?

Thx guys, learned something new. will implement it that way.

Should I place the key-pair generation under 'system wireguard' or 'system options wireguard'?

@dmbaturin thx for the input, I have added the route setup to the wireguard.py script, because if the interface gets delete from the config, the wg device gets deleted from the OS and all its routes. The config would still have then the routes in the effective config and when you reboot it tries to setup routes on a non existing interface.
The examples on the wireguard website, do it similar, after the tunnel is up, they add the routes. I also couldn't find anything in their code which adds automatically the routes for allowed-ips.

pre-build pkgs:
https://github.com/hagbard-01/wireguard-pkgs

Hi Guys,

@Asteroza I can understand why. I never knew about it till I got the task here, digging into the documentation for a few days, I was quite impressed and thought, well let's test it first. It's an awesome way of implementing tunnels.

@syncer I think by the end of this week I should have it fully working. Didn't have much time during the weekend to do anything since I was on-call. I read their paper they published, the technology is actually pretty cool.

In case anyone wants to follow the progress: https://github.com/hagbard-01/vyos-1x/tree/wireguard

Arghh, I had the rolling build from July 30th. Sorry for the noise, all working now.
Oh and you guys are really awesome.

2312 open("/sys/module/wireguard/initstate", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2312 stat("/sys/module/wireguard", 0x7ffeb8212c70) = -1 ENOENT (No such file or directory) <-----
2312 open("/lib/modules/4.14.26-amd64-vyos/extra/wireguard.ko", O_RDONLY|O_CLOEXEC) = 3
2312 fstat(3, {st_mode=S_IFREG|0644, st_size=342768, ...}) = 0
2312 mmap(NULL, 342768, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0f94c3a000
2312 finit_module(3, "", 0) = -1 EINVAL (Invalid argument)
2312 write(2, "modprobe: ERROR: could not inser"..., 64) = 64

@UnicronNL module can't be loaded via modpprobe I get.

@syncer It doesn't really matter to me, I was just concerned that if you have pppoe-server running, you can't use gre tunnels (the kernel module can't be loaded anymore).

@dmbaturin No worries, I'm well aware of the new scheme. (will be a fresh and new implementation of the syntax).

@UnicronNL thx a lot for the packages, speeds my task up quite a bit.

@syncer I discovered a possible issue, accel-ppp is incompatible with the ip_gre driver, so using accel-ppp means you can't have gre tunnels anymore and vice versa. I'm not sure if accel-ppp is a good idea to integrate into vyos. Shall I continue with the packages or should we check if we can find anything compatible which doesn't interfere with router stuff. Not having gre is in my opinion a very significant issue.

It will come in 2 parts, the ppp server as a package first and then the rewrite for its config, hard to estimate the time it will need, let me first package accel-ppp.

Can please someone assign it to me, I was/am working on that one and opened a subtask since I can't assign this one here tom myself.

pending merge

pending merge

Problem happens in ln 27 in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireless/node.def, $VAR seems to be empty.

merged by Daniil. Please assign bugs to me, if any come up. I tested everything multiple times carefully, but you never know, so I take full responsibility :0.

Wouldn't it be easier by just excluding 127.0.0.0/8 and ::/1?
I haven't checked, but how is it handled with IPv6 anyway? Like the link local adresses.
I see if I can find out, why it takes a reboot for the host_name.py script to function properly, I found in my tests yesterday it is always executed. hostnamectl sets /etc/hostname to "hostname.domain", shouldn't be done that way anyway.
It seems to be the culprit, but more testing is required, I won't have much time today.

cat /etc/hosts
127.0.0.1 localhost debian <----
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

... and that is why you don't like systemd. hostnamectl is bailing out, why? No idea yet.
libnss-myhostname may fix that already, it modifies nsswitch.conf and myhostname is always being resolved regardless if its in /etc/hosts or not.
I'm still looking why it is not setting the hostname, but does when you reboot. The config is executed, I checked that.

additionally in /etc/hosts each change adds the localhost line instead of replacing it.

@syncer , @c-po
I can also check from the python script if /etc/rsyslog.d/vyatta-log.conf exists and if it does I remove it, since it's generated anyway.
That file is basically the last item (well and the user implementation) I have to work on.

Hi Guys, @dmbaturin

Syslog rewrite is now almost done, I currently testing everything, so I think if all goes well, I open a pull request next week for it. I'm still not sure how I should handle 'set system syslog user...', the help text states that it logs to the logged in user, but I didn't find anything implemented in the old perl script.

I never had a look into that, however I found something interesting.
https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-get-partition, check out save_old_keys() at line 433.
The script you are looking into is, when vyos is already installed.

Now I found out the mystery from logrotate, vyatta put the logrotate files into persistent storage since they are triggered by rsyslog itself. I have them currently moved to /etc/logroate.d since they are configured with a size. But this might be prone to a race condition. @c-po I think we need some kind of persistent storage for vyos as well if we want to decom /opt/vyatta at one point. Would be also good for T741.
I'm going to be busy with testing and work this week and I know you are busy as well, so no rush on an answer.

If anyone wants to view the progress, here is the link to the devel version.
https://github.com/hagbard-01/vyos-1x/blob/devel/src/conf_mode/syslog.py

status set to resolved. git repo needs to be merged.

I would start to look into /opt/vyatta/sbin/install-image*, those are the 'install image' scripts, you can see the mounts there since the OS part is a squashfs mount.

Yup, that's what I think too.

@syncer, @c-po /opt/vyatta/etc/logrotate/global is generated as well (logrotate for syslog files), where should I place the new one just under /etc/logrotate.d? It's going to be generated via the cli config, so an image update wouldn't do anything bad.
Also, I'm going to created different config files, rather than 1 global one. That way, we could later drop in database logging support and the such. As far as I have seen, you can currently only log to a remote host.

Sounds good, I experimented already with it. I can drop in certain functions into the same nodes. So the existing ones will still work. However the implementation of it will take a few weeks, primarily testing will be crucial.
The other option which I think might be a good one, is to implement everything which does currently exist and shift the new functions in for each update. That way rollbacks should be way easier and the overview might be better too.
I really like the functions I read about and played with them already in VMs, you can actually download a file and kill 1 firewall which doesn't affect your connection. So, multiple sync interfaces should be the way to go anyway.
I gotta think about it a bit more, op-mode is way easier :).

I implemented the hack I proposed, in my tests it did work quite well. Let me know if there are still issues.

to give you an idea what I have in mind:

Oh there is more stuff, like the different modes and IPv6 which I think need to be implemented as well. My concern is if I change the nodes and all that stuff for the cli, it requires migration scripts, otherwise it will break configs from people who update.
How do you usually deal with that stuff?

Making progress. There is a ton of options not implemented (e.g. multicast with more than 1 interface for HA etc.), if I implement it now I suppose I will need to write migration scripts?
According to https://manpages.debian.org/testing/conntrackd/conntrackd.conf.5.en.html, there are really nice features which I think become very handy once implemented, but I would also have to change the cli interface, probably putting sections in.
e.g.
set multicast default interface ...
set multicast ha1 interface ...
set multicast ha2 interface ...

vyatta deployed their own and modified dhcpd, their modification is to set the shared-networkname in the lease file (https://github.com/vyos/vyatta-dhcp3/blob/lithium/server/db.c#L135), which is parsed by get_active() (/opt/vyatta/share/perl5/Vyatta/DHCPServerOpMode.pm).
It's possible to set variables on a lease event (more events like release are possible as well, or executing scripts on a lease etc.). However, since there are multiple new features available, I think the best is to rewrite the dhcp-server (ipv4) stuff first.

Due to the newer dhcp-server package in jessie, the entries in dhcp.leases have changed and shared-network is not exposed in there, that is where the vyatta parser module fails ( /opt/vyatta/share/perl5/Vyatta/DHCPServerOpMode.pm ) in function get_active().

I can replicate it, looking into it.

All right. op-mode should be ready to go, but I haven't request a pull yet. I'm going to do still some tests and then moving onto cfg-mode.

I'm gonna close 721 since self-assign does now work. I track via the original T696.

Hi Guys,

Please have a look, I changed some logic compared to the original perl script. I read the real set values, while many are set in the perl script itself. The interface definition and everything else is still pending. My ideas was to have the op stuff implemented first and put in place, since the cfg stuff is separate anyway.
Just copy the script into the vyos home directory and call it from there before it makes its way into the vyos-1x package.
I would really appreciate if anyone with a life config could test it, I just configured 2 VMs and test it.

@Line2 I tested a RHEL7 (currently at work) and a debian 9. I can only imagine that their either used the patch you mentioned, or do it a similar way like observium does it with their perl script. it looks like the patch never made it into upstream in net-snmp, I haven't checked the source yet.

The only thing I can think about is, to read ifAlias from /sys and insert it into the snmp table. @c-po what do you think about this?

Did you do that on vyos? I tried and it doesn't work. That alias is usually set under /sys/class/net/<device>/ifalias, but the ip command didn't do it, nor was I successful setting it manually.

I see, yes .1.3.6.1.2.1.31.1.1.1.18 is empty and would have to be updated/set when the interface description is set. I believe it is not set in any Linux distribution, I also checked RHEL and the such, they leave it all empty. So, I would think it's a feature request than, rather than a bug, isn't it?

possibly affected:
./interfaces/bonding/node.tag/pppoe/node.tag/user-id
./interfaces/bonding/node.tag/vif/node.tag/pppoe/node.tag/user-id
./interfaces/ethernet/node.tag/pppoe/node.tag/user-id
./interfaces/ethernet/node.tag/vif/node.tag/pppoe/node.tag/user-id
./interfaces/openvpn/node.tag/authentication/username
./service/pppoe-server/authentication/local-users/username
./service/snmp/v3/trap-target/node.tag/user
./service/snmp/v3/user
./service/ssh/access-control/allow/user
./service/ssh/access-control/deny/user
./service/webproxy/authentication/ldap/username-attribute
./service/webproxy/url-filtering/squidguard/source-group/node.tag/user
./system/login/user
./system/package/repository/node.tag/username
./system/syslog/user
./vpn/l2tp/remote-access/authentication/local-users/username
./vpn/pptp/remote-access/authentication/local-users/username

does only affect username in pptp and l2tp.

Validated OID 1.3.6.1.2.1.2.2.1.2 (ifDescr), I think the task here can be closed as invalid request.

Are you sure?

in vyos-1x:

yes, still an issue in the latest rolling. (VyOS 1.2.0-rolling+201806251824)

Other vendors put in restrictions for that (cisco for instance allows only alpha numerical characters), that could be done in the xml with a regex to prevent the issue you have raised. I only had a look into the snmp configuration for now, but I expect that on many other places too.
Any objections about restricting the input?

Sorry, I'm still not able to reproduce your issue. I used the same config you posted, just changed the IPs and used 19,20 and the rolling from today, everything looks just good.
When you have the issue what is the output of ' sh interfaces detail | match br'.