Re: monit SMTP

[Michael Shigorin]

Pre Scriptum: you may safely skip to bottom, 2/3 is rant.

Jan-Henrik Haukeland wrote:
> This reminds me about jwz's who says that:
>  ``Every program attempts to expand until it can read mail.
>  Those programs which cannot so expand are replaced by ones
>  which can.''

Yeah, was remembering it too.  But I doubt you'll want to invent
something that sucks less badly than mutt, and I have that for
most of my mail (non-directly-business-related) already ;-)

> The bottom line is that I agree with you, except on a few
> important issues.

Well then maybe I'd join to discuss them.

> First, I'm convinced that we should *not* attempt to implement
> more features around the already existing monit SMTP
> implementation.

Ugh.  But you'll be tempted every now and then ;-)

> I agree with you that monit should be as simple as possible and
> as orthogonal as possible. 

Sure.  And "threads" sound quite alarming to me so as "what if
libpthread.so.* gets corrupted?"

> That is, monit should not include (much) other functionality
> than what is needed for it to fullfill it's goal, which is:
> monitoring and mending services on a Unix system.

Yep; IMCO the only functionality that could be worth redoing it
is the one that is available either in no-good form ("pre-alpha
0.0.1, hey I'm learning!") or full-fledged (and full-sized)
implementations.

> But, I disagree that monit should not implement it's own SMTP
> agent. My arguments for this are more or less the same as
> Christian's and Martin's but allow me to clarify; If we where
> about to start implementing monit now I would agree that using
> an external program to handle mail would seem like a good idea,
> but monit's SMTP agent has been around from one of the first
> versions (i.e. it's been part of monit for many years) and it
> works! (You know the saying, if it works, don't change it).

Yes I know (used it last time when convincing myself not to ask
xmms-1.2.8-alt7 with a pack of nice features like id3v2 editor
and charset conversion to ALT's fresh beta which gets stabilized
but holds working *old* 1.2.7 with some things wrong but
generally proven).

But it's one of the things that was surprising: emphasizing on
e-mail and having no hooks for other transports.

In that exact case, monit was (2314 2313 2312.. hm, is :) running
on a host serving the mobile messaging platform mentioned.  And
we've got at least one additional transport, SMS through
almost-guaranteed premium gateway (NB: SMS isn't reliable
altogether on GSM network level, but that's another story).

Had to wrap /sbin/service in my script and push that into as a
"start program" to cope, but it's hackaround altogether since
many interesting states are untraceable; most obvious is that I
get a message only when monit tries to get the service back up,
not when it *has* the info on it being down.

> Besides, I cannot see that the very simple operation of opening
> up a socket and sending a mail through the SMTP protocoll is
> more error prone than calling an external program through
> execv() and send mail.

Well OK, but if it was done like "open up some socket at
/var/run/monit/mail and let the message there" (with consequent
reaction of e.g. monit-smtp, which could do it itself, or even
[try to] use super-puper-SSL-enabled local MTA which *maybe* is
at hand and just doesn't need additional setup) -- seems that
smtp component troubles would have less chance to affect main
process' (mis)behavoiur.

> The network code in monit is simple, effective and orthogonal
> and has not have any problem.

That's good; actually I'm more grumpy with config parser in 3.x
but that's another story ;-)

> In other words the current SMTP agent in monit is good enough.
> (Altough I would like to change the SMTP protocol
> implementation to use a simple state-machine so it will be more
> failsafe, the current implementation is just one glorious write
> loop. Even if simplicity is important, there are limits :)

OK, agreed.  *If* it's just another "transport" which can be
talked to in some simple and consistent manner. :)

> Another argument mentioned before, but one I would like to
> stress, is that our design philosophy is that monit should be
> as autonomous as possible.

It's reasonable.  But there are limits too ;-)

> The rationale for this is (as mentioned many times before) that
> monit should be easy to setup and run.

Well the default of "kick /usr/sbin/sendmail and it will go"
tends to work on most configured *nix hosts whose administrators
are reasonable and whose jobs don't interfere with that directly.
(running ahead of a train, I'm counter-myself as one of *my*
goals here is... ok, [1])

> Users should not need to download and configure many external
> components. By having a very low complexity on setting up and
> run monit means that configure errors are much less likely to
> occur.

Sure.  But that's one end of the road; another is (IMCO more
industry-leaning, not all that bad after all if it saves your
time with each install) distributions: here you're most likely
armed with a range of packages having software in reasonable
configurations, and requiring a package is moderate (e.g. RH) to
no pain at all (Debian, Conectiva, ALT...).

> Finally, an interesting point is that m/monit is sailing up to
> become a good alternative to take over many of the more
> enterprise issues, such as reporting and statistics and so on.

Ummm... well when talking on enterprise issues/focus, we're
definitely not down to "configure && make && sudo make install"
but rather to distributions. ("this came with hardware" may
actually boil down "to", but are AIXen popular amongst
monit-users?)

> It's not critical that m/monit runs all the time but it is very
> critical that monit does. This means that we have an option for
> pushing complexity over from monit to m/monit.

Great!  And it would be prudent to take away messaging the same
way: in the end of the day, we really care about service working,
not anout knowing "oh it had failed and monit did too".

> Thanks (Spasiba balsoje) for the discussion, I'm off to
> continue work on m/monit and monit :-)
> 
> Paka!

Whaaah :)  Sorry for being way too bad in Scandinavian languages
(even when one of Team members is not ;-)

-------------------------------------------------

PS: just to introduce myself with the first post: I'm 24, M.Sc.
in Organic Chemistry with computational/combinatorial chemistry
as one of (former) areas of interest; on Linux since being a
freshman at the University (ca. 1997--1998).

For now, usually able of looking at "the big picture" at times
but almost completely unskilled as developer: the best C code [2]
I ever wrote is still ugly, the favourite language (Ruby) isn't
"system" at all and got dusty in my hands altogether.

Taking part in osdn.org.ua / linux.kiev.ua coordination and F/OSS
promotion in Ukraine.

Supporting some packages in ALT Linux for some two+ years
(http://altlinux.org/?module=sisyphus&packager=mike).

Busy with new startup, emt.com.ua, which is aimed at providing
quality F/OSS consulting, development and support; wanted to do
that for some two years but only now have found adequate business
person to partner with as I'm no businessman, too techie in the
end.  Ummm.. and yes, I need monit for our server products. :)

PPS: had a call to an IT friend at local GSM operator; discussed
things I'm proposing below; he told it's what they'd appreciate
at the deployment of additional Linux servers they plan. (he's
seen monit in action at previous location where we worked
together on the said platform -- and now uses 3.x there)

------------------------------------------------- #bottom

[1] one of *my* goals here is getting monit [-alt*.*.rpm ;-)]
    to the distribution-friendly enterprise-ready Mega-Glo^W^W^W
    errr... some most sane shape for us packagers/administrators
    and eventually supporters ;-)
    
I'd like to propose these items for your considerations:

- general "modularization", just along the way with m/monit:
  alert transports should be seperated to allow (all in
  reasonably consistent manner):

  * adding new ones;
  * reconfiguring existing (e.g. builtin/wrapped SMTP modules);
  * using several transports to get the message out

- modular/SysV-style config file -- e.g. /etc/monitrc.d/
  where you can drop files from respective packages like apache.

  Here we get at least one *very* convenient and important
  benefit: sec updates can handle changing md5s automatically.
  It's especially handy when it's your cron who cares for them
  for the most part, and updating them by hand is a bit
  time-taking and error prone so you tend not to on a
  _significant_ number of hosts.

  This can be worked around by collating configlets with rpm
  scripts but that's evil.

- maybe it's worth communicating with colleagues focusing on
  networked monitoring (nagios, moodss) to find whether
  cooperation and mutual support is feasible.

If it doesn't sound too absurd then would be glad to continue
such architectural/integrational ranting ;-)

P^3S: thanks for monit, it has saved some nerves/money already.

-------------------------------------------------

[2] http://home.chem.univ.kiev.ua/~mike/?lang=en

-- 
 ---- WBR, Michael Shigorin <address@hidden>
  ------ Linux.Kiev http://www.linux.kiev.ua/

pgpzVr9SWdHuT.pgp
Description: PGP signature