email not going out - "getaddrinfo: Name or service not known"

[Whit Blauvelt]

Hi,

There have been multiple past discussions of email problems. Yet none seem
to cover this exactly. Here's what's logging, repeatedly:

2016/11/04 18:33:53 getaddrinfo: Name or service not known
2016/11/04 18:33:53 ossec-maild(1223): ERROR: Error Sending email to localhost (smtp server)

It would be helpful to have better error messaging. What "name or service"
does it wish to know? What specifically was the "error sending email"?

This system is:

ossec-hids-2.9rc3 (via install.sh)
Ubuntu 16.04.1 LTS
Postfix 3.1.0-3 (from Ubuntu apt)
- which works fine when test email composed in mutt and sent
- nothing in mail.log at time of ossec's "error sending email" events

ossec.conf's only modification was to put in localhost rather than our MX,
as we don't want this dependent on an external mail system that way:

<global>
<email_notification>yes</email_notification>
<email_to>blah...@obfuscated.com</email_to>
<smtp_server>localhost</smtp_server>
<email_from>oss...@ossec.obfuscated.com</email_from>
</global>

Postfix is there listening:

root@rpc-ossec:/var/ossec/etc# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ossec.obfuscated.com ESMTP Postfix (Ubuntu)

What's the secret sauce to get ossec-maild to be happy with Postfix?

Thanks,
Whit

[dan (ddp)]

On Nov 8, 2016 4:35 AM, "Whit Blauvelt" <wh...@transpect.com> wrote:
>
> Hi,
>
> There have been multiple past discussions of email problems. Yet none seem
> to cover this exactly. Here's what's logging, repeatedly:
>
>   2016/11/04 18:33:53 getaddrinfo: Name or service not known
>   2016/11/04 18:33:53 ossec-maild(1223): ERROR: Error Sending email to localhost (smtp server)
>
> It would be helpful to have better error messaging. What "name or service"
> does it wish to know? What specifically was the "error sending email"?
>
> This system is:
>
>   ossec-hids-2.9rc3 (via install.sh)
>   Ubuntu 16.04.1 LTS
>   Postfix 3.1.0-3 (from Ubuntu apt)
>     - which works fine when test email composed in mutt and sent
>     - nothing in mail.log at time of ossec's "error sending email" events
>
> ossec.conf's only modification was to put in localhost rather than our MX,
> as we don't want this dependent on an external mail system that way:
>
>   <global>
>     <email_notification>yes</email_notification>
>     <email_to>blah...@obfuscated.com</email_to>
>     <smtp_server>localhost</smtp_server>
>    

Have you tried 127.0.0.1?

<email_from>oss...@ossec.obfuscated.com</email_from>
>   </global>
>
> Postfix is there listening:
>
>   root@rpc-ossec:/var/ossec/etc# telnet localhost 25
>   Trying 127.0.0.1...
>   Connected to localhost.
>   Escape character is '^]'.
>   220 ossec.obfuscated.com ESMTP Postfix (Ubuntu)
>
> What's the secret sauce to get ossec-maild to be happy with Postfix?
>
> Thanks,
> Whit
>

> --
>
> ---
> 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.
> For more options, visit https://groups.google.com/d/optout.

[Dave Stoddard]

If you are getting that message with getaddrinfo, it is likely you do not have an /etc/services file on your system, or smtp is not defined in the /etc/services file. Alternatively, it could be referring to localhost - in that case, make sure you have an entry in the /etc/hosts file for localhost.

[dan (ddp)]

On Wed, Nov 9, 2016 at 1:19 PM, Dave Stoddard <lam...@gmail.com> wrote:
> If you are getting that message with getaddrinfo, it is likely you do not
> have an /etc/services file on your system, or smtp is not defined in the
> /etc/services file. Alternatively, it could be referring to localhost - in
> that case, make sure you have an entry in the /etc/hosts file for localhost.
>

Remember that maild is probably chrooted, so change the directory appropriately.

[Whit Blauvelt]

On Tue, Nov 08, 2016 at 04:37:04AM -0500, dan (ddp) wrote:

> Have you tried 127.0.0.1?

127.0.0.1 does work.

So this has something to do with chrooting in the current version? I do have
localhost defined in /etc/hosts. Not sure how OSSEC is handling the
chrooting. Where will I find documentation on that?

Whit

[Whit Blauvelt]

On Wed, Nov 09, 2016 at 10:19:21AM -0800, Dave Stoddard wrote:
> If you are getting that message with getaddrinfo, it is likely you do not have
> an /etc/services file on your system, or smtp is not defined in the /etc/
> services file. Alternatively, it could be referring to localhost - in that
> case, make sure you have an entry in the /etc/hosts file for localhost.

Thanks. I do have an /etc/services file with smtp defined in it, and a
localhost entry in /etc/hosts. So must be the chroot-y thing added lately.

Whit

[dan (ddp)]

What kind of documentation do you need? Ossec chroots to the install dir (/var/ossec by default)

[dan (ddp)]

Lately being relative, I guess. Maild has been chrooting for as long as I remember.

[Dave Stoddard]

If OSSEC is chrooting to /var/ossec, copy your /etc/services and /etc/hosts files to the /var/ossec/etc directory.  Do not use a symlink or a hardlink -- copy them physically into the directory. It will find them without any issue and your problem should go away. Best,

Dave 

[Whit Blauvelt]

On Fri, Nov 11, 2016 at 07:13:53PM -0500, dan (ddp) wrote:

> What kind of documentation do you need? Ossec chroots to the install dir (/var/
> ossec by default)

Documentation that explained the need to maintain a hosts file in
/var/ossec/etc -- and anything else that's similarly required to get full,
expected behavior given the chroot -- would be useful. Perhaps the default
installation should copy the existing /etc/hosts file there too?

Best,
Whit

[Whit Blauvelt]

Thanks Dave. Only question is: why doesn't the installation routine either
just do this, or ask for permission to do so?

Best,
Whit

[dan (ddp)]

IIRC the setting used to require an IP address,so this wasn't
necessary. Since then either no one's cared, no one's noticed, or no
one wants to change the default behavior (expecting admins to
understand chroot).

> Best,