Jay Banks wrote:

...

# radiusd -f -l syslog Sun Jul 1 10:40:09 2007 : Info: Starting - reading configuration files ... radiusd: Couldn't open syslog/radius.log for logging: Permission denied (rlm_eap_tls: Loading the certificate file as a chain) radiusd: Couldn't open syslog/radius.log for logging: Permission denied (rlm_passwd: nfields: 2 keyfield 0(User-Name) listable: no)

Output after that appears correctly via syslog. Have I missed something? Bug or feature?

With FreeBSD, that almost has to be some type of permission problem. What type of account are you running freeradius under? If you are testing freeradius using, for example, "radiusd -X", while not running as root, that is most likely your problem.

Not likely, but if you are trying to run freeradius from daemontools, there are instructions in the wiki for that. Basically, you have to make the process running a member of the group that has logging privileges. But again, the first suggestion is the first place to start.

freeradius is started as the root user and should then switch to an unprivileged user-id according to the config file: user = radius group = radius But that cannot be the problem here. A relative file name of "syslog/radius.log" is obviously wrong. Presumably the file cannot be opened due to missing write permissions. Anyway, when doing syslog, no log file should be opened at all, right? Both error messages seem to originate from modules during their initialization (rlm_eap_tls / rlm_passwd). After a quick look at the source, I would say, this is due to calling radlog()/vradlog() from the module initialization or elsewhere, *before* the 'radlog_dest' variable is correctly set to RADLOG_SYSLOG in src/main/radiusd.c. After radlog_dest has been set up there, no more such error messages appear, and log goes correctly to syslog as it should. Andreas -- Keep it icy man. I don't want to end up a corpse before my time because you were daydreaming.

Jay Banks wrote:

Here is the same problem, found in the archives for this list, which was posted back in January of 2004:

BUG?? Couldn't open syslog/radius.log for logging: Not a directory

Problem Summary: radiusd: radiusd: Couldn't open syslog/radius.log for logging: Not a directory

Problem Detials: It appears that freeradius is attempting to log to a file when asked to to log to the syslog. Listed below is the config settings and init script to confirm correct settings. In looking at the source, it appears that RADLOG_SYSLOG is never defined and as such has a null value when being evaluated in the following code snippets:

*************radiusd.c**********************

#if HAVE_SYSLOG_H /* * If they asked for syslog, then give it to them. * Also, initialize the logging facility with the * configuration that they asked for. */ if (strcmp(radlog_dir, "syslog") == 0) { openlog(progname, LOG_PID, syslog_facility); radlog_dest = RADLOG_SYSLOG; } /* Do you want a warning if -g is used without a -l to activate it? */ #endif if (strcmp(radlog_dir, "stdout") == 0) { radlog_dest = RADLOG_STDOUT; } else if (strcmp(radlog_dir, "stderr") == 0) { radlog_dest = RADLOG_STDERR; }

RADLOG_SYSLOG is defined, at least in 1.1.6. The problem is that 'radlog_dest' has a default setting of: radlog_dest_t radlog_dest = RADLOG_FILES; And the above processing of the special 'syslog/stdout/stderr' keywords in 'radlog_dir' which changes 'radlog_deest' to RADLOG_SYSLOG, does not take place until after the config file(s) have been read and modules have been setup by setup_modules(). This means if anything calls radlog()/vradlog() before, then radlog_dest will contain RADLOG_FILES, and the value from 'radlog_dir' will be suffixed with the default log file name, which gives 'syslog/radius.log'. A simple solution to this problem would be to change the default setting of 'radlog_dest' to RADLOG_SYSLOG and recompile. But then you wont be able to ever log to a file again, which might be ok if you intent on using syslog only anyway. The better way is probably moving the code block, that calls setup_modules() after the block that sets up 'radlog_dest' according to the special values from radlog_dir. So the radlog_dest variable would already been set correctly when setup_modules() runs. Anyway, the best solution would be to have a separate commandline switch, whose sole purpose is to set the log destination, and which is made effective immediately when commandline option processing occurs. i.e. radiusd -g files (*default*) radiusd -g syslog@daemon radiusd -g stdout radiusd -g stderr The current '-g' commandline option, which only sets the syslog facility is BTW not documented in the program usage output. best regard, Andreas -- Keep it icy man. I don't want to end up a corpse before my time because you were daydreaming.