This action installs the following cronjob:
sudo sh -c 'echo "#!/bin/sh" > /etc/cron.weekly/01vyos-popcon' sudo sh -c 'echo "/opt/vyatta/bin/vyos-popcon.pl 2>&1 >/var/log/popcon.log" >> /etc/cron.weekly/01vyos-popcon' sudo sh -c 'chmod +x /etc/cron.weekly/01vyos-popcon'
@dmbaturin @UnicronNL what‘s your opinion?
Do we know why it‘s not possible? Is it due to a missing configuration option in VyOS or is it due to non availability in the underlying Linux Components e.g. Strongswan?
On VyOS 1.1.7 we have /etc/radiusclient-ng/dictionary.merit which moved to /usr/share/freeradius/dictionary.merit on VyOS 1.2.x.
Thank you for the effort. I always liked the VMWare template installation. I also tried it for VyOS 1.2.x on ESXi 6.5. I followed the WiKi instructions which worked like a charm!
Vote for 1.2.x only.
BusyBox is a multi-call binary. A multi-call binary is an executable program that performs the same job as more than one utility program. That means there is just a single BusyBox binary, but that single binary acts like a large number of utilities. This allows BusyBox to be smaller since all the built-in utility programs (we call them applets) can share code for many common operations.
+1 for removal
As VyOS fully re-uses Debian packages it is not possible to enable any given applet inside Busybox. To get this enabled, VyOS has to maintain a forked version of the Debian busybox packages which makes life only harder.
cpo@AC1:~$ cat /boot/grub/grub.cfg | grep timeout set timeout=5
@syncer @dmbaturin @UnicronNL is there any reason to not implement this? I think this should be doable in less then two hours.
@kingrvbee this is not entirely correct. The problem comes from package vyos-1x which now holds the lldp configuration nodes. @dmbaturin is aware of this and wanted to fix it. Please be patient.
Please also see T393
@mickvav Interesting Idea, I should give it a try ...
@Asteroza this program forwards UDP packets (Layer 3) on specific ports. Unfortunately WoL is Layer 2 based.
I can verify that it now also boots on OVH.net VPS.
@babak that would be awesome as I do not have any IPv6 BGP connectivity. I created a temporary SSH key for this, could you please create a user cpo:
I guess that you are referring to the installation of VyOS, as a proper installed system will automatically boot up. At least last nights build does.
Maybe this is the reason why we also can't boot a VyOS instance on VPSs rentet from OVH.net
Well I think porting this to vyos-1x package would be a good lesson to learn the new system. Let me have a look...
@dmbaturin You have some good points. Using "service" to start/stop a daemon should be the weapon of choice now. This could/should be changed to have a consitent system, but this inital commit is just a 1:1 EdgeOS copy.
@syncer: Thinking about it I have a different proposal:
I think as not everybody has access to an IPv6 BGP router, a ro SNMP community for testing would be good. Even better would be a virtual instance to develop a fix for this problem.
Looks to me that you are mixing up two things. 6rd (Radpid Deployment) is used for ISPs to connect the customers to the IPv6 world (https://en.wikipedia.org/wiki/IPv6_rapid_deployment).
@syncer @dmbaturin Pull request ready: https://github.com/vyos/vyos-build/pull/10
Tag VyOS 1.2.x should be removed as CVE is already fixed.
Verified using iOS 10.3.3 accross VLANs. mDNS services like Airplay working.
@UnicronNL could you please mirror https://github.com/c-po/vyos-bcast-relay.git to https://github.com/vyos/vyos-bcast-relay.git and set up a CI job? After this I can submit the appropriate merge requests for vyos-world abd vyos-build.
@UnicronNL could you please mirror https://github.com/c-po/vyos-cfg-avahi.git to https://github.com/vyos/vyos-cfg-avahi.git and set up a CI job? After this I can submit the appropriate merge requests for vyos-world abd vyos-build.
Status can be seen here: https://github.com/c-po/vyos-cfg-avahi
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.
@syncer This one is fixed/merged and already working in the nightly builds.
Just to give some more information.
strip-private is a bash-pipe function (/etc/bash_completion.d/vyatta-op).
Good objection. This should be avoided!
VyOS 1.1.7 also has two interfaces (vti0 and ip_vti0)
Using VyOS 999.201708292137 I'm able to reproduce this.
@syncer could this change be approved or is anything else missing?
I double checked with VyOS 1.1.7 where I can not reproduce the error. Is version 1.1.7 correct in this BUG report?
@ethomas could you please provide a full configuration for my tests? The only thing I see is:
I'll start an investigation after T345.
Ok
During restructuring my IPsec HUB/SPOKES I would have liked this possibility, too.
@babak do you happen to know if this is workong on EdgeOS devices? Then I could extract their implementation.
@syncer, I integrated your referenced splash.png
This is how it would look like:
Removed and sent pull request:
https://github.com/vyos/vyatta-cfg-system/pull/59
https://github.com/vyos/vyatta-op/pull/10
Fixed in Kernel 4.4.26. VyOS 1.2.x (development) uses 4.4.47.
I just have verified that " LLDP-MED fast start mechanism: yes" is the default after my mentioned commit.
@syncer As this is an option to lldpcli I suggest fixing the above (1) and create a new command (2) for LLDP-MED enable/disable and interval. My current knowledge ov VyOS build/configure currently only allows me to fix (1).
I can remove -L so it's working again. Should I?
Please see: https://github.com/vyos/vyatta-wireless/pull/6 this should fix the wrong path issue!
@gaztel I modified the pm script responsible for the configuration and verified it with iOS 10.3.3 as I do not have a Mac. Windows 10 is now also able to connect.
https://github.com/c-po/vyatta-ravpn/commit/20b85ddf4777ced900da2a56c25922c190823dd5
I can confirm this. Above mentioned lines not present in my custom build (Version: VyOS 999.201708011131).