enterprise-ubuntu team mailing list archive

[Bolesław Tokarski <boleslaw.tokarski@xxxxxxxxx>]

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