enterprise-ubuntu team mailing list archive

["Dumond Stéphane CNE (SCA BCCP STSISI)" <stephane.dumond@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi,

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.

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... :-) ).
There are too many functionnal dependencies (with Firefox, Thunderbird,
Java JRE, VLC, LibreOffice and so on) with our internal softwares. So we
need to control the updates from the beginning (our own repos) to the
end (the desktop).

Your second semi-automatic way to deploy the updates is the choice we made.
To do this, we created 4 repositories :

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


.... I must leave (my children can't wait alone at school !), fell free
to ask me more details.

--
Stephane


Boles?aw Tokarski a écrit :
> Hello,
>
> I wanted to get your opinions/experiences/solutions used for automatic
> updates.
>
> I guess the 3 most common automatic upgrades approach are:
> 1. Go with it - install everything from upstream repositories.
> 2. Delay it - make a set of machines test the updates first before
> they are deployed everywhere
> 3. Verify it - go through each update and (dis)approve
> 4. Abandon it - Linux is secure, why should I update it?
> (note I meant 3 are most common, 4th is not ;)
>
> For 10.04 we went with 1. but under the exception that some packages
> were modified like in 3.
> For 12.04 we go with 1. - the custom packages are added-on and do not
> override any package from Ubuntu.
>
> The advantages of 1. are numerous:
> 1. Security - your systems are always up-to-date and you are unlikely
> to be behind with security vulnerabilities
> 2. Low (or no) amount of human intervention required. It just happens.
> 3. You are free to use any of the official Ubuntu mirrors on the
> Internet. Company laptops do not need to rely on corporate network to
> get updates.
>
> The problems we have with 1. are:
> 1. You never know what's going to happen with the next update,
> especially if you have custom add-ons to updated software. In some
> cases you need to adjust your add-ons quickly. By custom add-ons I
> also mean custom configuration.
> 2. There is no way to actually block a package that causes issues.
>
> Although Ubuntu provides the -proposed repository where packages that
> will land in main reside for at least a week (that would be enough for
> us to either prepare assisting changes or report that the packages
> causes issues here), we had a number of issues with updates that
> landed in -security which does not do staging in -proposed. Namely,
> these were Firefox and Thunderbird.
>
> I did not find a reasonable tool to do 2 or 3. Perhaps Landscape can
> do it, though I believe some required functionality is in development
> yet. We have used reprepro for filtering the package updates, but this
> caused another issue: when people went home, they either had no access
> to regular packages (no corporate connection) or they got updates from
> Ubuntu upstream that broke their environment.
>
> So, I was thinking how you approached the topic? Perhaps somebody has
> their custom Ubuntu repositories (not add-on repositories, I mean the
> whole ~100GB/distro) on the Internet? Or did you do some tweaks to
> block updates to specific software before it's tested?
>
> Cheers,
> Ballock
>

Ce message électronique et tous les fichiers attachés qu'il contient sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le retourner à son émetteur. Les idées et opinions présentées dans ce message sont celles de son auteur et ne représentent pas nécessairement celles de la gendarmerie nationale ou d'une autre administration. La publication, l'usage, la distribution, l'impression ou la copie non autorisée de ce message et des attachements qu'il contient sont strictement interdits.

En cas d'urgence, composez le 17 ou le 112.

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual to whom it is addressed. If you have received this email in error please send it back to the person that sent it to you. Any views or opinions presented are solely those of its author and do not necessarily represent those of the French gendarmerie or any other administration. Unauthorized publication, use, dissemination, forwarding, printing or copying of this email and its associated attachments is strictly prohibited.

In case of emergency, dial number 17 or 112.