On Monday 10 September 2007 16:39, Ryan Novosielski wrote: > 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.
Yes, unfortunately. Hopefully the downstream packagers are plugged into the project. > > >> 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.)? A migration ends up being a simultaneous backup of a restore so it is affected only to the extent that other simultaneous backups are writing to the same volume and the volume reaches the end. > > >> 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. Fortunately, after I had a few calm moments, I figured out a simple way to do the back port. I'm testing 2.0.4 now, and will provide a 2.0.3 patch and probably 2.0.0 and 2.0.1 patches as well. > > >> 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. Other than concern about getting patches for 2.0.x, which is perfectly normal, everyone has been very kind. Regards, Kern ------------------------------------------------------------------------- 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
