Hello, Stéphane,
Thank you so much for your input. I do have a number of questions, not
all of them related to the repositories, I hope you do not mind.
My "company" has currently 35,000 Ubuntu desktops/laptops deployed all
over our country (and we aim to have 80,000 within the 2 next years).
I'm the leader of this deployment.
That makes a really nice business case/case study. Is it by any chance
published?
You can easily understand that with such a numerous amount of
computers, I can't trust the upstream repository (I must admit : I'm a
quite paranoid... :-) ).
I guess it all depends on the requirements. Here we have requirement on
minimising the support costs per workstation and with just the 600 we
have the time required for reviewing the updates would be significant.
But if I multiplied our problems with unexpected updates by 60, I guess
I would be paranoid as well.
Your second semi-automatic way to deploy the updates is the choice we
made.
To do this, we created 4 repositories :
What software do you use for managing those repositories? Reprepro?
Debmarshall? Landscape? A custom tool?
* the "test" repo : this is a full copy of the upstream Canonical
repos, which is done twice a month (except the specific case of
security updates). It is used by developers
* the "internal add-on" repo : it contains specific packages
(internal software) and "*frozen*" packages (Firefox for example)
with the use of the "*pinning*"
Is there a specific need for freezing and pinning the packages? With
such a customised repository I guess it is just enough to eliminate
other versions from the repositories?
That brings me to another question: What's your specifics of your
deployment? Are those just desktops or you need to maintain laptops as
well? If you do have laptops and they leave the office, how do you
supply updates to those?
*
* the "qualifying" repo : this repo is the one used by some
end-users (~five hundred) to make operational tests. This is a
copy from the test repo when all the developers are OK.
How do you organise the operational tests? Do you notify the five
hundred users of the changes that are being deployed?
Did you organise any "community" around Ubuntu inside? I mean some
communication channels, mailing lists, wikis? Or are you just relying on
the ITIL-style support organisation to interface with the users?
*
* the "production" repo : this is the final repo, from which all our
Ubuntu computers are updated. This is a copy from the qualifying
repo when all the test end-users are OK.
All these successive validations take approximatly one month to be
done... This is the main drawback when you manage thousands of Ubuntu
computers...
That actually means that your machines are 2-2,5 months behind the
upstream ones. When I come to think of it, although it seems a long
time, I think it gives a feeling of comfort as in such a long time it is
really possible to solve prospective issues.
Especially that you say that security updates get some special
attention. Hey, what about Firefox and Thunderbird? These seem to always
have landed in -security. I recently had some tough nut to crack, but I
can't find anyone from Ubuntu that could explain to me: Why do the
Ubuntu LTS releases not stick to ESR (extended support release) versions
of Thunderbird and Firefox? It seems these are versions 10 and 17 at
this point. At the same time all FF versions were published in Ubuntu as
security updates.
Are you treating the "security" updates of FF and TB in some special way?
I guess I have lots of other topics to discuss :) Nice to have you here.
Cheers,
Ballock
--
Mailing list: https://launchpad.net/~enterprise-ubuntu
Post to : enterprise-ubuntu@lists.launchpad.net
Unsubscribe : https://launchpad.net/~enterprise-ubuntu
More help : https://help.launchpad.net/ListHelp
