Freeradius 3.0.21 with chroot enables fails to start from the Systemd unit file.

Wed Apr 20 18:30:43 UTC 2022

When freeradius -f is executed from the command line as user 'freerad' 
the process dies without logging anything to 
/var/log/freeradius/radiusd.log (originally I had /var/log/freeradius 
bind mounted to /var/freeradius/chroot/var/log/freeradius but I changed 
that to separate the log files for my tests).

So, if I run the chrooted freeradius -f from the command line as...
1) ...'freerad', the daemon dies without logging anything.
2) ...'root', Freeradius works as expected and "ps u -C freeradius" 
outputs "freerad   7758  6.1  9.2 175332 87020 ?        Ssl  17:08 
0:01 /usr/sbin/freeradius -f".

The systemd unit file contains the lines User=freerad and Group=freerad 
which, in the best of my knowledge, mean "run freeradius -f as user and 
group 'freerad'".

If I remove the User and Group lines (they both default to 'root'), 
systemd complains that the process "Failed with result 'timeout'" and 
freeradius logs "Warning: Failed notifying systemd that process is 
READY: Unknown error -2" in 
/var/freeradius/chroot/var/log/freeradius/radiusd.log. However, the 
chrooted freeradius process is up and works as expected.

Antonios

On 19/04/2022 19:14, Alan Buxey wrote:
> Its chroot'd, so unless you are pointing /var/log/freeradius to the correct
> louvain,  check contents of /var/freeradius/chroot/var/log/freeradius
> 
> alan
> 
> On Mon, 18 Apr 2022, 17:08 Antonios Kalkakos, <akalkakos at hotmail.com> wrote:
> 
>> On 18/04/2022 16:24, Alan DeKok wrote:
>>> On Apr 18, 2022, at 6:53 AM, Antonios Kalkakos <akalkakos at hotmail.com>
>> wrote:
>>>> I am trying to test chroot on a Raspberry Pi running the
>> distro-provided Freeradius 3.0.21 on the 32bit Raspberry Pi OS (Debian) 11.
>>>
>>>     Chroot should work by itself.  I doubt that it will work with
>> systemd, though.
>>>
>>> ...
>>>> Apr 16 14:14:37 raspberry systemd[1]: freeradius.service: Main process
>> exited, code=exited, status=1/FAILURE
>>>
>>>     Hmm... "FAILURE".   Maybe there's an additional error message buried
>> somewhere inside of the systemd logs?
>> Nothing is logged in /var/log/freeradius; logs in /var/log/syslog don't
>> give any detail:
>>
>> -------------------syslog----------------------------------
>> Apr 18 17:00:53 raspberry systemd[1]: Starting FreeRADIUS multi-protocol
>> policy server...
>> Apr 18 17:00:54 raspberry freeradius[6975]: FreeRADIUS Version 3.0.21
>> Apr 18 17:00:54 raspberry freeradius[6975]: Copyright (C) 1999-2019 The
>> FreeRADIUS server project and contributors
>> Apr 18 17:00:54 raspberry freeradius[6975]: There is NO warranty; not
>> even for MERCHANTABILITY or FITNESS FOR A
>> Apr 18 17:00:54 raspberry freeradius[6975]: PARTICULAR PURPOSE
>> Apr 18 17:00:54 raspberry freeradius[6975]: You may redistribute copies
>> of FreeRADIUS under the terms of the
>> Apr 18 17:00:54 raspberry freeradius[6975]: GNU General Public License
>> Apr 18 17:00:54 raspberry freeradius[6975]: For more information about
>> these matters, see the file named COPYRIGHT
>> Apr 18 17:00:54 raspberry freeradius[6975]: Starting - reading
>> configuration files ...
>> Apr 18 17:00:54 raspberry freeradius[6975]: Debug state unknown
>> (cap_sys_ptrace capability not set)
>> Apr 18 17:00:54 raspberry freeradius[6975]: Creating attribute Unix-Group
>> Apr 18 17:00:54 raspberry freeradius[6975]: rlm_cache (cache_eap):
>> Driver rlm_cache_rbtree (module rlm_cache_rbtree) loaded and linked
>> Apr 18 17:00:54 raspberry freeradius[6975]: tls: Using cached TLS
>> configuration from previous invocation
>> Apr 18 17:00:54 raspberry freeradius[6975]: tls: Using cached TLS
>> configuration from previous invocation
>> Apr 18 17:00:54 raspberry freeradius[6975]: rlm_detail (auth_log):
>> 'User-Password' suppressed, will not appear in detail output
>> Apr 18 17:00:54 raspberry freeradius[6975]: rlm_mschap (mschap): using
>> internal authentication
>> Apr 18 17:00:54 raspberry freeradius[6975]: Ignoring "sql" (see
>> raddb/mods-available/README.rst)
>> Apr 18 17:00:54 raspberry freeradius[6975]:  # Skipping contents of 'if'
>> as it is always 'false' --
>> /etc/freeradius/3.0/sites-enabled/inner-tunnel:340
>> Apr 18 17:00:54 raspberry freeradius[6975]: radiusd: #### Skipping IP
>> addresses and Ports ####
>> Apr 18 17:00:54 raspberry freeradius[6975]: Configuration appears to be OK
>> Apr 18 17:00:55 raspberry systemd[1]: freeradius.service: Main process
>> exited, code=exited, status=1/FAILURE
>> Apr 18 17:00:55 raspberry systemd[1]: freeradius.service: Failed with
>> result 'exit-code'.
>> Apr 18 17:00:55 raspberry systemd[1]: Failed to start FreeRADIUS
>> multi-protocol policy server.
>> Apr 18 17:00:55 raspberry systemd[1]: freeradius.service: Consumed
>> 1.323s CPU time.
>> -------------------end of syslog----------------------------------
>>
>>>
>>>> Although I am not a Systemd or a Freeradius guru, I made a simple
>> investigation with the following results:
>>>
>>>     That's all a very good approach.
>>>
>>>> b) As 'freerad' *with chroot enabled*, freeradius -f -lstdout returns
>> immediately without reporting or logging any error(s):
>>>>
>>>> ----------freeradius -f -lstdout output---------------------
>>>> freerad at raspberry:$ freeradius -f -lstdout
>>>> Sat Apr 16 14:24:50 2022 : Info: Starting - reading configuration files
>> ...
>>>> freerad at raspberry:$
>>>> ----------End of freeradius -f -lstdout output--------------
>>>
>>>     If you do "echo $?" immediately after that, you'll see if the server
>> exited with an error.
>> Yes, it just returns 1.
>>>
>>>     I'd say try 3.0.25, maybe it produces better error messages.
>>>
>> Will give a try on a testing machine on my spare time. It's a (sometimes
>> unfortunate) requirement for me to work with the distro - provided
>> packages.
>>
>>>> Is this a permission problem or am I doing something wrong?
>>>
>>>     chroot should work, but I can't recall trying it in the last few
>> years.
>>>
>>>     I doubt very much that chroot will work with systemd.  Systemd is
>> just too weird, and has many additional requirements over a normal chroot
>> process.
>> I totally agree with you! systemd sometimes makes simple things
>> complicated.
>>>
>>>     Alan DeKok.
>>>
>>> -
>>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>> Antonios
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html