Fantastic - thanks so much! I might be interested, but it's not safe
for me to commit to anything lately. :)

On May 17, 1:36 pm, Daniel Cid <[email protected]> wrote:
> Yes, just go to src/rootcheck/run_rk_check.c and comment the line that says:
>
> check_rc_ports();
>
> In fact, to disable any of the checks (do the same for those calls):
>
>     check_rc_dev(rootcheck.basedir);
>     check_rc_sys(rootcheck.basedir);
>     check_rc_pids();
>     check_rc_ports();
>     check_open_ports();
>     check_rc_if();
>
> Btw, anyone interested in doing a config check for each of those
> functions? So we can disable/enable them via ossec.conf? Good way
> to get started coding on ossec :)
>
> Thanks,
>
>
>
> On Tue, May 17, 2011 at 4:13 PM, dan (ddp) <[email protected]> wrote:
> > There's no switch, you'll have to edit the source.
>
> > On Tue, May 17, 2011 at 2:44 PM, Jen H <[email protected]> wrote:
> >> Bumping this - anyone know how to disable netstat tasks in syscheckd/
> >> rootcheck without disabling syscheckd or rootchecking completely? It's
> >> consuming too much CPU, but I don't want to disable checks completely.
>
> >> Thanks in advance.
>
> >> On May 14, 11:14 am, Jen H <[email protected]> wrote:
> >>> I've got a couple of servers that handle 500k concurrent connections
> >>> at any given time - I still want to be able to run syscheckd and
> >>> rootcheck, but as you can guess, syscheck's netstat commands make the
> >>> systems whine a lot, our load average charts are fun to look at...and
> >>> netstat is pretty useless at that point anyway. Any way to disable
> >>> these?
>
> >>> If it's a change I need to make in source that's fine as I build on-
> >>> the-fly at deploy time, just would like to know the best way of doing
> >>> it without turning off syscheck entirely...or breaking things - like,
> >>> I'm pretty sure if I go in and comment out run_netstat in
> >>> check_rc_ports.c, I will cause some havoc, so appreciate any guidance
> >>> you guys might have on a simpler way of doing this. ;)
>
> >>> Thanks a bunch in advance!
>
> >>> - Jen

Reply via email to