-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lan-inet nolog settings #16
Comments
Hi Arno, Can you be more specific... We have global logging variables as follows:
what specific rule can't we control logging ? |
FORWARD_DROP_LOG is too general. Like with the INET stuff we should have _NOLOG variables for LAN->INET stuff as well. |
So you are proposing new rules something like ?
Personally, on production systems I run with most all logging disabled, then when looking for something I temporarily enable the related logging and 'grep' for what I'm looking for. With that in mind adding selective 'on' logging rules like:
would allow selective logging to occur while the global logging is disabled. This approach would be much more straightforward to implement as well. Possibly an example where _NOLOG is particularly useful ? |
Well it's legacy and since we already use it in other places, might as well stick to it. I don't see any particular advantage/disadvantage of either implementation except for consistency (+legacy). |
Well, you added _NOLOG a few years ago :-) I think (for this topic) it is worth thinking how it would be used and whether _NOLOG or _LOG logic is the most convenient to users. I hope we both agree that we need to keep the LAN_OUTPUT_DENY_LOG, etc. global variables working as they are today. If so, that makes _NOLOG more troublesome to implement. |
Thinking about this more... Arno, back when you started this wonderful project, most every packet was interesting and the default was to log all blocked packets. As such if logs were coming from the same host and were annoying to see, you could disable them with _NOLOG, fine. Fast forward to today, I would suggest the exact opposite is the case... most every blocked packet is not interesting and they come at such a rate many users disable logging where possible. Only in special cases would a log be useful, and the logic of _LOG would be the more natural rule to use. |
A drawback is that it would break backwards compatibility. Not sure what approach feels more "natural" anyway, need to think about it. |
We could have a mix of _NOLOG (original) and _LOG (new stuff) without breaking backwards compatibility. |
lan-inet rules should have nolog settings for reject/deny
The text was updated successfully, but these errors were encountered: