Hi Michael, We fixed that in the code on the latest snapshot:
http://ossec.net/files/snapshots/ossec-hids-090626.tar.gz The idea for this restriction was to prevent the user from killing himself, but since the internal_options.conf file already has a warning, we will let the user decide :) Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Tue, Jun 23, 2009 at 2:16 PM, Michael Altfield<[email protected]> wrote: > > 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 >
