> On Mon, Jan 27, 2003 at 08:15:55AM -0600, Bruce Allen wrote:
> > In fact I think that Jamie's wish might in fact be accomodated under Tim
> > and Phil's scheme, if they make one additional change. They would need
> > to modify the code to EXPORT a number of environment variables before
> > calling the mail program. These exported variables might include:
> > SMARTDPATH (example: /dev/hda)
> Can we call this SMARTD_DEVICE or SMARTD_DEV? I kind of associate
> SMARTDPATH with the location where smartd is located in the filesystem -
> but that's nitpicking.
That's fine with me. I was mostly trying to explain the idea -- I agree
that some more thought should go into the names and the naming convention.
> > Then, since smartd will use the environment variable: SMARTDMAIL (by
> > default /bin/mail but Jamie can set it to /usr/local/bin/myscript) to
> > decide what mail program to run, Jamie could set SMARTDMAIL to point
> > to the script that he wants to run, and make this script ignore it's
> > command line arguments and stdin. [The command line arguments would be
> > things like '-s "subject" root@...' and stdin is the body of the
> > mail message.] This would allow the user (Jamie) to execute an arbitrary
> > script, and by making the script use the environment variables listed
> > above, it would had access to all the relevant info.
> Hmm...wouldn't it be cleaner to rename SMARTD_MAIL to SMARTD_SCRIPT then
> and provide an example SMARTD_SCRIPT that sends the same mail as smartd
> currently does? This would actually make smartd simpler and move non
> crucial parts out of the daemon. Or said the other way around - must a
> daemon really send mail, can't it just call an external script that
I did think about this, and I'm oppposed to it. I would like smartd to
remain simple to use for the "ordinary" user. So by default I would like
the -m option of smartd to "just send mail" using /bin/mail if SMARTDMAIL
is not set by the user. I don't want this to have to rely on a script
that the user has to understand or even copy to a standard location.
But, this still allows the "sophisticated user" to do exactly what
Jamie wants. The script that they write will receive some command line
arguments that would normally go to /bin/mail (which they can use or
ignore at their pleasure) and it will also receive some stdin, that
would normally be the body of the mail message (that again, they can
use or ignore at their pleasure).
Guido, while I am against your suggestion of requiring a script file to
get the mail functionality, this does suggest to me another alternative
to implement Tim's original idea of getting the output of smartctl -a
added to the mail message. Instead of building this into smartd, Tim could
simply provide a script that (1) sends the mail and (2) adds the smartctl -a
output to the mail message.
Tim, what do you think of this idea? It would actually simplify smartd, by
eliminating the -M exec option entirely. You would simply set
with a script something like this:
# save body of mail message produced by smartd
# by redirecting stdin to a temporary file:
cat > /tmp/mailmessage
# add output of smartctl -a to mail message:
/usr/sbin/smartctl -a SMARTD_DRIVE >> /tmp/mailmessage
# send mail message (re-use command line arguments):
/bin/mail $@ < /tmp/mailmessage
# remove temp file:
rm -f /tmp/mailmessage
You could of course use this to run sg_utils or whatever other
executables you wanted as well.
It seems to me like a good solution, that simplifies smartd and still
enables sophisticated users to do what they want, easily.