Done for all practical purposes. Everything else will deserve its own task.

It's done for OpenVPN. We can later add IPsec as a sub-task.

It will have to be refactored for the new vyos-1x approach, but then the entire package will, so we'll better have the .ac support now, and refactor later.

1. A nicer version of os.system('iw reg get')

This makes me think we should make a shared nicer version that returns a tuple of exit code and combined stdout/stderr and put it somewhere in a utility module.

@tic226 If we continue the chemical theme, since 1.1.x is helium, 1.2.x will be lithium, and 1.3.x will be beryllium.

The downloads.vyos.io is now using mandatory HTTPS. On the dev.packages.vyos.net, HTTPS is optional. To declare this closed, we need someone to independently verify that ISO build works with HTTPS for them.

Hey everyone,

I'll check, meanwhile, could you verify that you still see this issue in the latest build?

@begetan Does creating it with one interface first work for you?
Also, I still need the show version output from the running instance (complete with S/N and UUID) to see if it's the same issue or a different one.

@begetan It is the same build that the marketplace team at AWS distributes to all regions. I've just made an instance in Frankfurt and it worked for me.

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

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

It works for me. We need more details of your setup and your config to tell anything.

The lldpd package had really insufficient dependencies, it didn't even list libssl. This is why it wasn't rebuilt, we used apt-cache rdepend to find the packages that depend on libssl0.9.8, and due to missing dependencies this one didn't show up.

I could reproduce the bug. This doesn't appear to be an easy fix though.

Well, it *is* a stupid SEO thing. This person created two seemingly valid (even if irrelevant) tasks that include a link to some website unrelated to the task content. I think we should block @jensenbreck right away.

I've done pkg-release in that package to include the latest commits into debian changelog and update the package version (helium4 now).

The issue was with variable scoping, the variable for server subnet that was supposed to be global was instead updated in the local scope.

@UnicronNL Just to make sure, the package included in helium now is also patched?

@c-po I agree. By now I have a way better prototype of that thing than the original. I'll make a task about it.

If you want multiple interfaces with the same properties as the loopback, use dummy interfaces.

@S3m1r6 Could you test this image? http://dev.packages.vyos.net/iso/testing/vyos-1.1.8-rc2-amd64.iso I tested loading a config similar to yours (with ingress/egress QoS values added to make sure they get processed) and it works for me.

Not resolved yet. ;)

An AMI updated by hand was submitted to Amazon for testing.

Thanks, I'm looking at it now.

The only remotely sensible use case I can see is active/standby bonding of L2 VPNs to provide redundant paths. But then again, the real answer to this is distributed switches such as openvswitch.

BGP configuration is definitely loaded after VTI configuration is loaded.

Fixed in both 1.1.8 and current.

Well spotted! Fixed the typos.

Should we add it to 1.1.8? It's a pretty big change, I'm not sure if it should be in a maintenance rather than a major release.

The commit is indeed in helium now.

Imported it to 1.1.8: https://github.com/vyos/vyatta-cfg-quagga/commit/973afef2f599538ccda19a2befcf16e6730eaad2

That commit was in helium as well, but the real issue was in the debian install file: those paths were missing from it, so templates were generated but not included in the package.

Imported into 1.1.8

@UnicronNL The debian repo for helium is here: http://dev.packages.vyos.net/legacy/repos/debian/helium/

Fixed 1, 2, and 3.

Yes, @Tania and I are working on the rewrite.

Create a new repo (dev.packages.vyos.net/debian) and moved hvinfo to there.

https://github.com/vyos/vyos-1x/commit/ecdbe7b6fb64ae7d27d9147aa2c4a55b3a491735
https://github.com/vyos/vyos-1x/commit/5404d4108b510765150c2ac54098cd26ec18a683

The current implementation with postfix aliases is/was a bit problematic because all spam sent to it is forwarded to all members, and the mail servers where member addresses are get upset with mine and report me to spam lists.

I've merged the quagga pull request. Do you have implementation of the CLI for it, or shall I add it?

@c-po The post I made yesterday (http://blog.vyos.net/vyos-development-digest-number-10), the vyos-1x package is pretty much that, the future single package for all config scripts and data. I would be reluctant to put things that are not VyOS-specific into it though. With small things such as the mDNS repeater things get shaky of course. Something like PMACCT is a clear case, merging it into another package would be insanity. Those relays are small enough to make one wonder if they really need their own packages.

@JulesT I'm afraid Perl code is going to be around for quite a while, as many things need to be fixed before any rewrite of them can take place.
It's the code for new features that concerns me, not as much in the language as in the old approach that is not conductive to either automated testing or future implementation of transactional commit.

@JulesT 99% of new EdgeOS code is proprietary. I see no reason to stick with it for the tiny open source bits they may release once in a while. EdgeOS could use their departure from Vyatta Core as a chance to rethink those decisions, but apparently due to time pressure they didn't... Now they are stuck with backporting UnionFS forever and never getting e.g. fully transactional commits or

And now that I've actually looked into it... ;)

I think before we call it finished, we should move those repos under vyos organization and give @c-po access to them (frankly, I also propose to add him to maintainers).

We should, but somehow I don't have write access to this task. We should find a way to change the default permissions so that all maintainers can do that.

@sebastianm In VyConf it's going to be fairly easy (ok, possible at least) to implement different input and output formats, so chances are we can add | display json or | display yaml filters if there's demand for it.