bacula client configuration is broken out of the box

Hi Scott,

Thanks for taking the time to get in touch with the Ubuntu Development team. We understand that bacula is planning to send a couple of developers to Fosscamp, and think that might be an appropriate forum to collaborate on a final solution. I'll attend Fooscamp and I'm ready to discuss this issue with them.

Is is this an acceptable solution for you?

I would just like to present my opinion on this one...

This change was introduced in Debian as fix for Debian bug 367105:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367105

Both configurations have valid use cases. I'm kind of in favor of
having bacula file daemon listening only on localhost, as it is now.

Why? Here is why...

Bacula will never work out of box, cause of lots of configuration
options that should be changed after installation. Changing listening
IP address is just a tip of an iceberg.

On the other hand, people that don't have any clue about bacula, and
are just testing the software, are in danger. I would advise not
changing default at least until we solve bug #222558 - each bacula
client and daemon have the same password. This is cause password is
generated on compile time.

IMHO, talking about this and working on this issue should be
post-intrepid.

On Tuesday 21 October 2008 20:20:04 Ante Karamatić wrote:
> I would just like to present my opinion on this one...
>
> This change was introduced in Debian as fix for Debian bug 367105:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367105
>
> Both configurations have valid use cases. I'm kind of in favor of
> having bacula file daemon listening only on localhost, as it is now.
>
> Why? Here is why...
>
> Bacula will never work out of box, cause of lots of configuration
> options that should be changed after installation. Changing listening
> IP address is just a tip of an iceberg.

The standard Bacula rpms do work out of the box, as does the SQLite make
install. Since .debs are better (I am not at all being sarcastic here), why
cannot they do the same thing, or at least attempt to approach it?

>
> On the other hand, people that don't have any clue about bacula, and
> are just testing the software, are in danger. I would advise not
> changing default at least until we solve bug #222558 - each bacula
> client and daemon have the same password. This is cause password is
> generated on compile time.
>
> IMHO, talking about this and working on this issue should be
> post-intrepid.

A couple of points here:

Following your logic on the localhost problem, we arrive at the following:
If you want to make daemons secure and hobble them to localhost then please do
it uniformly to DNS, Apache, SSH, and the other daemons that can be used
internally without connection to the Internet, because I may not have a clue
about how they work and just want to test them. (A bit simplistic, but you
probably get the idea).

Concerning the random password problem: The rpms created by Bacula have had
random passwords installed for many years now. It is really quite easy to
fix. I mentioned this problem in the .debs and the solution to the Debian
maintainer quite a long time ago (probably years). I have also sent the .deb
scripts that we (Bacula) use internally to the Ubuntu Bacula packaging crew.
Our .deb packages when installed produce random passwords.

I'll leave it to you if/when to change anything.

Kern
Bacula Project Manager

On Tuesday 21 October 2008 18:36:11 Mathias Gug wrote:
> Hi Scott,
>
> Thanks for taking the time to get in touch with the Ubuntu Development
> team. We understand that bacula is planning to send a couple of
> developers to Fosscamp, and think that might be an appropriate forum to
> collaborate on a final solution. I'll attend Fooscamp and I'm ready to
> discuss this issue with them.
>
> Is is this an acceptable solution for you?

I won't speak for Scott for the above question, but I will be attending
FossCamp, and would be more than happy to provide as much help as I can to
arrive at solutions for all problems, concerns or questions you may have
about Bacula.

Kern Sibbald
Bacula Project Manager

On Tue, 2008-10-21 at 19:54 +0000, Kern Sibbald wrote:
> On Tuesday 21 October 2008 18:36:11 Mathias Gug wrote:
> > Hi Scott,
> >
> > Thanks for taking the time to get in touch with the Ubuntu Development
> > team. We understand that bacula is planning to send a couple of
> > developers to Fosscamp, and think that might be an appropriate forum to
> > collaborate on a final solution. I'll attend Fooscamp and I'm ready to
> > discuss this issue with them.
> >
> > Is is this an acceptable solution for you?
>
> I won't speak for Scott for the above question, but I will be attending
> FossCamp, and would be more than happy to provide as much help as I can to
> arrive at solutions for all problems, concerns or questions you may have
> about Bacula.

Sorry, I will not be able to attend.

Scott

This bug was fixed in the package bacula - 2.4.3-1ubuntu1

---------------
bacula (2.4.3-1ubuntu1) jaunty; urgency=low

  * Store sd|fd|director passwords in debconf (LP: #222558)
    - added debian/bacula-common.templates
    - modified debian/bacula-common.postinst:
      + generate random passwords and store them in debconf
    - modified debian/bacula-[sd|fd|director-mysql|director-pgsql].postinst
      + read and set passwords from debconf
  * Daemons listen on all interfaces (LP: #286643)
  * Start daemons on installation
  * Build with generic XXX_*_XXX username, password and database name
    and replace it with dbconfig's settings in postinstall scripts
  * Merge from debian unstable, remaining changes:
    - Drop mt-st to suggests. So that bacula goes back to main. (LP: #286528)
    - debian/rules: Disable fortify source since it was causing
      bacula-director to segfault.
    - debian/control:
      + Added libdbi-perl and libdb-mysql-perl to depends for
        bacula-director-mysql
        due to new postinst configuration.
      + Cleaned up bacula-director-pgsql dependenices and recommends.
      + Made mysql the default director to install bacula-director-{mysql|pgsql}
        added database handling to postinstall scripts and templates, modifiied
        postinstall script's sed expressions.
      + Removed libwgtk-2.6-dev as a build dependency; as a result
        bacula-console-wx isn't built anymore.
      + Install gawk if not installed. (LP: #207527)
    - debian/make_catalog_backup_awk.[mysql|pgsql|sqlite3|sqlite]:
      + New scripts for catalog backup. (CVE-2007-5626)
    - debian/bacula-console-wx:
      + Dropped since we are not building them anymore.
    - debian/bacula-director-common.bacula-director.init,
      debian/bacula-fd.init, debian/bacula-sd.init
      + Made more LSB specific.

 -- Ante Karamatic <email address hidden> Wed, 26 Nov 2008 13:53:30 +0100