Hey, This is expected to take a while. The agent_control -R only restarts the agent, but do not push the new configuration there. OSSEC pushes the files slowly and only when it has idle cycles to avoid blocking important events...
Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Fri, Jul 31, 2009 at 11:41 AM, doublejz<[email protected]> wrote: > > I take that back. After about 30 mins after doing a /var/ossec/bin/ > agent_control -R 009 the agent.conf was applied to the host. > > On Jul 30, 3:57 pm, Daniel Cid <[email protected]> wrote: >> Hi Danny, >> >> Can you try installing the latest snapshot of the Windows agent? >> >> http://ossec.net/files/snapshots/ossec-win32-090730.exe >> >> I made some fixes to the way we handle the Windows sockets that will >> probably solve this issue. >> What was happening is that the merged files (with all the shared >> configurations) were never >> arriving properly on the Windows agents. >> >> Thanks, >> >> -- >> Daniel B. Cid >> dcid ( at ) ossec.net >> >> On Thu, Jul 30, 2009 at 3:10 PM, Danny Fullerton<[email protected]> >> wrote: >> >> > Hello guys, >> >> > I've been trying to deploy a centralized config but ran into some problems. >> >> > I followed "http://www.ossec.net/main/manual/centralized-config/"; and >> > created the /var/ossec/etc/shared/agent.conf file but only one of my >> > servers is actually presenting the agent.conf hash that is used to >> > confirm it is using the centralized configuration: >> >> > Client version: OSSEC HIDS v2.1 / 8688892c3e847ef52c1eb393c6e3f437 >> >> > Every other clients show this info: >> >> > Client version: OSSEC HIDS v2.1 >> >> > Is there a way to push the agent config? "agent_control -R", "restarting >> > the agent and windows service", "restarting ossecd", "restarting the >> > server", "reinstalling the agent and "creating a new client entry" does >> > not work. >> >> > thanks, >> >> > -- >> > Danny Fullerton, GCIH GHTQ >> > Mantor Organization >
