La Fibre

Télécom => Logiciels et systèmes d'exploitation => Linux Linux => Discussion démarrée par: vivien le 27 avril 2017 à 09:28:12

Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:28:12
Statistiques du serveur de mise à jour Ubuntu par défaut pour la France

Vous savez que je gère le serveur https://fr.archive.ubuntu.com/ qui gère les mises à jour Ubuntu pour 99% des PC Ubuntu (et dérivés) installés comme étant en France. J'exclue de ce pourcentage, les entreprises avec un par Ubuntu important, qui ont déployée en interne leur propre miroir, comme par exemple la gendarmerie nationale.

Voici le trafic typique après une mise à jour, ici une nouvelle version d'un noyau Linux a été proposée à minuit :
(https://lafibre.info/images/stats/201704_ubuntu_if_max-day.png)

Le pic de 6h25 à 6h55 du matin puis de puis 7h25 à 7h55 est lié a des machines connectées 24h/24 : Par défaut elles vérifient les mises à jour (et pour certaines les télécharges et les installes, d'autres ne font que notifier de la présence de mises à jour sans les télécharger)

Le fichier /etc/crontab contient ce type de lignes sur Ubntu :
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

Les actions à exécutées chaque jour, des scripts qui sont dans /etc/cron.daily sont donc exécutés chaque jour.

C'est notamment le cas du script /etc/cron.daily/apt-compat qui gère les mises à jour :

#!/bin/sh

set -e

# Systemd systems use a systemd timer unit which is preferable to
# run. We want to randomize the apt update and unattended-upgrade
# runs as much as possible to avoid hitting the mirrors all at the
# same time. The systemd time is better at this than the fixed
# cron.daily time
if [ -d /run/systemd/system ]; then
    exit 0
fi

check_power()
{
    # laptop check, on_ac_power returns:
    #       0 (true)    System is on main power
    #       1 (false)   System is not on main power
    #       255 (false) Power status could not be determined
    # Desktop systems always return 255 it seems
    if which on_ac_power >/dev/null 2>&1; then
        on_ac_power
        POWER=$?
        if [ $POWER -eq 1 ]; then
            return 1
        fi
    fi
    return 0
}

# sleep for a random interval of time (default 30min)
# (some code taken from cron-apt, thanks)
random_sleep()
{
    RandomSleep=1800
    eval $(apt-config shell RandomSleep APT::Periodic::RandomSleep)
    if [ $RandomSleep -eq 0 ]; then
return
    fi
    if [ -z "$RANDOM" ] ; then
        # A fix for shells that do not have this bash feature.
RANDOM=$(( $(dd if=/dev/urandom bs=2 count=1 2> /dev/null | cksum | cut -d' ' -f1) % 32767 ))
    fi
    TIME=$(($RANDOM % $RandomSleep))
    sleep $TIME
}

# delay the job execution by a random amount of time
random_sleep

# ensure we don't do this on battery
check_power || exit 0

# run daily job
exec /usr/lib/apt/apt.systemd.daily

Le code inclus un "sleep" d'une durée aléatoire comprises entre 0 et 30 minutes, ce qui évite que tous les PC se connectent simultanèment au serveur.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:28:43
Sur ces graphes, hebdomadaire, mensuel et annuels, le trafic est représenté en affichant le débit moyen sur 5 minutes le plus élevé de la période.

Graphe hebdomadaire : chaque point représente une période de 20 minutes
(https://lafibre.info/images/stats/201704_ubuntu_if_max-week.png)

Graphe mensuel : chaque point représente une période de 2 heures
(https://lafibre.info/images/stats/201704_ubuntu_if_max-month.png)

Graphe annuel : chaque point représente une période de 24 heures
(https://lafibre.info/images/stats/201704_ubuntu_if_max-year.png)

On a donc sur ce dernier graphe la période de 5 minutes sur l'année avec le maximum de trafic, c'est a dire le matin entre 6h25 et 6h55 ou entre 7h25 à 7h55, certains type de mise à jour (Firefox par exemple) réalisant un pic de trafic plus important sur le créneau de 7h25 à 7h55. Les mises à jour du Kernel par contre ont toujours leur pic de trafic entre 6h25 et 6h55.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:38:07
Trafic moyen

Sur les graphes ci-dessous, le trafic reporté est le trafic moyen sur la période et non le trafic sur 5 minutes le plus élevé :
(https://lafibre.info/images/stats/201704_ubuntu_if-week.png)(https://lafibre.info/images/stats/201704_ubuntu_if-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_if-month.png) (https://lafibre.info/images/stats/201704_ubuntu_if-year.png)

Sur le dernier graphe, on a donc un trafic moyenné sur toute la journée.

Ce type de graphe cache des pic de trafic instantanés à plus de 5 Gb/s.

Exemple de consommation internet instantanée, récupéré avec nload lors d'une mise à jour du kernel :
(https://lafibre.info/images/stats/201610_fr-archive-ubuntu_maj_kernel_1.png)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:38:29
Trafic vu du serveur Apache en volume (Mo par seconde et non Mb/s)

Ce trafic est assez proche de celui vu coté réseau, les encapsulations en moins.
(https://lafibre.info/images/stats/201704_ubuntu_apache_volume-week.png)(https://lafibre.info/images/stats/201704_ubuntu_apache_volume-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_apache_volume-month.png) (https://lafibre.info/images/stats/201704_ubuntu_apache_volume-year.png)



Nombre de requêtes sur le serveur Apache en millier de requêtes par secondes

Le nombre de requêtes est lié aux différents serveurs et PC qui se connectent pour vérifier si il y a des mises à jour.
Leur volume est donc assez stable, contrairement au volume.

On voit ici les deux pic qui sont présents chaque jour (sauf une foie dans l'année quand on retarde l'heure d'une heure, il n'y a pas deux téléchargements en moins de 24h)

(https://lafibre.info/images/stats/201704_ubuntu_apache_accesses-week.png)(https://lafibre.info/images/stats/201704_ubuntu_apache_accesses-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_apache_accesses-month.png) (https://lafibre.info/images/stats/201704_ubuntu_apache_accesses-year.png)

Avec cette courbe annuelle, vous pensez que le nombre d'utilisateurs Ubuntu diminue ?

On pourrait à juste titre le penser. La réponse est non, c'est simplement que Ubuntu 16.04 a bien optimisé le système de mise à jour et divisé par 2 le nombre de requêtes nécessaires. Le nombre de requêtes diminue donc au fur et à mesure qu'Ubuntu 16.04 est déployé.


Fichier /etc/apt/sources.list par défaut pour Ubuntu server 16.04 LTS :
deb http://fr.archive.ubuntu.com/ubuntu/ xenial main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ xenial universe
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu xenial-security main restricted
deb http://fr.archive.ubuntu.com/ubuntu xenial-security universe
deb http://fr.archive.ubuntu.com/ubuntu xenial-security multiverse


Fichier /etc/apt/sources.list par défaut pour Ubuntu server 14.04 LTS :
deb http://fr.archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb http://fr.archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty universe
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb http://fr.archive.ubuntu.com/ubuntu/ trusty multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu trusty-security main restricted
deb-src http://fr.archive.ubuntu.com/ubuntu trusty-security main restricted
deb http://fr.archive.ubuntu.com/ubuntu trusty-security universe
deb-src http://fr.archive.ubuntu.com/ubuntu trusty-security universe
deb http://fr.archive.ubuntu.com/ubuntu trusty-security multiverse
deb-src http://fr.archive.ubuntu.com/ubuntu trusty-security multiverse
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:39:23
Nombre de requêtes simultanées

Un serveur web est limité en nombre de "slot", c'est à dire le nombre de requêtes qu'il est en mesure de traiter simultanèment.

La plupart des requêtes légitimes sont réalisées très rapidement et donc occupent peu de temps le serveur, sachant qu'Ubuntu n'effectue pas de requêtes simultanées, un client ne peut pas occuper plus d'un slot.

Il y a toutes fois du trafic exotique, des scripts, du slow DDOS, ect... qui peuvent occuper des slot. Je vois ainsi des fichiers qui sont téléchargés en plus de 12h depuis des IP situées hors de France. Il y a par moment des petits pic de très forte occupation du slot du serveur...

Avec 2500 slots pour 300 slots maximums utilisés de façon légitime, j'ai de la marge, mais il arrive occasionnellement qu'ils soient tous occupés (dans ces cas là il y a une file d'attente)

(https://lafibre.info/images/stats/201704_ubuntu_apache_processes-week.png)(https://lafibre.info/images/stats/201704_ubuntu_apache_processes-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_apache_processes-month.png) (https://lafibre.info/images/stats/201704_ubuntu_apache_processes-year.png)

Statistiques instantanées, récupérées avec Apache Server Status :
(https://lafibre.info/images/stats/201610_fr-archive-ubuntu_maj_kernel_2.png)


Exemple d'attaque slow DDoS sur mon serveur :
(https://lafibre.info/images/stats/201808_apache_slow_ddos_attaque.png)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:39:32
Le load average du serveur :

Un des facteur d'augmentation du load average est les accès disques lié a des demandes importantes sur du contenu qui n'est pas en RAM, l'augmentation du nombre de slot a cause de slow DDOS et la synchronisation du serveur avec du nouveau contenu.

Les pic de trafic le matin à plus de 4 Gb/s ne font pas monter le load average, car c'est toujours le même contenu qui est demandé et il est en RAM.
De plus tous les serveurs ont un grand débit, ce qui fait que les slot ne sont utilisés qu'un cours laps de temps : télécharger 70 Mo à 1 Gb/s, cela va très vite.


(https://lafibre.info/images/stats/201704_ubuntu_load-week.png)(https://lafibre.info/images/stats/201704_ubuntu_load-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_load-month.png) (https://lafibre.info/images/stats/201704_ubuntu_load-year.png)



L'utilisation CPU (c'est un Xeon 4 cœurs avec Hyper-Threading)

(https://lafibre.info/images/stats/201704_ubuntu_cpu-week.png)(https://lafibre.info/images/stats/201704_ubuntu_cpu-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_cpu-month.png) (https://lafibre.info/images/stats/201704_ubuntu_cpu-year.png)

Indicateur   Définition
systemCPU time spent by the kernel in system activities
userCPU time spent by normal programs and daemons
niceCPU time spent by nice(1)d programs
idleIdle CPU time
iowaitCPU time spent waiting for I/O operations to finish when there is nothing else to do.
irqCPU time spent handling interrupts
softirqCPU time spent handling "batched" interrupts
stealThe time that a virtual CPU had runnable tasks, but the virtual CPU itself was not running
guestThe time spent running a virtual CPU for guest operating systems under the control of the Linux kernel.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:39:43
L'utilisation des 16 Go de mémoire, principalement pour du cache disque des éléments les plus demandés :

(https://lafibre.info/images/stats/201704_ubuntu_memory-week.png)(https://lafibre.info/images/stats/201704_ubuntu_memory-day.png)
(https://lafibre.info/images/stats/201704_ubuntu_memory-month.png) (https://lafibre.info/images/stats/201704_ubuntu_memory-year.png)

Il y a un changement important début mars entre page mémoires actives et pages mémoires inactives : c'est lié au changement de kernel Linux : Je suis passé d'un noyau 4.4 à un noyau 4.8. Le reste est strictement inchangé.

IndicateurDéfinition
appsMemory used by user-space applications.
page_tablesMemory used to map between virtual and physical memory addresses.
swap_cacheA piece of memory that keeps track of pages that have been fetched from swap but not yet been modified.
slab_cacheMemory used by the kernel (major users are caches like inode, dentry, etc).
cacheParked file data (file content) cache.
buffersBlock device (e.g. harddisk) cache. Also where "dirty" blocks are stored until written.
unusedWasted memory. Memory that is not used for anything at all.
swapSwap space used.
vmalloc_used   'VMalloc' (kernel) memory used
committedThe amount of memory allocated to programs. Overcommitting is normal, but may indicate memory leaks.
mappedAll mmap()ed pages.
activeMemory recently used. Not reclaimed unless absolutely necessary.
inactiveMemory not currently used.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:47:25
Les reboot du serveur pour appliquer les mises à jour de sécurité :

(https://lafibre.info/images/stats/201704_ubuntu_uptime-year.png)

La longue période sans reboot a permis de voir le trafic passe le 1 Po :

Je viens de Passer 1 Po (soit 8 Pb) en 149 jours pour le serveur https://fr.archive.ubuntu.com qui distribue les mises à pour pour la France.

$ uptime
 17:01:09 up 149 days, 11:40,  1 user,  load average: 0,30, 0,48, 0,39


$ ifconfig
lo        Link encap:Boucle locale 
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          Packets reçus:1755415 erreurs:0 :0 overruns:0 frame:0
          TX packets:1755415 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1
          Octets reçus:1737669659 (1.7 GB) Octets transmis:1737669659 (1.7 GB)

p1p1      Link encap:Ethernet  HWaddr 90:e2:ba:19:f7:50 
          inet adr:194.158.119.190  Bcast:194.158.119.191  Masque:255.255.255.252
          adr inet6: fe80::92e2:baff:fe19:f750/64 Scope:Lien
          adr inet6: 2001:860:f70a:100::2/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:319436905449 erreurs:0 :0 overruns:0 frame:0
          TX packets:672964588886 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:24466146214985 (24.4 TB) Octets transmis:1001402094413622 (1.0 PB)

Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 09:47:34
Statistiques sur le téléchargement d'un nouveau noyau Linux, suite à une faille de sécurité :

Tu es sur que RedHat n'a pas distribué le correctif ?

Cela m'étonne fortement.

Pour Ubuntu, il est disponible depuis le 20 octobre à 5h45 du matin, sur le serveur de mise à jour utilisé par défaut en France (https://fr.archive.ubuntu.com)

Comme je gère ce serveur, j'ai réalisé quelques stats. J'ai bien nettoyé les log de tout ce qui est script et j'ai également par mégarde supprimé les mises à jour réalisées depuis un mobile (le serveur reçois le code 304 - Document non modifié depuis la dernière requête, car il est en cache coté FAI).

Nombre de mises à jour du noyau correctif par heure :
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_horaire.png)

Le nombre de machines non patchées dois être encore très important.

Nombre de mises à jour du noyau correctif par heure et par distribution :
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_horaire_par_distribution.png)

Je rappelle que les autres version d'Ubuntu ne sont plus maintenues.

Nombre de mises à jour du noyau correctif par heure par architecture : (i386 = 32bits / AMD64 = 64bits)
(https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu_repartition_horaire_par_architecture.png)

Voici un fichier Calc avec les données sources, si vous pensez qu'il y a d'autres graphes à faire : 201610_stats_ubuntu.ods (https://lafibre.info/testdebit/ubuntu/201610_stats_ubuntu.ods)

(lisible avec Libre office Calc et Microsoft Excel)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 14:21:06
Ce matin, j'ai encore dans mes logs AH00485: scoreboard is full, not at MaxRequestWorkers

L'attaque est bien visible :
(https://lafibre.info/images/stats/201704_ubuntu_apache_processes-day_2.png)

Voici ma configuration actuelle, j'ai mis de trés nombrex commentaires pour détailler mes choix : /etc/apache2/mods-enabled/mpm_event.conf

# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of worker threads
# MaxConnectionsPerChild: maximum number of requests a server process serves

# Nb de slots total (busy + idle + free) est la valeur la plus basse entre :
# - MaxRequestWorkers (150 par défaut)
# - ThreadsPerChild (25 par défaut) * ServerLimit (16 par défault)

# Nb de slots idle au démarrage à vide est la valeur la plus haute entre :
# - MinSpareThreads (25 par défaut) arrondi supérieur, pour être un multiplde entier de ThreadsPerChild
# - ThreadsPerChild (25 par défaut) * StartServers (2 par défaut)

# Nb minimal de slots idle quand de nombreux slots sont "busy" :
# = MinSpareThreads (25 par défaut) avec un arrondi supérieur pour que
# busy + idle soient un multiplde entier de ThreadsPerChild (25 par défaut)

# Nb maximal de slots idle quand de nombreux slots sont "busy" :
# = MaxSpareThreads (75 par défaut) avec un arrondi supérieur pour que
# busy + idle soient un multiplde entier de ThreadsPerChild (25 par défaut)

<IfModule mpm_event_module>
# Nombre de processus enfants du serveur créés au démarrage
# Influence uniquement le nb de slots idle au démarrage
# Régle pour déterminer StartServers: arrondi supérieur de
# (MinSpareThreads / ThreadsPerChild) + (MaxRequestWorkers / (40 x ThreadsPerChild))
#StartServers 2
StartServers 9

        # Limite supérieure de la définition du nombre de processus
        # Régle pour déterminer ServerLimit: MaxRequestWorkers / ThreadsPerChild
# Pour modifier ServerLimit un restart est nécessaire (donc coupure des connexions en cours)
        # Je conseille donc de prendre une marge ServerLimit = 1.5 x (MaxRequestWorkers / ThreadsPerChild)
# Permet, par la suite, d'augmenter de 50% ThreadsPerChild avec un simple reload
        # ServerLimit            16
        ServerLimit              150

# Nombre minimum de threads inactifs qui seront disponibles
# pour pouvoir traiter les pics de requêtes
        # Régle pour déterminer MinSpareThreads: 20 + (MaxRequestWorkers / 20)
#MinSpareThreads 25
MinSpareThreads 145

# Nombre maximum de threads inactifs
# But: libérer de la RAM inutilisée après un pic de trafic
# Régle pour déterminer MaxSpareThreads: 3 x MinSpareThreads
#MaxSpareThreads 75
MaxSpareThreads 435

# Le nombre de threads maximum que l'on peut définir par processus enfant
# Il est possible de modifier ThreadsPerChild par un simple reload jusqu'à ThreadLimit
# Pour modifier ThreadLimit un restart est nécessaire (donc coupure des connexions en cours)
# Si ThreadLimit > ThreadsPerChild, de la mémoire partagée supplèmentaire sera inutilement allouée.
# Régle pour ThreadLimit: ne pas toucher a la valeur par défault: 64 quel que soit MaxRequestWorkers
# Régle pour déterminer ThreadsPerChild: 25 (valeur par défault), quel que soit MaxRequestWorkers
#ThreadLimit 64
ThreadLimit 25

# Nombre de threads créés par chaque processus enfant
# Influence le nb total de slots max ET le nb minimal de slots
# Si > 40, Apache ne répond plus a certaines requetes, quand il y a de nombreuses connexions asychrones
# Régle pour déterminer ThreadsPerChild: 25 (valeur par défault), quel que soit MaxRequestWorkers
ThreadsPerChild 25

# Nombre maximum de connexions pouvant être traitées simultanèment
# Détermine le nombre de requetes actives pouvant être traitées simltanèment.
# A déterminer en fonciton de la charge et de la mémoire disponible
# Il est possible de modifier MaxRequestWorkers par un simple reload
#MaxRequestWorkers 150
MaxRequestWorkers 2500

# Limite le nombre de connexions qu'un processus enfant va traiter au cours de son fonctionnement
# Définir MaxConnectionsPerChild à une valeur non nulle limite la quantité de mémoire
# qu'un processus peut consommer à cause de fuites (accidentelles) de mémoire.
# Régle pour déterminer MaxConnectionsPerChild: fixé à 0, sauf fuite mémoire importante
MaxConnectionsPerChild   0

# Cette directive permet de personnaliser finement la limite du
# nombre de connexions par thread. Un processus n'acceptera de
# nouvelles connexions que si le nombre actuel de connexions
# (sans compter les connexions à l'état "closing") est inférieur à:
# ThreadsPerChild + (AsyncRequestWorkerFactor * nombre de threads inactifs)
# A faire varier entre 1.5 et 3 en fonction du type de clients du site
# Régle pour déterminer AsyncRequestWorkerFactor: fixé à 2 (valeur par défault)
# Note: Si vous modifiez la valeur par défaut, vous devrez effectuer des tests approfondis
AsyncRequestWorkerFactor 2

</IfModule>

Je viens de rajouter deux mesures de protections supplèmentaires : (je suis preneur de vos autres idées)

   # Temps pendant lequel le serveur va attendre certains évènements avant de considérer
   # qu'une requête a échoué. Lors de la lecture de données en provenance du client,
   # c'est le temps maximum jusqu'à l'arrivée d'un paquet TCP si le tampon est vide.
   # Défaut: TimeOut 60
   # Réduire le TimeOut a 30 secondes, permet de limiter le temps maximum pendant
   # lequel Apache httpd va attendre des entrées/sorties, lors des attaques de slow DDOS.
   Timeout 30

   # Spécifie le délai maximum après lequel le serveur va s'arrêter dans le cas d'un arrêt "en douceur"
   # Défaut: GracefulShutdownTimeout 0 => le serveur va attendre jusqu'à ce que toutes les requêtes en cours aient été traitées.
   # Réduire le GracefulShutdownTimeout a une heure (3600 secondes) permet de réduire certains attaques slow DDOS.
   # Réduire cette valeur en dessous d'une heure peut poser problème pour des clients avec du bas débit
   # Une connexion a 400 Kb/s (50 Ko/s) est en mesure de télécharger 180 Mo en une heure.
   GracefulShutdownTimeout 3600


GracefulShutdownTimeout d'une heure peut vous sembler énorme, mais je prévois le cas où un client avec une petite connexion fait de gros téléchargements.
Si il commence la nuit au moment où les serveurs redémarrent ou après une attaque, quand il faut diminuer le nombre de serveurs, là je donne une garantie d'un minimum de 1h sans être coupé.
En temps normal, des connexions de plusieurs heures passeront sans problème, cette ligne ne devrait pas trop changer les choses, juste libérer quelques serveurs qui restent bloquées plusieurs heures a cause d'un slow DDOS.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 14:23:44
Je m’aperçois que même hors des attaques, j'ai un nombre important de requêtes qui prennent des sots pour rien, qui est important.

Exemple : Apache Server Status ce midi en filtrant les requêtes W (il y a une GET complet qui a été reçu et le serveur envoi la réponse), une durée en secondes SS depuis la dernière requête > 60 secondes et le nombre d'octets transféré Req de 0 octets.
(https://lafibre.info/images/stats/201704_ubuntu_ddos.png)

C'est un type de connexion qui me semblent complètement frauduleuses : si j'ai bien compris après le GEt le client n'est plus manifesté. Comme à un time out par défaut de 60 secondes et que ces connexions dépasseent largement ce délais, c'est que les opérations pour faire un GET ont déjà pris pas mal de temps.... bref je pense que c'est du slow DNS...

Légende :

MMode of operation : "_" Waiting for Connection, "S" Starting up, "R" Reading Request, "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup, "C" Closing connection, "L" Logging, "G" Gracefully finishing, "I" Idle cleanup of worker, "." Open slot with no current process
SSSeconds since beginning of most recent request
ReqMilliseconds required to process most recent request
ConnKilobytes transferred this connection
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Hugues le 27 avril 2017 à 14:30:08
Les reboot du serveur pour appliquer les mises à jour de sécurité :

sudo snap install canonical-livepatch  ::)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 15:35:01
Canonical Livepatch Service est limité à 3 machines par identifiant.

Il ne gère pas le kernel des Hardware Enablement Stack... (je suis en Kernel 4.8 sur un LTS 16.04)

Bref c'est utile mais je ne l'utilise pas.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Hugues le 27 avril 2017 à 15:48:36
Pourquoi utiliser l'Hardware Enablement Stack ? Autant passer en non LTS dans ce cas...
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 19:23:49
Pour que ceux qui nous lisent comprennent, il y a 3 type de cycles qu'il est possible de suivre chez Ubuntu :

- Ubuntu server LTS => On reste deux ans avec le même kernel (4.4 pour Ubuntu 16.04). Il y a un support de 5ans, on n'est pas obligé d'upgrader tout de suite à la sortie de la version suivante.

- Ubuntu server LTS avec Enablement Stacks => On profite des améliorations de performances des nouveaux Kernel, en changant automatiquement de Kernel tous les 6 mois. Ubuntu 16.04 et 16.04.1 utilise le kernel 4.4, Ubuntu 16.04.2 le kernel 4.8, Ubuntu 16.04.3 le kernel 4.10, Ubuntu 16.04.4 un kernel à définir. Le support reste de 5 ans et il est possible de supprimer facilement Enablement Stacks.
A noter que les kernel sont utilisés pendant 3 mois dans les version Ubuntu classiques avant d'être mis dans Enablement Stacks. Il ne devrait donc pas y avoir de gros bugs.

- Ubuntu server => Il est nécessaire d'upgrader le système d’exploitation tous les 6 mois. Le support d'une version se termine 3 mois après la sortie de la version suivante. Cela laisse très peu de marge de manœuvre pour décaler un upgrade. Il faut donc éviter ce type d'OS en prod.

Bref, j'utilise presque systématiquement Enablement Stacks sur mes serveurs, car cela permet de profiter des améliorations des nouveaux noyaux sans prendre le moindre risque. Par exemple pour ce forum, toujours pas compatible PHP7, j'aurais été embêté si j'étais obligé d'upgrader tous les 6 mois.

(https://lafibre.info/testdebit/ubuntu/201604_ubuntu_kernel_support.svg)

(https://lafibre.info/testdebit/ubuntu/201608_ubuntu_release.png)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 19:32:45
Comment activer Enablement Stacks ?

Ubuntu et dérivé (avec interface graphique)

sudo apt install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04

On passe alors dans le dernier noyau (le 4.8 actuellement, le 4.10 en juillet après avoir été utilisé 3 mois par Ubuntu 17.04) mais aussi dans la dernière pile graphique, celle de Ubuntu 16.10 actuellement (En juillet, ce sera celle d'Ubuntu 17.04) permettant des amélioration de performances.


Ubuntu Server (sans interface graphique)

sudo apt install --install-recommends linux-generic-hwe-16.04



Comment désactiver Enablement Stacks ?

Ubuntu et dérivé (avec interface graphique)

sudo apt purge linux-generic-hwe-16.04 xserver-xorg-hwe-16.04


Ubuntu Server (sans interface graphique)

sudo apt purge linux-generic-hwe-16.04
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Hugues le 27 avril 2017 à 19:33:10
Ok, je comprends ton choix :)

Perso j'essaie d'être le plus à jour sur les serveurs non critiques, donc j'ai déjà une bonne partie en Zesty, même si la majorité reste en Xenial (avec du livepatch sur tous !)  ;)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 27 avril 2017 à 19:42:41
Je n'ai aucun serveur en Zesty (Ubuntu 17.04) par contre tous mes PC (interface graphique) pour mon utilisation sont en Zesty.
Les PC de mes connaissances par contre reste en LTS, une upgrade tous les 2 ans, c'est largement suffisant.

Pour le livepatch tu payes le service ?

(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/testdebit/ubuntu/201610_Ubuntu_LivePatching.png) (https://lafibre.info/testdebit/ubuntu/201610_Ubuntu_LivePatching.pdf)

Quand-est ce que Debian va sortir ça ? Cela permettrait de se différencier (aujourd'hui toutes les distrib que le proposent le font payer)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Hugues le 27 avril 2017 à 20:54:15
Pour le livepatch tu payes le service ?

*tousse* j'ai un très bon système d'alias mail *tousse*


 ;)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 30 avril 2017 à 07:03:35
Je viens de rajouter deux mesures de protections supplèmentaires : (je suis preneur de vos autres idées)

   # Temps pendant lequel le serveur va attendre certains évènements avant de considérer
   # qu'une requête a échoué. Lors de la lecture de données en provenance du client,
   # c'est le temps maximum jusqu'à l'arrivée d'un paquet TCP si le tampon est vide.
   # Défaut: TimeOut 60
   # Réduire le TimeOut a 30 secondes, permet de limiter le temps maximum pendant
   # lequel Apache httpd va attendre des entrées/sorties, lors des attaques de slow DDOS.
   Timeout 30

   # Spécifie le délai maximum après lequel le serveur va s'arrêter dans le cas d'un arrêt "en douceur"
   # Défaut: GracefulShutdownTimeout 0 => le serveur va attendre jusqu'à ce que toutes les requêtes en cours aient été traitées.
   # Réduire le GracefulShutdownTimeout a une heure (3600 secondes) permet de réduire certains attaques slow DDOS.
   # Réduire cette valeur en dessous d'une heure peut poser problème pour des clients avec du bas débit
   # Une connexion a 400 Kb/s (50 Ko/s) est en mesure de télécharger 180 Mo en une heure.
   GracefulShutdownTimeout 3600


Le gain du timeout à 30 secondes est impressionnant => plus de slow DDOS depuis sa mise en place le 27 en milieu de journée.

La valeur était de 300 secondes avant la modification.
(https://lafibre.info/images/stats/201704_ubuntu_apache_processes_1.png)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 02 mai 2017 à 22:42:52
Nouvelles tentatives de mettre un Timeout 300 (en conservant GracefulShutdownTimeout 3600) :

(https://lafibre.info/images/stats/201704_ubuntu_apache_processes_2.png)

No comment.

Je vais donc remettre :
- Timeout 30
- GracefulShutdownTimeout 3600

+ rajouter une nouvelle : KeepAliveTimeout 2
La valeur par défaut est de 5 secondes.

KeepAliveTimeout est la durée pendant laquelle le serveur va attendre une requête avant de fermer une connexion persistante

L'implèmentation des connexions persistantes dans HTTP/1.1 permet de faire plusieurs requêtes dans une même connexion TCP.

Avec KeepAliveTimeout 2, Apache va fermer 3 secondes plus tôt cette cette attente d'une nouvelle requête sur la même connexion TCP. Cela permet de libérer des ressources importantes, quand il y a de nombreux petit téléchargements effectués, comme les mises à jour qui sont checké char jour par tous les PC Ubuntu.

Si le serveur est très long pour enchaîner les requêtes, le seul impact sera l’obligation d'ouvrir une nouvelle connexion TCP. Ce cas devrait être très rare. Le Timeout restant lui à 30 secondes.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 09 janvier 2018 à 08:49:08
Nouveauté : il y a maintenant des statistiques temps réel sur le serveur.

=> Statistiques du serveur miroir Ubuntu "fr.archive.ubuntu.com" (https://lafibre.info/ubuntu-stats/)

J'ai essayé de donner une définition accessible au plus grand nombre des graphes.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 09 mai 2018 à 17:08:41
Statistiques de https://lafibre.info/ubuntu-stats/ le 9 mai 2018.

La hausse de trafic à partir de 0h26 est lié à la mise à jour des Kernel pour toutes les versions d'Ubuntu encore maintenu (excepté la nouvelle version 18.04 LTS qui avait déjà les correctifs et la version 18.10 en développement)

Le pic de 6h25 à 6h55 du matin (trafic moyen de près de 5 Gb/s pendant ces 30 minutes) puis de puis 7h25 à 7h55 est lié a des machines connectées 24h/24 : Par défaut elles vérifient les mises à jour (et pour certaines les télécharges et les installes, d'autres ne font que notifier de la présence de mises à jour sans les télécharger)

Environ 700 000 machines se connectent a ce serveur chaque jour pour récupérer les mises à jour de sécurité.


(https://lafibre.info/images/stats/201805_stats_serveur_miroir_ubuntu_fr.archive.ubuntu.com.png)
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 09 mai 2018 à 20:13:47
La faille corrigé par la mise à jour de ce matin :

Windows, macOS, Linux et BSD partagent une même faille

Sécurité : Éditeurs de systèmes d'exploitation et d'hyperviseurs corrigent une faille de sécurité permettant à des pirates de crasher des systèmes ou de lire des données de la mémoire.
la rédaction de ZDNet

Windows, macOS, les principales distributions Linux, FreeBSD, VMware et Xen sur les processeurs AMD et Intel x86 sont affectés par un problème de sécurité causé par une mauvaise interprétation par les développeurs de la documentation de débogage des deux fournisseurs de processeurs.

Les éditeurs d'OS et d'hyperviseurs concernés ont publié mardi des correctifs pour une faille commune qui pourrait permettre à un attaquant authentifié de "lire des données sensibles en mémoire ou de contrôler des fonctions de bas niveau du système d'exploitation" selon le CERT. (https://www.kb.cert.org/vuls/id/631579)

Des exceptions mal gérées

Les correctifs sont disponibles auprès d'Apple, de DragonFly BSD, de FreeBSD, de Microsoft, de Red Hat, de SUSE Linux, d'Ubuntu, de VMware et de Xen. Dans le cas des distributions Linux, deux problèmes distincts affectent le noyau Linux et l'hyperviseur KVM du noyau. Des liens vers toutes les mises à jour disponibles sont disponibles dans l'avis du CERT.

Selon la description fournie par RedHat, la faille découle de la façon dont les systèmes d'exploitation et les hyperviseurs gèrent certaines fonctionnalités de débogage dans les processeurs modernes - dans le cas présent, la gestion des exceptions de débogage.

"Généralement, les exceptions sont levées à la limite de l'instruction, toutes les instructions avant celle causant l'exception sont autorisées à s'exécuter et celle causant l'exception est bloquée, de sorte que l'exécution peut reprendre une fois l'exception traitée" note RedHat.

"Dans quelques cas", un comportement inattendu peut se produire si certaines instructions telles que SYSCALL suivent les deux instructions d'exception MOV to SS ou POP to SS, précise le CERT.

Concernant un système d'exploitation Linux, la faille peut permettre à un attaquant de planter un système. Toutefois, la faille peut également permettre à un utilisateur invité KVM sans droits de "planter l'invité ou, potentiellement, d'augmenter ses privilèges."

Microsoft affirme que la vulnérabilité pourrait permettre à un attaquant d'exécuter du code arbitraire en mode noyau. "Pour exploiter cette vulnérabilité, un attaquant devrait d'abord se connecter au système. L'attaquant pourrait ensuite exécuter une application spécialement conçue pour prendre le contrôle d'un système affecté" souligne l'éditeur.

La faute à Intel et AMD ?

VMware signale que ses hyperviseurs ne sont pas affectés, au contraire d'autres de ses produits, potentiellement concernés, parmi lesquels VMware vCenter Server, VMware Data Protection et VMware vSphere Integrated Containers.

Le projet Xen indique que toutes les versions de Xen sont affectées, mais que la faille ne peut être exploitée que par des invités PV ou paravirtualisation. La virtualisation assistée par matériel (HVM) ne peut pas exploiter la faille.

Le CERT signale que ce problème semble avoir été causé par le fait que les développeurs du système d'exploitation ont mal géré ces exceptions.

Mais bien que les vulnérabilités ne soient pas dues au design des processeurs, l'interprétation erronée de l'exception était "due à l'interprétation d'une documentation existante potentiellement vague et à des conseils sur l'utilisation de ces instructions."

La vulnérabilité a été découverte par les chercheurs Nick Peterson d'Everdox Tech et Nemanja Mulasmajic de Triplefault.io qui présenteront leurs recherches lors de la BlackHat 2018.

"C'est une faille de sécurité sérieuse et un oubli de la part des fournisseurs de systèmes d'exploitation en raison d'une documentation floue et peut-être même incomplète sur les règles d'exception de l'instruction POP SS et de son interaction avec la sémantique des interruptions" commente le duo d'experts dans son rapport.


Source : ZD-Net (http://www.zdnet.fr/actualites/windows-macos-linux-et-bsd-partagent-une-meme-faille-39868008.htm), le 9 mai 2018 Par Liam Tung
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Leon le 10 mai 2018 à 12:36:12
Environ 700 000 machines se connectent a ce serveur chaque jour pour récupérer les mises à jour de sécurité.
Ca commence à faire beaucoup, 700 000 machines.
Est-ce que tu as moyen de récupérer des statistiques? Par exemple quelle distribution? La part de serveurs / desktop?

Leon.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Hugues le 10 mai 2018 à 18:05:00
Genre ça ? :p

https://fr.archive.ubuntu.com/stats/stats_of_day-1.html
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: Leon le 10 mai 2018 à 18:16:25
Merci!

Leon.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 10 mai 2018 à 18:17:33
Hugues a répondu avant moi.

Les statistiques d'hier :
- Ubuntu 18.04    : 4.817% (34847 separate computers)
- Ubuntu 17.10    : 6.323% (45744 separate computers)
- Ubuntu 17.04    : 2.063% (14925 separate computers)
- Ubuntu 16.10    : 1.285% (9301 separate computers)
- Ubuntu 16.04 LTS: 57.308% (414574 separate computers)
- Ubuntu 15.10    : .634% (4593 separate computers)
- Ubuntu 15.04    : .910% (6585 separate computers)
- Ubuntu 14.10    : .157% (1139 separate computers)
- Ubuntu 14.04 LTS: 18.539% (134117 separate computers)
- Ubuntu 13.10    : .273% (1976 separate computers)
- Ubuntu 13.04    : .173% (1253 separate computers)
- Ubuntu 12.10    : .127% (919 separate computers)
- Ubuntu 12.04 LTS: 5.904% (42712 separate computers)
- Ubuntu 11.10    : .143% (1035 separate computers)
- Ubuntu 11.04    : .122% (886 separate computers)
- Ubuntu 10.10    : .046% (334 separate computers)
- Ubuntu 10.04 LTS: .960% (6948 separate computers)
- Ubuntu  9.10    : .044% (321 separate computers)
- Ubuntu  9.04    : .029% (215 separate computers)
- Ubuntu  8.10    : .006% (45 separate computers)
- Ubuntu  8.04 LTS: .109% (793 separate computers)
- Ubuntu  7.10    : .003% (27 separate computers)
- Ubuntu  7.04    : .002% (18 separate computers)
- Ubuntu  6.10    : 0% (2 separate computers)
- Ubuntu  6.06 LTS: .012% (94 separate computers)
- Ubuntu  5.10    : 0% (3 separate computers)
- Ubuntu  5.04    : 0% (1 separate computers)
- Ubuntu  4.10    : 0% (0 separate computers)
Total Ubuntu      : 100% (723407 separate computers)


Il n'est pas possible de faire la différence entre une station avec interface graphique vs serveur sans interface graphique.

Il n'est pas non plus possible de savoir ce qui est Ubuntu / Kubuntu / Xubuntu / Lubuntu / Ubuntu Budgie / Ubuntu Mate / Ubuntu Studio ou des distributions autres qui utilisent les paquets Ubuntu. Linux Mint utilise soit les paquets Ubuntu (Éditions standard  / Éditions dérivées comme Mate, Xfce  ou KDE) soit les paquets Debian (Linux Mint Debian).

Je me demande si "Ubuntu 12.04 LTS Extended Security Maintenance" (extension de maintenance payante au-delà des 5 années incluses de base) pointe sur me dépôts ou si tout passe un dépôt spécifique et protégé par authentification.

Au total seul 87% des requêtes sont réalisés par des versions d'Ubuntu maintenus, si on suppose qu'il n'y a pas d'Extended Security Maintenance. Il y a toujours eu une part non négligeable de version d'Ubuntu qui ne sont plus maintenu (13% actuellement, dont 5,9% pour Ubuntu 12.04 et 2,1% pour Ubuntu 17.04) qui sont toujours connecté à Internet et qui vont voir tous les jour si il y a des mises à jour.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 11 mai 2018 à 21:18:11
Aujourd'hui c'est la mise à jour de Firefox.

La taille est un peu prés équivalent au nouveau Kernel de l'autre jour mais le profil étant sur des machines avec interface graphique, la mise à jour est plus étalée dans la journée :

(https://lafibre.info/testdebit/ubuntu/201805_stat_ubuntu_maj_firefox.png)

Le pic de entre 16h et 17h (+700 Mb/s par rapport au trafic voisin) est lié a une aspiration des fichiers pour constituer un nouveau miroir partiel. C'est http qui est utilisé pour cette duplication et non rsync.
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: retho le 12 mai 2018 à 18:09:13
Hugues a répondu avant moi.

Les statistiques d'hier :
- Ubuntu 18.04    : 4.817% (34847 separate computers)
- Ubuntu 17.10    : 6.323% (45744 separate computers)
- Ubuntu 17.04    : 2.063% (14925 separate computers)
- Ubuntu 16.10    : 1.285% (9301 separate computers)
- Ubuntu 16.04 LTS: 57.308% (414574 separate computers)
- Ubuntu 15.10    : .634% (4593 separate computers)
- Ubuntu 15.04    : .910% (6585 separate computers)
- Ubuntu 14.10    : .157% (1139 separate computers)
- Ubuntu 14.04 LTS: 18.539% (134117 separate computers)
- Ubuntu 13.10    : .273% (1976 separate computers)
- Ubuntu 13.04    : .173% (1253 separate computers)
- Ubuntu 12.10    : .127% (919 separate computers)
- Ubuntu 12.04 LTS: 5.904% (42712 separate computers)
- Ubuntu 11.10    : .143% (1035 separate computers)
- Ubuntu 11.04    : .122% (886 separate computers)
- Ubuntu 10.10    : .046% (334 separate computers)
- Ubuntu 10.04 LTS: .960% (6948 separate computers)
- Ubuntu  9.10    : .044% (321 separate computers)
- Ubuntu  9.04    : .029% (215 separate computers)
- Ubuntu  8.10    : .006% (45 separate computers)
- Ubuntu  8.04 LTS: .109% (793 separate computers)
- Ubuntu  7.10    : .003% (27 separate computers)
- Ubuntu  7.04    : .002% (18 separate computers)
- Ubuntu  6.10    : 0% (2 separate computers)
- Ubuntu  6.06 LTS: .012% (94 separate computers)
- Ubuntu  5.10    : 0% (3 separate computers)
- Ubuntu  5.04    : 0% (1 separate computers)
- Ubuntu  4.10    : 0% (0 separate computers)
Total Ubuntu      : 100% (723407 separate computers)


Il n'est pas possible de faire la différence entre une station avec interface graphique vs serveur sans interface graphique.

Il n'est pas non plus possible de savoir ce qui est Ubuntu / Kubuntu / Xubuntu / Lubuntu / Ubuntu Budgie / Ubuntu Mate / Ubuntu Studio ou des distributions autres qui utilisent les paquets Ubuntu. Linux Mint utilise soit les paquets Ubuntu (Éditions standard  / Éditions dérivées comme Mate, Xfce  ou KDE) soit les paquets Debian (Linux Mint Debian).

Je me demande si "Ubuntu 12.04 LTS Extended Security Maintenance" (extension de maintenance payante au-delà des 5 années incluses de base) pointe sur me dépôts ou si tout passe un dépôt spécifique et protégé par authentification.

Au total seul 87% des requêtes sont réalisés par des versions d'Ubuntu maintenus, si on suppose qu'il n'y a pas d'Extended Security Maintenance. Il y a toujours eu une part non négligeable de version d'Ubuntu qui ne sont plus maintenu (13% actuellement, dont 5,9% pour Ubuntu 12.04 et 2,1% pour Ubuntu 17.04) qui sont toujours connecté à Internet et qui vont voir tous les jour si il y a des mises à jour.

Pour quelles raisons des personnes utilisent encore les anciennes versions Ubuntu (ou dérivés) ?

Et les statistiques portent sur des téléchargements de version ou de mises à jour ? Car si les anciennes versions ne sont plus supportées, elles ne sont plus mises à jour, non ?
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 12 mai 2018 à 18:37:09
Je compte les demandes de mise à jour de la liste des logiciels : chaque jour et une seule fois par jour, un PC Ubuntu vas télécharger la liste des logiciels pour voir si il y a des mises à jour.

3 cas possible :
- Version maintenue : il reçois la liste qui comporte peut être des mises à jour
- Version non maintenues mais encore en ligne : il reçois la liste qui ne comprend aucune mise à jour (enfin sauf si il réinstalle depuis le CD cette veille version)
- Version non maintenues et plus en ligne : c'est une erreur qui est retourné, le serveur n'ayant plus les fichiers.

Pour quelles raisons des personnes utilisent encore les anciennes versions Ubuntu (ou dérivés) ?

Pourquoi des personnes utilisent encore Windows XP en 2018 ?

C'est la même chose :
- Pas envie de changer qq chose qui fonctionne / N'ose pas faire la mise à jour / Ne sais pas faire / Ne comprend pas l’intérêt de le faire
- Ne sait pas faire la mise à jour (exemple mot de passe root perdu avec connexion automatique au démarrage : la perte du mot de passe ne bloque que les mises à jour et l'installation de nouveaux logiciels)
- CPU trop ancien pour supporter la nouvelle version (Si tu as un Pentium III ou un Athlon XP, il faut prendre une veille version : car aucun navigateur web moderne ne supporte un CPU sans les 144 instruction SSE2 : Sous Linux comme sous Windows ces instructions sont nécessaires à tous les navigateurs web dans leur dernières versions)
- Pas assez de RAM pour une utilisation fluide avec la nouvelle version (la consommation en RAM augmente au fur et à mesure)
- Connexion Internet 128Kb/s trop lente pour télécharger les mises à jour
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: retho le 12 mai 2018 à 18:49:23
C'est la même chose :
- Pas envie de changer qq chose qui fonctionne / N'ose pas faire la mise à jour / Ne sais pas faire / Ne comprend pas l’intérêt de le faire
- Ne sait pas faire la mise à jour (exemple mot de passe root perdu avec connexion automatique au démarrage : la perte du mot de passe ne bloque que les mises à jour et l'installation de nouveaux logiciels)
- CPU trop ancien pour supporter la nouvelle version (Si tu as un Pentium III ou un Athlon XP, il faut prendre une veille version : car aucun navigateur web moderne ne supporte un CPU sans les 144 instruction SSE2 : Sous Linux comme sous Windows ces instructions sont nécessaires à tous les navigateurs web dans leur dernières versions)
- Pas assez de RAM pour une utilisation fluide avec la nouvelle version (la consommation en RAM augmente au fur et à mesure)
- Connexion Internet 128Kb/s trop lente pour télécharger les mises à jour

Vous êtes gentils du coup les mainteneurs (c'est un métier ? lol) de faire disposer un serveur d'archive pour des très vieilles versions.

Du coup, pour la version Ubuntu 4.10, par exemple, il existe une date limite à la suite de quoi cette version sera supprimée des serveurs d'archives ?
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 13 mai 2018 à 09:57:44
Une distribution est rapidement supprimée des serveurs miroirs (c'est Canonical qui décide de la date)

La liste des distribution encore sur le serveur est affiché ici : https://fr.archive.ubuntu.com/ubuntu/dists/

artful/ => Ubuntu 17.10
bionic/ => Ubuntu 18.04 LTS
cosmic/ => Ubuntu 18.10
devel/ => raccourci vers la distribution en cour de développement qui est la 18.10 en ce moment
precise/ => Ubuntu 12.04 LTS
trusty/ => Ubuntu 14.04 LTS
xenial/ => Ubuntu 16.04 LTS

Ubuntu 17.04, qui est sorti en avril 2017 n'est déjà plus sur les serveurs.

Il y a un serveur qui garde les derniers paquets de chaue version d'Ubuntu : il suffit de remplacer dans /etc/apt/sources.list le miroir présent pat
http://old-releases.ubuntu.com/ubuntu/
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 15 mai 2018 à 07:23:22
En terme de volume de données,

Voici ce qui a été échangé en exactement 20 jours et 0 heure :

Octets reçus:4074680092830 (4.0 TB)
Octets transmis:177578632306307 (177.5 TB)

Cela donne :
- 204 Go par jour en réception pour les acquittements TCP et les mises à jour du miroir.
- 8 879 Go par jour pour les données émises
Titre: Statistiques du serveur de mise à jour Ubuntu par défaut pour la France
Posté par: vivien le 15 septembre 2018 à 10:20:20
Statistiques sur le serveur miroir Ubuntu "fr.archive.ubuntu.com"

Les statistiques en temps réel sont sur https://fr.archive.ubuntu.com/stats/stats_server.html

Voici les données historiques :
- A gauche les stats d’août 2017 à septembre 2018
- A droite les stats de mars 2016 à avril 2017

Trafic réseau en Gb/s généré par les mises à jour (via http/htps/rsync) sur la carte Intel X710 :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_if-year.png) (https://lafibre.info/images/stats/201704_ubuntu_if-year.png)

Nombre de fichiers téléchargés par seconde pour les mises à jour (via http/https) :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_apache_accesses-year.png) (https://lafibre.info/images/stats/201704_ubuntu_apache_accesses-year.png)

Répartition de l'utilisation des slots du serveur web Apache :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_apache_processes-year.png) (https://lafibre.info/images/stats/201704_ubuntu_apache_processes-year.png)

Débit des connexions Apache (mises à jour via http/https) en Mo/s :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_apache_volume-year.png) (https://lafibre.info/images/stats/201704_ubuntu_apache_volume-year.png)

Temps d'attente (en milliseconde) pour charger un fichier Apache :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_http_loadtime-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Rsync: Débit en Mb/s. Bleu:Canonical met à jour ce serveur Vert:Des serveurs tiers se mettent à jour via ce serveur
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_rsync_bytes-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Rsync: Nombre de fichiers échangés par seconde lors des synchronisation distante de l'archive Ubuntu :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_rsync_count-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Espace disque. L'archive Ubuntu es sur la partition /home, d'une taille de 1,9 To (50% et 70% sont les seuils d'alerte)
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_df-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Load average (moyenne de la charge système) :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_load-year.png) (https://lafibre.info/images/stats/201704_ubuntu_load-year.png)

Usage du processeur Xeon E3-1240 v6 (1 cœur=100% => 4 cœurs hyper-threading, donne un maximum de 800%) :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_cpu-year.png) (https://lafibre.info/images/stats/201704_ubuntu_cpu-year.png)

Usage des 32 Go de mémoire vive (DDR4 SDRAM) :
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_memory-year.png) (https://lafibre.info/images/stats/201704_ubuntu_memory-year.png)

Uptime (durée de fonctionnement du serveur, en jours): Les reboots sont liés à l'applications de correctifs de sécurité
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_uptime-year.png) (https://lafibre.info/images/stats/201704_ubuntu_uptime-year.png)

Consommation électrique du serveur Dell R330 (en Watts): La donnée est remontée avec des palliers de 14 watts.
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_ipmi_power-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Température de l'air en degrés d’entrée (vert) / sortie (bleu). (40°c corespond au seuil d’alerte pour l'entrée d'air)
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_ipmi_temp-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Température du CPU (vert) / PCH (bleu). Le PCH (Platform Controller Hub) est un chipset Intel sur la carte mère.
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_acpi-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)

Vitesse des 8 ventilateurs du serveur (en tours par minute): Les ventilateurs des deux alimentations ne sont pas remontés.
(https://lafibre.info/images/stats/201809_fr_archive_ubuntu_ipmi_fans-year.png) (Nouvel indicateur: pas de statistiques pour mars 2016 à avril 2017)