i mean, if that works silently but after install fails to boot from SW RAID
assuming that part of raid installs affected

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

i think we also need mechanism to fix other installs once we sort out this problem

Here it is

Rebooting the router fixed it...

I appreciate your work! Could you make the patch easier for us to merge and then to track for release and changelog?
Here's the proper procedure for making patches: https://wiki.vyos.net/wiki/Submit_a_patch

At a glance, a lot more looks wrong here than just this. Why is it checking for every rule in the rule set if the rule set is uniquely named?

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

We are hit by bugs in the OSPF of Quagga which are not fixed in newer versions, but are fixed in FRR. Most of my stuff is working. Getting up to date on Quagga is probably also quite some job, and from the testing perspective it's just the same. Everything must be tested... From the design and documentation perspective we need to put down some more work if we are using FRR.

The current Quagga included is rather old, so if it is possible to migrate to FRR that would make a big difference.
I am testing my configs in the alpha release and so far it looks good. To assist i can test setups and configs.

@dmbaturin is there a (estimated/proposed) releasedate on 1.2.0?

@aopdal I suppose 1.2.0 will stick with quagga, though if we are able to weed out all issues with FRR in reasonable timeframe, perhaps we can attempt migration to FRR in 1.2.0 rather than a release after it.

Using two debian VM i have played around with this today.
I have been using debian 9.2 and keepalived v1.3.2

Ah, I missed the -t raw. I thought maybe the ULOG target needs uacctd running first on netlink group 2, so I started it:

Are we going for FRR in 1.2, or are we going to keep Quagga?
I'm just wondering what I should test ;-)

I suppose I should also mention that I am also using a proxy PAC file hosted on the internal lighttpd instance as well over HTTP (again, can't use HTTPS due to certificate trust issues for unknown client PC's) which is important due to DHCP server URL designation of a PAC/WPAD file currently.

Web proxies are relatively complex by nature and offer an attractive attack surface. I don't like having such software on routers at all, even if they are properly maintained. Better to relegate this functionality to a system which is external to the router.

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

But if you run:

No, ULOG is there:

duplicate of T296, this one can be deleted.

I was not able to create a patch for vyos-build since I am missing something in my understanding of submodules. There should be some way to generate a git patch that adds submodules. But this works:

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

that's exactly how i tested before. All other vpn config was done before and is running fine (commit and saved). As soon as i change (set or delete) something at 'vpn ipsec logging log-level' oder vpn ipsec logging log-modes' I get this message:

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 .

yes that's the version I tested on

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

thanks @c-po.
I don't know what other information could be relevant. It's an instance on AWS. Nothing special before. The log-modes are set after the error messages. I can say that. Look at this here:

I can't reproduce this.

With limited people in the project I think the "core" features for a router should be of priority. A lot of things is nice to have, but we need to have a good router.
IPv6 with VRRP, connection tracking, updated routing engine, IPv6 PD is stuff we need and requires a lot of design, implementation, testing and documentation.

This is a drawing of my current lab environment.

Any updates to this?

@Asteroza thanks for feedback!

I do use squid in production, but without the hardcoded blacklists, rather my own local list only, and as an explicit proxy with a rejection message locally hosted as HTTP on the inbuilt lighttpd instance (can't serve HTTPS rejections because of certificate trust issues).

Thanks @Line2 !

hey @c-po
can you check this one.

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

The nightly builds started working again on the 16th, so this task should be moved to 'finished'.

I have a script that builds all (well, almost all) the vyos packages from source, including the kernel, and then builds an iso with those rebuilt packages.

@c-po Thanks for sharing your Kernel build steps. My question however was about building a custom Kernel _into_ a new ISO, so includung a successful run of "make iso".

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

patch attached{F27881}

cloud init will be available in 1.2 and up
not included in 1.1.8

Started testing in 1.1.8. It doesn't show as a command.

@higebu here is latest ovf that i used for official ova -

@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

@c-po Yes, I happily would!
BTW: How did you manage to build 1.2.x with a custom Kernel? I continuously fail on the attempt when the build process tries to build the initrd for the custom Kernel. Would you mind to share your build steps?

Thanks Brandon for your findings. IPSec with dynamic peer is no problem in VyOS. We use some of that with x.509 auth. Only VTI with dynamic peer is not allowed by VyOS. Do you know more about VTI and dynamic peer with strongswan on other linux installations (not VyOS)? Is it possible there?

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

me neither
@dmbaturin can you move it to finished?

@syncer This tasked can be moved to finished, i do not have the rights.

What to so with this task, requests were closed.