Letting you know that I moved the ar.conf file out of the shared directory of the mercury OSSEC agent host, and the listing below shows what I got for the shared directory:
[r...@mercury shared]# ls -l total 176 -rwxrwx--- 1 root ossec 3764 Aug 27 14:00 agent.conf -rwxrwx--- 1 root ossec 9487 Aug 27 14:00 cis_debian_linux_rcl.txt -rwxrwx--- 1 root ossec 8184 Aug 27 14:00 cis_rhel5_linux_rcl.txt -rwxrwx--- 1 root ossec 14241 Aug 27 14:00 cis_rhel_linux_rcl.txt -rw-r--r-- 1 ossec ossec 77829 Aug 27 14:00 merged.mg -rwxrwx--- 1 root ossec 14925 Aug 27 14:00 rootkit_files.txt -rwxrwx--- 1 root ossec 5307 Jun 3 2009 rootkit_trojans.txt -rwxrwx--- 1 root ossec 0 Sep 2 2009 -svn -rwxrwx--- 1 root ossec 7975 Aug 27 14:00 system_audit_rcl.txt -rwxrwx--- 1 root ossec 4676 Aug 27 14:00 win_applications_rcl.txt -rwxrwx--- 1 root ossec 3853 Aug 27 14:00 win_audit_rcl.txt -rwxrwx--- 1 root ossec 4923 Aug 27 14:00 win_malware_rcl.txt Note that the file ar.conf is completely missing. Frustratingly enough, the contents of merged.mg show the contents (current and correct) of the ar.conf file on the OSSEC server host: !203 ar.conf restart-ossec0 - restart-ossec.sh - 0 restart-ossec0 - restart-ossec.cmd - 0 firewall-drop600 - firewall-drop.sh - 600 firewall-drop3600 - firewall-drop.sh - 3600 win_nullroute600 - route-null.cmd - 600 On Aug 27, 1:51 pm, "dan (ddp)" <ddp...@gmail.com> wrote: > On Fri, Aug 27, 2010 at 1:37 PM, blacklight <vphu...@yahoo.com> wrote: > >> So, your answer is "no." > > > The answer is "no", and only for that reason. > > >> You should also try deleting or emptying the agent.conf file. See if that > >> helps > > > That could be murderous - My OSSEC server is working with a hundred > > OSSEC agent hosts. Should I delete or empty 100 agent.conf files on > > the OSSEC agent side? The other aspect is that the agent.conf was > > properly replicated in each case. > > I meant the ar.conf file on an agent NOT the agent.conf, sorry about > my confusion. > > > > > > > As an aside, the listing below shows the contents of mercury's /var/ > > ossec/etc/shared directory right now: > > > [r...@krusty shared]# ls -l > > total 176 > > -rw-r--r-- 1 ossec ossec 3764 Aug 25 11:22 agent.conf > > -rw-r--r-- 1 ossec ossec 111 Jul 16 2009 ar.conf > > -rwxrwx--- 1 root ossec 9487 Aug 25 11:22 cis_debian_linux_rcl.txt > > -rwxrwx--- 1 root ossec 8184 Aug 25 11:22 cis_rhel5_linux_rcl.txt > > -rwxrwx--- 1 root ossec 14241 Aug 25 11:22 cis_rhel_linux_rcl.txt > > -rw-r--r-- 1 ossec ossec 77824 Aug 27 13:12 merged.mg > > -rwxrwx--- 1 root ossec 14925 Aug 25 11:22 rootkit_files.txt > > -rwxrwx--- 1 root ossec 5307 Jun 3 2009 rootkit_trojans.txt > > -rwxrwx--- 1 root ossec 7975 Aug 25 11:22 system_audit_rcl.txt > > -rwxrwx--- 1 root ossec 4676 Aug 25 11:22 win_applications_rcl.txt > > -rwxrwx--- 1 root ossec 3853 Aug 25 11:22 win_audit_rcl.txt > > -rwxrwx--- 1 root ossec 4923 Aug 25 11:22 win_malware_rcl.txt > > > Note that the contents of "merged.mg" have yet to be transferred over > > to the respective files in the shared directory. > > >> I'm not seeing that behavior on my installation. My > >> ossec/etc/shared/.test directory is not transferred as a directory, > >> but the name is not changed (it shows up as an empty file with the > >> exact same name on the agents). It sounds like a limitation in the way > >> the files are transferred. > > > Anything I can do about this limitation? In fact, I don't mind it as > > long at it does not interfere with the contents of "merged.mg" being > > properly transferred to the corresponding files in the shared > > directory, resulting in the files being properly updated. > > Unfortunately, it seems to be interfering, at least in my case. Is > > your .test hidden directory interfering with all of your files being > > properly updated? > > Testing this now. But remember, I'm using a recent version of OSSEC. > > > > > My question at this point, is where do I go from here? If you want me > > to try deleting agent.conf from one of the OSSEC agent hosts and > > restart the OSSEC server, I'll try that. But I don't seem to be > > getting any closer at this point to understanding why ar.conf is not > > being replicated and what I can do about it. > > Try deleting the old ar.conf file on one of the agents. See if it gets > rebuilt at some point with more up to date information.
