Kern Sibbald wrote:
> Hello,
> 
> I would like to solicit comments about an auto upgrade feature for clients.  
> The email message I have included below was sent to me nearly four years ago!
> I have hesitated implementing a feature such as this because of security 
> concerns, but I think now is the time to start discussing it.
> 
> The ideas in this email are very good.  However, I would like to implement 
> something possibly a bit more comprehensive.  The main considerations for me 
> are:

Personally, I think that this kind of management should be considered outside
the scope of Bacula.  Any decent modern operating system will already have
some set of existing package management tools to handle most of these issues,
which reduces the potential benefit of having Bacula duplicate the same
functionality.

> 1. The sysadmin should be able to either upgrade all clients, or only clients 
> he selects.
> 
> 2. The client conf file should define whether or not the client can be 
> upgraded, and possibly the URL of the repository from which the upgrade will 
> be obtained.
> 
> 3. We need some very clear indication of the OS version so that the correct 
> version can be selected from the various packages that could be used for an 
> upgrade.
> 
> 4. The operation needs to be extremely secure so that only a very specific 
> Director can effect the upgrade, and possibly using a different 
> authentication method.
> 
> 5. We need some way to verify the cryptographic signature on an upgrade 
> candidate before applying it.
> 
> 6. All this must be OS independent or at least adaptable to various OSes and 
> various packaging methods (including possibly building the client from 
> source).

As a good example of how many cases there are, take a look at the package
management facility of puppet, a cross platform systems management tools.
Currently, it supports *22* different package managers.  Granted, some of them
won't be applicable, such as the ruby gem package manager, but even supporting
half of them properly would require a fair bit of code to be maintained.

> There are probably a few other considerations as well.  Though it could be 
> possible, I am not sure this can be put into the next release.  However, it 
> is something that is becoming critical -- I saw one user report that he is 
> backing up 10,000 server machines with Bacula -- can you imagine the problems 
> of upgrading the File daemons on those machines!

Very true.  However, assuming that all of the machines are more or less under
the same administrative domain, he's also got exactly the same problem for
every other piece of software on the box, from Firefox to security patches.
If he doesn't have some existing solution in place for package distribution
(not to mention plenty of other system aspects, like user accounts), he's
already got bigger problems than dealing with programs with the exceptional
backwards compatibility of Bacula.

In the other case, where the machines are not in the same administrative
domain (for example, someone using Bacula to sell backup services to numerous
clients) the proposition of automatically self-upgrading software becomes
higher risk.  The only OS where I've ever seen self-upgrading software is
Windows, where there's nothing even approximating a yum or apt repository.

It's not so much that I'm against the idea, as I believe that there are
already pre-existing solution that not only solve the problem in a much
broader scope than just Bacula, but are also a virtual necessity in any
installation of non-trivial size.

As a simpler, lower risk alternative, how about adding in the ability to at
least periodically generate a notification when there's a newer version
available?  The quick and dirty way would be for the FD to compare its own
version with the version of the director, and generate a notification (no more
than, say, once a week).

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users