Worked, thanks
https://wiki.vyos.net/wiki/User_Guide#mDNS_Repeater

After removal of telnet configuration nodes/scripts and upgrading from VyOS 1.1.8 with telnet enabled worked.

Installing VyOS 1.1.8 on RAID1 and later on upgrading to 1.2.x works. Also the RAID set is intact.

vyos@vyos:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      4190144 blocks [2/2] [UU]

Still the same

I wanted to add the following into the WiKi

TODO: Add CI job for https://github.com/vyos/mdns-repeater when CI is back online

Using AVAHI as mDNS reflector has the big disadvantage that the reflection interface can not be specified. It will reflect the mDNS messages on ALL interfaces. Mdns-reflector does not have this problem. It needs to be configured which interface is used for repetition. Configuration is planned for vyos-1x package.

Each time a new image is added via add system image GRUB configuration is triggered.

@syncer what do you mean by "other installs"?

Backporting coreutils could give us quiet some headache ... let's just schedule this for VyOS 1.3 where it will be auto fixed.

Implemented as 10 second timeout in https://github.com/vyos/vyos-build/pull/14

@alainlamar I tried and tried but I never made it to properly build an image that has everything inside. This is a task for 1.3.x then, which is based on Debian 9! If this is setup it should be a piece of cake.

Fixed in

@carl.byington I added a branch on my Github fork: https://github.com/c-po/vyos-build/commit/65f1b3d77d2ac1022004dcc6095db5683e0ff917 this has all the submodules you mentioned.

@carl.byington Thanks for this blogpost. Do you mind in supplying a build-all bash script we can have insied the vyos-build repository?

@carl.byington thank you for the investigation. I'll check if it produces a reasonable ISO and will perform a pull request.

Can you please do a ls -al /run and check for charon.ctl?

Can you please try the following, setup your IPSEC connection w/o log-modes and check that after commit your connection is online. In a second step try set vpn ipsec logging log-modes mgr .

CurrentlyI'm running VyOS 999.201711072137 but upgrading to 999.201711232137 still works.

I can't reproduce this.

Thank you @carl.byington, Pull Request generate for @UnicronNL or @dmbaturin https://github.com/vyos/vyatta-op/pull/13

@afics is this implementation as expected? If so, this feature request is completed @syncer.

@alainlamar Unfortunately I have some problems with APT building my ISO but I added the steps for you here: https://wiki.vyos.net/wiki/Rebuild_VyOS_kernel_Step#VyOS_1.2.x

@alainlamar would you be willing to test a special image with all your required changes inside (Kernel, hostapd, firmware-atheros)? Only extension of vyatta-wireless is missing, but looks you could do this "on the fly"?

I can confirm that by using this approach we can have hostapd 2.4 from debian stretch

Closed b/c I wanted to rewrite it using vyos-1x command package.

Thanks for this feature request. I'm not to happy having a cloud provider install some SSH keys onto my system. If you have to manage many VyOS machines, why not use Ansible?

Possibly http://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html#apt-pinning will do the trick. I will start a test build...

@alainlamar thank you very much for providing such detailed information e.g. what is required inside the kernel configuration. This seems to be not a big deal to enable those.

@afics @syncer done, will be in the next nightly build

This did the trick. Just build a fresh ISO:

@UnicronNL maybe this will fix this issue:

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.

@syncer https://github.com/vyos/vyatta-cfg/pull/9

Using a self build ISO: VyOS 999.201710291829 I can confirm this.

implemented 11/2016, merged 04/2017
https://github.com/vyos/vyatta-cfg-system/commit/4a03838ea877a3a867b283ba85956795e769d563

This regression is fixed. @syncer should we resolve it?

False positive as a previous command was failing.

Isn't it the scenario for which all those people in debian have used package manager for decades? Isn't it better to just update one package in installed system?

Fixed in https://github.com/vyos/vyatta-cfg-system/pull/65

Removed in https://github.com/vyos/vyatta-cfg-system/pull/65

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?

@syncer @dmbaturin https://github.com/vyos/vyatta-op/pull/12

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.

@TomekC @syncer just wondering ... should we maybe add those commands to VyOS CLI?

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.

@syncer this was actually done by @JulesT. Thank you @JulesT.

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.

@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