Thank you! At the default settings (syscheck.sleep=2 and syscheck.sleep_after=15), it took about 50 minutes to complete a syscheck of about 6500 files. When I changed the source, recompiled, and changed syscheck.sleep=2 to syscheck.sleep=0, I was able to drop this time down to under 10 minutes!
Is there any way I can request that this source change is made in the official release? I see no reason why OSSEC shouldn't at least *support* running syscheck without sleeping after calculating X number of file checksums... Thanks again, Michael On Jun 16, 3:11 pm, cnk <[email protected]> wrote: > You could most likely increase the limit of 128 on sleep_after by > modifying the src. A quick search and you'll find the following in > these 2 files: > > syscheckd/syscheck-baseline.c > syscheckd/syscheck.c > > { > syscheck.tsleep = getDefine_Int("syscheck","sleep",1,64); > syscheck.sleep_after = getDefine_Int("syscheck","sleep_after",1,128); > } > > If you comb through it some more I think you'll also find some process > priority code which you could also modify. Obviously in *most* cases > we don't want syscheck to interfere with system operation hence the > current restrictions in place. Once again YMMV and proceed with > caution. > > cheers, > > cnk > > On Tue, Jun 16, 2009 at 11:57 AM, Michael Altfield<[email protected]> > wrote: > > >> Just remember that this could have a [significant] performance impact > >> on the system. > > > I'm aware of the impact. I'll be forcing the syscheck when I have > > taken the machine out of production for maintenance--hence, it will > > need to be finished as quickly as possible so that it can be put back > > into production as quickly as possible. This also means that nothing > > will be running on the machine when the sycheck is forced, so there is > > no reason to reduce the process' priority. > > >> To decrease the amount of time a scan takes you could look at changing > >> the following parameters in internal_options.conf (on the agent): > > >> syscheck.sleep=2 > >> syscheck.sleep_after=15 > > > I've already tried tuning these values, but they have limits. It > > appears that syscheck.sleep_after has a maximum value of 128, and > > syscheck.sleep has a minimum value of 1. > > > Is there any better way to do this so that I can *truly* execute the > > syscheck without any limitations? > > > Thanks, > > Michael > > > On Tue, Jun 16, 2009 at 7:19 AM, cnk<[email protected]> wrote: > > >> Hey Michael, > > >> You can manually force a syscheck from the ossec server with the > >> following command: > > >> # /var/ossec/bin/agent_control -r -u <agent_id> > > >> To decrease the amount of time a scan takes you could look at changing > >> the following parameters in internal_options.conf (on the agent): > > >> syscheck.sleep=2 > >> syscheck.sleep_after=15 > > >> Just remember that this could have a [significant] performance impact > >> on the system. > > >> For more information check out these links: > > >>http://www.ossec.net/main/manual/manual-syscheck/ > >>http://www.ossec.net/main/manual/manual-agent_control-tool/ > >>http://www.ossec.net/wiki/index.php/Know_How:Syscheck_Perf > > >> cheers, > > >> cnk > > >> On Mon, Jun 15, 2009 at 6:25 PM, Michael Altfield<[email protected]> > >> wrote: > > >>> Hello ossec gurus, > > >>> I was wondering if it is possible to force the execution of a > >>> full-capacity re-scan of the files' checksum DB. > > >>> Basically, when preforming system maintenance on a per-server basis, > >>> I'd like to be able to: > >>> 1) turn off ossec and disable alerting for this box in ossec.conf > >>> 2) update the box with our current application version (modifying > >>> monitored files and, thus, altering their checksums) > >>> 3) issue a fast-as-possible rescan of the files on the server > >>> (generate checksums of the new files), and > >>> 4) restart ossec with alerting re-enabled > > >>> Ideally, the only alerts that I will receive after this process are: > >>> "ossec agent disconnected" and "ossec agent connected" > > >>> The problem with this is: normally, ossec-syscheckd would be niced > >>> *way* down so that #3 above would take an unreasonably high amount of > >>> time. Is there a way to make it a #1 priority? > > >>> Cheers, > >>> Michael Altfield
