Hi, I'm struggling by configuring the accounting for logs of module sqlippool (messages exists/success/clear/failed/nopool) (freeradius 3.x). I would like to have these logs directed to my stdout as I'm using freeradius into a docker container and also the main logs of freeradius are directed to stdout. I found a way to log them via linelog but I need the logs to be directed to stdout. The module linelog does not support it ;( Is there a way to log the attribute %{control:Module-Success-Message} that contain these information to the standard radius log module? In that way I will find sqlippool logs "mixed" with the other freeradius logs (as was in the 2.x freeradius release). Probably the right way it's via the update/control directive but I didn't got lucky by reading the docs and experimenting... Can a freeradius expert point me to the right direction? Thanks! Matteo
On Mar 14, 2022, at 11:23 AM, Matteo Sgalaberni <sgala@sgala.com> wrote:
I'm struggling by configuring the accounting for logs of module sqlippool (messages exists/success/clear/failed/nopool) (freeradius 3.x). I would like to have these logs directed to my stdout as I'm using freeradius into a docker container and also the main logs of freeradius are directed to stdout.
I found a way to log them via linelog but I need the logs to be directed to stdout. The module linelog does not support it ;(
linelog { ... filename = /dev/stdout ... } :) Alan DeKok.
----- On 14 Mar, 2022, at 16:54, Alan DeKok aland@deployingradius.com wrote:
linelog { ... filename = /dev/stdout ...
Hi Alan, already tried ;( With filename = /dev/stdout - On a debian server vanilla: Mon Mar 14 17:32:55 2022 : Error: rlm_linelog: Failed to open /dev/stdout: Bad file descriptor - On a container (https://hub.docker.com/r/freeradius/freeradius-server/): Mon Mar 14 14:53:45 2022 : Error: rlm_linelog: Failed to open /dev/stdout: Permission denied I tried to find the in the source code the root cause: https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... https://github.com/FreeRADIUS/freeradius-server/blob/bef190c8da06716b871e2fb... I'm not a C expert and I didn't debugged it well. I suppose that the open() used in that way is not compatible with stdout or named pipes (tried also), It works only with regular files. Or do you think that should work and there is definitively something else causing the issue (Failed to open /dev/stdout)? Thanks M.
On Mar 14, 2022, at 12:47 PM, Matteo Sgalaberni <sgala@sgala.com> wrote:
Hi Alan, already tried ;(
With filename = /dev/stdout
- On a debian server vanilla: Mon Mar 14 17:32:55 2022 : Error: rlm_linelog: Failed to open /dev/stdout: Bad file descriptor
- On a container (https://hub.docker.com/r/freeradius/freeradius-server/): Mon Mar 14 14:53:45 2022 : Error: rlm_linelog: Failed to open /dev/stdout: Permission denied
I tried to find the in the source code the root cause: https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... https://github.com/FreeRADIUS/freeradius-server/blob/bef190c8da06716b871e2fb...
I'm not a C expert and I didn't debugged it well. I suppose that the open() used in that way is not compatible with stdout or named pipes (tried also), It works only with regular files.
The code in exfile.c is trying to create /dev/stdout, and I guess that's not allowed. Or the C library is too dumb to notice. I've pushed a fix to the v3.0.x branch on GitHub. Alan DeKok.
----- On 14 Mar, 2022, at 18:05, Alan DeKok aland@deployingradius.com wrote:
The code in exfile.c is trying to create /dev/stdout, and I guess that's not allowed. Or the C library is too dumb to notice.
I've pushed a fix to the v3.0.x branch on GitHub.
Uhu, thanks, found it https://github.com/FreeRADIUS/freeradius-server/commit/6ea9cc233d4a16de2cb23... ! Can you help me also with the initial idea to bring the %{control:Module-Success-Message} of sqlippool into the standard logs? I found several people with the same needs in lots of posts but I haven't found any solutions. All mailing lists threads finish with "use linelog". Does exists an alternative or not at all? Thanks! M.
On 14/03/2022 17:24, Matteo Sgalaberni wrote:
Can you help me also with the initial idea to bring the %{control:Module-Success-Message} of sqlippool into the standard logs?
I found several people with the same needs in lots of posts but I haven't found any solutions. All mailing lists threads finish with "use linelog". Does exists an alternative or not at all?
There's only limited ways of changing the standard logging (e.g. /var/log/radius/radius.log), though in the log{} section of radiusd.conf you can edit "msg_goodpass" and "msg_badpass", you might be able to add extra info there. "Use linelog"... that's what it's for - custom log messages. Another way to get stdout in Docker is to run something like rsyslogd configured to write to stdout, and then just syslog stuff. -- Matthew
On Mar 14, 2022, at 1:24 PM, Matteo Sgalaberni <sgala@sgala.com> wrote:
Uhu, thanks, found it https://github.com/FreeRADIUS/freeradius-server/commit/6ea9cc233d4a16de2cb23... !
Can you help me also with the initial idea to bring the %{control:Module-Success-Message} of sqlippool into the standard logs?
I found several people with the same needs in lots of posts but I haven't found any solutions. All mailing lists threads finish with "use linelog". Does exists an alternative or not at all?
There is no way to log random things into the main log files. There rarely any need for it. If you want to log the output of sqlippool, you can add your own attribute into raddb/dictionary: ATTRIBUTE SQL-IPPool-Success 3000 string ... sqlippool update control { SQL-IPPool-Success := &control:Module-Success-Message } That saves the message into a place where it won't get modified. You may need to grab the *last* success message with: ... sqlippool update control { SQL-IPPool-Success := &control:Module-Success-Message[n] } Then, just use the standard (and documented) logging mechanisms. See the "log" section of radiusd.conf: log { ... auth_goodpass = yes msg_goodpass = "SQL module says %{control:SQL-IPPool-Success}" ... } That's it. Alan DeKok.
participants (3)
-
Alan DeKok -
Matteo Sgalaberni -
Matthew Newton