Freeradius configuration cannot be stored on a mapped Docker volume
When attempting to include a volume mapping to anything under either the /etc/raddb or /etc/freeradius container folders, the container crashes on startup. Despite the original ticket being closed as a Docker issue, the behavior does not occur with non Freeradius containers. For example, if the docker-compose.yml file includes: volumes: - ./freeradius:/etc/freeradius or volumes: - ./raddb:/etc/raddb This will not allow the container to start. Only a mapping to a specific file will work, but is sub-optimal because then you cannot persist anything in the mods-enabled folder. While the documentation explicitly handles this persistence with the `COPY raddb/ /etc/raddb/` line, it seems this is a workaround to supporting a very standard way of handling it in the docker-compose.yml.
Hi Timothy, Could you share the debug output of radius, why it crashes?? - Lineconnect
On 23. Jan 2024, at 01:48, Timothy Weaver <timothyweaver@gmail.com> wrote:
When attempting to include a volume mapping to anything under either the /etc/raddb or /etc/freeradius container folders, the container crashes on startup. Despite the original ticket being closed as a Docker issue, the behavior does not occur with non Freeradius containers.
For example, if the docker-compose.yml file includes:
volumes: - ./freeradius:/etc/freeradius
or
volumes: - ./raddb:/etc/raddb
This will not allow the container to start. Only a mapping to a specific file will work, but is sub-optimal because then you cannot persist anything in the mods-enabled folder.
While the documentation explicitly handles this persistence with the `COPY raddb/ /etc/raddb/` line, it seems this is a workaround to supporting a very standard way of handling it in the docker-compose.yml. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Unfortunately I can't because no logs are generated. Neither the console nor a "docker logs freeradius" give any output. On Tue, Jan 23, 2024 at 1:21 AM <nabble@felix.world> wrote:
Hi Timothy,
Could you share the debug output of radius, why it crashes??
- Lineconnect
On 23. Jan 2024, at 01:48, Timothy Weaver <timothyweaver@gmail.com> wrote:
When attempting to include a volume mapping to anything under either the /etc/raddb or /etc/freeradius container folders, the container crashes on startup. Despite the original ticket being closed as a Docker issue, the behavior does not occur with non Freeradius containers.
For example, if the docker-compose.yml file includes:
volumes: - ./freeradius:/etc/freeradius
or
volumes: - ./raddb:/etc/raddb
This will not allow the container to start. Only a mapping to a specific file will work, but is sub-optimal because then you cannot persist anything in the mods-enabled folder.
While the documentation explicitly handles this persistence with the `COPY raddb/ /etc/raddb/` line, it seems this is a workaround to supporting a very standard way of handling it in the docker-compose.yml. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, 23 Jan 2024 at 17:30, Timothy Weaver <timothyweaver@gmail.com> wrote:
Unfortunately I can't because no logs are generated. Neither the console nor a "docker logs freeradius" give any output.
docker run -it -v ./freeradius:/etc/freeradius freeradius/freeradius-server -X
On Tue, Jan 23, 2024 at 1:21 AM <nabble@felix.world> wrote:
Hi Timothy,
Could you share the debug output of radius, why it crashes??
- Lineconnect
On 23. Jan 2024, at 01:48, Timothy Weaver <timothyweaver@gmail.com> wrote:
When attempting to include a volume mapping to anything under either the /etc/raddb or /etc/freeradius container folders, the container crashes on startup. Despite the original ticket being closed as a Docker issue, the behavior does not occur with non Freeradius containers.
For example, if the docker-compose.yml file includes:
volumes: - ./freeradius:/etc/freeradius
or
volumes: - ./raddb:/etc/raddb
This will not allow the container to start. Only a mapping to a specific file will work, but is sub-optimal because then you cannot persist anything in the mods-enabled folder.
While the documentation explicitly handles this persistence with the `COPY raddb/ /etc/raddb/` line, it seems this is a workaround to supporting a very standard way of handling it in the docker-compose.yml.
Actually I was able to get into the container with "docker run --rm -it --entrypoint bash freeradius" and then try to manually start the server with "freeradius -X". Here's where it dies. The entire /etc/freeradius configuration folder is the default files straight from the repository. ---- snip --- including files in directory /etc/freeradius/policy.d/ including configuration file /etc/freeradius/policy.d/abfab-tr /etc/freeradius/policy.d/abfab-tr[49]: Parse error in condition /etc/freeradius/policy.d/abfab-tr[49]: (&GSS-Acceptor-Service-Name && (&outer.request.GSS-Acceptor-Service-Name != &GSS-Acceptor-Servi... /etc/freeradius/policy.d/abfab-tr[49]: ^ Cannot use attribute reference on right side of condition Errors reading or parsing /etc/freeradius/radiusd.conf --- snip --- On Tue, Jan 23, 2024 at 1:21 AM <nabble@felix.world> wrote:
Hi Timothy,
Could you share the debug output of radius, why it crashes??
- Lineconnect
On 23. Jan 2024, at 01:48, Timothy Weaver <timothyweaver@gmail.com> wrote:
When attempting to include a volume mapping to anything under either the /etc/raddb or /etc/freeradius container folders, the container crashes on startup. Despite the original ticket being closed as a Docker issue, the behavior does not occur with non Freeradius containers.
For example, if the docker-compose.yml file includes:
volumes: - ./freeradius:/etc/freeradius
or
volumes: - ./raddb:/etc/raddb
This will not allow the container to start. Only a mapping to a specific file will work, but is sub-optimal because then you cannot persist anything in the mods-enabled folder.
While the documentation explicitly handles this persistence with the `COPY raddb/ /etc/raddb/` line, it seems this is a workaround to supporting a very standard way of handling it in the docker-compose.yml. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 23, 2024, at 1:46 PM, Timothy Weaver <timothyweaver@gmail.com> wrote:
Actually I was able to get into the container with "docker run --rm -it --entrypoint bash freeradius" and then try to manually start the server with "freeradius -X". Here's where it dies. The entire /etc/freeradius configuration folder is the default files straight from the repository.
That's a little odd. It works everywhere else.
---- snip --- including files in directory /etc/freeradius/policy.d/ including configuration file /etc/freeradius/policy.d/abfab-tr /etc/freeradius/policy.d/abfab-tr[49]: Parse error in condition /etc/freeradius/policy.d/abfab-tr[49]: (&GSS-Acceptor-Service-Name && (&outer.request.GSS-Acceptor-Service-Name != &GSS-Acceptor-Servi... /etc/freeradius/policy.d/abfab-tr[49]: ^ Cannot use attribute reference on right side of condition Errors reading or parsing /etc/freeradius/radiusd.conf
The short answer is that if you're not using the abfab-tr policy, then just delete that file. Alan DeKok.
participants (4)
-
Alan DeKok -
nabble＠felix.world -
Terry Burton -
Timothy Weaver