Contexte : avoir plus de visibilité ne suffit pas

Quand un utilisateur signale « le Wi-Fi est lent », la tentation est connue : ouvrir la topologie, zoomer, parcourir les clients, vérifier les voyants et espérer détecter le problème d’un coup d’oeil. Cela peut fonctionner sur un petit réseau. Sur un environnement multi-sites, la visibilité devient vite du bruit. Il est toujours bon d’éviter le bruit.

Le vrai problème n’est pas toujours l’absence de données. C’est l’absence de contexte, le contexte est clef : qu’est-ce qui a changé ? depuis quand ? sur quel segment ? est-ce un client isolé, un point d’accès instable ou une configuration différente de celle approuvée ?

La version 10.6 de l’application UniFi Network, annoncée fin août 2026, est intéressante précisément parce qu’elle traite cette chaîne opérationnelle. Topology Spotlight réduit la carte aux clients pertinents. Le time machine d’Unifi ajoute un historique aux ports. SafeOps étend la logique de test puis confirmation à des changements sensibles. Site Manager apporte Drift Inspector et la préparation à la haute disponibilité.

La nouveauté n’est donc pas « une interface plus jolie ». C’est la possibilité de passer de « je vois le réseau » à « je peux expliquer ce qui s’est passé et corriger sans perdre la main ».

Ce que UniFi Network 10.6 change concrètement

Topology Spotlight : réduire la carte aux événements

Topology Spotlight permet de mettre en évidence un groupe de clients et de réduire visuellement les éléments qui ne participent pas à l’analyse. Dans un grand site, cette différence est immédiate : au lieu de parcourir toute la topologie, l’équipe commence par un filtre — un VLAN, un site, un type de client ou un ensemble concerné par l’incident.

Ce n’est pas seulement un gain de confort. Une vue plus ciblée réduit le risque de modifier le mauvais équipement parce que plusieurs chemins se ressemblent à l’écran. Le support peut aussi partager une capture qui raconte quelque chose : les clients concernés, leur point d’accès, leur segment et le lien à vérifier.

Time Machine : remettre l’historique dans le dépannage

Les notes de version 10.6.97 ajoutent Time Machine à la vue Radios pour examiner, sur les dernières 24 heures, des métriques d’usage, des changements de configuration et des événements radio. Port Manager Time Machine s’étend à tous les ports et ajoute un filtre pour les appareils qui se reconnectent fréquemment.

Cette profondeur reste courte, mais elle change la conversation. Au lieu de demander « est-ce encore lent ? », l’équipe peut demander : « qu’est-ce qui s’est passé avant le décrochage ? »

Pour le Wi-Fi, Channel AI peut également exécuter une optimisation nocturne avec une sélection de radios configurable. C’est utile dans un environnement dense, à condition de traiter l’automatisation comme une hypothèse à mesurer, pas comme une promesse magique. Un canal qui paraît meilleur pour l’algorithme n’est pas forcément le meilleur choix pour un réseau qui transporte de la voix, des terminaux mobiles ou des équipements sensibles aux microcoupures.

SafeOps, Drift Inspector et le score de haute disponibilité : corriger sans improviser

SafeOps étend le mécanisme Test & Confirm à des réseaux VPN et de management. L’idée est simple et saine : une modification est appliquée, la connectivité est vérifiée, puis la configuration est confirmée ou rétablie si le test échoue. L’annonce Ubiquiti cite notamment les changements de VLAN de management et la protection par retour à la dernière configuration fonctionnelle.

Site Manager ajoute aussi Drift Inspector dans les Blueprints. L’équipe peut distinguer une exception locale approuvée d’un écart accidentel par rapport au modèle de site. Le High Availability Readiness Score donne, de son côté, une lecture rapide des points uniques de défaillance côté ISP, alimentation et passerelle.

Ces fonctions ne remplacent pas une architecture résiliente. Elles rendent simplement plus difficile le fait de confondre les possibilités de failles entre elles.

Comment l’utiliser dans un cas réel

Scénario : huit sites, une équipe IT et trop de tickets

Imaginons une PME répartie sur huit sites. Chaque implantation possède plusieurs points d’accès, des VLAN utilisateurs et invités, des équipements de téléphonie ou de visioconférence, et une passerelle UniFi. L’équipe IT reçoit régulièrement des tickets de lenteur, mais les incidents sont souvent terminés avant qu’un technicien puisse les observer.

L’objectif n’est pas d’activer toutes les options le même jour. Il est de construire un petit runbook reproductible.

Étape 1 : créer une ligne de base avant la mise à jour

Choisissez un site représentatif et notez :

• la version UniFi OS et la version de l’application Network ;
• les modèles et versions de firmware des passerelles, switches et points d’accès ;
• les SSID, VLAN et usages sensibles ;
• les changements planifiés dans les prochaines 24 heures ;
• les indicateurs qui permettront de dire « le réseau va mieux ».

Faites une sauvegarde et planifiez l’opération dans une fenêtre où quelqu’un peut intervenir localement ou hors bande. Une fonction de rollback n’annule pas le besoin d’un accès de secours.

Étape 2 : utiliser Spotlight pour cadrer le symptôme

À l’ouverture d’un ticket, ne commencez plus par la vue globale. Filtrez d’abord les clients touchés, puis comparez leur point d’accès, leur VLAN et leur chemin vers la passerelle. Si un seul groupe est concerné, laissez les autres équipements hors champ.

Documentez la question initiale : « les clients du SSID invité sur le site B perdent-ils leur session ? » est beaucoup plus exploitable que « le Wi-Fi du site B est bizarre ».

Étape 3 : remonter les 24 dernières heures

Consultez Time Machine sur les radios et les ports associés. Cherchez une modification de canal, une série de reconnexions, un port qui flap, un changement de configuration ou une dégradation apparue juste avant les signalements.

Si le symptôme est intermittent, exportez dans le ticket l’heure approximative et les observations. L’historique n’a de valeur que si l’équipe peut le rapprocher de l’expérience utilisateur, d’un changement ou d’un événement externe.

Étape 4 : automatiser avec mesure, pas avec foi

Activez l’optimisation nocturne Channel AI sur un périmètre pilote et définissez une mesure simple : nombre de reconnexions, plaintes, débit médian ou temps de roaming selon le cas d’usage. Prévenez les équipes qu’un changement de canal peut provoquer une courte interruption.

Les retours associés aux notes de version montrent que certains administrateurs s’interrogent encore sur le comportement du mode automatique, notamment le changement effectif de canal et les environnements avec un seul point d’accès. Ce sont de bons rappels : une option visible dans l’interface doit être vérifiée dans le contexte réel avant d’être déployée partout.

Étape 5 : sécuriser les changements sensibles

Pour une modification de VLAN de management, de VPN ou de politique réseau :

1. capturez la configuration de départ et le chemin d’accès de secours ;
2. lancez la modification avec Test & Confirm lorsque le matériel et la version le permettent ;
3. vérifiez la connectivité des équipements de management, pas seulement celle d’un poste utilisateur ;
4. confirmez uniquement après le test ;
5. consignez le résultat et l’heure dans le journal de changement.

À l’échelle multi-sites, utilisez ensuite les Blueprints et Drift Inspector pour séparer les exceptions approuvées des écarts non expliqués. Une exception qui n’a pas de propriétaire finit presque toujours par devenir la nouvelle norme.

Étape 6 : transformer le score en test de continuité

Le score High Availability Readiness est un point de départ de discussion. Pour chaque site, demandez : que se passe-t-il si l’ISP tombe ? si l’alimentation du switch principal est coupée ? si la passerelle ne revient pas ?

Ajoutez au score une preuve : date du dernier test, durée de basculement, services réellement vérifiés et personne responsable. Un indicateur de préparation ne remplace pas un exercice.

Limites et points de vigilance

Tout n’est pas disponible de manière uniforme. Ubiquiti précise que Multicast Suppressor et Port Locking arrivent d’abord en Early Access dans sa présentation de Network 10.6 ; les notes de version indiquent en parallèle des prérequis de firmware — UAP 8.8 ou ultérieur pour Multicast Suppressor, firmware de switch 7.6 ou ultérieur pour le verrouillage de port. Vérifiez le canal de diffusion, la version de l’application et les modèles concernés avant d’inscrire une fonction dans un plan de production.

Time Machine apporte un historique utile, mais limité à une fenêtre de 24 heures dans les éléments documentés. Ce n’est pas un système de rétention longue ni une preuve forensique complète. Pour les incidents récurrents, exportez les faits utiles vers votre outil de suivi ou votre supervision.

SafeOps réduit le risque d’une mauvaise configuration dans l’environnement UniFi ; il ne répare pas un câble, un opérateur en amont, un firmware incompatible ou une dépendance externe. Gardez un accès de secours, une sauvegarde et un plan de retour arrière.

Enfin, les notes de version recommandent UniFi OS Server pour les déploiements auto-hébergés afin de bénéficier de l’expérience de plateforme et des intégrations les plus récentes. Cette recommandation mérite une vérification de compatibilité, de sauvegarde et d’exploitation avant toute migration improvisée.

Élargir : moins de dépannage héroïque, plus d’exploitation documentée

Une équipe réseau ne gagne pas seulement du temps quand elle trouve une panne plus vite. Elle gagne de la sérénité quand la panne est résolue en suivant un workflow précis.

Network 10.6 pousse UniFi dans cette direction : filtrer avant d’observer, consulter l’historique avant de modifier, tester avant de confirmer, comparer au modèle avant de déclarer une dérive. La technologie devient un partenaire d’exploitation, pas un substitut au raisonnement.

Cela change aussi la relation avec les utilisateurs. Au lieu de répondre « nous avons redémarré le point d’accès », l’équipe peut expliquer : « les reconnexions ont commencé après telle modification, elles touchent tel groupe, et nous suivons tel indicateur depuis le retour arrière ». La confiance naît rarement d’une interface spectaculaire. Elle naît d’une explication claire et précise qui donne du sens à l’action de l’équipe technique mais aussi au client qui conçoit l’action de l’équipe technique.

Conclusion

Le réseau n’était pas forcément invisible. Il était simplement trop large pour être interprété rapidement et bénéficiait de trop peu d’historique pour raconter ce qui venait de se passer.

UniFi Network 10.6 apporte les briques d’une méthode plus calme : une topologie focalisée, un historique court mais exploitable, des changements réversibles et une lecture des écarts entre sites. Le principal changement n’est pas que la console fasse davantage de choses ; c’est que l’équipe puisse prendre de meilleures décisions avec moins de suppositions.

Travaux pratiques — Sur un seul site, créez un mini-runbook en six lignes : symptôme, filtre Spotlight, historique Time Machine, changement récent, action SafeOps et preuve de retour à la normale. Testez-le sur le prochain incident Wi-Fi et mesurez le temps gagné avant d’activer davantage d’automatisation.

Sources consultées

• Ubiquiti — Introducing UniFi Network 10.6
• Ubiquiti Community — UniFi Network Application 10.6.97
• Ubiquiti — What’s New
• Dong Knows Tech — UniFi Network 10.6

• Rapport SMART  alerte au fur et à mesure du compte, mais notifie seulement si moins de 10 alertes.
• Rapport SMART plus « propres »
• Support pour Daylite 6
• Alerte quand une application précise est supprimée
• Support pour les chainages de sauvegardes dans Carbon Copy Cloner

Changement :

• Carbon Copy Cloner ne vous préviendra plus juste parce que la destination est manquante. Seulement quand il n’a pas pu finir une sauvegarde dans le temps imparti.

Réparations :

• Surveillance de la présence de la capacité du volume est à nouveau possible
• Certains rapports de status SMART n’avait pas de contenu, en dépit d’un status SMART normal.

Pour forcer le client de WM à établir un rapport maintenant :

sudo /Library/MonitoringClient/RunClient -F

Pour forcer le client de WM à vérifier s’il existe des mises à jour :

sudo /Library/MonitoringClient/RunUpdater -F

Pour désactiver la recherche automatique de mise à jour :

/usr/bin/defaults write /Library/MonitoringClient/ClientSettings Update_Enabled -bool false

Ôter le client WM d’un ordinateur :

/Library/MonitoringClient/Utilities/RemoveClient -F

Changer le groupe d’un client (vous changerez GROUPE_D’UN_CLIENT par le nom de l’un de vos groupes clients) :

/usr/bin/defaults write /Library/MonitoringClient/ClientSettings ClientGroup -string « GROUPE_D’UN_CLIENT »

Changer la durée de temps pour être prévenu de l’exécution de Time Machine (vous changerez 10 par n’importe quel nombre entre 1 et 99) :

defaults write /Library/MonitoringClient/PluginSupport/check_time_machine_settings Days_Until_Warning -int 10

Activer ou désactiver la surveillance de Time Machine (false : pas de surveillance, true : surveillance active) :

defaults write /Library/MonitoringClient/PluginSupport/check_time_machine_settings Warning_Enabled -bool false

Ajuster le seuil de la capacité du volume Root (par défaut : 90%) :

defaults write /Library/MonitoringClient/PluginSupport/check_root_capacity_settings Root_Warn_Level -int 90

Désactiver complètement un plugin :

defaults write /Library/MonitoringClient/ClientSettings PluginsDisabled -array-add « check_[service-to-ignore].plugin »

Trouver le nom du plugin dans /Library/MonitoringClient/Plugins pour désactiver time machine par exemple (c’est une requête qui revient assez souvent) :

defaults write /Library/MonitoringClient/ClientSettings PluginsDisabled -array-add « check_time_machine.plugin »

Dire au plugin Daylite ne pas surveiller un compte utilisateur précis (cette commande vous permettra d’arrêter de surveiller l’utilisateur « admin » pour le plugin Daylite) :

/usr/libexec/PlistBuddy -c « Set :Users_To_Monitor:admin bool false » /Library/MonitoringClient/PluginSupport/check_daylite_client_settings.plist

Activer les notifications de redémarrage :

defaults write /Library/MonitoringClient/PluginSupport/check_reboot_time_settings Warn_On_Reboot -bool true

A propos de l’affichage du panneau de Préférences système :

Toutes les commandes doivent être envoyées en tant que root, et ce faisant les fichiers deviendront illisibles par l’utilisateur logué.

Cela ne causera aucun problème concernant les rapports normaux, mais cela peut avoir un effet cosmétique peu appréciable lorsque vous voudriez voir le plugin dans les Préférences systèmes (pendant les tests de la ligne de commande, bien sûr).

La routine du plugin chaque heure remettra l’agent avec les permissions correctes, et convertira le fichier binaire en xml, ce qu’il préfèrera

Vous pouvez forcer le rapport et donc le rafraîchissement avec la commande :

sudo /Library/MonitoringClient/RunClient -F

Vous ouvrirez à nouveau les Préférences Systèmes pour vérifier les changements.

FileCloud chez NausicaMedia, c’est votre box sécurisée dans un cloud privé ! Offrez-vous la meilleure offre sur le marché. Une box survitaminée !

• Hébergé dans un cloud privé sécurisé en France
• Échange de fichiers sécurisé pour les entreprises
• Chiffrement 256-bit AES pour l’hébergement et pour la transmission
• Synchronisation entre tous les appareils, ordinateurs (PC, Mac, Linux) et iPhone, iPad
• Sauvegarde de dossiers depuis les postes utilisateurs
• Intégration avec les applications Microsoft Office
• Prévention en temps réel
• Aperçu des documents
• Intégration du répertoire utilisateur
• Versions et verrouillage des fichiers
• Antivirus
• WebDAV
• Multilangue
• Partage évolué (public, privé et temporaire).
• Contrôles du téléchargement de fichiers
• Validation en deux étapes
• Comptes clients illimités et gratuits…

Daylite hébergé dans un cloud privé, c’est disponible maintenant !

Avez-vous jamais rêvé de ne plus avoir aucun problème de réseau ? Cette offre est faite pour vous.

Pour 35 € par utilisateur par mois, offrez-vous un pack de services (sauvegarde, hébergement, sécurité, disponibilité), votre licence Daylite et toutes ses mises à jour à venir !

— Nous vous installons toutes les mises à jour de Daylite (mineures, majeures, plus jamais de frais de mise à jour).

— Toutes vos données sont stockées en France, à Paris dans un data center de notre partenaire Claranet (secure tier 3 data center).

— Vous avez une requête (nouvel utilisateur, etc.) : vous ouvrez un ticket et nous nous chargeons de tout.

— Taille de base de données illimitées.

— Vos données sont accessibles de partout à tout moment.

— Vous souhaitez l’intégration avec Carnet d’adresses, Calendrier ou MoneyWorks ou Billings Pro, nous vous installons tous les plug-ins.

— Toutes les communications sont chiffrées en TLS ou VPN.

— Vous désirez revenir à une ancienne sauvegarde, ouvrez un ticket sur notre site de maintenance et nous le ferons pour vous.

— Maintenance illimitée, mises à jour, sécurité, sauvegarde (quotidienne).

Bender est un petit utilitaire écrit par Forget Computers pour automatiser la sauvegarde de OS X Server. Il y a plusieurs façons de réaliser cette action : en utilisant Time Machine comme je l’avais montré dans cet article et maintenant avec Bender. Comme toujours avec l’action de sauvegarder, c’est l’action de restaurer qui importe !

Bender arrive sous la forme d’une archive PKG. Une fois installé, Bender créera un dossier à la racine de votre disque et sauvegardera à 22h à l’intérieur de ce dossier, les fichiers suivants :

• Un répertoire comportant la date et l’heure auxquelles la sauvegarde s’est faite.
• Une archive Open Directory si le serveur est configuré en maître Open Directory
• Un fichier de sauvegarde avec les services du serveur afin de permettre la restauration des réglages ou leur importation.
• La base de données postgres utilisée par les services Profile Manager et Wiki.

Bender fonctionne de OS X Server 10.6 à Yosemite.

Pour restaurer, votre OS X Server en cas de soucis, voici la marche à suivre :

Pour Open Directory, il suffit d’utiliser Server admin (10.7 et avant), d’aller dans la partie Open Directory, de cliquer sur l’onglet Archive, de choisir l’archive que vous voulez utiliser et de cliquer restaurer. En revanche il vous faudra connaître le mot de passe utilisé pour chiffrer l’archive, pour cela, il vous faudra aller dans le Terminal :

system_profiler SPHardwareDataType | awk ‘/Hardware UUID/{print $3}’

Il n’existe aucune option de restauration dans Server.app en 10.8 et après, il vous faut utiliser la ligne de commande :

sudo slapconfig -restoredb /path/to/your/archive.sparseimage

Pour restaurer tous les réglages OS X Server :

sudo serveradmin settings < /path/to/your-sa_backup-allservices.backup

pour restaurer un réglage spécifique :

sudo serveradmin settings < /path/to/your-sa_backup-servicename.backup

Le Terminal accepte aussi le glisser-déposer, vous pouvez donc prendre un plist dans le dossier de sauvegarde afin de restaurer son réglage.

Pour aider à réaliser cela, 318 a proposé le package sabackup. Son projet était d’utiliser les commandes internes à Mac OS X afin de réaliser les sauvegardes essentielles et d’exporter les configurations de services d’une façon que vous puissiez les importer dans serveradmin après avoir procéder aux réparations et avoir votre serveur qui fonctionne à nouveau. Ce package m’a sauvé maintes fois, mais il m’a aussi permis de trouver quels changements avaient été réalisés (généralement après avoir réalisé que ce changement avait cassé quelque chose).

Avec Lion et Mountain Lion, Apple a décidé de résoudre le problème de proprement sauvegarder les services et les données, et Time Machine inclut un mécanisme pour sauvegarder OS X Server. À l’intérieur du bundle Server.app, dans le dossier ServerRoot, vous trouverez maintenant le dossier server_backup avec les commandes spécifiques. Il y a là un ensemble de scripts de sauvegarde (/Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup) qui permettent de sauvegarder et de restaurer les services. Il y a aussi une collection de scripts de style System V dans le dossier /Applications/Server.app/Contents/ServerRoot/etc/server_backup qui contient les paramètres que ServerBackup utilisera pour sauvegarder les services. Comme avec toutes choses chez Apple, il y a aussi les plists XML. Certains services utilisent leur propres scripts : Open Directory, PostgreSQL, Partage de fichiers (appelé « sharePoints » dans ce contexte, Web, et Message. Le script OD produit une archive dans  /var/backups, le script PostgreSQL produit une exportation de toute votre base de données, et le serveur Message vous donnera une sauvegarde de la base de données Jabber. La sauvegarde de la configuration Web, mais et c’est important de le noter, il ne sauvegarde pas les données. Enfin, il y a le script de ServerSettings qui produit une exportation serveradmin de toutes les configurations pour tous les services. Chaque chose étant enregistrée dans /var/log/server_backup.

C’est à peu près ce que sabackup réalisait, Apple a amélioré le processus, l’a rendu plus modulaire, plus robuste et 100% Apple-façon-de-penser. Avec ceci dans l’esprit, nous avons décidé d’arrêter le développement de sabackup. En se reposant sur les outils Apple, cela permet que tout nouveaux services soient automatiquement inclus à l’avenir. ServerBackup sera mis à jour avec Server.app.

ServerBackup a aussi ses bizarreries. Il est profondément lié à TimeMachine, ce qui veut dire que TimeMachine doit être activé. Ça ne signifie pas que TimeMachine doive vous servir pour autre chose. Si vous excluez tous les dossier visible du Finder, vous aurez toujours un dossier .ServerBackup à la racine de votre volume de sauvegarde, avec toutes les sauvegardes du serveur. Vous aurez aussi /private incluant var (où sont les sauvegardes et les logs), et etc, où beaucoup de fichiers de configuration demeurent. Vous pouvez dédier un petit disque à TimeMachine, laissez TimeMachine s’occuper de la sauvegarde des configurations et des données des services de Server.app, et prenez soin que ce disque fasse partie de votre solution de sauvegarde numéro un. Solution, que vous avez bien sûr ?

Cet article a paru sur Tech Journal de 318, le 19 novembre 2012.1.

http://store.nausicamedia.com

Certains produits ne sont plus là (CalDigit par exemple) et nous ne vendons plus ces produits donc inutile de nous les demander. Seuls les produits en ligne sont en vente à NausicaMedia.

Les fonctionnalités sont nombreuses :

PresSTORE Backup2Go:
– Amélioration du fonctionnement général: support de Bonjour facilitant la sélection des serveurs Backup2Go
– Ajout d’options de restauration: restauration complète des postes de travail en cas de sinistre. Téléchargement des fichiers et dossiers sauvegardés depuis toutes machines distantes.
– Nouvelles options de sauvegarde: les sauvegardes des postes de travail peuvent être limitées à certaines plages horaires et en fonction de la source d’alimentation électrique (batterie ou secteur).
– Enregistrement du référentiel sur bandes: PresSTORE Backup permet la sauvegarde des référentiels Backup2Go sur bandes. Cette procédure «Disk2Disk2Tape» place la sécurité de Backup2Go à un nouveau niveau.
– Windows comme serveur Backup2Go: Backup2Go s’installe maintenant sur Windows 2008R2 et Windows 7 pour être utilisé comme plateforme serveur de sauvegarde.

PresSTORE Archive:
– Sélection d’archive: La sélection apporte la possibilité de collecter de multiples dossiers et fichiers dans un seul processus d’archive.

Interface graphique:
– Nouvelles vues récapitulatives: les données des licences utilisées, celles des opérations d’archivage et des opérations de synchronisation sont maintenant présentées par des vues d’ensemble.

Support de solutions tiers
– PresSTORE étend le support des solutions tiers avec le support d’HELIOS UB2, la dernière version des solutions de publication de données d’HELIOS Software et avec le support de JAMF Casper Suite, le produit d’administration des plateformes Mac et IOS.

(source PresSTORE France)

#!/bin/bash
#Converts a standalone disk to a RAID 1 and automates adding the second member.
clear
echo -n « Enter the name of the first volume to be placed in the mirror:  »
read disk_1
export disk_1nv=`echo $disk_1 | sed ‘s:/Volumes/::g’`
echo  »
creating the $disk_1 mirror »
sleep 2
export disk_1slice=`diskutil list « $disk_1 » | grep -m 1 « $disk_1nv » | grep -o « disk… »`
diskutil appleRAID enable mirror $disk_1slice
echo -n « Enter the name of the second volume to be placed in the mirror:  »
read disk_2
export disk_2nv=`echo $disk_2 | sed ‘s:/Volumes/::g’`
export disk_2root=`diskutil list « $disk_2 » | grep -m 1 « $disk_2nv » | grep -o « disk. »`
export raid_uuid=`diskutil info $disk_1slice | grep « Parent RAID Set UUID » | sed -e ‘s_Parent RAID Set UUID:__g;s_^[ t]*__’`
diskutil AppleRAID add member $disk_2root $raid_uuid

 

 

Cette article a paru sur Tech Journal de 318, le 12 septembre 2011.