[dev] Automatic error submission to administrative user

Kevin Myer kevin_myer at iu13.org
Sat May 21 14:05:40 PDT 2005


Hello,

I have a small HEAD installation that I am tracking daily updates on fairly
closely.  During installation, I encountered a few errors, all of my own doing
of course (issues dealing with Apache chroot, the way the OpenBSD PEAR package
differs from "standard" PEAR, etc.)  These errors often threw on the page a
dump of the various values, which were essentially a traceback, I'm assuming to
aid debugging and which were very useful (and which I hope disappears in a
release versions - all it takes is a misconfiguration and your database
password or LDAP bind password are written to the screen [or you could just
look at the Admin Setup screen too] ;)  Drawback there is you don't want the
Horde errors echoed to the screen, because they may have sensitive information.

Now another way to gain information about errors is to set a file log facility
for PHP and review that periodically.  You'd then need to review that log file
and attempt to correlate errors with URLs in your webserver logs, and maybe
figure out what the user was trying to do at the time the error was generated. 
Drawback there is log correlation on a large install (or even a small one), can
be time consuming and you aren't always sure what the user was doing, or which
particular HTTP access generated the eorr.

Finally, you can leave PHP's display_errors set to on, and have the users submit
errors as they see them.  That works for testing but is not advisable for a
production site.  If you use the Problem button to submit feedback, you can get
a sense of some additional info (browser, OS, where they clicked from, etc.) 
Drawback is of course it makes your production site look bad, and it relies on
the user clicking the feedback link from the screen that generated the error.

So what I'm thinking would be extremely helpful (and maybe this already exists
in HEAD but I haven't explored it fully) is to have an automated feedback
mechanism, such that if an error is generated, the Horde/PEAR
Notification/Error class can collect relevant information about what just
occured - the PHP error, the user, browser, what they clicked on to generated
the error, even machine statistics perhaps, like memory.  Roll the idea of the
existing Horde test.php scripts, a core dump, a Mozilla Talkback, a Windows
Error Report, the mysqlbug script, the OpenBSD sendbug script and a Java
exception log into one, stir, shake, and what falls out 9as relevant to a Horde
install) would hopefully be a useful Horde bug report.

It sure would save me a lot of print_r's and var_dumps :)

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org



More information about the dev mailing list