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]