For fun, I decided to try implementing what I've suggested below. It
added ~ 10 lines to smartd.c. I've tested it and checked it into CVS; we
can back it out if this turns out to be a bad idea.
You can see the code I've added with:
cvs diff -r 1.100 -r 1.101 smartd.c
If you just run smartd "as is" you will see no change from the previous
behavior. It sends mail as governed by -m and -M options.
If you first do:
export SMARTD_MAILER=/bin/true
(for example) before running ./smartd, this will use /bin/true as the
mailer program, and you'll get no mail at all.
If you then set (warning! Example only)
export SMARTD_MAILER=/root/myscript
where /root/myscript contains the four lines:
#!/bin/bash
cat > /root/normal_mail_message
/usr/sbin/smartctl -a $SMARTD_DEVICE >> /root/normal_mail_message
/bin/mail -s "SMART errors detected on host: `hostname`" $SMARTD_ADDRESS <
/root/normal_mail_message > /dev/null 2> /dev/null
you will get the output of smartctl -a appended to the mailer output,
which is what Tim had originally wanted. Note that the code currently
exports the environment variables:
> setenv("SMARTD_DEVICE", cfg->name, 1);
> setenv("SMARTD_MESSAGE", message, 1);
> setenv("SMARTD_ADDRESS", address, 1);
> setenv("SMARTD_TFIRST", ctime(&(mail->firstsent)), 1);
that can be used in a script. Additional variables can be added with
one extra line per variable in smartd.c
If we want the user to be able to run a different script for each device
then we might want to retain the -M exec option, rather than using the
environment variable SMARTD_MAILER. Or we could leave this up to the
user, since of course the script can test the value of SMARTD_DEVICE to
see which device is being used...
The rule for writing scripts is the following:
-- script should ignore any command-line arguments
-- script receives the "normal" mail message on stdin. It can
use this, ignore it, or dispose of it, as desired.
-- Anything that the script writes to stdout or stderr is lost. So
any output from the script should be mailed, logged to syslog,
or written to a log file.
-- script should return exit status 0 if all is well, else
non-zero exit status if there is a problem
This seems to me a simple change to the code that gives the user complete
flexibility while maintaining ease-of-use for most people.
Comments?
Bruce
On Tue, 28 Jan 2003, Bruce Allen wrote:
> Hi Phil,
>
> > I'm all for adding a '-s' Directive to allow the user to specify an
> > arbitrary script for smartd to run and I'm all for removing the
> > (incomplete) '-M exec' Directive and requiring the user to write their
> > own script if they want to be mailed the output of 'smartctl -a' or
> > whatever.
>
> In fact we can accomplish all of this with really tiny changes to the
> code, and without adding a "-s" option at all. We make the following
> modifications. [Note: the environment variables names below are
> off-the-cuff, and there may be a better choices of names]:
>
> (1) if SMARTD_MAIL is set, use it instead of /bin/mail as the program
> to execute. This lets the user execute an arbitrary script.
>
> (2) before running SMARTD_MAIL, export environment variables:
> SMARTD_DEVICE
> SMARTD_DEVICETYPE
> SMARTD_ERRORTYPE
> SMARTD_ERRORNUMBER
> ...
>
> I think that this satisfies ALL requirements, while making the changes to
> the code minimal.
>
> (A) 'Ordinary' users just run the code "as is". It's easy to use and
> requires no scripting, additional configuration, etc.
>
> (B) 'Sophisticated' users (such as Tim) who want additional output
> set SMARTD_MAIL to point to their own script such as the one below
>
> #! /bin/bash
> file=/only/writeable/by/root.$SMARTD_DEVICE
> cat > $file
> /usr/sbin/smartctl -a $SMARTD_DRIVE >> $file
> /bin/mail $@ < $file
>
> (C) 'Strange' users who want to do something *else* can set
> SMARTD_MAIL to point to a script that does whatever:
>
> #! /bin/bash
> echo -e \a
> echo -e \a
> echo -e \a
> wall 'smartd warning: shutdown in 20 secs'
> sleep 20
> /sbin/shutdown -hf now
>
> [This beeps the console three times, issues a warning to
> all users, and powers off the machine!]
>
> It seems to me that this satisfies ALL requirements:
>
> -- allows users to easily send mail using current scheme that works well
> for most people
> -- lets users use a different path to mail if they want
> -- lets users write a customized script that adds additional info
> to the mail message if they want
> -- lets users execute an arbitrary script if they want, including
> creating custom mail, using custom mailers, etc.
>
> In addition, it requires very minimal changes to the code.
> To specify the executable path with the environment variable SMARTD_MAIL
> is trivial, and we can export the values of the other variables either by
> using
> export SMARTD_VAR1=...
> syntax in the script argument to system() or by "doing it properly" with
> fork/execle.
>
> > I also think it's worth keeping '-m' for users who just want a basic
> > email warning when one of their drives starts doing something weird.
> > I suspect that most smartd users would use this feature and that it is
> > adequate for the vast majority of users (Bruce, do you think that's
> > right?)
>
> Yes, I do.
>
> > so I would prefer that we don't force them to write (or modify) a
> > script for this. We definitely need to allow the user to specify the
> > mail program though (something I know Bruce has mentioned before).
>
> I completely agree with this.
>
> Tim, what do you think?
>
> Cheers,
> Bruce
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Smartmontools-support mailing list
> Smartmontools-support@...
> https://lists.sourceforge.net/lists/listinfo/smartmontools-support
>
|