James Carlson wrote: > Jordan Brown writes: >> associated with this SNMP trap" and get reasonable answers. If the >> SNMPisms are buried in user-provided shell scripts, those questions >> can't be answered. Similarly for e-mail notification: you should be >> able to get a list of all addresses that will get e-mail notifications. > > Worse still, upgrade becomes problematic: if these things are just > specified as scripts, with users encouraged to hack away, then it's > really not possible to "fix" anything that a user may have modified if > we discover a bug in the original script. > > I agree that calling out to external scripts is maximally flexible, > but be careful: a lot of future cost comes with that flexibility.
Calling out to a user-provided script seems pretty fundamental. If it's a user-provided script, then there's no upgrade problem. The upgrade problem comes if it's a Sun-provided script and the user edits it. Perhaps there are "actions" that are Sun-provided, that might happen to be implemented as shell scripts, and one of the actions is "run user-provided program". (Note that I say "program" rather than "script"; it should be anything that you can exec, which includes but is not limited to shell scripts. Let's avoid repeating the /etc/rc*.d discussion :-) There should probably be a way to trigger multiple actions, so that one can send an SNMP trap *and* send e-mail *and* run a user program, without having to hack the action script. If, after all that, the user edits the script that implements an action, it's just like editing any other script that implements a system feature: upgrades will likely wipe out your changes, your change is unsupported, et cetera.
