Suggested feature for rlm_detail: logging only a few specific users
During debugging of production systems, I've often wished there was some way to enable debugging only for specific users. The attached patch (against 1.1.x CVS for now) extends rlm_detail with an optional rlm_files compatible "usersfile" option. It does not change the behaviour for existing configurations. Usage example: modules { .. detail debugusers { detailfile = "${logdir}/debuglog" usersfile = "${raddbdir}/users.debug" } .. } .. post-auth { Post-Auth-Type REJECT { debugusers } } Where users.debug contains a list of users to debug. The syntax is similar to users(5). It can even contain check-items and DEFAULT entries (which only makes sense if combined with check items), to filter the logging even more. I'm posting this here to get some feedback whether this is a good idea or if I'm reimplementing something that already exists, or if this should go into a separate module. Comments? Bjørn
Bjørn Mork wrote:
During debugging of production systems, I've often wished there was some way to enable debugging only for specific users.
Indeed.
I'm posting this here to get some feedback whether this is a good idea or if I'm reimplementing something that already exists, or if this should go into a separate module.
Comments?
I prefer using a sniffer to track down an issue on a prod system. I don't like to hack the config files and restart the server. You might look at "radsniff" in a recent CVS snapshot. It accepts a filter with the same syntax as a "users" file, and its output is similar to a detail file. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> writes:
I prefer using a sniffer to track down an issue on a prod system. I don't like to hack the config files and restart the server.
Wise :-)
You might look at "radsniff" in a recent CVS snapshot. It accepts a filter with the same syntax as a "users" file, and its output is similar to a detail file.
Thanks for the tip. I remember it when you mention it. Looks like exactly what I need. Bjørn
=?iso-8859-1?Q?Bj=F8rn_Mork?= <bjorn@mork.no> wrote:
Where users.debug contains a list of users to debug. The syntax is similar to users(5). It can even contain check-items and DEFAULT entries (which only makes sense if combined with check items), to filter the logging even more.
You should be able to configure the server to do this. Put the per-user logging in a special Post-Auth-Type, and configure the Post-Auth-Type dynamically per user. If you pull the Post-Auth-Type from a database, you should be able to change it on the fly. In other words, if your patch is to combine the "users" module with the "detail" module, the server is configurable enough that you should already be able to do that. Alan DeKok.
"Alan DeKok" <aland@nitros9.org> writes:
=?iso-8859-1?Q?Bj=F8rn_Mork?= <bjorn@mork.no> wrote:
Where users.debug contains a list of users to debug. The syntax is similar to users(5). It can even contain check-items and DEFAULT entries (which only makes sense if combined with check items), to filter the logging even more.
You should be able to configure the server to do this. Put the per-user logging in a special Post-Auth-Type, and configure the Post-Auth-Type dynamically per user. If you pull the Post-Auth-Type from a database, you should be able to change it on the fly.
Great tip!
In other words, if your patch is to combine the "users" module with the "detail" module, the server is configurable enough that you should already be able to do that.
Yes, the idea was to "users" and "detail". I still think it has a couple of advantages that makes me want it, but I'm getting the feeling that I'm alone ;-) I'll try to explain why I want it: - it can be used to log rejects on a per-user basis (which I don't think your method above will?) - it makes per-user logging available in configuration sections with other modules. rlm_detail supports authorize, accounting, pre_proxy, post_proxy and postauth, and I want to be able to do per-user logging in any of these sections Bjørn
?iso-8859-1?Q?Bj=F8rn_Mork?= <bjorn@mork.no> wrote:
- it can be used to log rejects on a per-user basis (which I don't think your method above will?)
No.
- it makes per-user logging available in configuration sections with other modules. rlm_detail supports authorize, accounting, pre_proxy, post_proxy and postauth, and I want to be able to do per-user logging in any of these sections
You could do something similar to what I suggested in other sections, too. I think that the real answer is to have a general logging subsystem that's much more configurable than the current one. Or, use radsniff, which does much the same thing without touching the server. Alan DeKok.
participants (3)
-
Alan DeKok -
Bjørn Mork -
Nicolas Baradakis