You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(7) |
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(3) |
Nov
(2) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(56) |
Jun
(95) |
Jul
(51) |
Aug
(34) |
Sep
(98) |
Oct
(30) |
Nov
(10) |
Dec
(41) |
2008 |
Jan
(15) |
Feb
|
Mar
(11) |
Apr
(2) |
May
(2) |
Jun
(4) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(12) |
Nov
|
Dec
(2) |
2009 |
Jan
(15) |
Feb
(2) |
Mar
(6) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Kern S. <ke...@si...> - 2010-08-03 15:21:26
|
Hello, This is to let you know that we will be releasing Bacula 5.0.3 this week, so for packagers, it would be a good time to take a look at the SF repository to see if there are any changes need to make packages. It is always good to have the "final" package source in the final release we make. Best regards, Kern |
From: Kern S. <ke...@si...> - 2010-02-25 15:12:58
|
Hello, Bacula version 5.0.1 source code and Windows (32/64 bit) binaries have been released to Source Forge (thanks Eric). This is a major bug fix release including a few directives that have been rewritten, one new directive, and some different directive behavior (see the release notes below). As is usual for a patch release (last digit changes by one), this version is compatible with the 5.0.0 database and with prior clients. However, you *must* upgrade all components that are on any one machine (that is you must upgrade your Director, Storage daemon, and File daemon at the same time, if they reside on the same machine). Note, Bacula does not normally uninstall previous versions, and we have changed the shared object naming convention, so you might want to first save your configuration files then uninstall the old Bacula using the old Bacula uninstall prior to installing the new one. If you do not, it should not be serious, but you may be left with some older Bacula shared objects that are not used and hence wasting a small amount of disk space. If you are upgrading from version 3.0.x or prior, please see the full release notes as you must do a database upgrade. When updating from 5.0.0 to this release there is no database upgrade needed. Scott has made a number of changes and improvements in the rpm packaging over the past few weeks since version 5.0.0 was released, so he will probably be releasing the 5.0.1 rpms quite soon. Thanks for using Bacula :-) Best regards, Kern ============= Performance Note ================== Some of you have encountered performance problems with your database (mainly with MySQL) with Bacula version 5.0.0. This is mainly because we've changed the SQL query used for restore, accurate jobs and base jobs. We have extensively tested this change, and though it should be a little bit slower than the previous versions, on a well configured database it should run extremely well. We strongly recommend to avoid the temptation to add new indexes. In general, these will cause very significant performance problems in other areas. A better approch is to carefully check that all your MySQL memory configuation parameters are are suitable for the size of your installation. If you backup millions of files, you need to adapt the database memory configuration parameters concerning sorting, joining and global memory. By default, sort and join parameters are very small (sometimes 8Kb), and having sufficient memory specified by those parameters is extremely important to run fast. If adjusting your MySQL memory configuration values does not solve your problem, you can also consider switching to PostgreSQL, which performs much better with Bacula on big installations (many millions of files per Job). However for large installations, you will also need to adjust the default PostgreSQL memory configuration parameters. ========================================== Release Notes for Bacula 5.0.1 Bacula code: Total files = 1,081 Total lines = 217,272 (Using SLOCCount) !!!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! The Allow Duplicate Jobs directive has been significantly reworked, and the default value has changed. See below. Truncate On Purge has been totally rewritten. See the new features section of the manual. When Volume Poll Interval is set in the SD DEVICE configuration, (default 5 mins), after a certain number of polling tries (approx 10) polling will stop and the operator will be asked to resolve the problem. Previously there was no limit, and an error message could be produced at each poll attempt. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Changes since 5.0.0 ------------------- - We believe that we have resolved most of the problems concerning canceled or failed jobs being "stuck" in the Director. There is one outstanding problem in the SD when canceling jobs that we will fix in the next major release. If you see jobs that seem to be stuck, in general issuing a cancel command in bconsole should now make them go away. Directives: - The default for "Allow Duplicate Jobs" has been changed from no to yes. If you use this directive, please check your conf file, and note the next two items !!!!!!!!!!!!!!!!!!! - AllowHigherDuplicates disabled. It did not work as documented and was confusing. - New directive "CancelLowerLevelDuplicates" See New Features section in the manual. - Truncate on Purge rewritten. See New Features section in the manual. Bug fixes: 1448 1466 1467 1468 1476 1481 1486 1488 1494 1497 1499 1501 1505 1509 1513 - Ensure SD asks for help when looping even if poll set. Fixes bug #1513. - Fix three-pool regress bug - Modify bacula.spec fixes bug #1505 - This version fixes an issue where the console window would start out docked. It is fixed by initiating the variables in the Pages class wi constructor. - Fix make_catalog_backup.pl fails when catalog db is on other host - Apply MacOSX installer patch from bug #1509 - Apply fix to previous fix of Copy problem. Fix proposed by reporter o #1476 - Fix bug #1501 -t does not print errors - Apply SQLite3 update fix from bug #1497 - Apply bashism fix for diskchanger.in script from bug #1499 - Apply rpm fix for Sci Linux from bug #1494 - Take most recent Ukranian po from bug #1448 - Probable fix for Copy/Migration bug #1476 - Fix bug #1488 -- avoid recursion and race conditions in messages.c - Upgrade cats library also to 5.0.0 - Fix missing console page in bat - Add bat help files to Window install - Improve Windows upgrade to ensure old FD is shutdown - Fix bug #1481 -- bat consumes all console file descriptors - Backport truncate on purge from 5.1.x - Fix bug #1486 -- bat doesn't show any errors on command-line - Update the bsock error URL - Correct .my.cnf umask in make_catalog_backup.pl - Apply fix for dbcheck use by make_catalog_backup.pl - Fix seg fault in bscan from new comment field - Allow multiple CNs when using TLS - Fix seg fault in SQlite driver - Make shared libs version the same as the Bacula release version - Remove file_index sequential check - Fix #1466 about Bogus pruning message For Packagers: 1. The default query.sql file is now, except for some comments, empty. The old file, which we no longer support (it is impossible or difficult to make it work on every backend, and the queries are mostly contributed) can be found in <bacula-source>/examples/sample-query.sql. The sample file is not installed by the Makefiles 2. When you install the mtx-changer script, you must also install mtx-changer.conf if it does not exist. This new file (mtx-changer.conf) is required for mtx-changer to work, but it is a user configurable file, so on any update, any existing file should not be overwritten. 3. Bat should be built on every platform that is capabable of running Qt. However, the Qt code is changing rather quickly and is not always compatible from version to version. We have built and verified bat on Qt 4.3.4. We strongly recommend that you do not build and distribute bat with any other version of Qt unless you personally test it. To build against Qt 4.3.4, download the depkgs-qt package from the Bacula Source Forge download location, read the README file and follow the instructions. If you are building for Bacula version 5.0.0, please ensure that you do not have qmake-qt4 loaded on your system. If you do, either remove it or rename it before trying to build bat. If you do not, bat will probably be built using the shared objects on your system. For Bacula 5.0.1 and later, this problem (bug) does not exist. depkgs-qt does not install Qt on your system, nor does it interfere with you having any other version of Qt installed on your system. Once you build bat with depkgs-qt, it should *not* use the Qt shared objects, but rather they will be linked into the program. After fully installing bat (make install), you can run "ldd bat" to see what shared objects it will use. If any Qt shared objects are referenced, something has gone wrong. 4. Unless absolutely necessary, we recommend that you do not define any special library environment variables that apply to the ./configure -- for example: LIBDIR=/... ./configure <your-options> is strongly discouraged. Doing so, could potentially cause Bacula to be linked against the wrong shared objects. 5. The Bacula project strongly recommends that you install Bacula into a single directory, with a few minor exceptions such as the MySQL or PostgreSQL databases. Preferrably this should be /opt/bacula. The full recommendation is: #!/bin/sh # Recommended configure script for Bacula prefix=/opt/bacula email=xxx@yyy.zz CFLAGS="-g -O2 -Wall" \ ./configure \ --sbindir=${prefix}/bin \ --sysconfdir=${prefix}/etc \ --docdir=${prefix}/html \ --htmldir=${prefix}/html \ --with-working-dir=${prefix}/working \ --with-pid-dir=${prefix}/working \ --with-subsys-dir=${prefix}/working \ --with-scriptdir=${prefix}/scripts \ --with-plugindir=${prefix}/plugins \ --libdir=${prefix}/lib \ --enable-smartalloc \ --enable-tray-monitor \ --enable-bat \ --with-mysql \ --with-dump-email=${email} \ --with-job-email=${email} \ --with-smtp-host=localhost \ --with-baseport=9101 Obviously, the email, and some of the minor options (mysql, postgresql, ...) can be changed to suit your distribution, but the directory names defined above are strongly recommended, and over time the default values in the bacula-dir.conf and bacula-sd.conf will reflect these choices. If you have any questions about this or would like a detailed document describing our recommendations including packaging requirements, please send an email to the bacula-devel list. 6. Starting with Bacula version 3.0.0 up to Bacula 5.0.0, the shared libraries that Bacula uses by default are named xxx-1.0.0. Starting with Bacula 5.0.1, we are going to name the libraries using the Bacula version. So in Bacula 5.0.1, the libraries will be named xxx-5.0.1. With future versions, the last digit may or may not change when we distribute patch updates (i.e. the last digit of the version changes). This will depend on whether or not we have changed something in the library. Hopefully this new procedure will resolve some of the incompatibility problems between different versions of the shared objects. 7. The default build option for bconsole is conio (my own little console routines). I did this because some years ago, readline was very difficult to maintain -- it and where it was found seemed to change on every release. This generated at the time a number of support problems. It seems to me that since then there have been very few problems with readline. As a consequence, I have no problem if you want to make bconsole with readline enabled. It will actually give some very nice new bconsole command completion functionality that Eric has written. Bottom line: feel free to use readline or not as you please. ========================================================== |
From: Kern S. <ke...@si...> - 2010-02-16 15:37:09
|
Hello, I have switched the regression scripts to that they will do the testing against Branch-5.0 rather than master. This will be done automatically the next time you do a "git pull" or during the next nightly-disk regression you use. After version 5.0.1 is released, I will switch it back to doing regressions against our development master branch. Many thanks for your testing. Best regards, Kern |
From: Kern S. <ke...@si...> - 2010-02-12 19:07:35
|
Hello, This is to let you know that if all goes well, we will be releasing Bacula version 5.0.1 this weekend, or perhaps early next week. It is principally a bug fix to Bacula 5.0.0, but also consists of a redesign of the Truncate on purge feature that did not work correctly. For packagers, there are a few things to note for Bacula version 5.0.0 and later. 1. The default query.sql file is now, except for some comments, empty. The old file, which we no longer support (it is impossible or difficult to make it work on every backend, and the queries are mostly contributed) can be found in <bacula-source>/examples/sample-query.sql. The sample file is not installed by the Makefiles 2. When you install the mtx-changer script, you must also install mtx-changer.conf if it does not exist. This new file (mtx-changer.conf) is required for mtx-changer to work, but it is a user configurable file, so on any update, any existing file should not be overwritten. 3. Bat should be built on every platform that is capabable of running Qt. However, the Qt code is changing rather quickly and is not always compatible from version to version. We have built and verified bat on Qt 4.3.4. We strongly recommend that you do not build and distribute bat with any other version of Qt unless you personally test it. To build against Qt 4.3.4, download the depkgs-qt package from the Bacula Source Forge download location, read the README file and follow the instructions. If you are building for Bacula version 5.0.0, please ensure that you do not have qmake-qt4 loaded on your system. If you do, either remove it or rename it before trying to build bat. If you do not, bat will probably be built using the shared objects on your system. For Bacula 5.0.1 and later, this problem (bug) does not exist. depkgs-qt does not install Qt on your system, nor does it interfere with you having any other version of Qt installed on your system. Once you build bat with depkgs-qt, it should *not* use the Qt shared objects, but rather they will be linked into the program. After fully installing bat (make install), you can run "ldd bat" to see what shared objects it will use. If any Qt shared objects are referenced, something has gone wrong. 4. Unless absolutely necessary, we recommend that you do not define any special library environment variables that apply to the ./configure -- for example: LIBDIR=/... ./configure <your-options> is strongly discouraged. Doing so, could potentially cause Bacula to be linked against the wrong shared objects. 5. The Bacula project *strongly* recommends that you install Bacula into a single directory, with a few minor exceptions such as the MySQL or PostgreSQL databases. Preferrably this should be /opt/bacula. The full recommendation is: #!/bin/sh # Recommended configure script for Bacula prefix=/opt/bacula email=xxx@yyy.zz CFLAGS="-g -O2 -Wall" \ ./configure \ --sbindir=${prefix}/bin \ --sysconfdir=${prefix}/etc \ --docdir=${prefix}/html \ --htmldir=${prefix}/html \ --with-working-dir=${prefix}/working \ --with-pid-dir=${prefix}/working \ --with-subsys-dir=${prefix}/working \ --with-scriptdir=${prefix}/scripts \ --with-plugindir=${prefix}/plugins \ --libdir=${prefix}/lib \ --enable-smartalloc \ --enable-tray-monitor \ --enable-bat \ --with-mysql \ --with-dump-email=${email} \ --with-job-email=${email} \ --with-smtp-host=localhost \ --with-baseport=9101 Obviously, the email, and some of the minor options (mysql, postgresql, ...) can be changed to suit your distribution, but the directory names defined above are strongly recommended, and over time the default values in the bacula-dir.conf and bacula-sd.conf will reflect these choices. If you have any questions about this or would like a detailed document describing our recommendations including packaging requirements, please send an email to the bacula-devel list. 6. Starting with Bacula version 3.0.0 up to Bacula 5.0.0, the shared libraries that Bacula uses by default are named xxx-1.0.0. Starting with Bacula 5.0.1, we are going to name the libraries using the Bacula version. So in Bacula 5.0.1, the libraries will be named xxx-5.0.1. With future versions, the last digit may or may not change when we distribute patch updates (i.e. the last digit of the version changes). This will depend on whether or not we have changed something in the library. Hopefully this new procedure will resolve some of the incompatibility problems between different versions of the shared objects. 7. The default build option for bconsole is conio (my own little console routines). I did this because some years ago, readline was very difficult to maintain -- it and where it was found seemed to change on every release. This generated at the time a number of support problems. It seems to me that since then there have been very few problems with readline. As a consequence, I have no problem if you want to make bconsole with readline enabled. It will actually give some very nice new bconsole command completion functionality that Eric has written. Bottom line: feel free to use readline or not as you please. Best regards, Kern ------------------------------------------------------- |
From: Kern S. <ke...@si...> - 2010-02-03 10:58:25
|
Hello, Bat: We have received a number of problem reports and bugs about building and running bat, and unfortunately our documentation was insufficient, which is hopefully now corrected. Bat is built with the Qt packages for doing the GUI. I have worked with a lot of different GUI packages (Sun/Solaris, Mac, Windows, OS/2, wxWidgits, X, Qt3, Qt4, ...) and I prefer Qt4 over all the other ones. However, it is very version dependent, which is a bit of a pain. As a consequence, the only way to get a stable working version of Bat is to build it on the version of Qt where we have built and tested it. That version is Qt 4.3.4 (default on Ubuntu 8.04). So to get bat to build correctly, we have released a depkgs-qt that contains the source code for Qt 4.3.4, and if you are trying to build Bat, either you should load the Qt 4.3.4 binaries on your system, or download our depkgs-qt release from Source Forge and built Qt 4.3.4 there. Building from depkgs-qt does not install Qt on your system, it is just used in the Bat build. We have updated the manuals (5.0.0 and 5.1.x-development) on the web site to have more detailed instructions on building Bat. Hopefully this will resolve any and all problems you may be having. Sorry for the inconvenience. Please see: http://www.bacula.org/5.0.x-manuals/en/main/main/Installing_Bacula.html#SECTION001250000000000000000 for details. ============================== ActionOnPurge: --- Please do not use!!! Action on purge is a new directive in 5.0.0, which permits automatically truncating your volumes with the volume is purged. Unfortunately, this new code is not very robust and in some cases can lead to problems. We strongly recommend that you avoid using this directive. We are rewriting the implementation for version 5.0.1 where it will be a very useful feature. Best regards, Kern |
From: Kern S. <ke...@si...> - 2010-01-25 09:25:00
|
Hello, Bacula version 5.0.0 will be released today. For those of you who are packagers, I strongly encourage you to use the .spec files that are in platforms/redhat for making your .rpm releases. As usual, they will very likely need a bit of work, but they do have quite a few bug fixes that I have added over the past months, and in addition, I have separated bat, mtx, and the docs from the main bacula.spec, which simplifies things quite a bit. In fact, the bat build uses depkgs-qt, which *should* build on any machine, in particular RedHat and CentOS where we should be releasing bat. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-10-17 15:58:32
|
Hello, In principle, Bacula version 3.0.3 is now ready release. We will run a few addition overnight tests with the code as it is, then release it -- probably Sunday or more likely Monday. In case of any serious problems, it can still be updated. There still remain a few bugs to fix, but since 3.0.3 already has a good number of bug fixes, we would like to get it out rather than waiting any longer. If you want a copy before the release, you can get it with the following commands: git clone git://bacula.git.sourceforge.net/gitroot/bacula/bacula xxx cd xxx git checkout -b 3.0.3 you will then have a 3.0.3 branch defined and the code that we plan to release will be in xxx, which can be any directory name you want. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-09-18 15:28:08
|
Hello, We would like to release a bug fix version 3.0.3 in the near future (before mid-October), and this is just to let you know that if you want to experiment with it, it is in branch "3.0.3" in the Git repository. If you are running nightly regression tests using the nightly-disk script, we are going to temporarily force your regression tests to run on the 3.0.3 branch. Once the release is made, we will switch you back to the master branch. As with all scripts and multiple OSes, there is always a possibility something goes wrong so don't worry too much :-) Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-08-24 11:29:53
|
Hello, Some of you who are running regression tests have upgraded the tests to run with GIT -- many thanks. However, our GIT repo has been moved, and your tests are still running old Bacula code. Please make the following modification to your GIT repo where you are running the regression tests: cd <Bacula-git-main-directory> edit .git/config (change the following line ... url = git://bacula.git.sourceforge.net/gitroot/bacula to url = git://bacula.git.sourceforge.net/gitroot/bacula/bacula That should do it. You can test if it is working by doing: git pull Many thanks, Kern |
From: Kern S. <ke...@si...> - 2009-08-20 12:00:56
|
Hello, This is to inform you that yesterday, Source Forge changed the URL of our Bacula source GIT repository. They did so to permit projects to have multiple GIT repositories -- (very good!). Those of you, especially those running nightly regression testing, who have cloned the GIT repository will need to make a minor modification to the config file or to delete the old repository and clone a new one. The simplest solution is to: cd <your-repo-directory>/.git (edit the file "config") and change the line that reads: url = git://bacula.git.sourceforge.net/gitroot/bacula to url = git://bacula.git.sourceforge.net/gitroot/bacula/bacula That is just append a /bacula to the end of the URL. If you do not feel at ease directly editing the git config file, then: rm -rf <your-repo-directory> git clone git://bacula.git.sourceforge.net/gitroot/bacula/bacula <your-repo-directory> Sorry for the inconvenience ... Regression testing: Since we have switched to git, a number of you who were previously doing nightly testing have not yet moved to git. It takes a bit of work, especially if you are running on a system like CentOS or RedHat where there is no git package, but we would really appreciate the effort to put in place nightly regressions. Running regression tests helps you ensure that when we release a new version, it will work on your system without unpleasant surprises! If you have not done regression testing, and you have a few extra cycles to spare every night (or when you want), it is not very hard to set up Bacula regression testing on a machine. It is reasonably well documented in the Developer's guide, and if you have any questions or problems, you can feel free to email us on the bacula-devel email list. Anyone can do regression testing and post it to the Bacula regression dash board: http://regress.bacula.org/index.php?project=bacula If you do decide to do regression testing, it can be helpful for us if you send the "name" you use to identify your regression tests with your email address. That way, if we detect any problems and need to understand what your environment is, we can more easily contact you. For those of you who have been testing (Frank and DassIT): many thanks. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-08-04 14:45:12
|
Hello, If you are currently running nightly regression scripts for Bacula, I thank you very much because your test results help us find subtle OS dependent bugs. Due to the change from SVN to git, you will need to make some minor modifications to get the regression scripts running again. (Thanks to Frank Sweetser for making the svn to git regress patch). First ensure that git is installed on your machine. If you currently have the following directory structure for running the regression scripts: xxxx xxxx/bacula xxxx/regress Then please copy "xxxx/regress/config" to some temporary location, e.g. cp xxxx/regress/config /tmp/config then do the following, which will delete and replace your xxxx directory by the git version. rm -rf xxxx git clone git://bacula.git.sourceforge.net/gitroot/bacula xxxx cp /tmp/config xxxx/regress/config where in each case, replace xxxx by the full path to directory containing bacula and regress. Once you have done the above, the regression scripts can be run exactly as they were before. In fact, if you have a cron job that does it, it should continue to work as before. Thanks for testing and sorry for the inconvenience. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-07-19 15:44:24
|
Correction: The Release-3.0.2 tag is now set at release 9074 Kern |
From: Kern S. <ke...@si...> - 2009-07-19 14:43:53
|
Hello, If you are a packager or a translator, please be aware that I have now tagged version 3.0.2 in the SVN. If there are no problems, it will probably be released on Tuesday. There there are problems, I may add a few fixes prior to the final release (unlikely). The release is marked with a tag Release-3.0.2 and is revision 9066. For packagers, you can start working on packaging with what is currently in the SVN. For documentors, please be aware that the docs files have been updated to have the new date and version number, and the po translation files have been updated to match the current source code, so please do "svn update" before continuing your work. I have posted the most recent Spanish and German translation of the manual to the web site (the French manual is not currently under active development). For regression testers, many thanks for testing so many different platforms. It really helps us. If you are not aware, the results of regression testing are displayed in our CDash dashboard at: http://regress.bacula.org/index.php?project=bacula Thanks for all your help. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-07-01 20:02:09
|
Hello, This Bacula status report will discuss the following items: - Up coming Release 3.0.2 - Discontinuing version 2.4.x - Bacula Enterprise Edition - Foundation Course - Email problems - New development strategy Up coming Release 3.0.2: We have been working on bug fixes and a few minor new features that are going into version 3.0.1, and if all goes well, we will release version 3.0.2 sometime shortly after mid-July. In the mean time, the SVN seems quite stable. There are still a number of bugs outstanding, and we hope to fix most of them in the next two weeks. Discontinuing version 2.4.x: As I previously discussed, we are discontinuing version 2.4.x. This is because we are focusing all our Bacula project effort on the current trunk (3.0.x). As a consequence version 2.4.4 will no longer be supported; we will no longer produce pataches for it; and bugs will only be considered if they seem to be relevant to the current development version (3.0.x). This doesn't mean we will have extra time on our hands, because we are effectively replacing the old 2.4.x branch by the Bacula Enterprise Edition (see the next item). Bacula Enterprise Edition: As I noted in a previous email (quite a while ago), Bacula Systems will be releasing a version of Bacula that will be targeted for the enterprise market -- in fact, high end enterprises. It will be announced shortly and will be called the Bacula Enterprise Edition. This version of Bacula will effectively replace the old 2.4.x branch. As you probably know, many "commercial" branches of Open Software projects add additional features to their enterprise editions and do not release the source code -- they effectively take a major portion of the project proprietary. This will not be the case with the Bacula project and Bacula Systems -- all the code we develop will be released. In fact, the Enterprise Edition will have fewer features than the "community" version. So, if you want to use the enterprise edition, you will be able to, but the Bacula project already has its hands full with the development stream, so we will not be supporting it. The closest analogy to Bacula - Bacula Systems is Fedora - Red Hat, where you can get the source code for both, but if you want support for the Red Hat Enterprise Linux version, you must have a subscription. Some of you may not want to hear about enterprise stuff, and I can understand that. I will try to avoid "commercial" messages as much as possible on these lists, but Bacula Systems and the enterprise market are very important to me for two main reasons: 1. I am spending a lot of time on enterprise stuff 2. I believe the enterprise market (with their financial weight) is the key to getting a host of new and interesting features into Bacula. If you read my 3.0.0 release message, you should have gotten a good appreciation for the number of new features that were sponsored by enterprises for that version. Foundation course: Over the past 6 months I have been devoting a large fraction of my time to develop Bacula training, which is critical for the enterprise market. The first part -- a Bacula Foundation Course is now ready, and the next course will be given by me in Yverdon-les-Bains, Switzerland, the 7th, 8th, and 9th of July. This course if for people who do not yet know Bacula (if you have built and installed it, this is not a course for you). If you are interested, please see the Bacula web site (www.bacula.org) or the Bacula Systems web site (www.baculasystems.com). I am now beginning work on the Advanced Course, which should interest many of you, but I expect that it will take 4-6 months before this course will be ready. Email problems: I've been having serious problems with email lately for two reasons: 1. I have not received a good number of emails sent to me. 2. The emails are coming into my inbox faster than I can deal with them. Problem 1 seems to be due to the fact that my backup relay server stopped relaying email. Thanks to Marco for figuring this out -- it was very annoying and should now be fixed. Problem 2 isn't getting much better, but hopefull will over the next month or two. Bottom line: I am sorry if you sent me email and I have not reponded. If this is the case please ping me as I may have never received your email. New development strategy: One part of development that has always bothered me was when we get close to a release, we must slow down, and finally "freeze" the development SVN to ensure that the new release is stable. I've taken a good look at Open Source tools that can alleviate a lot of these problems -- in particular Bazaar and Git, and after a lot of thought, we will be converting the base part of the Bacula source repository from Subversion to Git. If all goes well this will happen around mid-July. If you currently use our SVN repository to pull versions of Bacula, you should have absolutely no problem switching to git. However, if you are a developer and do commits, using git is a whole different story -- it is much more powerful, and thus different from Subversion and consequently more complicated. I would recommend to all developers to start learning git. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-04-30 07:49:50
|
Hello, This is just to let you know that I have cut Bacula version 3.0.1 in the SVN, and will be uploading it to SourceForge today. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-04-12 09:41:52
|
Hello, This is to let you know that you should turn off your 2.4 branch testing as the branch is now no longer in need of testing -- it will not be maintained any further. I have modified the normal nightly-* scripts in the branch simply to exit, so in any case, even if you do not turn it off, it should just stop immediately. Some of you are running tests with broken configurations: this typically shows up by huge numbers of "false" failures -- i.e. more than half the tests fail. Please periodically check the ouput, and if your tests are failing in large numbers and other peoples tests are not, please examine the output. Typical reasons for "false" failures: 1. You are running with a host name other than "localhost" and you have not defined that host in your /etc/hosts file (i.e. using the host name as an address causes the DNS lookup to fail). 2. Improper setup of PostgreSQL -- typically this is because you have not defined the proper character encoding format. It should be SQL_ASCII (if I remember right). ... Many thanks for all your help testing. It really has helped me enormously to have testing on so many different machines -- often there are subtle differences, and most regressions run fine, but on some version of some OS on some hardware the regress fails. Because of your testing, I have resolved a good number of such timing/OS/hardware dependent problems. Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-04-07 06:29:41
|
On Tuesday 07 April 2009 02:51:01 Dan Langille wrote: > Kern Sibbald wrote: > > Hello packagers, > > > > We will be releasing Bacula version 3.0.0 shortly (within a week or two), > > so it might be a good time to look at packaging it. There are a number > > of new challenges: > > One thing I was pleased to see: > > 06-Apr 20:48 ducky-dir JobId 0: Warning: Encoding error for database > "bacula". Wanted SQL_ASCII, got UTF8 Yes, you can than Eric Bollengier for that -- a nice touch to reduce user pain and support requests for our PostgreSQL users :-) > > This will help quite a bit. |
From: Dan L. <da...@la...> - 2009-04-07 00:51:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kern Sibbald wrote: > Hello packagers, > > We will be releasing Bacula version 3.0.0 shortly (within a week or two), so > it might be a good time to look at packaging it. There are a number of new > challenges: One thing I was pleased to see: 06-Apr 20:48 ducky-dir JobId 0: Warning: Encoding error for database "bacula". Wanted SQL_ASCII, got UTF8 This will help quite a bit. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknao3UACgkQCgsXFM/7nTyuDACeI4hn9OYqJJ/mnH7XDdmdHS4F NGMAoNZycdgVSWmp93NKQ7RPFHkjsoCE =RQj9 -----END PGP SIGNATURE----- |
From: Dan L. <da...@la...> - 2009-03-29 21:25:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kern Sibbald wrote: > On Sunday 29 March 2009 21:30:14 Dan Langille wrote: >> Phil Stracchino wrote: >>> Scott Barninger wrote: >>>> Kern and I have had some offline discussion previously on this subject. >>>> The current RPM build offers 2 options, one to place files with LSB >>>> compliance and a second to place files as Kern has advocated and which >>>> is how Bacula Systems is delivering binaries. >>>> >>>> My 2 cents worth is that packages published by the project on >>>> sourceforge should respect LSB and distribution (linux or BSD) >>>> guidelines. The advantages of this approach are: >>>> >>>> 1. we don't get emails from people complaining about file placement >>>> 2. we don't suffer hesitation from people who are strongly in favor of >>>> LSB 3. it creates a differentiator for Bacula Systems. >>>> >>>> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote: >>>>> Discussion trimed to devel & beta >>> FWIW, I have *always* used the /opt/bacula layout. It puts the entire >>> Bacula installation in one place separate from everything else on the >>> machine, and makes it trivial to (for example) install Bacula on an >>> otherwise bare disk booted from a CD, then do a full system restore >>> without overwriting any active files. One could, for instance, boot >>> from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it >>> from a USB stick (as we were discussing recently). >>> >>> The problem with slavish adherence to things like the LSB is that it >>> isn't always the best solution for everything. >>> >>> "Our corporate policy says we always do this." >>> "That's fine, but this won't work if you do that." >>> "But corporate policy says..." >>> >>> One size does not fit all. Standards are great, but sometimes you have >>> to recognize that there are special cases for which the standard is not >>> the best solution, and that sometimes trying to make them conform to >>> "the standard" is actively harmful. The trick is to recognize the >>> occasions upon which applying "the standard" is not appropriate. >> When it comes to the official port/package/whatever of a given OS, it >> must adhere to the standards set by that OS. Hence, I can't see the >> FreeBSD port doing anything other than what it's doing now. >> >> I don't think anyone is suggesting otherwise. > > Yes, I am suggesting that all distros should use the Bacula recommended > configuration. We can then automate a lot of nice stuff. > >> I do see the benefits in providing a solution which contains a >> completely self-contained installation of Bacula. I'd welcome someone >> working on that for FreeBSD. >> >> FWIW, in case, if I were recovering a failed box on new hardware, my >> first step would be installing the OS, then Bacula, and going from there. > > Unfortunately, life is generally much more complicated than that -- first, how > do you recover Bacula? Without your bacula-dir.conf, bacula-sd.conf, > bacula-fd.conf files, plugins, modifications to scripts such as the > autochanger, ... you will have problems. The new Bacula proposed > installation permits very easy restoration of all that. > > On my system, the backup of the catalog, *all* bacula files, and a snapshot of > my hard disk configuration are all done in one simple script -- I don't have > to worry about missing a file because the install has put files all over the > place. As I say, it is for each to choose ... If said scripts use variables for the directories, customizing these to suit is easier. It is also good practice. If we do that, then the particular OS can adhere both their users expectations and those of Bacula. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknP5zQACgkQCgsXFM/7nTwOIACg/13QWp+ymjHu+O7FIjw+A1Jd K0wAnRsQd8CR1/viemj/jXfRbl35id7w =gfYe -----END PGP SIGNATURE----- |
From: Kern S. <ke...@si...> - 2009-03-29 20:16:01
|
On Sunday 29 March 2009 21:30:14 Dan Langille wrote: > Phil Stracchino wrote: > > Scott Barninger wrote: > >> Kern and I have had some offline discussion previously on this subject. > >> The current RPM build offers 2 options, one to place files with LSB > >> compliance and a second to place files as Kern has advocated and which > >> is how Bacula Systems is delivering binaries. > >> > >> My 2 cents worth is that packages published by the project on > >> sourceforge should respect LSB and distribution (linux or BSD) > >> guidelines. The advantages of this approach are: > >> > >> 1. we don't get emails from people complaining about file placement > >> 2. we don't suffer hesitation from people who are strongly in favor of > >> LSB 3. it creates a differentiator for Bacula Systems. > >> > >> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote: > >>> Discussion trimed to devel & beta > > > > FWIW, I have *always* used the /opt/bacula layout. It puts the entire > > Bacula installation in one place separate from everything else on the > > machine, and makes it trivial to (for example) install Bacula on an > > otherwise bare disk booted from a CD, then do a full system restore > > without overwriting any active files. One could, for instance, boot > > from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it > > from a USB stick (as we were discussing recently). > > > > The problem with slavish adherence to things like the LSB is that it > > isn't always the best solution for everything. > > > > "Our corporate policy says we always do this." > > "That's fine, but this won't work if you do that." > > "But corporate policy says..." > > > > One size does not fit all. Standards are great, but sometimes you have > > to recognize that there are special cases for which the standard is not > > the best solution, and that sometimes trying to make them conform to > > "the standard" is actively harmful. The trick is to recognize the > > occasions upon which applying "the standard" is not appropriate. > > When it comes to the official port/package/whatever of a given OS, it > must adhere to the standards set by that OS. Hence, I can't see the > FreeBSD port doing anything other than what it's doing now. > > I don't think anyone is suggesting otherwise. Yes, I am suggesting that all distros should use the Bacula recommended configuration. We can then automate a lot of nice stuff. > > I do see the benefits in providing a solution which contains a > completely self-contained installation of Bacula. I'd welcome someone > working on that for FreeBSD. > > FWIW, in case, if I were recovering a failed box on new hardware, my > first step would be installing the OS, then Bacula, and going from there. Unfortunately, life is generally much more complicated than that -- first, how do you recover Bacula? Without your bacula-dir.conf, bacula-sd.conf, bacula-fd.conf files, plugins, modifications to scripts such as the autochanger, ... you will have problems. The new Bacula proposed installation permits very easy restoration of all that. On my system, the backup of the catalog, *all* bacula files, and a snapshot of my hard disk configuration are all done in one simple script -- I don't have to worry about missing a file because the install has put files all over the place. As I say, it is for each to choose ... Regards, Kern |
From: Dan L. <da...@la...> - 2009-03-29 19:30:23
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phil Stracchino wrote: > Scott Barninger wrote: >> Kern and I have had some offline discussion previously on this subject. The >> current RPM build offers 2 options, one to place files with LSB compliance >> and a second to place files as Kern has advocated and which is how Bacula >> Systems is delivering binaries. >> >> My 2 cents worth is that packages published by the project on sourceforge >> should respect LSB and distribution (linux or BSD) guidelines. The advantages >> of this approach are: >> >> 1. we don't get emails from people complaining about file placement >> 2. we don't suffer hesitation from people who are strongly in favor of LSB >> 3. it creates a differentiator for Bacula Systems. >> >> On Sunday 29 March 2009 11:03:32 am Dan Langille wrote: >>> Discussion trimed to devel & beta > > > FWIW, I have *always* used the /opt/bacula layout. It puts the entire > Bacula installation in one place separate from everything else on the > machine, and makes it trivial to (for example) install Bacula on an > otherwise bare disk booted from a CD, then do a full system restore > without overwriting any active files. One could, for instance, boot > from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it > from a USB stick (as we were discussing recently). > > The problem with slavish adherence to things like the LSB is that it > isn't always the best solution for everything. > > "Our corporate policy says we always do this." > "That's fine, but this won't work if you do that." > "But corporate policy says..." > > One size does not fit all. Standards are great, but sometimes you have > to recognize that there are special cases for which the standard is not > the best solution, and that sometimes trying to make them conform to > "the standard" is actively harmful. The trick is to recognize the > occasions upon which applying "the standard" is not appropriate. When it comes to the official port/package/whatever of a given OS, it must adhere to the standards set by that OS. Hence, I can't see the FreeBSD port doing anything other than what it's doing now. I don't think anyone is suggesting otherwise. I do see the benefits in providing a solution which contains a completely self-contained installation of Bacula. I'd welcome someone working on that for FreeBSD. FWIW, in case, if I were recovering a failed box on new hardware, my first step would be installing the OS, then Bacula, and going from there. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknPzEYACgkQCgsXFM/7nTzXSACgtEDvU0WHEPx1xCUbhvHoESZL JwgAoO2DrPkVhBtTXkX+LITdaf37yxGu =fqob -----END PGP SIGNATURE----- |
From: Kern S. <ke...@si...> - 2009-03-29 17:43:39
|
On Sunday 29 March 2009 19:16:56 Phil Stracchino wrote: > Scott Barninger wrote: > > Kern and I have had some offline discussion previously on this subject. > > The current RPM build offers 2 options, one to place files with LSB > > compliance and a second to place files as Kern has advocated and which is > > how Bacula Systems is delivering binaries. > > > > My 2 cents worth is that packages published by the project on sourceforge > > should respect LSB and distribution (linux or BSD) guidelines. The > > advantages of this approach are: > > > > 1. we don't get emails from people complaining about file placement > > 2. we don't suffer hesitation from people who are strongly in favor of > > LSB 3. it creates a differentiator for Bacula Systems. > > > > On Sunday 29 March 2009 11:03:32 am Dan Langille wrote: > >> Discussion trimed to devel & beta > > FWIW, I have *always* used the /opt/bacula layout. It puts the entire > Bacula installation in one place separate from everything else on the > machine, and makes it trivial to (for example) install Bacula on an > otherwise bare disk booted from a CD, then do a full system restore > without overwriting any active files. One could, for instance, boot > from a Knoppix CD and copy /opt/bacula from an NFS share, or mount it > from a USB stick (as we were discussing recently). > > The problem with slavish adherence to things like the LSB is that it > isn't always the best solution for everything. > > "Our corporate policy says we always do this." > "That's fine, but this won't work if you do that." > "But corporate policy says..." > > One size does not fit all. Standards are great, but sometimes you have > to recognize that there are special cases for which the standard is not > the best solution, and that sometimes trying to make them conform to > "the standard" is actively harmful. The trick is to recognize the > occasions upon which applying "the standard" is not appropriate. Yes, I completely agree with you. If you ever have a disaster (I hope not), I think you will be better prepared to cope with it. Packages that spray Bacula files all over the system (IMO) do a disservice to the users. I pointed this out to the Ubuntu gurus, and their response was that /opt was for optional packages and since Bacula is part of our "system" that we ship, it is not appropriate to put it there. I think it is a mistake (possibly a big one) to spray the files of a system backup program all over your system, but then I'm not going to dictate to anyone ... |
From: Dan L. <da...@la...> - 2009-03-29 15:03:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Discussion trimed to devel & beta One purpose of this email is to document how the FreeBSD port differs and where work is required. Kern Sibbald wrote: > 7. I *strongly* recommend that you use the following file placement. This > does not agree with the LSB, but it does make it possible for the user to > much easier do a disaster recovery. This kind of configuration is commonly > used on Solaris and is also used on Linux. This is now the official Bacula > recommendation -- it may take a bit more time to update our documentation. FreeBSD has a well defined layout which tells us where particular types of files should go: http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html or http://tinyurl.com/manhier I imagine other OS may have their own constraints. Below, I have tried to highlight the FreeBSD directories. > > > ./configure \ > --sbindir=/opt/bacula \ /usr/local/sbin > --sysconfdir=/opt/bacula \ /usr/local/etc > --libdir=/opt/bacula \ I think that's /usr/lib > --docdir=/opt/bacula/doc \ > --htmldir=/opt/bacula/html \ Pretty sure both would be: /usr/local/share/doc/bacula FreeBSD installs the docs via sysutils/bacula-docs man pages go to /usr/local/man > --with-pid-dir=/opt/bacula/working \ /var/run/bacula*.pid > --with-subsys-dir=/opt/bacula/working \ > --with-working-dir=/opt/bacula/working \ both /var/db/bacula I think > --with-scriptdir=/opt/bacula/scripts \ /usr/local/share/bacula > --with-plugindir=/opt/bacula/plugins \ I don't know. > --enable-smartalloc \ we set this > --enable-bat \ And we have sysutils/bacula-bat to install this > --without-qwt \ At present, if bat is enabled, we set --with-qwt > --enable-batch-insert \ set > --with-openssl \ That is an option which can be set at install time. > --with-dump-email=root@localhost \ > --with-job-email=root@localhost \ The FreeBSD port sets neither of those. Work is required. > --with-tcp-wrappers \ set > --with-db-name=bacula \ > --with-db-user=bacula \ The FreeBSD port sets neither of those. Work is required. > --with-baseport=9101 \ Not set. > # --with-mysql > # or > # --with-postgresql FreeBSD offers SQLite2/3, MySQL, and PostgreSQL. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknPjcQACgkQCgsXFM/7nTxuhwCg3iE2e9EaqZNbNbI9x5igakDK 4J4An1mLN9+OoiDV8DE63z3L2fgQ2wg1 =gSLa -----END PGP SIGNATURE----- |
From: Kern S. <ke...@si...> - 2009-03-29 13:26:37
|
Hello packagers, We will be releasing Bacula version 3.0.0 shortly (within a week or two), so it might be a good time to look at packaging it. There are a number of new challenges: 1. Lots of new files added to the "make install" - bat help files - typical doc type release files (technotes, release notes, License, ...) - shared object files - the bacula script that is installed in the scripts dir is now also installed in the sysbindir - plugins are installed in the plugins directory 2. There are a number of new ./configure options: . --docdir (default=/usr/share/doc/bacula-VERSION) where VERSION is something like 3.0.0 the release technotes, LICENSE, ... go here. . --htmldir (default=/usr/share/doc/bacula-VERSION/html) the bat .html help files go here . --disable-libtool if you do not want shared objects . --libdir= where shared objects go (default=/usr/lib) . --with-plugindir=xxx 3. There are most likely (unfortunately) other packaging considerations that I have not thought of ... 4. The LICENSE file has been changed. 5. The code in this version of Bacula is now license clean, which means that there should no longer be any license incompatibilities between the Bacula code and OpenSSL. 6. The following components will still build but they are deprecated: - the gnome console (use bat instead) - sqlite version 2 - bwx-console (it is still used on Win32, but will be removed when we have bat working there). 7. I *strongly* recommend that you use the following file placement. This does not agree with the LSB, but it does make it possible for the user to much easier do a disaster recovery. This kind of configuration is commonly used on Solaris and is also used on Linux. This is now the official Bacula recommendation -- it may take a bit more time to update our documentation. ./configure \ --sbindir=/opt/bacula \ --sysconfdir=/opt/bacula \ --libdir=/opt/bacula \ --docdir=/opt/bacula/doc \ --htmldir=/opt/bacula/html \ --with-pid-dir=/opt/bacula/working \ --with-subsys-dir=/opt/bacula/working \ --with-working-dir=/opt/bacula/working \ --with-scriptdir=/opt/bacula/scripts \ --with-plugindir=/opt/bacula/plugins \ --enable-smartalloc \ --enable-bat \ --without-qwt \ --enable-batch-insert \ --with-openssl \ --with-dump-email=root@localhost \ --with-job-email=root@localhost \ --with-tcp-wrappers \ --with-db-name=bacula \ --with-db-user=bacula \ --with-baseport=9101 \ # --with-mysql # or # --with-postgresql Best regards, Kern |
From: Kern S. <ke...@si...> - 2009-02-18 20:19:40
|
Hello, The code for the database format change, which I mentioned in my previous email today, is now committed to the SVN. Bacula can now (by default) keep track of more than 4 billion File records! :-) Best regards, Kern |