--On 27. Mai 2015 11:25:52 -0400 Alan DeKok <aland@deployingradius.com> wrote:
I'm not sure what can be done about that, if anything, but at the very least I would like to have a better understanding of what class of error gets past a "radmin -e hup". Normally we would always test configuration changes locally on the staging server, so that errors like the one above shouldn't ever get pushed to a production system. But as you know, eventually everything that can go wrong will go wrong ...
The check should really be without radmin. Just stop the server and re-start it.
I would, but I have found another problem. We use user and group "radiusd". When I try to start radiusd with that user, the following happens: $ /usr/sbin/radiusd -d /etc/raddb radiusd: Cannot change ownership of log file /var/log/radius/radius.log: Operation not permitted But the log file actually belongs to radiusd: $ ll /var/log/radius/radius.log -rw-r----- 1 radiusd radiusd 5322 29. Mai 15:03 /var/log/radius/radius.log With strace I was able to see that the chown tries to set the user to UID 0, i.e. root: ... open("/var/log/radius/radius.log", O_WRONLY|O_CREAT|O_APPEND, 0640) = 3 chown("/var/log/radius/radius.log", 0, 95) = -1 EPERM (Operation not permitted) futex(0x3fc403c3a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(2, "radiusd: Cannot change ownership"..., 97radiusd: Cannot change ownership of log file /var/log/radius/radius.log: Operation not permitted ) = 97 ... I'm not clear why that happens. The code in mainconfig.c->switch_users() looks OK at first glance ... ideas? Sebastian Hagedorn -- .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.