Description of problem:
Radiusd doesn't find configuration file if the binary file of radiusd is renamed. It seems that radiusd tries to find configuration file in /etc/raddb based on its binary file name. For example, if radiusd is located in /usr/bin/radiusd.blabla, it tries to find configuration file /etc/raddb/radiusd.blabla.conf, but this file does not exist, so radiusd fails to start.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Rename radiusd.
# mv /usr/sbin/radiusd /usr/sbin/radiusd.blabla
2. Run radiusd.blabla.
# radiusd.blabla -X
including configuration file /etc/raddb/radiusd.blabla.conf
Unable to open file "/etc/raddb/radiusd.blabla.conf": No such file or directory
Errors reading or parsing /etc/raddb/radiusd.blabla.conf
Radiusd does not find configuration file if it is renamed.
Radiusd finds configuration file if it is renamed.
Hmm, why do we need to have radiusd renamed?
I suspect that looking up for <program_name>.conf file is a part of core functionality. Perhaps the same library is used to load configuration for different executables and as a "clever" hack to lookup corresponding config file uses the program name.
I have test which renames radiusd and creates new radiusd file (shell script), which prepares some python environment for renamed radiusd and then calls renamed radiusd. It works in 3.0.4, but it does not work in 3.0.12, because renamed radiusd tries to find configuration file which does not exist.
If you consider it as not-a-bug, I can fix my test. It's up to you.
Although I see e.g. Debian removing that functionality in their patches, I think we can live with this. Could you perhaps try changing your test to supply the '-n' option to radiusd?
From the man page:
Read freeradius/name.conf instead of freeradius/radiusd.conf.
You can also move it into a subdirectory without changing the file name.
Tell me if that's unsuitable and we'll try something else.
Ok, workaround works for me, but, sincerely, I don't like it. I think, program would not change configuration file base on its name.
If upstream wants it, you can close this bug :-).
Yeah, I don't like it much either, but if it's not a problem for you, nor for users, we should be OK. Please feel free to re-open if it makes your life difficult.