That appears to have been exactly the problem. I did a quick:
touch /var/log/radwtmp chown radiusd.radiusd /var/log/radwtmp
And now the unix module is returning OK, and it appears (according to the logs) that it's sending the account response packets that it wasn't before. Thanks!!
-----------------------------------------------------------------
radius_xlat: '/var/log/radacct/10.45.0.9/detail-20050308'
rlm_detail: /var/log/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radacct/10.45.0.9/detail-20050308
modcall[accounting]: module "detail" returns ok for request 81
modcall[accounting]: module "unix" returns ok for request 81
radius_xlat: '/var/log/radutmp'
radius_xlat: 'black'
modcall[accounting]: module "radutmp" returns ok for request 81
modcall: group accounting returns ok for request 81
Sending Accounting-Response of id 237 to 10.45.0.9:7015
Finished request 81
Alan DeKok wrote:
Scott Baker <[EMAIL PROTECTED]> wrote:
errors. Maybe someone on the list can help me. The only thing I see is that it's complaining about no NULL realm, and that the module "unix" returns "fail" What should I be looking for?
That the server doesn't send an Accounting-Response to the client. This is because the "unix" module returns "fail".
The short answer is to delete "unix" from "accounting".
From looking at the source code to rlm_unix, this happens because it can't write to the "radwtmp" file. It SHOULD be printing out a descriptive error message, though.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Scott Baker Canby Telephone - Network Administrator - RHCE Ph: 503.266.8253
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
