getting centralized agent.conf working reliably

[x509v3]

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

[Jeremy Lee]

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).

[x509v3]

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.

[loyd.darby]

If the agent is running as user ossec...
ps -ef |grep agentd
ossec 15812 1 0 Nov17 ? 00:01:00 /var/ossec/bin/ossec-agentd

then the file must be owned by ossec before it can be updated...
ls -l /var/ossec/etc/shared/agent.conf
-rw-r--r-- 1 ossec ossec 146 2010-11-18 11:03
/var/ossec/etc/shared/agent.conf

--
R. Loyd Darby, OSSIM-OCSE
Project Manager DOC/NOAA/NMFS
Infrastructure coordinator
Southeast Fisheries Science Center
305-361-4297

[Jeremy Lee]

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?

[dan (ddp)]

Double check your permissions. I don't have access to a setup at the
moment to provide working permissions unfortunately....

Does merged.mg match on both systems?

Is there other "junk" in your /var/ossec/etc/shared directory?
Everything in that directory should get copied across, and directories
seem to cause issues (regular and hidden .directories).

Run the processes in debug mode, I remember seeing a debug message
about requesting a new agent.conf or something.

[x509v3]

I had double-checked the file permissions, the agent's agent.conf was
owned by root -- which didn't match the process owner. Fixing that
didn't resolve the problem, and there was never any errors logs on the
agent. Even running the agent in full debug mode proved unhelpful.
(the problem was be further upstream)

I then noticed that the server's /var/ossec/etc/shared/agent.conf was
also owned by root (perms 540) and the server logs indicated a
problem:
2010/11/22 06:31:25 ossec-remoted: Error accessing file '/etc/shared/
agent.conf'

[root@host etc]# ps -ef | grep remoted
ossecr 11141 1 0 Nov19 ? 00:00:11 /var/ossec/bin/ossec-
remoted

ah ha...the user "ossecr" can't read the agent.conf. The file was
owned by root, without world read access. I was so focused on the
agent's settings, I forgot to carefully examine the permissions and
ownership of the server. :(

Solution: make sure that the server's agent.conf file is properly
owned by the process running ossec-remoted.