SearchThis release increments the VMOD ABI version number, which means that VMODs will have to be recompiled in order to load. Packages for Varnish Cache Plus 4.1.9r1 and updated VMOD packages are available from our package repositories. Thirdparty VMODs will have to be recompiled manually.
Some other changes include:
req.ttl when keeping track of expired objects.The Varnish Cache uses an in-tree implementation of SHA-256 to do hashing internally. These functions used the same names as the ones provided by OpenSSL’s libcrypto, and on some platforms (Debian in particular) this is causing problems where OpenSSL starts to use Varnish’ SHA-256 functions.
To resolve this conflict, Varnish’ SHA-256 functions have been renamed, adding a V to the front of each symbol. While this solves the naming conflict, this could cause subtle runtime problems for deployed VMODs if they end up using OpenSSL’s SHA-256.
To prevent problems in this area going unnoticed, the ABI major version in Varnish Cache Plus 4.1.9r1 has been bumped. The ABI major version is encoded in VMODs at build time, and Varnish will refuse to load VMODs where the ABI major doesn’t match that of Varnish. What this means is that all custom VMODs need to be recompiled after installing Varnish Cache Plus 4.1.9r1.
Packaged versions of VMODs have updated packages in the
repositories and can be updated using yum and apt-get. The previous version of the packaged VMODs will refuse
to load after upgrading Varnish, so make sure to update these packages
at the same time.
Custom VMODs compiled from source need to be recompiled after upgrading to get the right ABI version marker. Note that compatibility macros for the SHA-256 rename are present, so there is no need to patch the VMODs even if they use Varnish’ SHA-256 implementation.
Varnish will refuse to load VMODs that were built on previous ABI versions and log the following error:
Message from VCC-compiler:
Incompatible VMOD cookie
File name: ...
VMOD version 3.2
varnishd version 4104.0