Skip to main content

WSUS – Relancer manuellement la synchronisation du catalogue Windows Updates

S'applique à : Medulla Serveur
Version : Toutes versions
Environnement : On-Premise
Catégorie : Windows Updates / WSUS / Maintenance

Cette FAQ explique le fonctionnement de la récupération du catalogue des mises à jour Microsoft par Medulla, sa synchronisation sur les serveurs Medulla et les procédures de relance et de diagnostic.

À retenir :
Medulla n'utilise pas un serveur WSUS Microsoft classique. Le catalogue est généré de manière centralisée puis distribué aux serveurs Medulla depuis https://updates.medulla-tech.io.

Sur chaque serveur Medulla, sa récupération et sa reconstruction locale sont assurées par /usr/sbin/medulla-generate-winupdate-packages, automatiquement chaque nuit à 01h30.

1. Fonctionnement du service Windows Updates

Rôle Adresse Fonction
Génération centrale wsusdb01.medulla.lan Construit la base à partir du catalogue Microsoft.
Distribution Medulla https://updates.medulla-tech.io Distribue le catalogue aux serveurs Medulla.
Source Microsoft http://go.microsoft.com/fwlink/?linkid=74689 Source du fichier wsusscn2.cab.

Génération centrale

Le serveur wsusdb01.medulla.lan :

  1. télécharge wsusscn2.cab ;
  2. compare son MD5 avec le catalogue précédent ;
  3. reconstruit base_wsusscn2 lorsque le catalogue a changé ;
  4. complète les données depuis le Microsoft Update Catalog ;
  5. génère un dump SQL ;
  6. le publie sur updates.medulla-tech.io.

Synchronisation des serveurs Medulla

Chaque serveur Medulla exécute :

/usr/sbin/medulla-generate-winupdate-packages

Le script :

  1. lit les identifiants BDD et keyAES32 dans /etc/mmc/plugins/xmppmaster.ini.local ;
  2. calcule le MD5 du dump local dans /var/lib/pulse2/downloads/ ;
  3. récupère le MD5 du dump publié : 
    https://updates.medulla-tech.io/wsusscn2_dump.md5
  4. télécharge le nouveau dump si le MD5 diffère, avec possibilité de reprise via curl -C - ;
  5. vérifie son MD5 ;
  6. importe le dump dans base_wsusscn2 ;
  7. exécute up_reinit_table_update_data() ;
  8. exécute up_create_product_tables() ;
  9. supprime les produits obsolètes, notamment XP, Vista, Windows 7 et Embedded Standard 7 ;
  10. lit les produits configurés dans /etc/mmc/plugins/updates.ini et updates.ini.local ;
  11. recrée les packages et liens symboliques avec pulse2-generation_package.py.

Important :
medulla-generate-winupdate-packages ne télécharge pas directement wsusscn2.cab depuis Microsoft. Cette opération est effectuée en amont par wsusdb01.

Confidentialité :
Le dump SQL est protégé par un token correspondant à keyAES32 dans la section [defaultconnection] de /etc/mmc/plugins/xmppmaster.ini.local. Cette valeur ne doit jamais être diffusée.

2. Relancer immédiatement la synchronisation

Il n'est pas nécessaire d'attendre l'exécution automatique de 01h30. La même tâche peut être lancée manuellement.

Elle doit être exécutée sur le serveur Medulla principal de l'infrastructure concernée, et non sur un poste Windows ou sur wsusdb01.

1. Vérifier que le script et le cron sont présents

ls -l /usr/sbin/medulla-generate-winupdate-packages /etc/cron.d/medulla_winupdates_dl

2. Vérifier qu'aucune synchronisation n'est déjà en cours

pgrep -af medulla-generate-winupdate-packages

Si une exécution est présente, attendre sa fin.

3. Vérifier l'espace disque

df -h /var/lib/pulse2

4. Lancer la synchronisation

La commande doit être exécutée avec les droits root :

/usr/sbin/medulla-generate-winupdate-packages 2>&1 | tee -a /tmp/medulla-generate-winupdate-packages.log

Avec sudo :

sudo sh -c '/usr/sbin/medulla-generate-winupdate-packages 2>&1 | tee -a /tmp/medulla-generate-winupdate-packages.log'

Pourquoi root ?
Le script doit lire xmppmaster.ini.local, accéder aux identifiants BDD et à keyAES32, écrire dans /var/lib/pulse2/downloads/ et recréer les packages et liens sous /var/lib/pulse2/packages/.

Avec sudo, utilisez sudo sh -c afin que tee soit lui aussi exécuté avec les privilèges nécessaires.

Exécution en arrière-plan

Pour pouvoir fermer la connexion SSH :

nohup sh -c '/usr/sbin/medulla-generate-winupdate-packages 2>&1 | tee -a /tmp/medulla-generate-winupdate-packages.log' >/dev/null 2>&1 &

Suivre ensuite l'exécution :

tail -f /tmp/medulla-generate-winupdate-packages.log

Ctrl+C arrête alors uniquement tail, pas le traitement.

À éviter :
Ne lancez pas manuellement la synchronisation à proximité de 01h30. Le script ne dispose pas d'un verrou empêchant deux exécutions simultanées. Contrôlez toujours avec pgrep avant une relance.

Pendant l'import, update_data est réinitialisée puis reconstruite. Les informations du module Windows Updates peuvent donc être temporairement incomplètes.

3. Vérifier le résultat

Suivre les dernières étapes

grep -E "^\[20" /tmp/medulla-generate-winupdate-packages.log | tail -10

Rechercher les erreurs

grep -iE "error|denied" /tmp/medulla-generate-winupdate-packages.log | tail

Un traitement normal comporte notamment :

##### Starting medulla-generate-winupdate-packages
Remote checksum:
Checksum changed. Downloading ...
ou
File ... is already up to date
Importing ... to base_wsusscn2 database
Reinitialising update_data table
Creating product tables
Deleting obsolete products
Recreating packages database records and symlinks

Contrôler le code retour

Immédiatement après une exécution avec tee :

echo ${PIPESTATUS[0]}

0 indique que le script n'a pas retourné d'erreur.

Attention :
Le script ne contrôle pas nécessairement le résultat de toutes les commandes MySQL. Un code retour 0 ne garantit donc pas à lui seul l'absence d'erreur SQL. Consultez toujours le journal.

Comparer le dump local avec le dump publié

md5sum /var/lib/pulse2/downloads/*dumptable_update_data.sql
curl -s https://updates.medulla-tech.io/wsusscn2_dump.md5

Les empreintes MD5 doivent correspondre.

4. Cas « already up to date »

Le message already up to date signifie uniquement que le dump local est identique au dump publié et qu'aucun nouveau téléchargement n'est nécessaire.

Le script poursuit toutefois le traitement local : import dans base_wsusscn2, réinitialisation de update_data, recréation des tables produits, packages et liens symboliques.

  • Pour obtenir de nouvelles mises à jour Microsoft : une relance est inutile tant qu'un nouveau dump n'a pas été publié.
  • Pour reconstruire les données locales : une relance peut être utile après une exécution interrompue, une modification de updates.ini ou un problème de packages/liens.

5. Erreurs et diagnostic

Erreur / symptôme Cause probable Action
Error downloading .../wsusscn2_dump.md5 Internet, DNS, proxy, pare-feu ou service indisponible. curl -sI https://updates.medulla-tech.io/wsusscn2_dump.md5 doit retourner un accès valide.
Erreur de téléchargement du dump protégé keyAES32 incorrect/absent, disque plein ou téléchargement incomplet. Contrôler la configuration, df -h /var/lib/pulse2 et relancer.
DL_URL parameter is not set Script ou configuration incorrect. Vérifier/réinstaller le script.
ERROR 1045 ... Access denied Droits ou identifiants BDD. Relancer en root et contrôler xmppmaster.ini.local.
tee: ... Permission denied sudo appliqué seulement au script. Utiliser sudo sh -c '...'.
crudini: command not found Paquet crudini absent. Installer/vérifier crudini.
Aucune nouveauté sur toutes les infrastructures depuis plusieurs jours Le dump central n'est peut-être plus généré. Comparer le MD5 distant puis contrôler wsusdb01.

Checklist rapide

pgrep -af medulla-generate-winupdate-packages
curl -sI https://updates.medulla-tech.io/wsusscn2_dump.md5
grep -E "^\[20" /tmp/medulla-generate-winupdate-packages.log | tail -15
grep -iE "error|denied" /tmp/medulla-generate-winupdate-packages.log | tail
ls -l /var/lib/pulse2/downloads/
df -h /var/lib/pulse2
cat /etc/cron.d/medulla_winupdates_dl
md5sum /var/lib/pulse2/downloads/*dumptable_update_data.sql
curl -s https://updates.medulla-tech.io/wsusscn2_dump.md5

6. Forcer le re-téléchargement complet du dump

Si le dump local est suspect ou corrompu, commencez par identifier son nom :

cd /var/lib/pulse2/downloads/
ls -l

Renommez-le plutôt que de le supprimer :

mv dumptable_update_data.sql dumptable_update_data.sql.old

Puis relancez :

/usr/sbin/medulla-generate-winupdate-packages 2>&1 | tee -a /tmp/medulla-generate-winupdate-packages.log

Après validation du nouveau dump et de son import, le fichier .old peut être supprimé.

Attention :
Vérifiez le nom réel du fichier avant de le renommer. Il ne doit y avoir qu'un seul fichier *dumptable_update_data.sql utilisé par le traitement. Plusieurs fichiers correspondants peuvent fausser le calcul du checksum local.

7. Interruption et durée du traitement

La durée varie selon la taille du dump, le débit réseau et les performances du serveur : de quelques minutes à sensiblement plus lors d'un nouveau téléchargement et de l'import SQL.

Une exécution lancée directement depuis une session SSH peut être interrompue si cette session est fermée. Utilisez nohup, screen ou tmux pour éviter ce problème.

Il est également déconseillé d'utiliser Ctrl+C pendant l'import SQL : base_wsusscn2 ou update_data pourraient rester partiellement reconstruites.

Si cela arrive, relancez simplement le script. Pendant un téléchargement, la reprise est prise en charge avec curl -C -.

8. Planification automatique

Tâche Fichier cron Horaire Commande
Windows Updates /etc/cron.d/medulla_winupdates_dl 01h30 /usr/sbin/medulla-generate-winupdate-packages
Mises à jour majeures Windows /etc/cron.d/medulla_osupgrade_dl 04h30 /usr/sbin/medulla-generate-winupdatemajor-packages

Ces tâches sont déployées par le rôle Ansible medulla_osupdates lorsque INTERNET_DISABLED est faux. Lors de l'installation, une première exécution est également programmée via at environ 30 minutes après le déploiement.

Modification du cron :
Il est possible de modifier manuellement son horaire, mais cette modification peut être écrasée lors d'un prochain déploiement Ansible. Pour un changement permanent, modifiez le rôle Ansible.

Pour programmer ponctuellement une synchronisation, par exemple à 22h :

echo '/usr/sbin/medulla-generate-winupdate-packages 2>&1 | tee -a /tmp/medulla-generate-winupdate-packages.log' | at 22:00
atq

Pour contrôler la dernière exécution :

grep -E "^\[20" /tmp/medulla-generate-winupdate-packages.log | tail -10

Selon la configuration du système :

grep medulla-generate /var/log/syslog | tail

Information :
Le journal est stocké dans /tmp et complété avec tee -a. Il peut donc grossir et, selon la configuration du système, disparaître après un redémarrage.

9. Mises à jour majeures Windows

Les upgrades Windows utilisent une tâche distincte :

/usr/sbin/medulla-generate-winupdatemajor-packages

Pour la relancer manuellement :

pgrep -af medulla-generate-winupdatemajor-packages
/usr/sbin/medulla-generate-winupdatemajor-packages

Elle est normalement planifiée à 04h30 via /etc/cron.d/medulla_osupgrade_dl.

10. La synchronisation installe-t-elle les mises à jour sur les postes ?

Non. Elle actualise uniquement le catalogue des mises à jour Windows connu de Medulla : base_wsusscn2, tables produits et packages.

Elle ne modifie aucun poste client. Le déploiement effectif dépend ensuite des listes grises, blanches ou noires et des règles d'approbation configurées dans Medulla.

11. Quand une nouvelle KB Microsoft devient-elle visible ?

Une nouvelle KB doit parcourir toute la chaîne :

  1. publication par Microsoft dans les sources utilisées ;
  2. prise en compte par wsusdb01 ;
  3. génération et publication d'un nouveau dump ;
  4. récupération du dump par chaque serveur Medulla.

Le délai peut donc atteindre un à deux jours après la publication Microsoft.

Dès que le MD5 distant a changé, la synchronisation peut être lancée manuellement sans attendre 01h30.

12. Infrastructure sans accès Internet

Lorsque Medulla est déployé avec INTERNET_DISABLED, le cron de récupération n'est pas installé et le serveur ne peut pas joindre updates.medulla-tech.io.

Le dump doit alors être apporté et importé par une autre méthode.

Information :
La procédure d'import hors ligne n'est pas couverte par cette FAQ.

13. Diagnostic de la génération centrale

Cette opération concerne uniquement l'infrastructure centrale Medulla. Elle est à envisager lorsque le MD5 publié sur updates.medulla-tech.io ne change plus et que le problème affecte plusieurs infrastructures Medulla.

Le serveur de génération est :

wsusdb01.medulla.lan

Accès configurés :

ssh wsusdb
ssh wsusdb-root

Le lanceur est :

medulla-wsusdb-generate-base.sh

Sa configuration est :

medulla-wsusdb.ini

Pour retrouver la planification sur le serveur :

crontab -l
ls /etc/cron.d/

Le lanceur fonctionne en nohup et refuse normalement de démarrer lorsqu'une autre instance est déjà active.

Support Medulla :
Cette procédure concerne l'administration de l'infrastructure centrale Medulla. Elle ne doit pas être confondue avec la relance de medulla-generate-winupdate-packages sur un serveur Medulla client.

Le chemin d'installation exact du lanceur, son horaire de planification et le mécanisme de publication du final_output_folder vers updates.medulla-tech.io doivent être confirmés directement sur wsusdb01.

14. Résumé des commandes utiles

Objectif Commande
Vérifier une synchronisation en cours pgrep -af medulla-generate-winupdate-packages
Relancer la synchronisation /usr/sbin/medulla-generate-winupdate-packages
Suivre le traitement tail -f /tmp/medulla-generate-winupdate-packages.log
Rechercher les erreurs grep -iE "error|denied" /tmp/medulla-generate-winupdate-packages.log | tail
Tester la distribution curl -sI https://updates.medulla-tech.io/wsusscn2_dump.md5
MD5 distant curl -s https://updates.medulla-tech.io/wsusscn2_dump.md5
MD5 local md5sum /var/lib/pulse2/downloads/*dumptable_update_data.sql
Espace disque df -h /var/lib/pulse2
Afficher la planification cat /etc/cron.d/medulla_winupdates_dl

Relance rapide :
Pour actualiser immédiatement le catalogue Windows Updates d'un serveur Medulla, vérifiez d'abord qu'aucune synchronisation n'est en cours :

pgrep -af medulla-generate-winupdate-packages

Puis exécutez en root :

/usr/sbin/medulla-generate-winupdate-packages 2>&1 | tee -a /tmp/medulla-generate-winupdate-packages.log
Back to top