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:
>
> 1. The sysadmin should be able to either upgrade all clients, or only
> clients he selects.

Sure

> 2. The client conf file should define whether or not the client can be
> upgraded,

Yes

> and possibly the URL of the repository from which the upgrade 
> will be obtained.

Why not, but for 10.000 (even 270 like in my case), this will be painful to
change this.

> 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.

Yes, this depends on lot of things
 - OS (Linux Redhat, Debian, Win32, etc...)
 - OS Level (and sometime OS patches...)
 - Static binaries or not
 - FD compilation options (ssl, gzip, etc..)
    -> for ssl, this is a bit horrible, each distribution (even servers) have 
different version of SSL (9.7b, 9.8, 9.8a) etc...

In my case, i made my own "packages" for each kind of server
 - debian 3.1
 - debian 3.1 without ssl
 - debian 4.0
 - redhat3
 - redhat4
 - redhat4 without ssl
 - win32
 - aix4.3
 - aix5
etc...

My upgrade script try to guess the good version.

IMHO, Juan Luis approach seems to be good.

> 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.

Yes, but the director (and storage) can already "read" or "write" any file on 
the client...

> 5. We need some way to verify the cryptographic signature on an upgrade
> candidate before applying it.

Yes, it's also a good idea to backup the previous version in a local 
directory.

> 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).

Building the client from the source need to have gcc available and usable.
For my case, production environment, we don't have gcc installed.

Systems can use RPM, DEB, or simple tar.

We will have the same problem for binary/source download, i think it's better
to transfert the archive from the director, maybe a bit more secure. 

> 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!
>
> Comments would be appreciated.

Bye 

> Best regards,
>
> Kern
>
>
> ----------  Forwarded Message  ----------
>
> Subject: [Bacula-devel] [PATCH] Auto upgrade clients.
> Date: Thursday 18 November 2004
> From: Juan Luis Frances <bacula_list AT veloxia DOT com>
> To: bacula-devel AT lists.sourceforge DOT net
>
>
> Hello,
>
> Because I needed a faster method to upgrade clients when new bacula
> versions are released, I have develop a system to upgrade linux clients. At
> the moment, it's only tested with Red Hat 9 clients.
>
> This project is at a first stage as far as I need your feedback and your
> opinion. Maybe you can suggest me a best method to do it?
>
> The system have 3 parts:
>
> - Patch to director and file daemon: New command added "upgrade". (Kern,
> I'm sorry in advance if I have soiled your code).
>
> - Perl script to do automate task of upgrade: upgrade_clients.pl
>
> - Bash script that does theupgrade task: bupgrade.sh
>
>
>
> Description of each part:
>
> "upgrade" dir command (PATCH of 1.36.0 version)
> ---------------------------------------------------------------------------
>----- Syntax: upgrade CLIENTNAME URL
>
> Where:
> URL is the URL where the client will download the bacula "tar.gz"
>
> When upgrade command is sent, filed client will run bupdater.sh and it will
> die. When bupgrade.sh ends, it will restart bacula-fd.
>
> PS: You need apply patch to both, director and clients.
>
>
> bupdater.sh for Red Hat 9
> -----------------------------------------
> Syntax: bupdater.sh URL
>
> Where:
> URL is the URL where to download the bacula "tar.gz".
>
> This script will do the task to download, to configure, to compile and to
> install the new bacula-fd. Put bupdater.sh at /bin of each client machine.
>
> PS: bupgrade.sh is tested with Red Hat 9 but you can catch it to create a
> new script for your distribution if you want.
>
> When you pack the patched source, put the same dir that the packet file.
>
> Ex:
> # tar cvfp bacula-patched.tar bacula-patched
> # gzip bacula-patched
>
> You can view the log of each update attempt at /tmp/bupdater.log
>
>
> upgrade_clients.pl
> -------------------------------
> Features:
> - Generate clients list from director.
> - Upgrade clients of a personalized clients list.
> - Check clients version.
>
> Edit this file with your preferences.
>
>
>
> Surely, I haven't explained myself clearly; My fight with the english...
> ;-) I wait your comments and your critics.
>
> Best regards,
> Juan Luis Francés
>
> -------------------------------------------------------



-------------------------------------------------------------------------
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