Josip Rodin wrote:
Yes, I understood that originally. The gist of the rationale for the current
behaviour is quite clear, but even so, many users would nevertheless be best
served by many per-packet errors being more clearly visible, because even
when they enable debug level 2+, they get a
Hi,
So you fit the bill anyway - if you're prepared for a completely dead
FreeRADIUS, you're prepared for the situation such as a logging issue.
not at all. dead radiusd not an issue compared to several gigabytes
of sudden unexpected log behaviour due to an issue at remote proxy,
for example.
On Tue, Dec 08, 2009 at 09:59:32AM +, Alan Buxey wrote:
Hi,
So you fit the bill anyway - if you're prepared for a completely dead
FreeRADIUS, you're prepared for the situation such as a logging issue.
not at all. dead radiusd not an issue compared to several gigabytes
of sudden
Hi,
Again, my point was that people who are prepared to immediately intervene in
a dead radiusd are most commonly are prepared to immediately intervene in a
faulty configuration file.
revisiting the early messages in this thread clearly indicate a
desire for much more verbose logging of proxy
On Tue, Dec 08, 2009 at 11:32:36AM +, Alan Buxey wrote:
Hi,
Again, my point was that people who are prepared to immediately intervene in
a dead radiusd are most commonly are prepared to immediately intervene in a
faulty configuration file.
revisiting the early messages in this
Josip Rodin wrote:
But the proxy state logging is not a priori per-packet, it's based on status
check events. Only if each packet changes the proxy status (?!), then you'll
get as many status check logs as there are packets.
Ah... that's the misunderstanding.
The messages which should be
Hi,
The messages you've asked to make log file would result in
per-packet errors, not general state change errors. That's why I'm
reluctant to make those changes.
exactly.
chuck me EVERYTHING in debug mode. i'll take the hit..i NEED the info...
but in general use - status change only...
On Tue, Dec 08, 2009 at 11:02:30PM +0100, Alan DeKok wrote:
Logging *state changes* is OK. e.g. this packet caused the proxy to
decide that the home server is down. That happens for *one* packet,
when the home server changes state.
The messages you've asked to make log file would
Alan Buxey wrote:
it'd be nice if SNMPTRAPs
could be generated too natively but thats a different issue.
On the roadmap.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, Nov 25, 2009 at 02:33:30AM +0100, Josip Rodin wrote:
[myownlittle_linelog] expand: %{%{Packet-Type}:-format} -
Accounting-Request
[myownlittle_linelog] Entry .Accounting-Request is not a variable
assignment
Speaking of which, while browsing
Josip Rodin wrote:
Speaking of which, while browsing 558c51a711d7a326604eda0fc51040cbda2b77a8
I just noticed that it would be good for these error messages be elevated
so that users can see them outside of debug mode. Specifically:
RDEBUG2(Badly formatted variable: %s, *from);
RDEBUG2(Badly
On Sun, Dec 06, 2009 at 07:43:49PM +0100, Alan DeKok wrote:
Josip Rodin wrote:
Speaking of which, while browsing 558c51a711d7a326604eda0fc51040cbda2b77a8
I just noticed that it would be good for these error messages be elevated
so that users can see them outside of debug mode. Specifically:
Josip Rodin wrote:
People should want to know as soon as possible if their configuration is
has syntax errors - it's likely that the same issue can have bad effects
on the functionality they want.
I agree. They should test their configuration before putting it
live into a production
On Sun, Dec 06, 2009 at 08:34:41PM +0100, Alan DeKok wrote:
Josip Rodin wrote:
People should want to know as soon as possible if their configuration is
has syntax errors - it's likely that the same issue can have bad effects
on the functionality they want.
I agree. They should test
Hi,
People whose servers do 1k operations/s are the ones who can be assumed to
be already prepared for the situation where the log volume increases by a
magnitude, for whatever reason.
err, no - the reason? most of our logging of RADIUS stuff does into
fast DBs - hosted elsewhere. therefore
On Sun, Dec 06, 2009 at 09:54:31PM +, Alan Buxey wrote:
Hi,
People whose servers do 1k operations/s are the ones who can be assumed to
be already prepared for the situation where the log volume increases by a
magnitude, for whatever reason.
err, no - the reason? most of our logging
On Wed, Nov 25, 2009 at 08:50:32AM +0100, Alan DeKok wrote:
I made my own instance of linelog and configured it just like the default,
i.e. it has:
format = ...
reference = %{%{Packet-Type}:-format}
That's used for logging per-packet information.
Accounting-Request
Hi,
I made my own instance of linelog and configured it just like the default,
i.e. it has:
format = ...
reference = %{%{Packet-Type}:-format}
Accounting-Request {
Start = ...
unknown = ...
}
However, I'm not getting the
Josip Rodin wrote:
Hi,
I made my own instance of linelog and configured it just like the default,
i.e. it has:
format = ...
reference = %{%{Packet-Type}:-format}
That's used for logging per-packet information.
Accounting-Request {
Start = ...
19 matches
Mail list logo
