Yes, we are aware of that. Hence we don't usually use stream packages, and hence my question if pin pointing to an older version was a possibility. So no worries. VM is not an option, since these servers are with different providers. We have a bash installation script as base line for future installations that has worked very well in the past. The only solution I see is to auto compile version 3.0.21 within the installation script, that way we control the version we want. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 14 March 2021 15:10, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 14, 2021, at 10:48 AM, Mark Antony via Freeradius-Users freeradius-users@lists.freeradius.org wrote:
We are going to have multiple VPN servers running on Debian 10. Each server has its own freeradius installation connecting to a central Freeradius database. More servers will be added to the pool in future.
OK.
If each future installation gets the latest freeradius copy, a schema change could break it when trying to communicate to the central freeradius database, that has now an older schema.
So... don't install the latest one? Just clone one of the VMs.
i.e. you should have a base "template" VM you're using, with most everything pre-installed.
You should NOT be installing new systems from scratch every time. It's not just FreeRADIUS that may change. Everything may change. And then you have no idea what you're running.
Ideally we need to freeze all future installations to a specific version, even if newer versions get to be released.
(a) clone a template VM
(b) cache all of the packages you used to install the VM, so you can re-use them later.
And turn off auto-updates.
The current base version on Debian 10 is 3.0.17, which is pretty old. Hence I was hoping there was a way to freeze it to 3.0.21 for all our future installations.
Freezing things is your responsibility.
What you're asking here is that everyone else keep old packages around. Some people might do this, others will not.
In the end, they're your systems, and your responsibility. It costs nothing to create a template VM. It costs nothing to cache the packages used to create this VM.
You really don't want to upgrade (or install new) production machines to random upstream packages. Doing this means that all of your systems will be slightly different. This is a recipe for disaster.
Alan DeKok.