Deploying VRRP transition scripts with cloud-init

General questions
1

Hey,

as I managed to get past my last issues with cloud-init, I now have a new one I’m seemingly unable to solve: How do I deploy VRRP transition scripts via cloud-init? The classic write_files directive in the user-data appears to run too early to write to /config/scripts. A quick search over the cloud-init docs didn’t suggest any other locations where I could conveniently write some files, so my question is: how should I proceed? We switched to cloud-init provisioning only to eliminate some other provisioning related issues (which worked pretty much fine) and there is no way we’re returning to on the fly config or something hybrid, as that would re-introduce the issues we just solved. I already thought of baking the scripts into the base image, but that isn’t very flexible either, especially as we don’t need all scripts on all of our VyOS instances.

Any help is appreciated!

Best regards

2

Hi Michael, could you check if this docs section resolves the case - VyOS cloud-init — VyOS 1.5.x (circinus) LTS

3

Thank you for pointing out that section, I must have missed it while searching somehow, weird.

However, it solves my question only partially (if my currently building seed.iso turns out to be working - building takes a while it went through):

  • What happens to scripts with the same name existing at /config/scripts? Is one or the other preferred or would they simply run both (in case of pre/post config script)?
  • If I’m not mistaken, that directory is not persistent on upgrades, is it? In that case, would it be enough to simply keep the seed.iso attached to the VM, causing it to be run again automatically after the update? I just noticed, it will be copied over to /config/scripts, so it should persist. As I’m not 100% sure about existing files, the above question still holds.
  • In case I’m supposed to solve the latter by ensuring a post config script moves the files around: Where is the repo contianing these docs, so I can add that to it?
  • What can I do about VRRP scripts handing addresses? We have a single Wireguard endpoint on our main routers that are configured for HA with VRRP. As a Wireguard interface can’t be given a floating address, we use transition scripts to set/unset the address on the interface depending on the each routers VRRP state. This ensures we can always reach each of these routers via dedicated management network (the VPN that is terminated), no matter which one currently is master. The script itself works, but after cloud-init all routers end up with an address for the Wireguard interface, blocking access to the non-master ones, as the native route towards the “stale” wg interface is prioritized over our static fallback route via current master router.

Something unrelated to my initial question I’ve noticed: The proxmox cloud-init section seems to be off about the .qcow2 image generation. The VyOS image repo was archived 2024, such images are supposed to be built via vyos-build repo using a proper build-flavor or cli commands.