Hello, Community!
VyOS 1.3.0-epa1 images are now available for download. The “epa” suffix stands for “early production access”—the finish line of the new LTS release stabilization. The generic ISO is available publicly, while all other flavors are now reserved for subscribers—they will be available in the support portal within a couple of days. We recommend trying this release on lab VMs and upgrading non-critical production routers first since this release makes a log of big changes and some corner case issues may still exist.
First of all, we'd like to thank everyone who contributed to this release by sending us patches, testing images, writing documentation, supporting us through subscription purchases and donations, and otherwise helped us bring the release day closer. It wouldn't be possible without you!
Thanks to the efforts of everyone involved, VyOS 1.3 is quite stable already, and we are already running this release in production and it serves us well, but we recommend you try it with your production configurations on lab VMs first, then upgrade non-critical production routers, and only then schedule maintenance windows to upgrade your mission-critical installations. With so many big changes, there's always potential for unhandled corner cases. Please report any issues you find!
Also, remember that we are happy to issue free subscriptions to contributors: if you are already contributing to VyOS, please fill out the application form. And if not, hunting bugs in the upcoming release is a perfect way to start.
The branch name of the 1.3.0 release line is Equuleus. It’s named after a small and faint constellation of the northern sky whose name means “little horse” in Latin (no relation to My Little Pony!). In these almost three years of work, we have rewritten more than 50% of the legacy code from Perl to Python, and from the old unstructured approach to the new architecture that will eventually enable live rollbacks to previous config versions, commit dry-run functionality, and many other improvements. That’s not counting the more immediate benefit: those rewrites make the code much easier to maintain, extend, and contribute to.
The base system was upgraded to Debian 10 (Buster). Long-term support for Buster from Debian developers is planned to continue until June 2024, so that will give us 2.5 years of official updates, not counting the Freexian extended LTS that will last even longer. That said, we do upgrade and patch a lot of packages ourselves, so we aren’t limited by the official support time frame, but it’s easier to focus on improvements to VyOS itself when the base system can be easily kept up to date. As usual, many packages are already newer than the base system provides: for example, Linux kernel 5.4.148 and FreeRangeRouting 7.5.
One thing of note is that VyOS 1.3 images are smaller than those of 1.2.x. We’ve always been unhappy about the bloated, over 400 megabytes large images of 1.2.x, but we considered the changes needed to improve that are too risky for an LTS release.
However, 1.3.0 images are only slightly larger than 300 megabytes. That took quite some effort because there wasn’t a single source of bloat. We removed unneeded packages, developed a procedure to automatically select files from the linux-firmware package that are actually used by modules enabled in the current kernel build configuration, and tweaked the SquashFS compression options to achieve that result.
VyOS 1.3 includes many frequently requested and long-awaited features. Among them:
That’s not counting numerous smaller improvements in many components—read the changelog for details.
Additionally, some components changed their underlying implementations, which opens up new possibilities for performance and functionality improvements. For example, L2TP and PPTP servers are now based on accel-ppp, a high-performance implementation used by many service providers. It scales much better than the old xl2tpd and pptpd implementations.
Custom OpenVPN options need to be adjusted from the old approach (e.g. "--push ...") to the new one ("push ..."). Our OpenVPN scripts now generate config files for OpenVPN instances to allow them to be easily restarted if needed, instead of starting an openvpn process with a long string of inline options. Thus custom options also need to be written to be included in a config file rather than to be passed in the command line. We are investigating automatic migration options, but it may not be possible. We'd be happy to make it just work, but custom options are always end user's responsibility and not a part of the stable configuration API, so if you are using custom OpenVPN options, consider removing them before upgrade and re-creating them with the new approach.
We are also planning to add more options to the CLI to make custom options less necessary. If you are using custom options and want them to be first-class configuration entities, let us know!
First of all, configuration files from Vyatta Core versions older than 6.5 are no longer supported. Since Vyatta Core 6.5 was released in 2012, almost a decade ago, we assume it’s not going to be an issue for anyone. Moreover, it’s always possible to upgrade such installations to VyOS 1.1.8 first and then to the latest version.
The “service dns forwarding listen-on” configuration option is no longer supported. When we changed the DNS forwarding implementation from DNSMasq to PowerDNS in VyOS 1.2.0, we kept that option for compatibility. PowerDNS cannot actually be configured to listen on an interface and requires listen-address settings instead, so in VyOS 1.2.0 we added a script to compensate for this and retrieve the addresses from listen-interfaces. However, that approach has reliability issues and isn’t suitable for a long-term solution. In the end, all users should reconfigure their routers and specify listen-addresses explicitly.
To partially alleviate the problem, we added a migration script that will automatically insert addresses of interfaces with statically configured addresses. However, if you had the DNS server listen on an interface that doesn’t have a fixed address, or one that doesn’t use “address” option (e.g. OpenVPN), that configuration will disappear from the config, and you will have to adjust your settings manually.
The event handler (“set system event-handler”) is not present in the VyOS 1.3.0-epa1 image. It was removed due to the poor quality of its code. It’s not very robust, especially when using external processes as event sources, since it cannot restart those processes if they crash. It’s also not very reliable and can leak memory in some situations because it’s written in Perl and perl’s garbage collector cannot break reference cycles.
We plan to replace it with a better implementation later, but it’s going to involve non-migratable syntax changes, so for now, it’s removed. Since it’s always been an obscure and rarely-used feature, we hope it will not cause many inconveniences.
However, if you are using that feature, please let us know—we’d like to hear about your needs to make a better implementation!
The clustering feature is deprecated. In all fairness, it’s been deprecated even before the fork—the implementation is based on the abandoned heartbeat project, and the configuration code has not changed in many years. It’s full of missed opportunities and design shortcomings, but one thing kept us from removing it: it still works, and there may be people who depend on it.
We also believe that many people can benefit from a better clustering implementation that would support more resource types than just IP addresses. However, it will have to be based on a different project (e.g. pacemaker) and it’s unlikely that configuration syntax will be possible to automatically migrate.
If you are currently using the clustering feature, please let us know here (We also would like to hear from you about your experience with the clustering feature, and your needs for a new, improved implementation); meanwhile, we advise migrating to VRRP, because it’s more robust and, thanks to transition scripts, in fact, covers more use cases than clustering and fully supports dual-stack configs.