How to install a specific version of freeradius via apt?
Based on Freeradius website, it is possible to echo "deb https://packages.networkradius.com/releases/debian-buster buster main" >> /etc/apt/sources.list sudo apt-key adv --keyserver keys.gnupg.net --recv-key 0x41382202 apt update But it doesn't allow me to install the older version 3.0.20: apt install --only-upgrade freeradius=3.0.20 Is there a way to achieve that? Many Thanks, Mark
On Mar 14, 2021, at 7:38 AM, Mark Antony via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Based on Freeradius website, it is possible to
echo "deb https://packages.networkradius.com/releases/debian-buster buster main" >> /etc/apt/sources.list sudo apt-key adv --keyserver keys.gnupg.net --recv-key 0x41382202 apt update
But it doesn't allow me to install the older version 3.0.20: apt install --only-upgrade freeradius=3.0.20
We don't keep older copies of the packages around. Is there any reason you don't want to install the latest version? Alan DeKok.
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. 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. Ideally we need to freeze all future installations to a specific version, even if newer versions get to be released. 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. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 14 March 2021 13:48, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 14, 2021, at 7:38 AM, Mark Antony via Freeradius-Users freeradius-users@lists.freeradius.org wrote:
Based on Freeradius website, it is possible to echo "deb https://packages.networkradius.com/releases/debian-buster buster main" >> /etc/apt/sources.list sudo apt-key adv --keyserver keys.gnupg.net --recv-key 0x41382202 apt update But it doesn't allow me to install the older version 3.0.20: apt install --only-upgrade freeradius=3.0.20
We don't keep older copies of the packages around.
Is there any reason you don't want to install the latest version?
Alan DeKok.
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.
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.
Just an idea: Maybe you can maintain your own little Debian repository where you keep the version you want for all your servers... On 14.03.21 16:19, Mark Antony via Freeradius-Users wrote:
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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
g4-lisz＠tonarchiv.ch -
Mark Antony