Ahh missed that. Forgot that it also tells you the status, etc.

I dunno then - if it's connected and agent_control results in a restart,
then maybe something with the agent.conf syntax is off? Try turning debug on
maybe and look at the ossec.log?

On Fri, Nov 19, 2010 at 10:19 AM, x509v3 <[email protected]> wrote:

> You mean besides the successful "agent_control -i 001" summary I
> included in my original post? ;)
>
> Seriously though, I ran tcpdump on the agent and verified that there
> is bi-directional traffic on port 1514/udp when I run agent_control -R
> 001.  I also verified that the server is restarting the agent by
> watching the agent's logs when doing the same.
>
> It's a mystery.
>
> On Nov 19, 10:00 am, Jeremy Lee <[email protected]> wrote:
> > Have you made sure that the agent is definitely connected to the server
> and
> > that there are no communication issues between the two (check with
> > agent_control -l)? Off the top of my head that would be the primary
> thing...
> > if they are communicating properly, after restarting both the server and
> > agent(s), you should see the new agent.conf within a matter of minutes
> (in
> > most circumstances).
> >
> > On Fri, Nov 19, 2010 at 9:04 AM, x509v3 <[email protected]> wrote:
> > > I'm really enjoying ossec, but one of the areas that consistently
> > > confounds me is getting a reliable centralized config working.
> >
> > > The goal is to have as minimal-as-possible ossec.conf on each agent,
> > > and drive all configs from the ossec master's agent.conf.  I've
> > > purchased and read the book, followed the many excellent blogs and doc
> > > pages, but I'm still seeing the following:
> >
> > > The agent is happily communicating with the server, using an
> > > agent.conf-powered configuration. But I cannot get the agent to update
> > > its agent.conf (or have the server push an updated one to the agent).
> >
> > > I suspect there's some sort of cache issue or update mechanism that's
> > > getting bad data and isn't getting the hint to update itself.  Would
> > > love to hear if there are any other "tricks" to force an agent to grab
> > > a new config. I'd like to avoid manually updating 100+ agents each
> > > change.
> >
> > > Anyone know how the agent (or server) determines when the agent's out
> > > of sync and needs a new update?
> >
> > > In the example below, note that the md5sums do not match. I restarted
> > > both the server and the agent over 8 hours ago, but they're still out
> > > of sync.
> >
> > > On the server:
> > >  ls -al ../etc/shared/agent.conf
> > > -r--r----- 1 root root 1532 Nov 18 21:50 ../etc/shared/agent.conf
> >
> > > md5sum ../etc/shared/agent.conf
> > > 8992ebf09a31a8344a9f06180e490fce  ../etc/shared/agent.conf
> >
> > > ./agent_control -i 001
> > > OSSEC HIDS agent_control. Agent information:
> > >   Agent ID:   001
> > >   Agent Name: test200
> > >   IP address: 10.1.2.89
> > >   Status:     Active
> >
> > >   Operating system:    Linux test200 2.6.18-128.el5 #1 SMP Wed Dec 17
> > > 11..
> > >   Client version:      OSSEC HIDS v2.5.1 /
> > > b488aae0f9ebf2b96b270b903483b790
> > >   Last keep alive:     Fri Nov 19 08:45:02 2010
> >
> > >   Syscheck last started  at: Fri Nov 19 01:02:19 2010
> > >   Rootcheck last started at: Fri Nov 19 02:08:37 2010
> >
> > > On the agent:
> > > ls -al agent.conf
> > > -rw-r--r-- 1 root root 1641 Nov 18 21:35 agent.conf
> > >  md5sum agent.conf
> > > b488aae0f9ebf2b96b270b903483b790  agent.conf
>

Reply via email to