In T386#7593, @c-po wrote:

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.

In T17#5090, @audreez wrote:

can someone tell me how to properly apply this patch? thank you!

@UnicronNL @syncer Using the latest beta ISO I can happily report everything seems to install + boot just fine!

@UnicronNL applied changes in both 1.1.x and 1.2.x

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

News about this ?

Well I think porting this to vyos-1x package would be a good lesson to learn the new system. Let me have a look...

@UnicronNL please add this when you have time

I think that best way to implement it, will be use a "extends" in snmpd for BGP4-V2-MIB-JUNIPER and use a vtysh as backed.

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

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

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

As I say... I don't have the standing or the background to really question the approach. If you guys aren't really interested in commits that are perl-based, though, then I'm afraid I don't really have a lot to offer.

@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

In T379#7550, @dmbaturin wrote:

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

There are some bad practices that I think should be changed before we call it complete as well.

First, now that the Python configuration library and the templates convertor work, can we stop adding new Perl code? Those scripts are short at least.
There are some very good reasons to do that as well. For example, now that we are using systemd, why should we have start-stop-daemon? We should never had it right in Perl code to begin with.
Second, I'm strongly against mixing VyOS configuration code with applications it configures. Let's move that out of this, and if we are going to move the configuration code to vyos-1x package, it will come naturally. We can merge the bcast-relay and mDNS repeater into one package perhaps.

The features are appreciated, but let's add them in a fashion that will make VyOS easier to maintain, not harder.

just a thought - much of this is porting EdgeOS features, right? Those guys are still using perl, so any features they implement that VyOS wants is going to be perl by it's nature, surely?

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.

Yes, let me regain access to this task

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

Unless there is a specific advantage to changing the behavior of VyOS the existing behavior should be kept. What is the advantage of going having the linux shell be the default? Also, I like the idea of making it configurable.

This is fixed, too. Can we close it?

This is definately fixed. Can we close this one?

Now as @higebu done T373 we can build custom config for waagent that will do provision via cloud-init mechanism

Moved the repo to vyos org. https://github.com/vyos/vyos-integration-test

Moved the repo to vyos org. https://github.com/vyos/vyos-cloudinit

Kim, can you merge this into current
Thanks!

Daniil, can you kindly review and merge
Thanks

Hi Kim, can you merge this
Thanks!

Resolving this and moving to finished

Tried on → 999.201706052137

merged to lithium

@syncer can we close this task? see @higebu fix..

falso fixed in 1.1.8

changes cherry-picked to lithium branch

Cool.

I checked on 2017-09-04 and I am not able to put in IPv6 address into the OpenVPN interfaces.

Agreed. I just re-tried it as of 2017-09-05 and it now saves the OpenVPN configuration file in the /config/config.boot file.

Found out that it already is implemented.

As workaround I used Beta/development build and get it working in my lab with dnsmasq(2.72) from

@syncer: Thinking about it I have a different proposal:

There is another problem. BGP4-MIB doen't cover IPv6 peers, the clue is implement a new MIB like https://iphostmonitor.com/mib/BGP4-V2-MIB-JUNIPER.html like Juniper did

Is it possible to do an strace of the snmp process?

I have access to to these routers, is VyOS like below will be ok?
vyos@vyos:~$ show version
Version: VyOS 1.1.7
Description: VyOS 1.1.7 (helium)

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.

I'm also really intereseted to make it working, is there any chance to help?

no problem:

config will be good to see

I'm all about compatibility with existing behaviour. Looking back over just about every network device I've ever operated, and the bits that annoy me the most is when behaviour is changed in a surprising fashion. I know there's a tension with the ability to actually continue to improve the product, but where there's a choice between 'make it unsurprising', or 'make it cooler', from a user perspective, you want the developers to have exhausted every option to do bother before making it surprising.

OK. Minor tweaks - actually wired 'show vpn ipsec sa' to use the pretty-print code, rather than just calling swanctl to get half a page of ugliness.

Ok, sorry about that.

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

@UnicronNL https://github.com/vyos/vyos-build/pull/11

@c-po https://github.com/vyos/vyos-cfg-avahi.git is created, and ci integration is also done.

Yeah, C-po. That doesn't surprise me.

Just added Finished Board for 1.2.x project
we likely will keep all there before include it in some milestone release

@syncer @dmbaturin Pull request ready: https://github.com/vyos/vyos-build/pull/10

@syncer @dmbaturin Please pull https://github.com/vyos/vyatta-cfg-system/pull/60 and https://github.com/vyos/vyos-build/pull/9

Tag VyOS 1.2.x should be removed as CVE is already fixed.