[syslog-ng] [PATCH]: Experimental SMTP destination

[Gergely Nagy]

On Mon, 2011-02-14 at 09:46 +0100, Valentijn Sessink wrote:
> Op 12-02-11 20:34, Gergely Nagy schreef:
> > However, it is an option that I do not like all that much. Having a
> > built-in smtp destination driver has a few advantages over using a
> > program destination:
> > 
> > * You don't need an external application (my #1 reason, apart from
> > "because I could").
> > * No need to fork off to launch the external program (though, this isn't
> > a big issue, since email alerts will probably be rather rare, so the
> > fork & launch overhad is negligible)
> 
> So isn't the built-in MTA a solution in search of a problem? 

Nope, it isn't. I have routers that do not have a reliable MTA, and I
don't intend to install one on them for the sole purpose of sending
syslog alerts.

There might be N other ways to accomplish the same thing, a built-in
smtp destination was the easiest for me, so I coded it up. All the other
soultions I could think of would have taken me more time and effort.

I had an itch, I scratched it, I'm happy.

> Also, I see some problems with the built-in SMTP destination. Misconfiguration now
> is a problem for syslog-ng itself - instead of the external MTA.

Yes, and that is good so. I will notice such misconfigurations far
sooner.

> This, of course, has two sides: when the misconfiguration consists of a
> log/mailing loop, using an external MTA could be a serious problem when
> tens of MTA instances are started in parallel; but an internal MTA will
> bring the system to it's knees by immediately filling memory, disk and
> the network with repeated messages - without any external help ;-)

Erm, no. The smtp destination has a configurable queue, if it fills up,
it will start to drop messages. That way, it will not consume all
memory. As for filling the disk with repeated messages, that's what
suppress() is for in the file destination.

Yes, you can bring the system to its knees, but one can do that without
the help of the smtp destination too.

The same 'problem' applies to program() too, by the way.

> However, at the moment your smtp destination does not seem to have a
> "throttle" configuration setting, while program() does have one.

Oops, good catch! Although, that's just a bug in the grammar file (and
about 4 lines to fix, which I will do tonight after work).

> > * Tighter integration with syslog-ng allows for easier troubleshooting:
> > one only has to look at one place
> 
> I'm pretty sure it won't be too hard to configure syslog-ng so, that
> it's pretty easy to troubleshoot the MTA that it sends it's messages to.

The thing is, I don't want a full-blown MTA on the same host that
syslog-ng runs on. So at best, I can have a program that forwards alerts
to an external host.

Now this has two consequences:

- While it is easy to troubleshoot the forwarder, the MTA is running on
another host. That alone makes it slightly more complicated to
troubleshoot it, as there's one more variable in the picture.

- I will either need a reasonably feature-full forwarder that can do TLS
and authentication, so I can use the SMTP server of my choice, or I need
an intermediate server that can accept mails from the syslog host, and
forward it (using TLS & auth) to the real smtp server.

Having an built-in smtp destination, that will have tls & auth real
soon, does not have these issues.

> But the main point is, that I don't think that an internal SMTP
> destination will do any good for misconfiguration. I.e. misconfiguration
> is a problem in itself, and no matter how many destinations you add to
> syslog-ng, you won't be able to prevent misconfiguration.

Correct. But as far as I'm concerned, I find it easier to debug one
program, on one host, than go through N hops to find which one is
misbehaving.

With the program() destination, in order for my alerts to leave my
system, it would go through several hops.

Assuming a sendmail that can do TLS and auth (best case):

        syslog-ng -> sendmail -> external SMTP host

With a bit of luck, the sendmail program will do proper logging, so I
can troubleshoot it easily. Hopefully, it will also do queuing, either
in memory, or on disk, so that when the SMTP host is unreachable, my
alerts will not get lost.

There's too many ifs in there, and I'm really not interested in finding
a small enough forwarder that can do all that. I know busybox can't, nor
can nullmailer. Dragonfly Mail Agent (dma) might be a good candidate,
but I'd need to review it. Esmtp is relay-only, and does not queue.

That's about all of the lighter MTA solutiosn available in Debian. Thus,
it looks like I need an intermediate step:

        syslog-ng -> sendmail -> internal SMTP relay -> external SMTP
        host

The problem with this, is that things can go wrong at yet another place,
and if the internal relay is not accessible for one reason or the other
(eg, it's restarting due to an upgrade), since the sendmail program does
not queue, and does not retry, there's a reasonable chance of alerts
disappearing.

With a built-in smtp destination, the setup would look like this:

        syslog-ng -> external SMTP host

Boom. The smtp driver will detect if there's a network outage, and queue
the mail, and retry later. It does this using syslog-ng's built-in
queuing mechanism. I don't need to go an extra mile to make sure that
any message sent from syslog-ng will be retried at least until the queue
fills up.

> > That, and having the option to do it without an external program was one
> > of the driving forces behind the code (I really, really don't like
> > calling external programs, if I can avoid it).
> 
> Being a Linux user, I don't think calling external programs is a problem
> per se. Yes, it has overhead, but in this case, the overhead seems
> perfectly acceptible.

As I said, the overhead is negligible indeed. It's not the overhead I'm
worried about in this case.

> A problem that was not yet mentioned is, that having an SMTP destination
> now makes syslog-ng dependent on yet another library, libesmtp.

It's optional, though. By that logic, we shouldn't have sql()
destinations, either, since one can just use program() with a perl
script. We wouldn't need tls, either, since one can set up a tunnel. We
wouldn't need tcp() and the rest, either, since we can use netcat...

> All in all, it sounds like the perfect solution for a certain
> widely-used proprietary operating system, that has no proper built-in
> SMTP possibilities. And because the SMTP destination is configurable
> with ENABLE_SMTP, Linux builds can easily avoid the new dependency ;)

If you're talking about the OS I think you're talking about, let me
assure you, I wouldn't touch it with a ten feet pole if I can avoid it
(not to mention, that libestmp is most probably not available for said
platform).

-- 
|8]