75840 - syncshadowdb needs to be more flexible

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P1)

Description

[Dawn Endico]

some improvements i'd like to make to syncshadowdb. i'm adding these as 
command line options.

mysqldump's for mozilla.org's database are collosal and need to be stored
on a different filesystem from where the bug database lives. make the
location of the tmp file be configurable.

bugzilla.mozilla.org is completely unusable anyway during a mysqldump. I'd
like syncshadowdb to turn off bugzilla during this process.

Doing a mysqldump is a lenghy process and our nightly backup process does two
of them. The first one is done by the process that recreates the shadowdb
and then a second mysqldump command is issued which creates the dump file
that is actually used. I'd like to be able  to disable the automatic 
deletion of the dump created by syncshadowdb and use that file as the 
backup.

going to attach a patch that implement the first two items.

Comment 1

[Dawn Endico]

Attachment: patch to implement -shutdown and -tempdir

Comment 2

[Dave Miller [:justdave]]

the way you implemented -tempdir will only work if -tempdir is the last parameter 
on the command line.

I'd suggest something like this:
Instead of this:
 foreach my $opt (@ARGV) {
do this:
 while (my $opt = shift @ARGV) {

then for your check for -tempdir do this:
 $tempdir = shift @ARGV;

It probably wouldn't hurt to check and make sure $tempdir is defined and that it 
doesn't start with a - (another option instead of the parameter to -tempdir) 
also.

Comment 3

[Matthew Tuck [:CodeMachine]]

*** Bug 91890 has been marked as a duplicate of this bug. ***

Comment 4

[Matthew Tuck [:CodeMachine]]

Two comments regarding the shutdown stuff:

1.  If Bugzilla is already disabled when the sync starts, rather than
overwriting the disabletext (temporarily) and syncing, we should refuse to sync
and complain to the administrator via email.  The rationale for this is that if
the database is down something may well be wrong and we don't want scheduled
syncing processes messing around with things.

2.  If the shutdown text was changed while the sync was occurring, something
weird is going on and we should complain to the administrator via email, and
leave the text as it is.

Comment 5

[Jacob Steenhagen]

Attachment: patch v2

Comment 6

[Jacob Steenhagen]

patch v2 accounts for Dave's comments and half of Matty's.  

For Dave's it uses the my $opt = shift @ARGS that he recommended.

For Matty's, it will abort the attempt to sync if shutdownhtml already exists
unless the -force command line is used.  It does not check to see if the
shutdownhtml has changed during the backup attempt as I'm not 100% sure how we'd
go about that (we'd have to reread the params from data/params) nor am I
convinved that it'll be needed (who would change the shutdown message while the
backup was in progress... esp when every bugzilla page they visit tells them
that bugzilla is down?).
This also impliments a feature briefly talked about in IRC that will wait until
there aren't any open connections to the bugs or shadow_bugs database before
proceeding (it'll only wait 10 minutes before it aborts).

Comment 7

[Zach Lipton [:zach]]

moving

Comment 8

[Jacob Steenhagen]

Patch v2 needs a little more work... it only refuses to run while shutdown if
we're requesting a shutdown.  It should always refuse to run while shutdown
(unless -force is used).

Comment 9

[Dave Miller [:justdave]]

correcting version field lost in product move

Comment 10

[Jacob Steenhagen]

Attachment: patch v3

Comment 11

[Jacob Steenhagen]

Attachment: patch v4

Comment 12

[Jacob Steenhagen]

Found a couple things in v3 that are corrected in v4.  The one that bit me that
hardest testing on landfill is that fact that globals.pl deletes the path
environment variable when it is loaded.  So I added some very simple code that
will try to sniff for the mysql binaries before loading globals.pl (using
`which mysql`).  This should work for the majority of installs, but if the mysql
binaries aren't in your path at all, you will have to hardcode the value for
$mysqlpath to the directory your binaries are in (without a trailing slash).

Comment 13

[Myk Melez [:myk] [@mykmelez]]

I tested the patch on two machines, one with a large bug database and one with a
small one.  On the first machine, I was able to confirm that Bugzilla is shut
down while the syncshadowdb process runs, but the process itself never completed
because my machine ran out of memory.  On the second machine, I was able to
confirm that the syncshadowdb process completes.  Both machines successfully
used the -tempdir option.

I didn't test the new code for finding the mysql binaries, but on b.m.o. anyway
those binaries cannot be found in the default path, so that code is unlikely to
work.  Maybe our solution is to put aliases to them into /usr/local/bin/.

Comment 14

[Jacob Steenhagen]

ln -s is certainly one option for how to fix that.  The other is to add a line
right under the sniffer that tells it where they really can be found:

$mysqlpath = '/usr/bonsaitools/bin';  # Just guessing at this path :)

which would be less changes than what the current setup requires [which is that
you change all the lines where I added the "$mysqlpath/" ].

Comment 15

[Dave Miller [:justdave]]

I think the solution for this is to put a variable in localconfig for the path
to the mysql binaries.  checksetup.pl should feel free to attempt to locate them
and set the variable for you if they're found, instead of prompting the user to
fix the variables, but prompt the user for the path if it can't find them.

I don't like the idea of using "which" to locate it at runtime, because you
never know what the PATH is and who has access to drop arbitrary files in
different places in the PATH (which is exactly why taint mode balks at PATH
being present and tainted).  This also means that the method you're using will
prevent us from getting syncshadowdb to run in taint mode.

Comment 16

[Jacob Steenhagen]

OK, fair enough... I knew the `which` thing was a hack... guess I didn't think
about the -T ramifications (which, incidentially, was why $ENV{PATH} is deleted
in globals.pl :)

Are the mysql binaries used anywhere other than syncshadowdb?

Comment 17

[Dave Miller [:justdave]]

not to my knowledge.  Checksetup.pl doesn't even use them, it uses DBI for
everything.

Comment 18

[Jacob Steenhagen]

Attachment: patch v5

Comment 19

[Jacob Steenhagen]

Here it is, the new and improved v5... the which call is safely tucked away in
checksetup.pl [if that script is ever made to run in taint mode, I'm sure
removal of that line will be the easiest part :) ].

Comment 20

[Dave Miller [:justdave]]

r= justdave, checked in.