]> git.sur5r.net Git - bacula/bacula/blobdiff - regress/README
ebl fix display_log to use LogId instead of Time for order
[bacula/bacula] / regress / README
index e9ebb627dd7199c0547915eeb5f4ad5ffdc8fbd8..040f87fc11a1878d5bf8e9646c453a81fe8da620 100644 (file)
@@ -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.