2 instances of ossec-maild

[Scott Wozny]

Just an "idle curiosity" kind of question.  In a 3.6.0 server installed from the tarball on CentOS 7, when I run a ps, I have 2 instances of /var/ossec/bin/ossec-maild running, both under UID ossecm.  Does anyone know why there are 2 instances of the same process run by the same user?

Thanks,

Scott

[dan (ddp)]

On Tue, Jun 16, 2020 at 5:35 PM Scott Wozny <saw...@gmail.com> wrote:
>
> Just an "idle curiosity" kind of question. In a 3.6.0 server installed from the tarball on CentOS 7, when I run a ps, I have 2 instances of /var/ossec/bin/ossec-maild running, both under UID ossecm. Does anyone know why there are 2 instances of the same process run by the same user?
>

When ossec-maild (I'll call it main) starts it forks off another
process (I'll call this one connector). There is a socket pair shared
between them for communication.
When the main process determines that an email should be sent, it
forks off another process (OS_Sendmail()). This sendmail process sends
a request to the connector process. The connector process finds the
smtp server and connects to it. Then forwards that connection back to
the sendmail process.
The purpose of all of this was to make managing it a bit easier. The
main process is chroot()ed to /var/ossec, so dns lookups for the smtp
server (if you don't use an IP adddress) were difficult. At a minimum
the /etc/resolv.conf had to be copied to /var/ossec/etc. Even that
didn't seem to work on some systems.
So the connector process was created. It is not chrooted, so it has
access to the entire system. resolv.conf no longer had to be copied,
and it even seemed to help with the "ipv6 is disabled" queries.

> Thanks,
>
> Scott
>
> --
>
> ---
> 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 ossec-list+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/7ad9c128-7bf4-493b-9271-a414d2add8d5o%40googlegroups.com.

[Scott Wozny]

Hi Dan,

Very interesting!  Feels kind of Rube Goldberg-y but I fully understand the reasoning and it makes perfect sense in the context of what's trying to be accomplished here.  I very much appreciate the explanation!  :)

Thanks,

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/CAMyQvMoBwFs0Y-tas3Zxj5ijpF5Gn3gbsAVHiRb25NKJw8KavQ%40mail.gmail.com.

[dan (ddp)]

On Wed, Jun 17, 2020 at 1:31 PM Scott Wozny <saw...@gmail.com> wrote:
>
> Hi Dan,
>
> Very interesting! Feels kind of Rube Goldberg-y but I fully understand the reasoning and it makes perfect sense in the context of what's trying to be accomplished here. I very much appreciate the explanation! :)
>

Maybe, but it's not too bad. Everything except the connector process
existed before, and I couldn't think of a better way to do it. It was
fun, but definitely needs some polishing.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/CACUKT_ptNYqVWaD%3DMe9nXzVRQhnpzZfc6o515YogF0xcuHDNVQ%40mail.gmail.com.