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

Qui aime gérer un changement de réseau à distance sans aucune angoisse ? La gestion d’un réseau sensible et complexe qui se situe à 500 kilomètres oblige à bien réfléchir et à soupeser le pour et le contre. Avec UniFi Network 10.5, Ubiquiti s’attaque enfin à une douleur très concrète : le moment où une équipe modifie un réseau et sait qu’une petite erreur peut se transformer en longue journée.

Contexte : l’origine du vrai problème

Le problème n’est pas seulement la complexité technique. Il vient aussi du fait que beaucoup d’équipes administrent des environnements de plus en plus distribués avec des marges de manœuvre de plus en plus faibles.

Une PME multi‑sites, une école, un commerce avec plusieurs points de vente : tout le monde veut de la visibilité, de la rapidité et moins d’interruptions. Mais dans beaucoup de cas, les changements réseau restent émotionnellement coûteux. Pourquoi ? Parce qu’un VLAN mal appliqué, un mauvais paramètre sur un switch ou une modification poussée trop vite peut couper l’accès précisément à l’outil dont vous avez besoin pour corriger le problème.

On présente souvent le réseau comme une question d’architecture. C’est vrai. Mais c’est aussi une question de sérénité opérationnelle. Et cette dimension est trop souvent sous-estimée.

Ce que Ubiquiti change concrètement

UniFi Network 10.5 introduit plusieurs briques qui vont dans le bon sens, notamment :

• Test & Confirm, qui évite de considérer un changement comme définitif tant que les équipements clés ne confirment pas le bon retour de connectivité ;
• un mécanisme de rollback automatique pour revenir à l’état précédent si la modification casse l’accès ;
• des améliorations de stabilité et de comportement réseau comme Link Debounce et Auto STP Edge ;
• une meilleure visibilité, dans la continuité des évolutions récentes d’UniFi sur la topologie, la chronologie d’activité et la visibilité d’infrastructure.

Ce que cela change est simple à formuler : l’interface ne sert plus seulement à configurer, elle commence à mieux protéger l’administrateur contre certaines erreurs de déploiement.

Utilisation dans la vie réelle

Imaginons un réseau de huit sites avec une petite équipe IT centrale. Chaque site dépend d’un accès distant, d’un ou deux switches, de bornes Wi‑Fi et d’une passerelle. Jusqu’ici, chaque changement un peu sensible — segmentation, politique Wi‑Fi, modification d’uplink, nettoyage d’un port profile — crée la même tension : combien de temps d’interruption en cas d’erreur ?

Avec UniFi 10.5, une méthode plus saine devient possible :

1. identifier les changements réellement risqués et les faire passer en priorité par un scénario Test & Confirm ;
2. documenter quelles confirmations doivent être observées avant de considérer le changement comme validé ;
3. profiter des vues de topologie et de visibilité d’infrastructure pour vérifier les dépendances avant la modification ;
4. prévoir un mini runbook de retour arrière, même si le rollback automatique existe ;
5. utiliser un site pilote ou une plage horaire restreinte pour les premiers déploiements sensibles.

L’intérêt n’est pas de “faire plus de changements”. L’intérêt est de faire les changements importants avec moins de stress, plus de méthode.

Limites et points de vigilance

Attention, un rollback n’est pas une permission de travailler à la légère.

D’abord, il faut comprendre ce que le mécanisme couvre réellement dans votre contexte. Tous les incidents ne se ressemblent pas.

Ensuite, la visibilité n’est utile que si l’équipe sait la lire. Une topologie plus riche, un historique plus détaillé ou des règles plus intelligentes ne remplacent pas la discipline de documentation si souvent traitée par le mépris.

Enfin, dans les environnements multi‑sites, il reste indispensable de distinguer ce qui relève d’une amélioration de confort et ce qui relève d’un vrai filet de sécurité. Les deux sont utiles. Mais les confondre expose à de mauvaises décisions.

Élargir : ce que cela change dans l’organisation

Le sujet est plus profond qu’une version logicielle.

Quand un outil réseau commence à intégrer des mécanismes de confirmation, de retour arrière et de meilleure lisibilité, il pousse les équipes à sortir d’une culture du « je connais mon infra par cœur » pour aller vers une culture de procédures partagées.

Une infrastructure robuste n’est pas seulement une infrastructure qui tient. C’est une infrastructure que plusieurs personnes peuvent comprendre, faire évoluer et dépanner sans dépendre d’un seul cerveau disponible au bon moment.

Conclusion

Le problème de départ n’est pas abstrait : chaque changement réseau à distance porte une part de risque, de stress et parfois d’improvisation. Avec UniFi 10.5, Ubiquiti apporte une réponse très concrète en sécurisant davantage la validation des changements et le retour arrière.

Le vrai bénéfice n’est pas seulement technique. C’est la possibilité de transformer une culture de maintenance nerveuse en une pratique un peu plus calme, plus documentée et plus transmissible. Loin d’être un petit gain, donc.

Travaux pratiques

Choisissez un changement réseau modérément risqué sur un site pilote — par exemple une modification de profil de port ou d’uplink — et testez-le avec un scénario documenté autour de Test & Confirm. Si votre procédure reste floue malgré l’outil, vous avez trouvé le vrai chantier à ouvrir.

• 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.

• Amélioration conséquente de la détection de défaillances de disques avec Smart Utility. Les disques connaissant des erreurs dans les dernières 250 heures émettront un rapport.
• Intégration avec FileWave (excellente nouvelle notamment pour la gestion cross-plateforme).

Changements :

• Amélioration de la détection des connexions réseaux actives, quand il y en a plusieurs de configurées.
• Alerte si le nom de l’ordinateur est changé par un espace.
• Rapport SMART omis sur le VM Macs.
• Amélioration du support de Daylite.

Bogues :

• Meilleur support pour les disques qui prennent trop de temps à envoyer leur rapport FileVault
• Meilleur rapport du statut UPS quand SPPowerDataType contient des caractères en langues étrangères.

Pour tout renseignements concernant Watchman Monitoring, n’hésitez pas à nous contacter.

Watchman monitoring marque le retour du monitoring simple, efficace, puissant et convivial. Depuis la fin de Lithium, le Mac se sentait un peu délaissé. Ce n’est pas qu’il n’existe pas de solutions de monitoring fonctionnant sur Mac c’est qu’aucune n’était aussi bien Mac-oriented.

Watchman Monitoring vous permet de surveiller jusqu’à 25 clients pour un coût limité (à peu près 50 euros par mois ou 570 euros par an). Il existe ensuite une option aux alentours de 200 euros par mois qui permet de surveiller jusqu’à 1500 clients.

Watchman Monitoring vous permet de surveiller à distance vos clients et serveurs, l’état de leurs disques durs, l’espace libre encore disponible, l’état de santé de la RAM, l’état de santé de vos RAID, la sauvegarde TimeMachine et même la date de fin de votre AppleCare. Watchman Monitoring surveille aussi des applications comme Daylite et LightSpeed ! Sans compter ce que vous pouvez décider de surveiller plus précisément.

La mise en place prend une minute, aucune maintenance n’est à faire, le coût vous paraitra modéré lorsque Watchman Monitoring vous aura sauvé la vie.

Cerise sur le gâteau, après avoir parlé avec Allen, le directeur de Watchman Monitoring, NausicaMedia devient revendeur Watchman Monitoring et nous vous offrirons une application en français très vite.

En attendant, cliquez sur le lien si vous voulez essayer Watchman Monitoring.

Premièrement faites un petit script :

#!/bin/bash
# Change an account's password

ACCOUNT="ladmin"
PASSWORD="MyNewP@55w0rd"
/usr/bin/dscl . passwd /Users/$ACCOUNT $PASSWORD

if [ $? = 0 ] ; then
echo "Password reset."
else
echo "Password not reset."
fi

Dans ARD, cliquez sur Unix (qui ouvre la fenêtre Envoyer une commande Unix et que vous trouvez sous ce nom dans le menu Gestion) et collez le script dans le champ texte. Choisissez d’exécuter la commande selon utilisateur et spécifiez Root.

Depuis le menu déroulant modèle dans le coin de la fenêtre en haut à droite, choisissez enregistrer comme modèle… inscrivez un nom évocateur et sauvegardez.

Pour utiliser et réutiliser ce modèle, sélectionnez les ordinateurs avec les mots de passe que vous voulez changer et choisissez Envoyer une commande Unix depuis le menu Gestion. Choisissez votre modèle dans le menu déroulant, ajustez le nom de l’utilisateur et le mot de passe dans le script et cliquez sur envoyer.

ARD peut changer des douzaines et même des centaines de mots de passe en quelques secondes sans avoir à connaître l’original.

Cet article a paru sur Tech Journal de 318, le 18 février 2013.

defaults write com.apple.dock autohide -bool false; killall Dock

En écrivant une clé pour le masquage qui est négative (false) dans com.apple.dock pour l’utilisateur courant, je n’ai plus à me préoccuper d’un Dock qui se cache. Je dois « tuer » (kill) le Dock.

Une fois que j’ai fini de travailler avec ce système, je peux faire réapparaître le Dock à nouveau :

defaults write com.apple.dock autohide -bool true; killall Dock

Ou bien, à la place je peux utiliser Command-Option-d quand je me connecte à un système avec Remote Desktop et recommencer la même commande quand je me déconnecte.

Cette article a paru sur Krypted de 318, le 30 août 2012.

Lithium est le meilleur système de monitoring (surveillance) de réseau sous Mac. Le logiciel incontournable pour tout administrateur système et pour tous ceux qui ont à assurer la maintenance d’un parc de Mac (bien que Lithium ne soit pas que pour Mac. Il existe maintenant une version virtuelle de Lithium core qui peut être installée sur Linux, Windows et sur un iPad ou un iPhone).

Lithium est maintenant vendu suivant trois modèles : Bronze, jusqu’à 20 utilisateurs. Silver : jusqu’à 100 utilisateurs et Gold en illimité. Il s’agit d’une simplification de la gamme, d’autant que toutes les souscriptions incorporent un support à distance. James Wilson se fera un plaisir de vous aider et vous ne rencontrerez personne de plus sympathique et compétent dans tout le Pacifique en général et en Australie en particulier.

Comme souvent les prix sont inférieurs sur le site de NausicaMedia que sur le site du constructeur. Dont acte !

CalDigit connaît de belles baisses de prix et je vous invite à passer en revue les modèles pour découvrir ses remises qui n’ont rien d’exceptionnelles, et qui sont même permanentes.

Lithium

CalDigit

]]> https://nausicamedia.fr/blog/les-mises-a-jour-du-store/feed/ 0 1417 https://nausicamedia.fr/blog/migration-apple-remote-desktop/ https://nausicamedia.fr/blog/migration-apple-remote-desktop/#respond Tue, 05 Apr 2011 16:53:40 +0000 http://www.nausicamedia.fr/blog/?p=1318 Lorsque vous commencez à faire de la migration de données, il est toujours important d’obtenir une bonne compréhension de quelle donnée vous avez besoin de transférer, et dans quel but vous faites cette migration : des éléments peuvent être plus importants  que d’autres pour vous. Dans le cas de Apple Remote Desktop (ARD), il y a différents endroits de stockage de ces données, il faut en être conscient :

/Library/Preferences/com.apple.RemoteDesktop.plist

Ce fichier contient toutes les préférences qui s’appliquent à tout le système, premièrement les informations de sérialisation, qui est système spécifique (vous devrez donc entrer le numéro de série sur le nouveau système).

/var/db/RemoteManagement

Cette base de données et son jeu de caches contient la base de données des client Remote Desktop, utilisée pour le reporting du client.

~/Library/Application Support/RemoteDesktop

Ce dossier est utilisé pour stocker les préselections de commandes (incluant les modèles de commandes de Envoyer une commande Unix), votre historique des tâches, et les actions et réglages du manager de tâches.

~/Library/Preferences/com.apple.RemoteDesktop.plist

Ce fichier contient la mémoire de votre expérience avec ARD, incluant la complète base de données de l’ordinateur, les listes d’ordinateurs, les scanners et tout aussi important les références des accès à tous les ordinateurs de la base de données.

Une fois que vous avez une compréhension des données et de leur lieu de stockage par ARD, il devient assez trivial de transférer les données de la base de données. Partant du principe dans l’exemple qui suit que vous désirez migrer votre base de données d’ARD depuis un ordinateur local vers un nouvel ordinateur connecté en mode cible avec Firewire et monté comme /Volumes/NewMac. Dans la plupart des cas, tout ce que vous avez à copier est le fichier de préférences de l’utilisateur principal situé à ~/Library/Preferences/com.apple.RemoteDesktop.plist :

cd /Volumes/NewMac/Users/username

cp -p ~/Library/Preferences/com.apple.RemoteDesktop.plist Library/Preferences/com.apple.RemoteDesktop.plist

Si vous avez des modèles de commandes stockés, ou que vous désirez préserver votre historique des tâches, copiez aussi le dossier depuis Application Support :

cp -pR ~/Library/Application Support/RemoteDesktop/  Library/Application Support/Remote Desktop/

Si votre installation d’ARD agit comme serveur de tâches et reçoit des rapports, vous voudrez aussi les copier. Parce que cette base de données appartient à root, vous aurez besoin d’utiliser sudo pour le copier :

sudo cp -pR /var/db/RemoteManagement/ /Volumes/NewMac/var/db/RemoteManagement/

Ça y est ! Une dernière chose, ce sera une bonne idée de redémarrer pour faire bonne mesure, mais un redémarrage de de l’application ARD pourra faire l’affaire et vous vous retrouverez avec votre nouvelle base de données.

Cet article a paru le 13 janvier 2011 sur le TechJournal de l’entreprise 318