45207 - Automated sanity check that can send an e-mail if there are problems

Status: RESOLVED FIXED

(Bugzilla :: Administration, task, P2)

Description

[Matthew Tuck [:CodeMachine]]

At the moment I believe it's too easy to miss problems with the database.

It would be nice if sanitycheck.cgi could automatically run periodically, and
email the results to a person.

I guess the period would be configurable.

Comment 1

[Zach Lipton [:zach]]

This could be done by running cron on the server to run sanitycheck.cgi to 
run and then hack email the results to an address. This is a mozilla.org 
issue, not a bugzilla issue. Maybe this should get kicked over to whoever 
is running the mozilla installation.

Comment 2

[Matthew Tuck [:CodeMachine]]

Who has bothered to do this so far?  Anyone?

I think that demonstrates why this would be good "out of the box".  People just
won't bother.  I'm not saying you wouldn't implement it as you say, but it needs
to be a no-brainer to set up as such, like in editparams.cgi or something.

Comment 3

[Chris Yeh]

automatically setting cronjobs on host machines would be rather rude. why not 
just add it to the right spot in the documentation?

"we're accepting patches"

Comment 4

[Matthew Tuck [:CodeMachine]]

I'm not really sure that running cronjobs is rude, I see lots of packages
running cronjobs on my machine.

But it is of course nice to have as an option.  That's why I suggested
editparams.cgi.

If you do think the documentation's still the best way to go, and I'm not
necessarily disagreeing, this should be a fairly straightforward command or
people will just not bother.

Comment 5

[Dave Miller [:justdave]]

A neat trick I saw used in Majordomo 2.0 is that the documentation has you 
insert two cron jobs that simply call a trigger script with a parameter to tell 
it which trigger it is.  That script will then look at your preferences, and see 
what it's supposed to be doing (if anything) at that point in time.

Comment 6

[Dave Miller [:justdave]]

moving to real milestones...

Comment 7

[Matthew Tuck [:CodeMachine]]

Moving to new Bugzilla product ...

Comment 8

[Joel Peshkin]

This should start as a sanitycheck that can be run from a command line with a
switch to either generate output on error only or regardless and have a return
code appropriate to the result.

Then, this could eventually find its way into a test suite as well.

Comment 9

[Matthew Tuck [:CodeMachine]]

Joel, what do you mean "a test suite" - isn't it already a test suite?

Comment 10

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 11

[Frédéric Buclin]

(In reply to comment #8)
> This should start as a sanitycheck that can be run from a command line with a
> switch to either generate output on error only or regardless and have a return
> code appropriate to the result.
> 
> Then, this could eventually find its way into a test suite as well.
> 

Taking! I didn't have in mind to convert it to t/010sanitycheck.t, but that could be a good idea... except tinderboxes will crash as they have no DB. ./runtests.pl is not supposed to do calls to the DB.

What I had in mind is to have sanitycheck.pl which would be run from the command line or from a cron job, which basically would do nothing more than calling Bugzilla->batch(1) and then get the output from sanitycheck.cgi and send it per email if problems are found. As I'm going to templatize sanitycheck.cgi in bug 312197, I will try to make this possible at the same time.

Comment 12

[Joel Peshkin]

If you are calling sanitycheck from a crontab, you probably also want to make it selectable to either send the results regardless or to send only errors.  A command-line switch for that would be fine.

Comment 13

[Frédéric Buclin]

Attachment: patch, v1

Comment 14

[Max Kanat-Alexander]

Comment on attachment 258054 [details] [diff] [review]
patch, v1

>+my $verbose = 0; # Return all comments if true, else errors only.
>+my $login = '';  # Login name of the user which is used to call sanitycheck.cgi.
>+
>+my $result = GetOptions('verbose' => \$verbose, 'login=s' => \$login);
>+
>+Bugzilla->usage_mode(USAGE_MODE_EMAIL);

  This should actually be USAGE_MODE_CMDLINE. USAGE_MODE_EMAIL is when Bugzilla is being used through the inbound email interface.

>+my $user = new Bugzilla::User({ name => $login })
>+  || ThrowUserError('invalid_username', { name => $login });

  I know this seems strange, but apparently there could be a user in the database with an empty login_name (if somebody manually edited the DB). So we should check to make sure $login isn't empty, also.

>Index: template/en/default/email/sanitycheck.txt.tmpl
>+  # The Initial Developer of the Original Code is Frédéric Buclin

  There needs to be a copyright also, there.

>+[% output %]

  You should FILTER txt here, or you get output like this:

flags.requestee_id
    (<a href="show_bug.cgi?id=4154" title="NEW - This is just another bug">bug 4154</a>)

  Everything else looks great!

Comment 15

[Frédéric Buclin]

Attachment: patch, v2

Keeping USAGE_MODE_EMAIL as per our discussion on IRC (else Bugzilla->login() doesn't let me go further) and setting the Original Developer to Netscape Corp. till someone knows for sure what it should be.

Comment 16

[Max Kanat-Alexander]

Comment on attachment 258077 [details] [diff] [review]
patch, v2

>+# The Initial Developer of the Original Code is Netscape Communications
>+# Corporation. Portions created by Netscape are
>+# Copyright (C) 1998 Netscape Communications Corporation. All
>+# Rights Reserved.

  No, no, this is incorrect. The discussion that I was having with justdave was about something else entirely.

  The correct attribution for new files is their *creator*. The reason that old files say "Netscape" is that Netscape was their creator.

>+Bugzilla->usage_mode(USAGE_MODE_EMAIL);

  I've filed this bug's new blocker so that we can really use USAGE_MODE_CMDLINE now. Just fix that and the above block, and this is r+.

Comment 17

[Frédéric Buclin]

Attachment: patch, v2.1

carrying forward mkanat's r+.

Comment 18

[Frédéric Buclin]

Checking in sanitycheck.cgi;
/cvsroot/mozilla/webtools/bugzilla/sanitycheck.cgi,v  <--  sanitycheck.cgi
new revision: 1.129; previous revision: 1.128
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/sanitycheck.pl,v
done
Checking in sanitycheck.pl;
/cvsroot/mozilla/webtools/bugzilla/sanitycheck.pl,v  <--  sanitycheck.pl
initial revision: 1.1
done
Checking in Bugzilla/Install/Filesystem.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v  <--  Filesystem.pm
new revision: 1.19; previous revision: 1.18
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/email/sanitycheck.txt.tmpl,v
done
Checking in template/en/default/email/sanitycheck.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/email/sanitycheck.txt.tmpl,v  <--  sanitycheck.txt.tmpl
initial revision: 1.1
done

Comment 19

[Sam Folk-Williams]

Attachment: docs patch for sanitycheck email

this bug is just about adding the email/automation functionality, but in looking for where to document i realized there is no documentation about sanity check except in the FAQ (please correct me if I'm wrong). I put this in the administration section. First draft here - let me know what you think.

Comment 20

[Frédéric Buclin]

Comment on attachment 298010 [details] [diff] [review]
docs patch for sanitycheck email

>+    To run the "Sanity Check" script, log in as an Administrator and click the
>+    "Sanity Check" link in the footer.

FYI, admin links are no longer displayed in the footer in Bugzilla 3.2. There is a single link pointing to admin.cgi, a page which lists all possible actions. This can be fixed on checkin, so r=LpSolit

Comment 21

[Frédéric Buclin]

tip:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.79; previous revision: 1.78
done


I also backported this patch to 3.0, keeping only the part about sanitycheck.cgi.

3.0.3:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.70.2.6; previous revision: 1.70.2.5
done

Comment 22

[Frédéric Buclin]

While I'm on it, I used the same backport on 2.20 and 2.22 branches:

2.22.3:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.55.2.13; previous revision: 1.55.2.12
done

2.20.5:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.50.2.16; previous revision: 1.50.2.15
done

Comment 23

[Max Kanat-Alexander]

Added to the Bugzilla 3.2 release notes in bug 432331.