radiusd -X On First Boot

Josip Rodin joy at entuzijast.net
Wed Jan 6 00:09:46 CET 2010


On Tue, Jan 05, 2010 at 03:37:25PM -0500, John Dennis wrote:
>>> I am running RHEL 5.3 and FreeRADIUS Version 2.1.8.
>>>
>>> When I install freeradius and attempt to start it for the first time using the /etc/init.d/radiusd start script it always fails (only right after freeradius is installed), once i run freeradius with -X (in debug mode) it creates all the keys and such then I can cntrl + c and start free radius from that point forward using the init script... my question is why do I have to do this? Is there anyway around this?
>>
>> probably because when run from the init script it cannot actually start the
>> daemon (due to requirements to create the key etc).  if everything is in place
>> correctly beforehand then it will work.
>>
>> I guess the question , then, is - can the RPM do the required creation of
>> example/test keys etc rather than require the admin to jump through the
>> hoops - and thats a question for the distro maintainers.
>
> The RPM could initially create the temporary certificates. There are two  
> reasons why it doesn't at the moment.
>
> 1) It would deviate from everything written here on this list and the  
> wiki. Discrepancies like that usually causes more problems than would be  
> solved by it. People have a hard enough time following instructions in  
> the first place (this list is pure evidence of that). If they then have  
> to modify the instructions based on the distribution they'll be  
> hopelessly confused :-(
>
> 2) The certificates created are *temporary* and *not* intended for  
> production use. As such it's always a good idea to bring this crucial  
> fact to the attention of the person installing the server. No better way  
> to make them aware of this than forcing them to perform a manual step.  
> Otherwise they'll blindly think everything is hokey-dokey and deploy the  
> server with temporary self-signed certs.
>
> If you really think this is needs to change then file a bug.

When I enabled EAP+SSL modules in the 2.1.8 Debian package, the eap.conf
defaults kicked in, so I added the use of snakeoil certificates explicitly
because I don't want to break all the new installations as well as upgrades.
It would piss off users by default, and that kind of behavior would IMHO be
significantly worse than either of those things you mentioned above.

These changes didn't make it into 2.1.8 (git) before upstream release, but
nevertheless you can see them at the patch tracker:
http://patch-tracker.debian.org/package/freeradius/2.1.8+dfsg-1

-- 
     2. That which causes joy or happiness.



More information about the Freeradius-Users mailing list