Auteur Sujet: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !  (Lu 5326 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 27 231
    • Twitter LaFibre.info
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #48 le: 22 novembre 2017 à 09:13:49 »
Je besoin, sur certains serveurs que les mises à jour de sécurité se réalisent à une heure précise (entre 5h55 et 5h56).

J'ai donc édite /etc/cron.daily/apt-compat pour réduire le temps d’attente aléatoire (passer de 0 à 1800 secondes => 0 à 60 secondes).

Pour l'heure de lancement, j'ai directement édité  /etc/crontab : le lancement des scripts de cron.daily a été avancé de 6H25 à 5h55 :
# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
55 5    * * *   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 )

J'ai bien les différents scripts quotidiens qui s'exécutent maintenant a 5h55 (rotation de log par exemple)

Par contre les mises à jour de sécurité sont toujours à l'ancienne heure, selon /var/log/unattended-upgrades/unattended-upgrades.log

En regardant le début du script /etc/cron.daily/apt-compat qui lance les mises à jour, j'ai trouvé une information intéressante :
#!/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

Bref, je pense qu'il y a un lancement crontab de /etc/cron.daily/apt-compat mais qu'il sort tout de suite car j'ai systemd.

D'où ma question : où contrôler la crontab de Systemd ?

zoc

  • Client Orange Fibre
  • *
  • Messages: 1 577
  • Antibes (06)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #49 le: 22 novembre 2017 à 10:32:54 »
Ca ne serait pas par hasard dans /lib/systemd/system/apt-daily.timer ?


vivien

  • Administrateur
  • *
  • Messages: 27 231
    • Twitter LaFibre.info
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #50 le: 22 novembre 2017 à 19:25:22 »
Tout a fait !

Si j'ai bien compris, il y a 6 fichiers importants pour les mises à jour automatiques sous Ubuntu et probablement Debian :

- apt-daily.timer  / apt-daily.service : lance le téléchargement des mises à jour toutes les 12 heures, après un temps d'attente aléatoire variant de 0 à 12h. Dans le passé, c'était une fois par jour, la nuit a 6h25 après un temps d'attente variant de 0 à 30 minutes.

- apt-daily-upgrade.timer / apt-daily-upgrade.service : Lance l'upgrade proposent dit et le reboot si c'est configuré comme ça. Le llancement se fait a 6h00 + une attente aléatoire variant de 0 à 60 minutes.

- /etc/apt/apt.conf.d/10periodic : Autorise la mise à jour des paquets permettant de voir si une mise à jour est disponible, le téléchargement de la mise à jour proprement dite et l'installation.

- /etc/apt/apt.conf.d/50unattended-upgrades : Indique si cela ne concerne que les mises à jour de sécurité ou toutes les mises à jour disponibles. C'est aussi là qu'on précise les options pour supprimer les anciens noyaux et si on souhaite un reboot après la mise à jour.

/lib/systemd/system/apt-daily.timer :
[Unit]
Description=Daily apt download activities

[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/apt-daily.service :
[Unit]
Description=Daily apt download activities
Documentation=man:apt(8)
ConditionACPower=true
After=network.target network-online.target systemd-networkd.service NetworkMana$

[Service]
Type=oneshot
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily update

/lib/systemd/system/apt-daily-upgrade.timer :
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/apt-daily-upgrade.service :
[Unit]
Description=Daily apt upgrade and clean activities
Documentation=man:apt(8)
ConditionACPower=true
After=apt-daily.service

[Service]
Type=oneshot
ExecStart=/usr/lib/apt/apt.systemd.daily install
KillMode=process
TimeoutStopSec=900

/etc/apt/apt.conf.d/10periodic :
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";

/etc/apt/apt.conf.d/50unattended-upgrades :
// Automatically upgrade packages from these (origin:archive) pairs
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for
// every release and this system may not have it installed, but if
// available, the policy for updates is such that unattended-upgrades
// should also install from here by default.
"${distro_id}ESM:${distro_codename}";
// "${distro_id}:${distro_codename}-updates";
// "${distro_id}:${distro_codename}-proposed";
// "${distro_id}:${distro_codename}-backports";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};

// This option will controls whether the development release of Ubuntu will be
// upgraded automatically.
Unattended-Upgrade::DevRelease "false";

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "false";

// Install all unattended-upgrades when the machine is shutting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
//Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

// Enable logging to syslog. Default is False
// Unattended-Upgrade::SyslogEnable "false";

// Specify syslog facility. Default is daemon
// Unattended-Upgrade::SyslogFacility "daemon";

vivien

  • Administrateur
  • *
  • Messages: 27 231
    • Twitter LaFibre.info
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #51 le: 28 novembre 2017 à 10:34:21 »
Cela fonctionne.

Ne pas oublier un sudo systemctl daemon-reload après avoir modifier un fichier, sinon ce n'est pas pris en compte.

lordzurp

  • Client OVH
  • *
  • Messages: 68
  • Thurins (69)
    • zUrp
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #52 le: 28 novembre 2017 à 11:04:02 »
arretez de vous faire du mal, passez sous UNIX :troll:

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 453
  • Amiens (80)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #53 le: 28 novembre 2017 à 21:13:49 »
Hum

seb

  • Pau Broadband Country (64)
  • Client SFR fibre FTTH
  • *
  • Messages: 512
  • FTTH 100/50 Mbps sur Pau (64)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #54 le: 29 novembre 2017 à 08:53:29 »
Si j'ai bien compris, pour surcharger la configuration d'un élèment systemd, il faut recopier le fichier /lib/systemd/system/quelque.chose sous /etc/systemd/system/, et faire ses modifs dedans.
Sinon, elles sauteront à la prochaine mise à jour du paquet qui embarque le fichier.

 

Mobile View