On Thursday, 19 February 2015 12:15:31 UTC, dan (ddpbsd) wrote: > > On Thu, Feb 19, 2015 at 3:14 AM, CraigL <[email protected] <javascript:>> > wrote: > > Further update, while I haven't seen the usual "File not available > error" no > > logs have been sent to the central server since after midnight which > leads > > me to believe that some part of the logrotate process or this patch for > > alerts.log may not be quite there. > > > > Alerts were being sent successfully before midnight though? >
Yep, last log generated and received was 23:56, then nothing until I restarted the agent this morning. > > > Is there any diagnostics info I can provide to help fault find this > issue? > > > > Just keep looking through the source trying to find the issue. > Not my forte I'll admit, but I guess there is always a first time for everything to try and learn! > > > Thanks, > > > > Craig > > > > > > On Wednesday, 18 February 2015 21:48:06 UTC, CraigL wrote: > >> > >> Applied the patch, upgraded the install on the hybrid box and it is > >> behaving well so far, certainly the longest it has done all day, most > of the > >> time it would have crashed within minutes, 10 - 20 minutes maximum. > >> > >> C > >> > >> > >> On Wednesday, 18 February 2015 20:19:46 UTC, CraigL wrote: > >>> > >>> I have seen this issue today while testing a tiered infrastructure on > >>> 2.8.1, will upgrading the existing installation apply the patch or > will I > >>> need to reinstall? > >>> > >>> Thanks, > >>> > >>> Craig > >>> > >>> > >>> On Thursday, 12 February 2015 12:56:01 UTC, dan (ddpbsd) wrote: > >>>> > >>>> On Thu, Feb 5, 2015 at 7:49 AM, dan (ddp) <[email protected]> wrote: > >>>> > On Wed, Feb 4, 2015 at 11:29 PM, John Luko <[email protected]> > wrote: > >>>> >> Ok. I did a local setup and after sometime I was finally able to > >>>> >> recreate > >>>> >> the issue. Setup was as follows: > >>>> >> > >>>> >> server1 (server mode) --> server 2 (hybrid mode) ---> computer1 > >>>> >> (agent only) > >>>> >> > >>>> >> I made a series of changes to files on computer1 and it reported > >>>> >> those > >>>> >> changes to server 2, which were reflected on server 1 (it did not > >>>> >> show what > >>>> >> the hashes were). I changed the file a bunch of times for a few > >>>> >> minutes and > >>>> >> everything was reporting just fine. It wasn't until I performed > >>>> >> several > >>>> >> sudo -i commands on server2 that it reported the following: > >>>> >> > >>>> >> 2015/02/04 23:16:58 ossec-logcollector(1904): INFO: File not > >>>> >> available, > >>>> >> ignoring it: '/var/ossec/logs/alerts/alerts.log'. > >>>> >> > >>>> >> It stayed connected for almost 20 minutes before the above > happened, > >>>> >> but in > >>>> >> production environments I am getting around 4 minutes before it > >>>> >> starts > >>>> >> ignoring that alerts.log. > >>>> >> > >>>> >> 2015/02/04 22:53:21 ossec-agentd(4102): INFO: Connected to the > server > >>>> >> (192.168.1.2:1514) > >>>> >> > >>>> >> So, at least for now, it appears that it is related to the sudo > >>>> >> commands > >>>> >> being run. Anything else I can provide to help with > troubleshooting? > >>>> >> Also, > >>>> >> is it possible for the hashes to be sent as well? > >>>> >> > >>>> > > >>>> > I've setup test environments, I need help tracking down the bug in > the > >>>> > code. > >>>> > > >>>> > >>>> I have a potential fix here: > >>>> https://github.com/ossec/ossec-hids/issues/442 > >>>> It needs some pretty heavy testing though. > > > > -- > > > > --- > > You received this message because you are subscribed to the Google > Groups > > "ossec-list" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
