OK. I found it. The issue has to do with $filepattern variable.
The filenames look like this:
(myhost1.mydomain.com) 10.10.10.184->syscheck
And the regex fails to match the first part of the filename (i.e.
(myhost1.mydomain.com)) because it does not check for existance of the "."
in the first part of the filename.
So, I went ahead and changed:
$filepattern = "/^\(([a-zA-Z0-9_-]+)\) ".
"[0-9\._]+->([a-zA-Z_-]+)$/";
to:
$filepattern = "/^\(([a-zA-Z0-9\._-]+)\) ".
"[0-9\._]+->([a-zA-Z_-]+)$/";
Note the addition of "\." in the first line above. Now it does match a
filename when the filename has a "." in the first part.
--Mehregan
On 2/3/11 4:38 PM, "Mehregan Nejat" <[email protected]> wrote:
> Hi Dan,
>
> So, I did enable debug and checked the permission and all that but still
> nothing still shows up in the log. However, looking at the code, I think I
> found the problem. It seems to be a logical problem that's why no error gets
> logged.
>
> The problem seems to be in " os_lib_syscheck.php" in function
> os_syscheck_dumpdb. It can not map the agent_name to a filename except for
> when the server is agent_name = ossec-server then it sets the filename =
> syscheck.
>
> Here is the piece of code that I think is the culprit:
>
> /* Getting all agent files */
> @$dh = opendir($sk_dir);
> if($dh !== FALSE)
> {
> while(($file = readdir($dh)) !== false)
> {
> $_name = NULL;
>
> if($file[0] == '.')
> {
> continue;
> }
>
> $filepattern = "/^\(([a-zA-Z0-9_-]+)\) ".
> "[0-9\._]+->([a-zA-Z_-]+)$/";
> if(preg_match($filepattern, $file, $regs))
> {
> if($regs[2] == "syscheck-registry")
> {
> $_name = $regs[1]." Windows registry";
> }
> else
> {
> $_name = $regs[1];
> }
> }
> else
> {
> if($file == "syscheck")
> {
> $_name = "ossec-server";
> }
> else
> {
> continue;
> }
> }
>
> /* Looking for agent name */
> print ("file = $file -- _name = $_name -- agent_name =
> $agent_name <br>");
> if($_name != $agent_name)
> {
> continue;
> }
> $syscheck_list = __os_getdb($sk_dir."/".$file, $_name);
> closedir($dh);
> return($syscheck_list);
> }
>
>
>
> On 2/3/11 2:46 PM, "dan (ddp)" <[email protected]> wrote:
>
>> No logs makes tracking down issues with this junk much much harder.
>> Look in the other log file too. access_log or whatever it's called.
>>
>> Can the web application access the files?
>> Have you tried modifying the permissions of the files that don't work
>> to match the file that does?
>>
>> On Thu, Feb 3, 2011 at 5:29 PM, Nejat, Mehregan
>> <[email protected]> wrote:
>>> Nothing shows up in the error_log when I try the "Dump database" function.
>>>
>>> Here are apache and php versions I am running:
>>>
>>> php -version
>>> PHP 5.1.6 (cli) (built: Jan 15 2008 04:57:50)
>>> Copyright (c) 1997-2006 The PHP Group
>>> Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
>>>
>>> /usr/sbin/httpd -version
>>> Server version: Apache/2.2.3
>>> Server built: Jan 11 2008 08:20:08
>>>
>>>
>>>
>>> On 2/3/11 2:15 PM, "dan (ddp)" <[email protected]> wrote:
>>>
>>>> Are there any web logs that might indicate an error?
>>>>
>>>> On Thu, Feb 3, 2011 at 4:57 PM, Nejat, Mehregan
>>>> <[email protected]> wrote:
>>>>> Hi,
>>>>>
>>>>> I just installed OSSEC 2.5 and configured couple of remote hosts. But,
>>>>> when
>>>>> I
>>>>> use the WebUI->Integrity Checking->Dump database for a remote hosts,
>>>>> nothing
>>>>> is displayed.
>>>>> It does work fine when I choose the server itself.
>>>>>
>>>>> I have checked the databases under /var/ossec/queue/syscheck and the
>>>>> databases do exists for my remote hosts and they do contain all the
>>>>> checksum
>>>>> etc...
>>>>>
>>>>> My server is running on RHEL 5.2 2.6.18-92.el5 and the remote hosts are
>>>>> both
>>>>> running Gentoo 2.6.28-gentoo-r5.
>>>>>
>>>>> Here is the output of ³ls ltr /var/ossec/queue/syscheck/:
>>>>>
>>>>> -rw-r--r-- 1 ossec ossec 258945 Feb 3 11:26 (myhost1.mydomain.com)
>>>>> 10.10.10.184->syscheck
>>>>> -rwxr----- 1 ossec ossec 348618 Feb 3 11:29 syscheck
>>>>> -rw-r--r-- 1 ossec ossec 10394583 Feb 3 13:55 (myhost2.mydomain.com)
>>>>> 10.10.10.192->syscheck
>>>>>
>>>>>
>>>>> P.S. My remote hostnames and IP addresses above have been renamed for
>>>>> security reasons.
>>>>>
>>>>> --Mehregan
>>>>>
>>>
>>>
>
