Thanks, CNK.

Another strategy we have discovered is to shutdown the agent and
backup the /var/ossec/etc and /var/ossec/queue/rids directories in
that order.  Then after the OS has been reinstalled on the agent's
host and the agent is reinstalled, restore the etc and rids
directories.  Of course this works fine only if the agent's host can
be brought down in a controlled fashion.  If, for example, the hard
disk crashed, then the only other alternative is to do what you
suggested.

Cheers!

On Jun 28, 5:02 pm, cnk <[email protected]> wrote:
> Hey Trevor,
>
> I just had the same issue and resolved it with these steps:
>
> -stop the agent and delete all files in the rids directory on that agent
> -delete the file associated with that agent ID in the rids directory
> on the server
>
> cheers,
>
> cnk
>
>
>
> On Thu, Jun 25, 2009 at 12:20 PM, tm<[email protected]> wrote:
>
> > Hello,
>
> > We are currently running an OSSEC pilot in a department at a
> > university .  Our environment consists of Mac, RHE, Solaris, SuSE and
> > Windows hosts.
>
> > The biggest issue we face in using OSSEC is reinstalling agents
> > because their hosts have had to have their operating systems
> > reinstalled.  This happens frequently in our environment.  Whenever we
> > try to reinstall the OSSEC agent, getting it to communicate with the
> > server using the same key has been problematic.
>
> > We have learned how to set up the agent's client.keys file using the
> > entry in the server's client.keys file.  However, we are unsure of how
> > to reinitialize the counters for that agent in the agent's /var/ossec/
> > queue/rids directory and the server's /var/ossec/queue/rids directory.
>
> > Because of the sheer number of potential agents in our environment we
> > don't want to use manage_agents to remove agents and recreate them in
> > coordination with the reinstallation of the OS on the agent.  This
> > results in a new ID and a new key.  We would rather use the same ID
> > and key for the agent once the OS has been reinstalled on the agent.
> > Also, using manage_agents is difficult to use in an environment where
> > we currently automate the reinstallation of the OS on the host.  We'd
> > like to include the agent reinstallation as part of the automation
> > process.
>
> > Can anyone explain how the counters work in the /var/ossec/queue/rids
> > directory on both the server and agent?  A counter seems to be of the
> > format x:y: where x is something called the global counter and y is
> > something called the local counter (according to the source code).  If
> > we reinstall an OSSEC agent, push out the key from the server's
> > client.keys file, what do we do with the counters in the /var/ossec/
> > queue/rids directory on the server and agent in order to allow them to
> > communicate again?
>
> > Cheers!
> > Trevor- Hide quoted text -
>
> - Show quoted text -

Reply via email to