Univention Bugzilla – Bug 55007
Custom freeradius configuration lost or overwritten by u-radius package updates
Last modified: 2024-04-24 14:56:08 CEST
A customer tested the update from UCS4 to UCS5 and found that their radius config was not migrated. Detailed information in attached ticket (german). This caused a not working freeradius. I can not recreate this in the moment, but please check if our test verify the migration of own configs. There are a lot of customers that have an own config. This would cause a lot of support cases if it is a generic problem.
I don't know if this helps, but when we updated from UCS4.4 to UCS5, I think we had a "custom" config and this one was activated, and the "default" configuration was deactivated. And after the update the default config was active as well, which resulted in Freeradius not starting at all. Deactivating one of those configs (removing the symlink) resulted in it working again.
The problem is, that the link /etc/freeradius/3.0/sites-enabled/default will be restored to link to /etc/freeradius/3.0/sites-available/default after any package update. This is a problem for customers with their own config that conflict with our 'default' config file. When also having a 'listen' statement in the custom config, freeradius will not start with: -- Failed binding to auth address * port 1812 bound to server custom: Address already in use /etc/freeradius/3.0/sites-enabled/default: Error binding to port for 0.0.0.0 port 1812 -- Workaround for a customer with a custom config in a file with the same name, after the package update: cd /etc/freeradius/3.0/sites-enabled rm default ln -s /etc/freeradius/3.0/sites-available/custom default
Moin, I think it's great when you implement feature requests; however, you should definitely work through this bug, because otherwise customers will run into it! It's nice that you can now allow MAC addresses via UCS, our mutual customer has run into this bug again due to this new feature. Every change to the univention-freeradius package leads to the customer running into this bug again! Please set the priority accordingly. You should definitely address this bug with the next change to freeradius. (Your ticket 2024010521000048)
Bugfix 57069 creashed again the customer environment, because the default is overwritten again.
Thanks for cleaning the MAC address issue (https://forge.univention.org/bugzilla/show_bug.cgi?id=57069) and shutting down the big customer with that update again! PLEASE: Solve this bug if you change anything in freeradius! Every update will overwrite the link to the custom config and set a softlink to default. That's not what updates should do.
Package: univention-radius Version: 7.0.7-3 Branch: ucs_5.0-0-errata5.0-7 Scope: errata5.0-7 univention-radius.yaml accfa5b9d45d | fixup! fix(radius): preserver custom configuration 14dba168b442 | fix(radius): preserver custom configuration univention-radius (7.0.7-3) 14dba168b442 | fix(radius): preserver custom configuration
For 5.1 Package: univention-radius Version: 8.0.10 Branch: ucs_5.1-0 Scope: univention-radius (8.0.10) cadf0afc076f | fix(radius): preserver custom configuration
For 5.2 Successful build Package: univention-radius Version: 9.0.7 Branch: 5.2-0 univention-radius (9.0.7) 045dd8f9c37f | fix(radius): preserver custom configuration
QA: OK: Code review. OK: Advisory. OK: On upgrade test, a custom configuration is not removed. OK: Cherry-pick 5.1 OK: Cherry-pick 5.2
<https://errata.software-univention.de/#/?erratum=5.0x1029>