I checked yesterday on Tuesday and everything is peachy, just as I
expected. Issue resolved.
On Sep 4, 1:00 am, blacklight wrote:
> Letting you know that updaing the version of the Windows OSSEC agent
> did result in the immediate upodating of the contents of the shared
> directory, so long as th
Letting you know that updaing the version of the Windows OSSEC agent
did result in the immediate upodating of the contents of the shared
directory, so long as the "merged.mg" file is there. For those OSSEC
agent hosts where the "merged.mg" file is not there, I'll check on
Tuesday whether the "merge
On 09/02/2010 07:48 PM, blacklight wrote:
That's a start. I am also looking for who else has permissions to the
shared directory of your agent host aside from the Administrator. The
agents on the Windows hosts range from 2.1t o 2.4.1 - I should
probably go through each Windows host, document what
That's a start. I am also looking for who else has permissions to the
shared directory of your agent host aside from the Administrator. The
agents on the Windows hosts range from 2.1t o 2.4.1 - I should
probably go through each Windows host, document what version it is
running and whther the files
On Thu, Sep 2, 2010 at 3:14 PM, blacklight wrote:
> For a start, are contents of the shared directory on your OSSEC server
> being fully replicated to the contents of the shared directory of your
> Windows agents?
>
>
The agent.conf is, I don't have the permissions to check the rest
right now and
For a start, are contents of the shared directory on your OSSEC server
being fully replicated to the contents of the shared directory of your
Windows agents?
On Sep 2, 2:35 pm, "dan (ddp)" wrote:
> On Thu, Sep 2, 2010 at 12:37 PM, blacklight wrote:
> > You will pleased to know that when I upgra
On Thu, Sep 2, 2010 at 12:37 PM, blacklight wrote:
> You will pleased to know that when I upgraded the server from 2.1 to
> 2.4.1 (the latest version) as 6:30 PM last night, both the ar.conf and
> agent.conf files got automatically updated overnight in the 25% of
> Linux hosts that were previously
You will pleased to know that when I upgraded the server from 2.1 to
2.4.1 (the latest version) as 6:30 PM last night, both the ar.conf and
agent.conf files got automatically updated overnight in the 25% of
Linux hosts that were previously resistant to these two files being
updated. At this point,
On Tue, Aug 31, 2010 at 3:43 PM, blacklight wrote:
> FYI, here is a typical listing on one of the agents showing a failure
> to update:
>
> [r...@he4 shared]# ls -l
> total 176
> -rwxrwx--- 1 root ossec 3303 Jan 11 2010 agent.conf
> -rwxrwx--- 1 root ossec 193 Jan 11 2010 ar.conf
> -rwxrwx-
FYI, here is a typical listing on one of the agents showing a failure
to update:
[r...@he4 shared]# ls -l
total 176
-rwxrwx--- 1 root ossec 3303 Jan 11 2010 agent.conf
-rwxrwx--- 1 root ossec 193 Jan 11 2010 ar.conf
-rwxrwx--- 1 root ossec 9487 Aug 30 12:03 cis_debian_linux_rcl.txt
-rwxrw
Letting you know that I followed your advice and removed the .svn
directory yesterday - I also followed your other advice and created a
bug report and posted it at http://ossec.uservoice.com
Linux machines: In 75% of the cases, the agents update the local
ar.conf file from the merged.mg file as ex
On Mon, Aug 30, 2010 at 10:04 AM, blacklight wrote:
> I just sent you in a zipped file a copy of the shared directory of our
> OSSEC server, which includes all the contents of said directory
> including the hidden .svn file.
>
> It hope that this makes it easier for you to reproduce our problem.
>
Testing a few things now.
On Mon, Aug 30, 2010 at 10:04 AM, blacklight wrote:
> I just sent you in a zipped file a copy of the shared directory of our
> OSSEC server, which includes all the contents of said directory
> including the hidden .svn file.
>
> It hope that this makes it easier for you
I just sent you in a zipped file a copy of the shared directory of our
OSSEC server, which includes all the contents of said directory
including the hidden .svn file.
It hope that this makes it easier for you to reproduce our problem.
On Aug 28, 8:10 am, blacklight wrote:
> Another alternative
> I ended up with the original merged.mg file in its place.
It looks like the system received the merged.mg file that was on your
server instead and overwrote the merged.mg file on the OSSEC agent
host. And quickly, too- "Quickly" is not what's happening on my OSSEC
agent host,by the way.
> Anywa
Another alternative I just thought up is for you to recreate the files
in the shared directory of the OSSEC server based on the contents of
the merged file and restart the OSSEC server - Recreating these files
manually should not take longer than 15 minutes. However, this
procedure does not take in
Got it. I don't think it's going to do much. I tried putting it on an
agent and restarting ossec. I ended up with the original merged.mg
file in its place.
I even emptied all of the files except the merged.mg file and
restarted the agent, only to find all of the files back in place. Not
sure why it
Cool. To what mailing address should I send the merged.mg file?
On Aug 27, 4:37 pm, "dan (ddp)" wrote:
> Send it, I'll give it a shot later. Probably tonight.
>
>
>
> On Fri, Aug 27, 2010 at 4:24 PM, blacklight wrote:
> > It does seem to take for ever for the update to take place. I really
> >
Send it, I'll give it a shot later. Probably tonight.
On Fri, Aug 27, 2010 at 4:24 PM, blacklight wrote:
> It does seem to take for ever for the update to take place. I really
> would like to send you my merged.mg file for you to test.
>
>
> On Aug 27, 3:46 pm, blacklight wrote:
>> I restarted t
It does seem to take for ever for the update to take place. I really
would like to send you my merged.mg file for you to test.
On Aug 27, 3:46 pm, blacklight wrote:
> I restarted the OSSEC server and the OSSEC agent 45 min ago.
>
> Here is the current listing for the shared directory on the OSSE
I restarted the OSSEC server and the OSSEC agent 45 min ago.
Here is the current listing for the shared directory on the OSSEC
server:
[r...@wiggum shared]# ls -l
total 180
-r--r- 1 root ossec 3764 Apr 7 16:51 agent.conf
-r--r--r-- 1 root ossec 203 Aug 27 15:04 ar.conf
-r--r- 1 ro
Give it a shot. I don't think it'll hurt anything.
On Fri, Aug 27, 2010 at 2:56 PM, blacklight wrote:
> My ar.conf file has yet to appear after close to one hour. Do you want
> me to try with your method below?
>
>
> On Aug 27, 2:49 pm, "dan (ddp)" wrote:
>> I tried doing this and getting the fi
My ar.conf file has yet to appear after close to one hour. Do you want
me to try with your method below?
On Aug 27, 2:49 pm, "dan (ddp)" wrote:
> I tried doing this and getting the file back took a bit. I ended up
> creating a blank ar.conf (with correct permissions), restarting the
> server and
I tried doing this and getting the file back took a bit. I ended up
creating a blank ar.conf (with correct permissions), restarting the
server and the agent. It eventually came back. Not sure if all of that
was necessary, I just didn't feel like waiting.
On Fri, Aug 27, 2010 at 2:15 PM, blacklight
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
This seems to indicate that the culprit could be the version ID of the
OSSEC server: you are running 2.4 on the server and you don't have a
problem. I run 2.1 on the server and I do.
One test I am interested in running is mailing you my copy of the
merge.mg file, and having your system unwrap it o
On Fri, Aug 27, 2010 at 1:37 PM, blacklight wrote:
> 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
On Fri, Aug 27, 2010 at 1:37 PM, blacklight 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
> 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
th
On Fri, Aug 27, 2010 at 11:59 AM, blacklight wrote:
>> Are any of the agents getting updated properly?
>
> agent.conf and almost all the files in the agent directory are
> successfully replicated. Restarting the agent forces the agent to
> reread the config files in the shared directory, and this
> Are any of the agents getting updated properly?
agent.conf and almost all the files in the agent directory are
successfully replicated. Restarting the agent forces the agent to
reread the config files in the shared directory, and this is what I
have when I restarted the agent. The rub is that th
On Fri, Aug 27, 2010 at 10:24 AM, blacklight wrote:
> Will updating the OSSEC server to 2.4 solve anything? Yes, the server
> is on 2.1 right now but I am experiencing the issue even when the
> agent is on 2.1
>
>
It's hard to tell if it will actually fix that problem or not. It's
just not recomm
Will updating the OSSEC server to 2.4 solve anything? Yes, the server
is on 2.1 right now but I am experiencing the issue even when the
agent is on 2.1
On Aug 27, 10:05 am, "dan (ddp)" wrote:
> Is there any chance you can update your OSSEC server to something
> recent? The server should be the l
33 matches
Mail list logo
