Re: Mass update deployment strategy
Dear George,
A setup that works well, is to work with your own Debian and/or Ubuntu
repository, to which you only commit (apt-move) packages when you
tested and approved beforehand.
On your test setup you will see exactly what the impact will be from
update X on configuration Y and you will have a chance to script the
answers to posed questions as well thus being able to fully automate
the installation while maintaining an integrit infrastructure.
This will also save quite a bit of bandwidth.
One more advanced step (where you limit the SPOF for the installation
server) is to use apt-proxy to get a peer2peer alike update mechanism.
You may then configure your systems to download and install all
updates at a set timely interval from your "CRM-production" mirror
without thinking.
If you setup two repo's, say "production" and "testing", you could
measure the impact of a (security)update on _one_ test system.
Perhaps you could also combine its functionality with the suggested
solution from Javier.
A fun addition would be to use a hypvervisor (Xen) to run one instance
of every deployed configuration from within your network on a separate
virtual machine.
Which adds even more advantages, because you can easily restore the
state of your machines and you only need _one_ machine to measure the
impact of updates.
Have used this setup quite a few times, where there is always one
(often combined with other services) update server per geographical
site.
Kind regards,
Freek Kauffmann
On 12/1/06, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
On Mon, Nov 27, 2006 at 08:37:42PM +0100, mario wrote:
> Do you have a strategy or anything to automate this task a little more?
> The server farm is growing and i might have to look after 20 or 30
> installations soon. I can already see myself updating ubuntu/debian
> installations all day long :(.
Let me throw some ideas around...
If your installation where slightly bigger (maybe 100 systems) I would
suggest you invest your time working with OVAL [1] and CVE [2]:
a) deploy an OVAL agent at the nodes with apt-capabilities
b) have a central OVAL server send new signatures to nodes so they can tell
you wether they are vulnerable or not (and need to have a DSA applied or
not)
c) priorise work based on the severity of the vulnerability (you can use both
NIST's CVE DB [1] and the priorities set by the Debian Testing Security
team in their tracker for this)
d) request systems to update with a patch (remote ssh connection will do for
this)
Unfortunately, a) is not yet possible. I have working OVAL agents for Debian
(i.e. they compile) but have not had the time yet to write an adapter for
Apt (shouldn't be too difficult). I'm trying to finish the DSA to OVAL xml
signature converter so that generating xml signatures from the DSAs published
at the website will be a breeze, but I have not yet finished with that. Any
help with that would be appreciated.
The only thing I can find close to that is to use Nessus with "Local Security
Checks" and use the feed which provides tests for Debian vulnerabilities
(I believe this is possible with the free feed, but maybe they have changed
it). This is hardly optimal as it requires the systems to be live in the
network when you are 'scanning it'.
You can also do it by hand, if you are so inclined:
a) have the systems send you their status files when they are online to a
central system
b) have a central system pick up those files and compare that information with
a database of known vulnerabilites in Debian
c) priorise the systems and vulnerabilities based on the above criteria
d) have the central system ask the other systems to install the patch from
security.debian.org (or your local repository) based on c)
The first two parts of that (by-hand) solution are already written in the
scripts provided by Tiger (check the package source:
systems/Linux/deb_checkadvisories and systems/Linux/2/update_advisories)
Unfortunately, nobody has written off a free "enterprise patch management"
for Debian. There are non-free commercial alternatives you can easily find,
but I'm not going to publitize them in this mailing list (contact me in
private if you are desperate looking for one).
Regards
Javier
[1] http://oval.mitre.org
[2] http://cve.mitre.org
[1] Formerly ICAT, now it's the National Vulnerability Database
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFb3OtsandgtyBSwkRAosBAJ9dYAeZCMxCqbh4nZq0nVP6RZcq7ACfQdPv
KgUoC58ZnelCJWGrO0o9Yi8=
=hokl
-----END PGP SIGNATURE-----
Reply to: