if the interface gets delete from the config, the wg device gets deleted from the OS and all its routes

This is exactly the reason why "set protocols static ..." commands use zebra instead of pushing routes directly to the kernel with iproute2. Zebra takes care of interfaces going up and down and reinstalls the routes when needed.

Now, is that suppose to happen automatically ( i can include it in the wireguard.py script), or is it supposed to be setup via 'set static proto ...'? What would be the better way?

If wireguard cannot create routes on its own, I believe we should leave route setup to the user. Doing it automatically when it's not actually supported is a very leaky abstraction.

Works now, though I need to discuss the pull requests with PPP maintainers.

Should be working now.

I believe I've fixed it, though feedback won't harm.

Closing for now then, let's reopen if needed, or make a separate task for bridging openvpn with new interface types.

@mb300sd The reason we do not allo arbitrary names is that there's no easy way to find out exact interface type, so we forced them to begin with eth, br, tun etc. so that scripts can find out what it is and filter only compatible interfaces.
Relaxing the requirements to "starts with keyword" like eth-lan or tun-office would be an interesting idea, but I'm afraid only in the long run, since a number of scripts have regexes like eth\d+ hardcoded in them and it will take time to clean up.

The renderer works now (for a long time already, even), so it's time to close this task finally. ;)

@UnicronNL @hagbard Please do not use that package! I've inspected it, and it's below any reasonable standards!

One note: I'm removing the "firewall" option. First, it's only relevant for RFC-compliant VRRP, and there's no checking for it. Second, it has no advantages over assigning the firewall directly to the parent interface in any case.
Third, it was implemented inconsistently: ethernet VIFs and non-ethernet interfaces (e.g. bond) lack it.

For the reference: https://github.com/acassen/keepalived/blob/master/doc/NOTE_vrrp_vmac.txt

Does the problem also exist with the other kind of VRRP?

I'd need to check.

There was one or two 1.2.0 images that did have a hostname problem due to a problem in the new implementation of the system host-name command, but I fixed it. I wonder if your problem might be carried over from one of those images.

Could you try updating some test machine from 1.1.8?

You get this when you upgrade from a previous rolling release, or from 1.1.8? If the former, which one?

Should we delete user home dirs when deleting a user then?

I think new version should still be able to sync with the old versions, since people will be upgrading routers in their HA pairs one by one, and loss of functionality during upgrades isn't a very nice situation.

@hagbard Migration scripts are no longer that much of a problem (though they still need to be carefully written). See http://blog.vyos.net/writing-migration-scripts-and-manipulating-vyos-config-files-outside-vyos-just-got-easier

https://github.com/vyos/vyos-1x/blob/new-vrrp/interface-definitions/vrrp.xml The new syntax draft.

That's my punishment for the sin of only testing op mode commands from conf mode.

The pull request was merged.

@runar Found an issue: show-raid.xml refers to ${vyos_op_scripts_dir}/show_raid.sh file, but that file does not exist.

Yes, it's been fixed a while ago.

@c-po I've rebuilt those newer packages from source (typically by using apt-get source). Due to different libc and all they indeed cannot be installed directly.

Appears to work fine now.

@hagbard If rewrite can be done in a reasonable time (days to a couple of weeks), I think trying to clean up old code is more trouble than it's worth.
With big stuff that cannot be easily rewritten, it may be worthwhile.

@hagbard If you are working on it, by all means, assign it to yourself. We do not have a formal assignment policy, it's more like "I'm working on it" flag for coordination.

@runar The sudo wrapper is mostly due to the fact that the op mode convertor is largely a clone of the conf mode convertor. This also interfers with operator level users' ability to run anything at all, so this is a good point.
We likely need to switch to adding sudo where needed instead, but we need to test which commands break from it when run by non-admin users.

Seems to work fine now, reopen if necessary.

@syncer @higebu Yes, stock quagga is missing many things that ours has. We have no choice other than to integrate the patches by hand.

It was just an error in the help. Someone probably copied it from somewhere else (e.g. the address option of firewall rules) and forgot to edit.

Interesting. Perhaps the config format has changed in newer versions? What do the docs say?

After installing pppd from T677, it seems to work again.

Found the issue. First, renaming is hadled in a pre-up script that was in the ppp package rather than vyatta-ravpn, so it is not included in 1.2.0.

State files are updated properly after keepalived upgrade, no need for this workaround anymore.

When we get to it, we should also get rid of built-in support for a handful of north american wireless providers (which is likely very out of date by now) and add support for custom connection strings etc.