Handling FreeRADIUS software upgrades
Hi All, In each of our FreeRADIUS installations, We have removed the default and inner-tunnel symlinks in the sites-enabled directory. We've also removed the default EAP symlink in the mods-enabled directory. We have left the original files in the 'available' directories for reference but we're using our own virtual server and eap module configurations, e.g. - parent-company site, parent-company-inner-tunnel site, eap-parentcompany module. - child-company site, child-company-inner-tunnel site, eap-childcompany module. This was running very well until we encountered a brief interruption on one of the servers when the recent RHEL package update for FreeRADIUS 3.2 was applied. The update re-added the default & inner tunnel site symlinks, as well as the default eap module symlink which resulted in the service not functioning as intended. We resolved this quickly by deleting the symlinks again but this will probably happen again with a future update. What changes should we make to our config to avoid this happening again? Delete the default files in the 'available' dirs? Replace them with dummy content? Copy dummy files into the sites-enabled and mods-enabled dirs? Cheers
George Benjin <george.benjin@gmail.com> writes:
What changes should we make to our config to avoid this happening again? Delete the default files in the 'available' dirs? Replace them with dummy content? Copy dummy files into the sites-enabled and mods-enabled dirs?
Maybe move your config into another directory, different from the one used by the Redhat package, and run radius -d /my/config/dir? Or switch to a distro where packages respect local config changes on upgrades. Bjørn
On Nov 28, 2024, at 4:09 AM, George Benjin <george.benjin@gmail.com> wrote:
The update re-added the default & inner tunnel site symlinks, as well as the default eap module symlink which resulted in the service not functioning as intended.
We resolved this quickly by deleting the symlinks again but this will probably happen again with a future update.
What changes should we make to our config to avoid this happening again? Delete the default files in the 'available' dirs? Replace them with dummy content? Copy dummy files into the sites-enabled and mods-enabled dirs?
After a quick look at the capabilities of RPM, it doesn't look like it's easy to fix this. i.e. there's no trivial way to say "install these files, but only if the parent directory doesn't already exist". The simplest way to fix this with minimal changes is to just create the problem files, but with zero content. They won't be over-written on any new install. Alan DeKok.
On Thu, Nov 28, 2024 at 08:27:28AM -0500, Alan DeKok wrote:
On Nov 28, 2024, at 4:09 AM, George Benjin <george.benjin@gmail.com> wrote:
The update re-added the default & inner tunnel site symlinks, as well as the default eap module symlink which resulted in the service not functioning as intended.
We resolved this quickly by deleting the symlinks again but this will probably happen again with a future update.
What changes should we make to our config to avoid this happening again? Delete the default files in the 'available' dirs? Replace them with dummy content? Copy dummy files into the sites-enabled and mods-enabled dirs?
After a quick look at the capabilities of RPM, it doesn't look like it's easy to fix this. i.e. there's no trivial way to say "install these files, but only if the parent directory doesn't already exist".
The simplest way to fix this with minimal changes is to just create the problem files, but with zero content. They won't be over-written on any new install.
+1. That's what we do: rm -f default inner-tunnel touch default inner-tunnel rm -f eap touch eap
Thanks everyone - I'll create zero content dummy files and test the upgrade on one of our other boxes. If it works, I'll sort out the rest and update our deploy scripts. Cheers On Fri, 29 Nov 2024 at 02:32, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
On Thu, Nov 28, 2024 at 08:27:28AM -0500, Alan DeKok wrote:
On Nov 28, 2024, at 4:09 AM, George Benjin <george.benjin@gmail.com> wrote:
The update re-added the default & inner tunnel site symlinks, as well as the default eap module symlink which resulted in the service not functioning as intended.
We resolved this quickly by deleting the symlinks again but this will probably happen again with a future update.
What changes should we make to our config to avoid this happening again? Delete the default files in the 'available' dirs? Replace them with dummy content? Copy dummy files into the sites-enabled and mods-enabled dirs?
After a quick look at the capabilities of RPM, it doesn't look like it's easy to fix this. i.e. there's no trivial way to say "install these files, but only if the parent directory doesn't already exist".
The simplest way to fix this with minimal changes is to just create the problem files, but with zero content. They won't be over-written on any new install.
+1. That's what we do:
rm -f default inner-tunnel touch default inner-tunnel
rm -f eap touch eap - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Bjørn Mork -
Geoffrey D. Bennett -
George Benjin