Hello!
i have a problem with a long output too.
i run netstat -tupln and got trancated output.
and i dont know how to avoid this.
On 29.01.2016 11:52, ZaNN wrote:
> Hi again,
>
> Anyone is monitoring iptables output? Anyone has faced the problem of
> a long command output?
>
> Thanks in
Hi again,
Anyone is monitoring iptables output? Anyone has faced the problem of a
long command output?
Thanks in advance
El miércoles, 27 de enero de 2016, 9:26:48 (UTC+1), ZaNN escribió:
>
> Hola Daniel,
>
> Yes, that was my first try. Problem was that the result of an iptables
> command was
Would it really be difficult to actually show the error remote host ID in
the ossec.log? This would make identifying key mismatch so much easier.
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop
Well, why there is such low limit without #define INT_MAX_VALUE YY
Is should be like (Mail->maxperhour > INT_MAX_VALUE) ?
--
Eero
2016-01-28 16:22 GMT+02:00 :
> Hi,
>
> I found that limit and it's hardcoded at function Read_Global(), in
> src/config/global-config.c
>
> if
I added this limit early on to prevent a flood of emails in case of a
config mistake or an attack.
Plus, operationally speaking, I doubt any team can realistically handle and
investigate more than 10,000+ emails in an hour :)
thanks,
On Fri, Jan 29, 2016 at 1:16 PM, Eero Volotinen
Awesome :)
On Fri, Jan 29, 2016 at 3:06 PM, Luke Hansey
wrote:
> Works great now. Thank you for the work on this. No worries about the
> time. It's developmental :) Plus, I have a little firmer grasp on OSSEC
> now.
>
> On Thursday, January 28, 2016 at 4:58:11 PM
Well, how about still using some #define MAX_VALUE for that ?
2016-01-29 20:47 GMT+02:00 Daniel Cid :
> I added this limit early on to prevent a flood of emails in case of a
> config mistake or an attack.
>
> Plus, operationally speaking, I doubt any team can realistically
Works great now. Thank you for the work on this. No worries about the
time. It's developmental :) Plus, I have a little firmer grasp on OSSEC
now.
On Thursday, January 28, 2016 at 4:58:11 PM UTC-8, Daniel Cid wrote:
>
> The issue was in my branch there. Mind getting the latest again? Should