|
(I think I forgot to send this, ignore if its a duplicate,
sorry for being slow if its not)
On Wed, Aug 03, 2005 at 11:46:34AM -0400, JD Weiner wrote:
> Horms wrote:
> > 1. The alerts need to be able to be turned on or off in the
> > configuration file. Perhaps a simple configuration varibale, that can
> > be global and per-virtual, and defaults to off. alertmail might not
> > be such a bad name
>
> Maybe instead of directly sending email, there should just be a hook
> for when a server changes status? If ldirectord could call an arbitrary
> user-defined program, then all the complexity and configurability could
> be pushed into that, instead of it having to live in the main code.
> Also, it would permit arbitrary actions instead of just email - I don't
> know if anyone's ever expressed interest in that, but it would leave the
> possibility open.
I'm cool with that too. Though I am not entirely sure what
information would need to be passed. I guess whatever information
is being sent to sendmail would be a good start.
My idea would be to indeed add a generic hook. And provide
a hook that sends the information out to an external program.
And other hooks to do things internally, like send mail.
On Wed, Aug 03, 2005 at 01:36:16PM -0700, Peter Mueller wrote:
> > 1. The alerts need to be able to be turned on or off in the
> > configuration file. Perhaps a simple configuration
> > varibale, that can
> > be global and per-virtual, and defaults to off. alertmail might not
> > be such a bad name
>
> Ok.
>
> > 2. The addresses also need to be configurable, again on a global or
> > per-virtual basis. alertmailfailaddress, alertmailsuccessaddress
> > might not be such bad names, though they are rather long.
>
> So both 1 and 2 need to be configurable via ldirectord.cf.
Yes, I think so.
> > I am also concerend about using /usr/lib/sendmail directly,
> > and this is probably the main reason I haven't added this
> > feature in the past. I'm happy to live with it for now, but
> > its certainly
> > an area for improvement in the future.
>
> Some others have mentioned using a perl mailer module. What is the one that
> most distributions use (Redhat, SuSE, and Debian)? Can someone provide an
> example of their use? I do not normally use Perl so I am not familiar with
> the different modules.
>
> We already have Mail::Sendmail and Mail::Sender. Mail::Sender sounds more
> generic and independent of sendmail, but Mail::Sendmail might be installed on
> a wider basis?
If I had to choose one or the other, I'd go for Mail::Sendmail,
as that seems to be simpler and I think that most systems have
something that is either sendmail or pretends to be sendmail -
its a simple interface that allows a separate programe to handle
how mail is sent in a locally-defined way.
In addition, adding Mail::Sender support would be good.
Covering piping mail into sendmail, and sending mail over
a TCP socket using SMTP should cover most bases.
Someone also mentioned being able to spawn an external problem.
I'm cool with that too. Though I am not entirely sure what
information would need to be passed. I guess whatever information
is being sent to sendmail would be a good start.
Mail Sendmail
http://cpan.uwinnipeg.ca/dist/Mail-Sendmail
http://cpan.uwinnipeg.ca/htdocs/Mail-Sendmail/README.html
Mail Sender
http://cpan.uwinnipeg.ca/search?query=Mail%3A%3ASender&mode=module
http://cpan.uwinnipeg.ca/search?query=Mail%3A%3ASender&mode=dist
--
Horms
|
