This is this the kind of thing that is likely better (easily)
implemented outside of the main
ossec managers. Maybe an external tool or cron.
I use the following shell script for example (added to cron to run
every 10min to restart ossec in case the IP changes):
#!/bin/sh
mydomain=`cat
Another question: My original scenario was when there was NO dns yet to
resolve -- only later did the dns record get added. In that case. What I
was seeing in that case was the agent would keep issue the error that it
could not connect. But if the agent was not even able to resolve to an ip
Is it expensive to restart an agent? For my case (the OP) I can use
consul-template to watch for the when the ossec-remoted's IP has changed
and rewrite the IP in the config file then restart the agent. Would the
reconnects to the server need to spread out or can it handle the thundering
herd
On Fri, 26 Feb 2016, dan (ddp) wrote:
IIRC, there was some talk previously about adding a dns daemon that
could be queried from inside the chroot.
I can't remember exactly what I had found, but it related to libasr
(https://github.com/OpenSMTPD/libasr). Maybe a dnsd of some sort built
into
On Fri, Feb 26, 2016 at 12:59 PM, Antonio Querubin wrote:
> On Fri, 26 Feb 2016, dan (ddp) wrote:
>
>> IIRC, there was some talk previously about adding a dns daemon that
>> could be queried from inside the chroot.
>> I can't remember exactly what I had found, but it related
On Fri, 26 Feb 2016, dan (ddp) wrote:
IIRC, there was some talk previously about adding a dns daemon that
could be queried from inside the chroot.
I can't remember exactly what I had found, but it related to libasr
(https://github.com/OpenSMTPD/libasr). Maybe a dnsd of some sort built
into
On Fri, Feb 26, 2016 at 12:39 PM, Antonio Querubin wrote:
> On Fri, 26 Feb 2016, Pedro S wrote:
>
>> The proxy server will be a good external solution of course,
>>
>> About OSSEC, maybe we need something like "reload", NOT restart, reload
>> could allow OSSEC to read again
The proxy server will be a good external solution of course,
About OSSEC, maybe we need something like "reload", NOT restart, reload
could allow OSSEC to read again all the configuration files and refresh
internal structures, sure it won't be easy but.. just thinking.
On Thursday, February
On Thu, Feb 25, 2016 at 9:37 AM, Barry Kaplan wrote:
> Ok, is this something that would be considered for change? In our
> environment there is no guarantee that nodes will remain on the same IP. For
> this we use consul and dnsmasq to lookup DNS names.
>
Sure, we would
Ok, is this something that would be considered for change? In our
environment there is no guarantee that nodes will remain on the same IP.
For this we use consul and dnsmasq to lookup DNS names.
For now I will hard code server_hostname to the DNS of the ossec server. At
least that value
Hi Barry,
If I understood well, you need to resolve the DNS IP Address more than
once, unfortunately seems like OSSEC won't do it.
At the very first start, OSSEC reads the file ossec.conf, when detecting a
11 matches
Mail list logo