Seems to be fine now.

Tested and appears to work.

Yes, since we let quagga manage static routes (and for a good reason — the kernel does not even try to restore routes if the interface they use flaps), we can only do what quagga allow now, or add something to quagga.

Already in use by now.

ALready packaged and actively used.

The AMI builds and boots now.

Implemented in https://github.com/c-po/vyos-1x/commit/b871546cdde982c65e243ec57610edecddb4701b

Even after changing the configuration to

snmp {
    listen-address 172.16.37.241 {
    }
    v3 {
        engineid 0xff42
        user test {
            auth {
                encrypted-key 0x63119b4e19ce4d69c7ad678ffe110047
                type sha
            }
            engineid 0xff42
            mode rw
            privacy {
                encrypted-key 0x63119b4e19ce4d69c7ad678ffe110047
                type aes
            }
        }
    }
}

@aibanez @csalcedo will be great to hear your input here

@aopdal I agree VRRPv3 supports both IPv4 and IPv6 at the protocols level, but keepalived wants groups to use either IPv4 or IPv6 addresses, but not both at the same time, so you need different groups for them in the config.

Commands will be:

Yes, that is correct option

@syncer this seems to be the option, plese correct if wrong.

I wasn't sure if we were maintaining our own package or not. If we're pulling updates from Debian security updates directly, then I see no problem. The researcher is still collecting and analyzing the fuzzer run so no published reports as of yet.

are there any new possibilities with the new kernel 4.14 and strongswan 5.6.2 in V1.2.0-rolling for this case here?

Works and already in use.

@syncer Sort of. Root doesn't get the full vyos environment so using vyos commands is inconvenient, though not impossible.

@Asteroza Our tcpdump comes straight from Debian, so the update should be picked automatically when they update theirs.

Seems to work.

Appears to work as expected now.

As promised on #vyos here is an description about how to implement DHCPv6-PD on OpenBSD v6.3 amd64 with XS4ALL as ISP. I am willing to test changes done in VyOS to make this work. Also I am willing to answer questions about my setup. As this is a private project, testing and answering will be primarily done at weekends. I have at my home a FTTH connection from XS4ALL. The purpose of the here described process is to tell XS4ALL that my network is willing to process IPv6 packets so that IPv6 can enable a route to my IPv6 subnet in their routing table. XS4ALL tells me my IPv6 subnet and prefix at their website. This information is needed during this process. XS4ALL has given me an plain Modulater-Demodulater (MoDem) also called a media converter. This modem converts the fiber to ethernet and nothing more. Here is the process on OpenBSD v6.3 to setup an IPv4 and IPv6 enabled connection with XS4ALL.

fixed by @higebu in VyOS 1.2.0-rolling+201805171657

fair warning, there's a security research currently fuzzing tcpdump who has been finding some stack overflow bugs so expect a package update or two in the not so far future...

Seems to be working now.

root when enabled, can use vyos configuration/op commands?

... reverting ...

@higebu and @UnicronNL agreed to the change, so I'm going to proceed with it.

I'm pretty sure there is a commit error when you try to use that no longer existing option. It only works because we (sadly) allow partial commits and our commits at this time are not real, transactional commits.

@c-po I think the spirit of it is to keep programs that are not useful for end users separate from programs that are, out of their $PATH, which would only pollute the completion and enable accidental execution of programs that may have strange effect when used in an unintended way outside of their normal workflow.

I think it's a bad idea in case of automation scripts, which rely on general linux root shell - e.g. don't need sudo to get root access. So, anyone with this kind of integrations will need to adjust their software, if it would be not possible to make VyOS act like ordinary linux and accept (without pain) things like

ssh root@vyos arping -I eth0 12.34.56.78

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html states:

Maybe I got something wrong but my Test indicated by upgrading from VyOS 1.1.7 to 1.2.x worked. the service ssh allow-root config line just vanished and remote login worked like a charm. I always tried to be backwards compatible at least with VyOS 1.1.7.

Turns out updating the hosts entry is more important than I thought: if it's missing, sudo constantly complains that it cannot resolve the hostname. While it appears to have no ill effect, it's still quite a nuisance.

This task is decidedly *not* complete until we have a migration script for it.

Proposal for command:

Merged as discussed via slack

Should be working now.

They are now vyos.version.get_version*

It's a general problem with the new Python scripts. Somehow the lib is injured :/ @dmbaturin

Hello @rodge.liu what exactly do you mean by invalid? Does it have no result? I'm currently re-writing this section to the new XML style interface so there could me a slip. A new ISO image is born at this very moment so please retry with the latest version in about 30 minutes.

I just tested the latest vyos-1x package commit 860b229.

I think option 2 is the best, but keep in mind the VRRP version is 3, and it support both IPv4 and IPv6.

Sorry it took me so long to react to!

Looks like pdns doesn't have a working command to reset all cache, but it has a command for clearing cache for individual domains.

My opinion is option#2 for a separate "cleaner" sub-tree for vrrp6 is best.

Implementation for this task is ready, only awaiting a decission.