-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kern Sibbald wrote: > On Monday 10 September 2007 04:27, Ryan Novosielski wrote: >> Kern Sibbald wrote: >>> At this time, I do not have a patch for 2.0.x versions, and unless there >>> is some really compelling reason to create one, I would prefer not -- it >>> would not be a huge effort to back port the patch, but it would require >>> rather extensive testing. Though it is hard to make a specific >>> recommendation, I believe that it probably will be the wisest and >>> simplest to either patch version 2.2.x if that is what you are currently >>> running, or upgrade to version 2.2.3 when it is released. >> My personal recommendation would be to release a patch to all versions >> back to at 1.38.x if the bug can be verified. I know that not too many >> people are running that version anymore, but if this bug is serious >> enough that the software will not work, I would personally be worried >> that someone will use one of these versions (the latest available of the >> minor release, eg. the latest 1.38.x) and not know that this is a >> problem. > > Yes, notifying users is a problem. If they are not subscribed to either the > bugs database or the announce list, they are out of luck :-( > > I'm considering adding a feature that the user could enable that would > automatically notify him of critical problems, but that won't help in this > case.
The website would be another place. I also applaud the decision to remove the affected versions for the time being. I guess the final risk here now is installing many current distributions will get you an affected version. >> Theoretically what you've discovered is that all versions of >> Bacula at least back to 2.0.x are a time bomb of sorts, and really >> should not be used at all. > > The above is a bit too simple. There is a bug and it is serious, the most > serious one we have had in a production release, but I wouldn't go so far as > to say that those versions should not be used at all. Please re-read the > announcement. I would suspect based on the number of questions about it, however, that MANY people using this software are using concurrent jobs. It is one of the things that Bacula appears to be more flexible on than many other packages, as well as its ability to write disk images. Does adding migration into this mix add another place where someone could trip over this bug (migrating across volumes, etc.)? >> I can't think of any such bugs in the past >> that carry a very real risk of data loss that were on non-beta versions >> of the code, > > Yes, this is the first major bug (aside from some encryption problems). > However, there is no data loss. It is there, and it *can* be recovered, it > is just not automatic. OK, having read the technical description, I agree, this is not that difficult. I guess the trouble though is being able to find that information in a disaster, or being aware that this kind of thing is needed. In any case, it is somewhat of a serious problem, especially when you might have backup operators (not true admins) in the mix. >> and I think not fixing the problem in older releases would >> not be good for Bacula's image. > > Well, I would not like to see anything bad for Bacula's image, but at the > moment, my main concern is to tie this bug down, properly document it, and > fix it in the current release. My announcement was made the same day that I > reproduced it, so it is still early in the process. After we get the current > version on track, we can calmly think about how to handle prior versions and > probably much more important is how do we ensure that downstream packagers > are aware of the problem. Certainly understandable -- I just present my opinion for going forward. >> I'm running 2.0.3 presently, and it's >> only 6 months old. I'm sure you can imagine there are many places that >> do not allow upgrades of major products except for certain times of the >> year. >> >> Not trying to give you a hard time, but I'm not sure how it would look >> to abandon such recent versions of software. > > I haven't abandoned anything -- please re-read what I wrote. I used the > word "prefer not". If you chose not to, that would be abandonment -- I'm not speaking of the current deliberation phase, I'm just arguing that ultimately I don't think it would be wise to leave them unpatched. >> PS: Does this affect spooled simultaneous jobs, or only simultaneous >> jobs that are simultaneously writing to storage? > > Please re-read item 1 of my announcement (above). My apologies -- I did miss that... skimming. :) Thanks for the very honest report, BTW. Hope you haven't been getting too much flak. - -- ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG5Vc4mb+gadEcsb4RAqvtAKCWs50uR+vgo2KeqYSeRVsD/nHyYQCffFL9 jomU8AR0ZJcCs99PUiDS/0M= =Jnxd -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
