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'.

Thanks for your comment. I read the wiki page already, but wasn't sure how to proceed. How do I assign myself to a task? I didn't find an option in phabricator to do it. I think I don't have permissions for it unless I created the task, I suppose.
I did dive through the majority of the existing code and am about to do some cleanups and therefore rewriting major parts. As far as I understand, that's the long term plan anyway until 2.0 can be released.
Let me know if it doesn't make sens to do surgery on the open heart, since it's going to be remove at one point anyway. Otherwise, I would check and see how I can become most useful to the entire project in general.

@mb300sd Can you please share your config for the bridged interfaces?
I did a few tests and can't find any issues.

I looked into ti, the xml is fairly easy, the perl code pretty nasty, it also refers (hardcoded) to sysV initd.
In my opinion it's almost impossible to convert the perl code into python without getting eye cancer, I think the python code needs to be written from scratch (will be invisible to the enduser on the cli, options will be the same)
Let me know if you need more details, I'm more than happy to discuss my finding.
The complete rewrite won't too long either, but hard to estimate due to the fact that the original code used libs and has different scripts for config and op commands.

I'm looking into it. (not sure how I could assign the task to myself?)

Thanks Christian, that helps a lot. I was assuming I only need to generate configs if I really write config data int oa local file, so I have something to compare.
Thanks again, still need to play with it a little, but I think I understand now the parts of it.

Sorry I got stuck a little.
I have the interface definition written, using the new recommended style. However, create/delete and the such need to be handled in a script.

Interface definition is the last piece which needs to be done, should happen this week.

I'll take it on.