X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;ds=sidebyside;f=regress%2FREADME;h=040f87fc11a1878d5bf8e9646c453a81fe8da620;hb=f3fcbb9dcbc80b38e5836c368b520e6e1aabfcf0;hp=e9ebb627dd7199c0547915eeb5f4ad5ffdc8fbd8;hpb=d4827b0558fd1167d32ddb6019b949df10e6b3b1;p=bacula%2Fbacula diff --git a/regress/README b/regress/README index e9ebb627dd..040f87fc11 100644 --- a/regress/README +++ b/regress/README @@ -1,20 +1,51 @@ - Bacula Regression - Kern Sibbald - April 2003 + Bacula Regression + Kern Sibbald This is Bacula's regression script directory. -To set it up, first edit Makefile and set BACULA-SOURCE to point -to your source. +!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! +Warning!!!! Make sure not to run it on the same system +with your production Catalog because the tables will all +be cleared. You can run it on the your production system +if you use a different database. E.g. if your production +system uses MySQL, you can use SQLite here. +!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -Second, make sure that depkgs is in the parent directory of this -directory (i.e. at the same level) and that it is pre-built. + +To set it up, create your personal configuration file, by +copying prototype.conf to xxx.conf or simply editing prototype.conf +directly. + +Then edit your conf file and define appropriate values +for the variables that are in that file. If you want to see +a real example, look at kern.conf, but please don't use my +email address! + +If you are using SQLite, make sure that depkgs is pre-built if it +isn't already: (cd your-depkgs; make sqlite). + +Note, if you use any database other than SQLite, be sure it is not +your production database because Bacula will delete all the tables +and recreate them. With SQLite, a new different database is created, +so it will not affect your production system. + +Using the .conf file, you can now select between any Catalog type: +SQLite, SQLite3, MySQL, or PostgreSQL. Be aware, however, if you +use an installed database on a production server, running these +tests will delete all the tables !!!!!!!!!!!!!!!!!! I run my +tests on a non-production machine, and in addition, I normally use +SQLite as the database, while my production uses MySQL. Then do: + ./config xxx.conf make setup -You run the above one time. +You run the above one time. This will build a Makefile from +Makefile.in and your xxx.conf file, copy the Bacula source, +configure, build it, and configure all the Bacula scripts +and conf files. If you change your source, you will need to +redo this command. Then you can run any of the tests in the tests subdirectory. Each test whose name ends in -root requires you to be root for @@ -22,32 +53,46 @@ a resonable run. Each test is totally independent of any other test. Aside from the required "make setup", each test is totally self-initalizing and should clean up after itself. -Not all the tests yet report OK. This is simply because there are -some spurious differences that I haven't yet taken the time to -eliminate. The working scrips as of 24 Apr 03 are: +All the tests expect you to execute them from the main regress +directory! -backup-bacula-test -sparse-test -compressed-test -sparse-compressed-test -two-jobs-test -wierd-files-test +You can run all the disk based tests by doing: -The tests expect you to execute them from the main regress -directory! + ./do_file + +The disk based tests are totally separate from any production +system, provided you have configured the database appropriately +as noted above. + +You can run all the disk and most of the tape tests by doing: + + ./do_all + +======== Important !!! ============ +When running the tape tests, Bacula will write on any tape that +is in the tape drive that you have configured. If it is a production +Bacula tape, it will be destroyed. If you have configured an Autochanger, +Bacula will write on the tapes in slots 1 and 2 thus destroying any +information on those tapes, even if they are Bacula production tapes. +=================================== + +Each of the above calls one or more scripts. By looking at the +scripts available in this directory, you can see that there are a number +of options for running tests. You can run them individually as: tests/two-jobs-test -or all tests: +or all non-root tests (my normal testing under my account) + + ./all-non-root-tests + +or all tests (I only run these before a production release): su ./all-tests -or all non-root tests - - ./all-non-root-tests after running the root tests, while still root, it is a good idea to do: @@ -55,3 +100,27 @@ to do: make reset this cleans up any files that may be created with root permissions. + +If you want to add more tests, do so by putting the shell script +in the tests subdirectory. Be careful when adding (or better not) +new clients, pools, and such to the test-bacula-dir.conf.in file +as it may invalidate a good number of tests, which respond to +questions by answering with a number (i.e. the order of the selection +list is known). It might be better to add your own testb-bacula... +configuration file. + +To avoid re-doing a make setup if you have made a change to the +conf files, and you do not need a new copy of the source, you can simply do: + + make sed + +Debugging failed tests: +The simplest thing to do is to edit tests/xxxx where xxxx is the name of +the test, and change the line "set_debug 0" to "set_debug 1". If the test has +not been updated to have the debug variable, please notify Kern, and I +will be happy to fix it -- I am upgrading them one at a time. + +Also, if you run from time to time on a computer that is not connected +to the network, please be sure that "hostname" is set to "localhost", +otherwise, your tests may fail because the hostname used by Bacula's +./configure cannot be properly resolved.