Why freeradius-config in debian packaging
Hi. I'm looking over changes between the old packaging in Debian and the newer stuff. I notice that the configuration files were split out into freeradius-config from freeradius-common. I'd like to understand the rationale for that change. Currently it breaks upgrades. I can fix that but it will be easier to do once I understand why splitting the config files is valuable. --Sam
Sam Hartman wrote:
I notice that the configuration files were split out into freeradius-config from freeradius-common.
That's Arran's change. The idea is to separate the *default* configuration from the local *edited* configuration.
I'd like to understand the rationale for that change. Currently it breaks upgrades.
If it breaks upgrades, it should be fixed.
I can fix that but it will be easier to do once I understand why splitting the config files is valuable.
Arran can answer more. I'm happy with changing it back to the old way. Alan DeKok.
"Alan" == Alan DeKok <aland@deployingradius.com> writes:
Alan> Sam Hartman wrote: >> I notice that the configuration files were split out into >> freeradius-config from freeradius-common. Alan> That's Arran's change. The idea is to separate the Alan> *default* configuration from the local *edited* configuration. so, is the idea that if I have my own local config I might not install freeradius-config at all?
On 29 Aug 2014, at 05:32, Sam Hartman <hartmans@mit.edu> wrote:
"Alan" == Alan DeKok <aland@deployingradius.com> writes:
Alan> Sam Hartman wrote:
I notice that the configuration files were split out into freeradius-config from freeradius-common.
Alan> That's Arran's change. The idea is to separate the Alan> *default* configuration from the local *edited* configuration.
so, is the idea that if I have my own local config I might not install freeradius-config at all?
Yes, you roll your own local config package, and manage the versioning independently of the server packages. Could you explain why it breaks upgrades? We never intended the version 2 packages to be upgraded to version 3, that won't work, the configurations are not compatible. There's not really a sane way to 'upgrade' configurations once they've been customised. I know debian packaging prevents customised config files from being overwritten, but it still installs new config files added to the default packages from the upstream source. This is annoying for administrators who like to strip down the default config to only the files they're using, as upgrades introduce cruft back into /etc/raddb. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
"Arran" == Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:
Arran> On 29 Aug 2014, at 05:32, Sam Hartman <hartmans@mit.edu> wrote: >>>>>>> "Alan" == Alan DeKok <aland@deployingradius.com> writes: >> Alan> Sam Hartman wrote: >>>> I notice that the configuration files were split out into >>>> freeradius-config from freeradius-common. >> Alan> That's Arran's change. The idea is to separate the *default* Alan> configuration from the local *edited* configuration. >> >> so, is the idea that if I have my own local config I might not >> install freeradius-config at all? Arran> Yes, you roll your own local config package, and manage the Arran> versioning independently of the server packages. OK, makes sense. Arran> Could you explain why it breaks upgrades? If you upgrade across the split, even if you just accidentally install 2.x and never change anything, you get file conflicts because files moved from one package to another without replaces and conflicts being declared. Based on what you're trying to do it's a very simple fix, and really an issue I only need to care about on the Debian side, because for a fresh install of 3.x it won't be a big deal. --Sam
On 29/08/14 00:06, Sam Hartman wrote:
Hi. I'm looking over changes between the old packaging in Debian and the newer stuff.
I notice that the configuration files were split out into freeradius-config from freeradius-common.
For what it's worth, we package an RPM locally with this setup. I like it; sometimes changes appear in the default config, which are maybe surprising.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers -
Sam Hartman -
Sam Hartman