0 Membres et 2 Invités sur ce sujet
# /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/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin# m h dom mon dow user command17 * * * * root cd / && run-parts --report /etc/cron.hourly25 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 )#
#!/bin/shset -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 timeif [ -d /run/systemd/system ]; then exit 0ficheck_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 timerandom_sleep# ensure we don't do this on batterycheck_power || exit 0# run daily jobexec /usr/lib/apt/apt.systemd.daily
Je viens de Passer 1 Po (soit 8 Pb) en 149 jours pour le serveur https://ubuntu.lafibre.info 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)
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://ubuntu.lafibre.info)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 :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 :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)Voici un fichier Calc avec les données sources, si vous pensez qu'il y a d'autres graphes à faire : 201610_stats_ubuntu.ods(lisible avec Libre office Calc et Microsoft Excel)
# 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>
Les reboot du serveur pour appliquer les mises à jour de sécurité :