Bacula uses a modular approach to handle the backup needs of a networked environment. As you can see in the first graph in the following address: http://www.bacula.org/rel-manual/bacula.html Bacula has three different daemons that may be installed in different machines. These daemons are: 1. Director: manges the whole installation 2. Storage: handles storage devices 3. File: installed in every machine with data to backup In addition you have the console, that may be installed in any other machine. If you have *just* one machine to backup, with the storage device attached, it makes sense to have everything installed and running, but if you have a real network environment, you usually have one machine with the director daemon installed and running, several machines with the storage daemon where the storage devices are attached, and file daemons in every machine with data to backup. The console can be installed in the operator/administrator workstation and configured to connect remotely to the director daemon. Maybe it's overkill to split the ebuild to build these component separately (maybe not), but at least the init script should be able to selectively start the daemons based perhaps in a /etc/conf.d file, so if I want to install bacula in my network I don't have to be individually customizing init scripts. Now the bit of positive criticism: I remember discussions about what's needed for Gentoo to become adopted in real business. I think this is one of the facts that may slow Gentoo adoption. I have found several packages configured to run on a single machine, so if you want to use them in a real environment you have to tweak things you shouldn't tweak, like in this package: there is no possibility of configuring the ebuild to get only a daemon type, or configuring the init script to only start the needed daemons. You have the feeling that whoever made this was thinking of Bacula as an overkill toy to just backup her single machine, instead of the powerful piece of software I think it really is when used in real life with a whole network to backup using full blown tape changers and completely automated and unattended operation with real business data instead of backing up my collection of MP3s and my mail to a CD-RW. I also have this feeling when I read in the mailing list or forums and see that a lot of people tell you to use tar/cp/rsync/whatever. That's ok for your home machine, but I don't think those are solutions for enterprise needs. Just imagine yourself telling your boss or client: "Yes, I'm gonna have all those machines with your critical business data backed up using rsync... err... oh, those tapes... don't worry, I'll write some scripts so the systems tars the rsynced copy and writes them to tape... err... oh. labeling... ummm, I'm gonna give you a wonderful pen so you can write on every tape... err... what do you say? tape changers? robots? err... don't you think those are a waste of money? Better sell them and contract somebody to manually change the tapes at 1:30am... after all somebody has to label them..." Joking apart, I think Gentoo needs a mind change to become a corporate distribution and attract people doing real business... just some thoughts of somebody who's trying to do Gentoo for a living and would love to see Gentoo in every data center. A final word: I have set severity to Normal instead of Enhancement as this ebuild in its current state prevents its use in a network environment unless you manually edit init scripts. Reproducible: Always Steps to Reproduce:
Created attachment 42372 [details] bacula-init-conf.tar.bz Tar containing splitted init scripts with corresponding conf.d files.
First of all, it seems that my message (posted also in the server list) has caused a bit of stir. Please accept my sincere apologies if my message was offensive in any way, as that wasn't my intention. After that, let's go back to work... I have been thinking of splitting the build process too, with three possible options: 1. Include some use flags to indicate the kind of build (director daemon, file daemon, storage daemon and console) 2. Split the ebuild in four different ebuilds: bacula-dir, bacula-fd, bacula-sd and bacula-console 3. Leave it as it is now and build everything always. I don't know if there are other packages with the same problem, and in that case, what approach has been taken. I don't even know if it's worth the effort of splitting the build. So before spending my time on this I would like to hear anything from Gentoo devs.
First of all let my say that I agree with your reasoning (and think it was a good joke :) Now back to the serious part. I believe option 2 you mentioned in Comment #2 it the best possible solution. With the small addition of a bacula build that would just depend on the 4 ones you suggested. The problem seems to be that bacula itself has no support for the completely separated builds we are talking about. So I'm including here a partial solution more like option 1 of Comment #2. This patch for bacula-1.34.4.ebuild creates an USE flag: clientonly (as per bacula configure option --enable-client-only). When this USE flag is enabled, you only get bacula-fd. This patch could be easily and quickly deployed and I think it should. Then we could try to get to more complex/complete solutions later. If there is need, I can create a version for bacula-1.34.5.ebuild also.
Created attachment 43306 [details, diff] bacula-1.34.4-clientonly.patch
zul: would you like to join app-backup?
What is the status of this? I just got around to bacula (switched from amanda) and find it a great system, but just this bug bugs me. :-) I agree that option 2 of comment #2 would be the cleanest solution. And that "editing the init script" got me aswell.
The new init script for 1.36.3-r1 ebuild allows /etc/conf.d/bacula to select which daemons to run. It would be good if you guys could take a look at the new ebuild and make suggestions.
