VyOS Networks Blog

VyOS 1.3.0-rc4 release candidate is now officially available for free download. We invite everyone to test it and report any issues you may find. Remember that active testers are eligible for contributor subscriptions! This release mostly features bug fixes and release process refinements. Many people rightfully suggested that we should include detailed changelogs for each release candidates, so starting from this release we are doing it, read on for details!

Changelog

Starting from this release candidate, we'll be including a detailed incremental changelog in every RC and snapshot release. Many people suggested we should do it, and we completely agree—unless you actively participate in the development process all the time, the changes are hard to follow, so there are no excuses for us not to do it. Here's what happened since 1.3.0-rc3:

New features

• Logs can now be colorized, if you use the new monitor log colored op mode command.
• There's now a way to tell the DHCP client to reject specific addresses to avoid modems giving out a local address before they retrieve a WAN address. The command is like set interfaces ethernet eth4 dhcp-options reject 192.168.0.0/24. See  T3454 for details.

Bug fixes

• Fixed an issue with DHCP script not stopping ddclient processes correctly (T3471).
• Removing a VLAN interface that belongs to a VRF no longer causes the entire VRF to be deleted (T3438).
• Fixed incorrect tunnel names in the output of run show vpn ipsec sa (T3055).
• Quoted MAC addresses in the hw-id option are now parsed correctly (T2838).

Internals

• The old script for uploading files to remote locations is being replaced with a new Python script that is easier to maintain and extend.
• The minisign utility is now included in the images, in preparation for switching away from GnuPG signatures.

Disappearing rc4 link incident

Additionally, on behalf of the VyOS team, I'd like to apologize for the release candidate mishaps we've had in the last months! We understand it's been confusing and inconvenient for everyone when links to images got all messed up or even disappeared from the community website. We've adjusted the scripts to prevent premature and erroneous publication of release candidate links in the future, and we hope there will be no more indidents like those. The process is new and quite unorthodox, so it takes time to refine—thanks to everyone for patience and collaboration!

For the curious, that's how the "disappearing rc4" incident went. We now keep nightly builds, snapshots, and release candidate images in Amazon S3 now (due to relatively wide adoptance of the S3 API, that does leave a possibility to migrate to an API-compatible service if we need/want to leave Amazon). Since S3 doesn't provide automatic directory listings, we generate an HTML image list using a Python script and incorporate its output in the web page at vyos.net/get/snapshots.  Site build runs when someone pushes to the repo, and on schedule every midnight to incorporate new nightly builds. What led to the incident was my incorrect assumption that we can use local build tests and a different S3 folder as a substitute for a proper staging environment. Freshly built rc4 was placed in a folder named "snapshots-staging". Sadly, due to an S3 API gotcha I didn't know about, when the site build ran on schedule, the script captured the staging directory and published it. By the time I noticed, it was too late: people have already seen it, and I had to do quite some explaning around the Slack channels.

While that incident didn't harm anyone, and the same rc4 images are now official, we should and will strive to have better safety procedures in this area.

What's next?

VyOS 1.3.0-rc5, of course. The release is stabilizing, but we aren't quite there yet, and it will take some more changes and testing before we can call it an LTS release. In the next image, we are updating the Linux kernel to 5.4.115 and FRR to 7.5. While the FRR update may be a somewhat risky change, we'd better have the newest version we can have so that we can keep backporting fixes for longer, since we will not be able to change the FRR branch during an LTS release lifecycle. Stayt tuned for updates!