Un truc étrange s’est produit hier alors que je copiais des données depuis mon Mac vers un disque externe : la fenêtre de progression de copie a tout simplement disparu… alors que la copie semblait pourtant toujours en cours, et qu’elle ne pouvait pas s’être achevée d’un coup. Pas de message d’erreur non plus… Et rien dans le menu Fenêtres, là où normalement une fenêtre de copie s’affiche tout en bas.
Mais alors que je lançais une copie de fichiers vers un autre disque, la fenêtre de copie est revenue, affichant toujours fièrement sa progression vers le premier disque ! Diantre, s’agirait-il d’un… bug ? Pas vraiment, mais d’un nouveau comportement de la fenêtre de progression de copie depuis macOS Monterey. Explications.
Avant Monterey, quand vous copiez un fichier, il n’était pas possible de masquer la progression de la copie en cours. La fenêtre était là, même si vous décidiez de masquer ou fermer toutes les fenêtres via un Option + clic sur le bouton de fermeture de fenêtre. D’ailleurs, la fenêtre de copie n’affichait pas de bouton de fermeture (le fameux bouton rouge).
Copie en cours… et pas de bouton rouge en haut à gauche. La fenêtre reste toujours présente.
Depuis macOS Monterey, le comportement a changé : désormais, si vous fermez ou masquez toutes les fenêtres du Finder, la fenêtre de copie se ferme, même si la copie continue en arrière-plan.
Quoi, un bouton rouge ? Mais pourquoi donc ? Ah oui, on peut fermer cette fenêtre.
Ce qui est curieux, c’est que si vous fermez la fenêtre, la copie continue donc. Pas d’alerte, rien. La seule façon de la faire revenir est de passer par le menu Fenêtre, où vous pouvez choisir d’afficher la progression.
Afficher la fenêtre de progression fait revenir la progression de la copie…
… et sa fenêtre apparaît alors tout en bas du menu Fenêtre.
J’avoue que je suis un peu perplexe devant ce changement, qui génère à mon avis plus de confusion qu’autre chose, et qui masque complètement qu’une opération qui peut être critique est en cours. Imaginez, vous êtes à la fin d’une copie, vous souhaitez débrancher le disque, et, ah non, y’a une tâche qui bloque. Hmmmmmm… mais je ne vois rien, eh ??? Et l’on vous dit que le volume est en service quand vous voulez le démonter, sans vous indiquer quel type de tâche est en cours… Donc, méfiez-vous si vous avez tendance comme moi à masquer un peu trop vite vos fenêtres.
Apple l’avait annoncé depuis quelques temps déjà : le langage de programmation Python 2, intégré à macOS, devait être retiré définitivement et non remplacé. Et que croyez-vous qu’il arriva : c’est le cas depuis macOS Monterey 12.3. Les conséquences sont parfois importantes : en effet, certains packages d’installation utilisent parfois des scripts en Python.
De même, de nombreux scripts qui circulent sur le net utilisent des commandes en Python. Et pendant très longtemps, même Apple recommandait de passer par une commande Python pour récupérer le nom de l’utilisateur courant. J’avais d’ailleurs indiqué une commande alternative lors d’un article précédent.
Les administrateurs de parc Mac seront donc avisés de vérifier que leurs scripts n’utilisent désormais pas de Python, ou en tout cas, de savoir quelles fonctions y font appel. Pour cela, il existe quelques outils qui peuvent faciliter la donne.
Vérifier la présence de Python dans vos scripts Jamf
Mon indispensable Laurent Pertois a commis un script capable de vérifier la présence de la commande désormais honnie dans vos scripts. Le script se récupère sur son Github, et vous devrez fournir quelques informations en début de script pour le faire fonctionner correctement (URL du serveur, identifiant et mot de passe). Comme il repose sur l’API Jamf, il sera conseillé de créer un compte réservé à l’utilisation de l’API avec des droits restreints.
Vérifier la présence de Python dans vos packages
L’excellent Armin Brezel de l’excellent site Scripting OS X a lui aussi créé un script fort efficace pour traiter le problème des packages. Indiquez simplement un ou plusieurs packages, ou encore un dossier suivi d’un joker (ex : mondossierdepackages/*) comme argument(s) du script, et il se chargera de vérifier lesquels font référence à Python (et donc à tester en priorité, ou à remplacer si possible).
Installer Python 3
Une dernière alternative reste pour les administrateurs d’installer eux-même Python 3. Une version maintenue par la communauté MacAdmins se trouve ici. Il sera cependant indispensable de faire en sorte que vos scripts soient modifiés pour en tenir compte (ou de faire en sorte de pointer vers la nouvelle version de Python quand on appelle /usr/bin/python). Et évidemment, à vous d’en assurer la maintenance.
J’en avais un peu parlé dans mon article sur la WWDC 2021 : il est désormais possible avec macOS Monterey de réintégrer un Mac dans une solution Apple Business Manager ou Apple School Manager, même si ce dernier n’a pas été acheté dans le circuit Apple classique (à savoir : un revendeur Apple agréé entreprise, ou un Apple Store). C’était pourtant possible depuis quelques temps pour les appareils iOS et iPadOS, à l’aide de l’app Apple Configurator pour macOS. Si vous ne connaissez rien à Apple Business Manager, je vous invite à voir ma conférence sur le sujet.
Mais alors, comment ça se passe ? Et bien, il faudra passer par l’app Configurator… pour iPhone ou iPad. Celle-ci est encore en bêta (disponible entre autres sur AppleSeed for IT), mais elle ne devrait plus trop tarder à être disponible pour tous (croisons les doigts). Il y a cependant quelques contraintes importantes pour pouvoir réintégrer un Mac dans Apple Business Manager :
– le Mac doit être équipé d’un processeur Apple Silicon, ou d’un contrôleur de sécurité T2 (liste ici) ;
– Le Mac doit être intégralement effacé au préalable (par exemple en utilisant la fameuse commande startosinstall avec l’option eraseinstall).
– Un administrateur du Mac peut retirer le poste d’Apple Business Manager durant 30 jours après l’enrôlement, simplement en le désenrôlant. Après 30 jours, l’intégration dans Apple Business Manager devient définitive.
J’ai testé avec un Mac que j’avais révoqué il y a quelques temps d’Apple Business Manager, et que je souhaitais réintégrer.
Une fois l’app Configurator installée sur l’iPhone ou l’iPad, il faut la lancer et la configurer avec un compte de votre instance Apple Business Manager. Le compte utilisé doit disposer des droits de Gestionnaire d’inscription des appareils.
Une fois configurée, l’app propose de chercher un Mac pour l’enrôler. Approchez donc votre iPhone de votre Mac (ce dernier doit être sur l’écran de choix du pays), et si tout va bien, l’écran va alors afficher le QR Code magique d’Apple. Il faudra alors essayer de mettre le motif dans le cercle. Attention, c’est plus facile à dire qu’à faire : si l’écran a un peu trop de reflet, ou pas assez de lumière, ça peut être délicat. J’ai remarqué que ça fonctionnait mieux avec la luminosité poussée à fond.
Si vous n’arrivez pas à faire reconnaître le motif pour appairer le Mac à l’iPhone, pas d’inquiétude : vous pouvez aussi utiliser un code unique à afficher sur le Mac et à recopier sur l’iPhone.
L’iPhone va alors transférer ses réglages de réseau au Mac (soit en utilisant le Wi-Fi existant, soit en transférant un profil créé au préalable et contenant la configuration Wi-Fi souhaitée).
Si tout se passe bien, le Mac est alors ajouté (vous pouvez voir le statut de l’ajout en cliquant sur l’icône de liste en bas à droite).
Et voilà, le Mac est correctement assigné à votre instance Apple Business Manager !
Cependant, il ne pourra pas être associé automatiquement à votre MDM : il sera listé dans un MDM spécifique Apple Configurator. Vous devrez donc attribuer votre MDM habituel à votre appareil dans Apple Business Manager avant de le redémarrer.
Notez qu’on rencontre parfois des bugs toujours rigolos liés à Apple Business Manager, ainsi le MacBook Pro ajoutait apparaissait comme… un iMac. Ça arrive de temps en temps… mais ça n’a pas impact à l’utilisation.
Même si Apple a mis pas mal de limitations sur cette fonctionnalité, cela reste une nouveauté fort utile dans certains cas, qui devrait faciliter le redéploiement des anciens Mac dans les parcs informatiques des entreprises ou des écoles.
NB : MacG a publié quasiment le même article quelques heures avant moi… Promis, j’ai pas copié ! :D
Une petite nouveauté qui n’a pas été très mise en avance par Apple : désormais, vous pouvez gérer les instantanés locaux (snapshots) APFS utilisés par Time Machine pour la sauvegarde à l’aide d’Utilitaire de disque. Les instantanés, ce sont ces sauvegardes Time Machine qui ne sont pas exécutées directement sur un disque externe, mais qui sont stockés sur le disque interne de votre Mac, par exemple lorsqu’il est déconnecté du disque de sauvegarde quand vous êtes en vadrouille avec votre MacBook Pro flambant neuf. Jusqu’à maintenant, Apple ne permettait pas un accès simple à ces disques, à l’exception de l’utilisation de la commande tmutil.
Désormais, avec Monterey, c’est beaucoup plus simple : lancez Utilitaire de disque et cliquez sur le menu Présentation > Afficher les instantanés APFS.
Hop ! Instantanément (huh huh), une nouvelle zone apparaît dans la fenêtre, vous permettant de visualiser ces fameux instantanés. Vous pouvez même double-cliquer sur un instantané dans la liste pour le monter sur le Bureau, comme une vulgaire disquette (oui, on est en 2021, et je parle de disquettes, jugez-moi). Vous pouvez alors naviguer dans la sauvegarde pour essayer de retrouver un fichier (est-ce vraiment plus intéressant que de passer par la jolie interface de Time Machine, je vous laisse juge).
Surtout, vous pouvez décider de supprimer des instantanés s’ils prennent trop de place (la colonne Taille privée vous indique l’occupation de l’instantané sur le disque). Il suffit effectivement de sélectionner un instantané puis de cliquer sur le bouton Moins pour le dégager sans sommation (enfin presque, vous devrez quand même valider la suppression de l’instantané).
Bon, en pratique, à moins de travailler pour la NSA, pas vraiment besoin de s’occuper de nettoyer les sauvegardes Time Machine à la main, vu qu’il y a un processus de macOS qui s’occupe de faire le ménage quand c’est nécessaire… Mais c’est toujours sympa de voir qu’Apple s’occupe de donner un peu plus de visibilité à certaines fonctions.
Depuis quelques temps (en fait depuis mon passage sur Big Sur ou sur le M1), je rencontre un bug curieux avec l’app Notes sur mon Mac : son utilisation du processeur est juste complètement démesurée (conjointement à une hausse également de consommation CPU) pour WindowServer :
Cela se traduit du coup par une baisse significative de l’autonomie et une chauffe excessive de la machine (ce qui est quand même fâcheux sur les Mac M1).
Après recherche, il s’avère que je ne suis pas le seul (comme souvent dans ce cas-là), et la solution semble relativement simple : il faut basculer du mode de présentation en liste vers une présentation en mode Galerie. Vous pouvez pour cela soit cliquer sur l’icône ad hoc, soit cliquer sur le menu Présentation > Par galerie.
Choisis ton arme, camarade !
Bon, le souci, c’est que c’est évidemment pas une vraie solution, le mode Galerie étant moins pratique que le mode Liste à mon goût, et du coup j’ai remonté le bug à Apple (FB9122849). N’hésitez pas à le remonter également afin de le faire corriger.
(Oui, je sais, mes titres sont parfois un peu longs.)
Une petite astuce qui m’a été fort utile il y a quelques jours avec Jamf Pro : un de mes clients avait besoin de créer plusieurs groupes d’une cinquantaine de Mac chacun pour procéder à un déploiement progressif sur l’ensemble du parc (plusieurs centaines de machines).
La première idée était de créer des groupes statiques comportant chacun une cinquantaine de machines. Et ça… c’est long à créer, car il faut créer le groupe, cocher 50 postes, enregistrer le groupe, créer un autre groupe, cocher les 50 postes suivants, enregistrer, etc… Fastidieux.
Mais en y réfléchissant un peu, il y avait une approche plus pertinente. À chaque fois qu’un poste est enrôlé, il lui est associé un identifiant unique : le JSS Computer ID. Et cet identifiant augmente de 1 pour chaque nouvel appareil ajouté. Le premier appareil a donc l’identifiant 1, le deuxième 2, etc. C’est bien fichu.
Et d’un coup, la solution est arrivée : il suffit de créer le nombre de groupes désirés (ici 8) sous forme de groupe intelligent, et spécifier comme critère pour le premier groupe :
JSS Computer ID est plus grand que 0
ET
JSS Computer ID est plus petit que 50
Finalement, ce JSS Computer ID sert à quelque chose…
Et pour créer les groupes suivants ? Vous avez juste besoin de dupliquer le groupe et changer les valeurs (49 -> 100, 99 -> 150, etc).
Voilà. Enregistrez votre groupe, et regardez le contenu : oooooh, des groupes des 50 postes ! Ou presque : en effet, chaque poste supprimé ne se voit plus réattribué un ancien JSS Computer ID. Donc peut-être que vous aurez un premier groupe comportant moins de machines. Mais l’idée étant surtout de dégrossir pour éviter d’avoir une charge trop importante et pouvoir déployer « au fil de l’eau », cela reste une solution très satisfaisante.
Allez, ça faisait un longtemps, un article bien technique, à l’attention d’un public averti. Je vais d’ailleurs cette année essayer de pousser un peu plus ces articles techniques destinés aux administrateurs systèmes et gestionnaires de MDM Apple.
Dans le cadre d’une intégration Jamf Pro chez un des mes clients, j’ai du gérer la problématique suivante :
Comment contrôler à quel moment un profil de configuration doit être installé sur un Mac ?
En effet, une fois un Mac enrôlé dans le MDM (que ça soit automatiquement au démarrage via le programme Apple Business Manager ou Apple School Manager, ou manuellement), à partir du moment où l’on souhaite par exemple déployer un profil Wi-Fi, il est déployé automatiquement via la magie du push. Ce qui pose le risque de casser le déploiement si le profil Wi-Fi impose une bascule automatique.
Exemple : vous êtes employé de Gete.Net Consulting, et vous recevez votre nouveau Mac rutilant. Votre nouveau boss, qui a tout prévu, vous a fait livrer votre Mac, et vous devez l’enrôler dans votre solution de gestion. Ce Mac a été prévu pour se connecter automatiquement au réseau GeteOuEssayéMaisRienNWiFi, dont le mot de passe particulièrement complexe est intégré au profil. Ce qui peut présenter l’avantage d’éviter de devoir transmettre le mot de passe oralement ou par écrit, et de lui donner une complexité bien plus importante. Le profil pourrait aussi permettre de pousser une authentification au Wi-Fi via certificat, ce qui est bien plus sécurisé.
Cependant, si le réseau est à portée d’antenne, le Mac aura tendance durant l’enrôlement à basculer sur ce réseau Wi-Fi sécurisé dès qu’il sera disponible, sans s’occuper de savoir si le reste de l’enrôlement (installation de logiciels par ex) est terminé. Ce qui peut être gênant, vous en conviendrez.
Pour éviter cette rupture dans le déploiement, on peut avoir deux approches :
Fournir le profil à l’utilisateur via le Self Service de Jamf Pro ;
Utiliser une méthode un peu plus complexe, mais entièrement automatisée.
Si nous optons pour l’approche automatisée, voici comment faire. Attention, c’est particulièrement sioux.
Créer un attribut d’extension
Dans la console Jamf Pro, cliquez sur Réglages > Ordinateur et sélectionnez Attributs d’extension.
Cliquez sur Nouveau
Appliquez les différents réglages comme sur la capture d’écran ci-dessous. Pour ce qui est du script lui-même, voici son contenu :
!/usr/bin/env bash RESULT="Wifi KO" if [ -f "/var/db/.wifi-ok" ] ; then RESULT="Wifi OK" fi /bin/echo "$RESULT"
Par défaut, on aura donc un attribut d’extension dont le résultat est Wi-Fi KO. Les chemins et les noms de fichier choisis ici sont par ailleurs totalement arbitraires, vous pouvez donc les customiser comme vous le souhaitez.
Variante : vous pouvez aussi créer le fichier à la fin d’un script d’enrôlement pour indiquer que l’enrôlement est bien terminé pour appliquer d’autres conditions. Vous pourriez donc nommer le fichier .EnrolementFini si ça vous chante. Par contre, je vous conseille de le laisser invisible. Perso, je génère un dossier au nom du client dans /usr/local et j’essaie de créer une petite hiérarchie propre dedans, donc ça pourrait être /usr/local/getenet/.EnrolementFini.
Créez un groupe intelligent
Une fois votre attribut étendu généré :
Cliquez sur Groupe intelligent d’ordinateurs > Nouveau ;
Cliquez sur Afficher les critères avancés ;
Choisissez votre critère Activation Wi-Fi ;
Dans la case Valeur, tapez Wifi OK (ou toute autre valeur générée dans le script).
Enregistrez.
Associer le groupe au profil Wi-Fi
Il nous faut maintenant créer notre profil Wi-Fi pour l’associer au Groupe intelligent. Pas l’opération la plus dure :
Cliquez sur Profils de configuration ;
Cliquez sur Nouveau ;
Remplissez votre profil de configuration Wi-Fi comme d’habitude ;
Cliquez sur Périmètre ;
Cliquez sur Computer Groups ;
Cliquez sur le bouton Add en face de votre groupe intelligent créé précédemment (oui, la régionalisation de Jamf Pro, c’est pas toujours ça…) ;
Validez, comme Johnny.
Pfiouuuu. Allez, c’est presque fini.
Activer l’état Wi-Fi Ready
Mais comment lui faire changer son état ? Facile : il suffit de générer le fichier /var/db/.wifi-ok via une simple commande, par exemple en ajoutant dans le script de déploiement la commande :
touch /var/db/.wifi-ok
Suivie d’une mise à jour de l’inventaire :
jamf recon
Notez que tout cela doit se faire dans le contexte du compte root (mais Jamf lance tous les scripts en tant que root, donc c’est OK).
Personnellement, j’ai utilisé cette méthode chez deux clients différents, et elle fonctionne parfaitement avec une version modifiée du script DEPNotify Starter, en générant le fichier à la fin du script.
Et si vous avez besoin d’aide pour mettre cette solution en place, il suffit de demander.
Ça n’a pas été signalé très fort, mais : fini les bobos aux doigts pour essayer de réaliser cette fameuse gymnastique pour réintialiser la PRAM ou la NVRAM de votre tout nouveau Mac équipé d’un rutilant processeur Apple Silicon, donc M1 pour le moment.
Car comme le précise la note de support technique d’Apple sur la réinitialisation de la PRAM (dans sa version anglaise pour le moment, pas encore mise à jour pour la VF) :
Cet article ne s’adresse qu’aux Mac équipés de processeurs Intel.
Adieu, donc, Cmd – Option – P -R bien aimé, adieu toi qui était parfois tout autant efficace qu’un morceau de sucre des laboratoires Boiron, adieu à toi, chère combinaison de touches qui nous a fait déclencher une arthrite précoce du bout des doigts. Tu nous auras quand même bien souvent sauvé la mise.
Et mine de rien, c’est un vrai reliquat du monde Mac qui disparaît ici. L’une des premières combinaisons de touches que j’ai retenues en lisant Le Mac pour les Nuls (ou Univers Mac, en tout cas c’était au milieu des années 90). Tout technicien qui se respectait et avait envie de gagner quelques minutes de répit savait qu’il fallait ordonner à l’utilisateur au bout du fil d’appuyer sur ces quatre touches magiques, soit au redémarrage du Mac, soit en l’ayant bien éteint au préalable pour nettoyer la NVRAM (après 2 démarrages, hein, pas moins).
Et de la même façon, la réinitialisation du SMC restera aussi une spécificité des Mac Intel. Fini là aussi les combinaisons de touches chelou différentes selon les modèles mais bien pratiques parfois quand la gestion de l’énergie se prenait les pieds dans le tapis, ou quand les ventilos décidaient de déclencher l’équivalent d’un ouragan force 12 dans le bureau…
Mais alors, on va faire quoi en cas de problème ? Et bien on s’appuiera sur la partition Recovery… ou sur Apple Configurator, comme expliqué par l’ami Dandumont.
Ou peut-être sur une autre combinaison de touches dont Apple a le secret. Qui sait.
Ça y est, macOS Big Sur est enfin disponible depuis jeudi 12 novembre ! Et du coup, en tant qu’administrateur système, vous êtes extrêmement pressé de voir tout votre parc adopter la nouvelle version…
Attendez, non, c’est pas ça ! Vous n’avez plutôt pas trop envie que vos utilisateurs basculent sur cette nouvelle version de macOS, parce que ça risque de vouloir dire incompatibilités en tout genre.
Faire le point sur les incompatibilités
Il faut d’abord regarder où se trouvent les éventuelles incompatibilités logicielles. En particulier :
Les applications encore 32-bit. Tout comme pour Catalina, celles-ci ne feront pas le saut vers macOS Big Sur.
Les applications reposant sur des extensions de noyau (les fameux kext). Même si macOS Big Sur ne les abat pas encore totalement (pour certaines, un redémarrage peut suffire), ces dernières n’ont pas vocation à rester et peuvent poser problème. Il faut pour certaines extensions de noyau déployer un profil pour les valider, et il faut redémarrer le poste… Pas idéal. Si l’éditeur d’un logiciel utilisant des extensions de noyau vous annonce qu’il n’est pas encore compatible pour macOS Big Sur, et qu’il ne sait pas quand ça arrivera… Il est peut-être temps de changer de crémerie.
Vérifiez aussi la compatibilité de vos matériels avec macOS Big Sur, en particulier vos imprimantes, traceurs… Si certains constructeurs assurent un bon suivi dans le temps, ce n’est pas toujours le cas. Donc, méfiance.
Certaines apps web, si vous utilisez Safari. Même si ça semble peu probable, mais si cela vous arrive, il faudra peut-être changer de navigateur.
Historiquement, on sait que les versions point zéro de macOS peuvent contenir des bugs parfois réhdibitoires voire critiques. Du coup, attendre la version 11.0.2 est sûrement un choix raisonnable. Et j’ai bien écrit 11.0.2 et non pas 11.0.1 puisque la version finalede macOS cette année est la 11.0.1, et non pas la 11.0 comme la tradition le veut. Bref, attendre quelques semaines n’est pas totalement déconnant.
Je ne veux pas que mes utilisateurs passent sur Big Sur, je fais quoi ?
À une époque où le modern management des ordinateurs devient une idée de plus en plus courante (accès administrateur autorisé à l’utilisateur, sous supervision du système informatique) , il est important de communiquer sur les raisons du blocage. Certains utilisateurs souhaiteront avoir accès dès que possible au dernier macOS, d’autres n’y verront aucun intérêt, mais c’est l’administrateur du parc qui doit assurer la continuité de service. Donc, si vous pouvez bloquer… bloquez.
Pour cela, il existe différentes méthodes.
Déployer un profil de configuration pour retarder les mises à jour via MDM
Si vos Mac sont intégrés dans un MDM (si ce n’est pas le cas aujourd’hui, c’est mal) ou un outil de déploiement de profil comme Munki, vous pouvez déployer un profil masquant les mises à jour pour une certaine durée. Pour cela, utilisez la clé enforcedSoftwareUpdate du payload Restrictions.
Vous pouvez créer ce profil à la main, avec un outil comme ProfileCreator ou configurer directement le réglage dans votre MDM s’il supporte ce payload, par exemple ici dans Jamf Pro :
Attention à bien choisir de retarder les mises à jour de logiciels. Il faudra macOS 10.13.4 minimum pour déployer ce profil.
Le défaut de cette méthode est qu’elle masque toutes les mises à jour, y compris d’éventuelles nouvelles mises à jour de sécurité pour l’OS actuel.
Utiliser une règle de restriction pour empêcher le lancement de l’app d’installation de macOS Big Sur
Quid des utilisateurs qui copient le logiciel d’installation de macOS Big Sur depuis un autre poste pour le lancer ? Dans ce cas, il peut être intéressant de bloquer complètement l’app d’installation de macOS Big Sur pour empêcher toute installation. Sur Jamf Pro, il suffit de bloquer le processus Install macOS Big Sur pour empêcher son lancement.
Déployer un package pour bloquer complètement macOS Big Sur
Une autre solution consiste à installer un package qui bloquera l’installation de macOS Big Sur : BigSurBlocker. Installez le package via votre outil de gestion habituel, et hop, l’utilisateur aura le droit à un petit message pour lui dire que non, nope, c’est pas pour tout de suite. La page liste également une méthode pour désinstaller BigSurBlocker proprement via un script.
Bloquer l’affichage de la mise à jour
Un point agaçant : quelque soit la solution utilisée, la mise à jour macOS Big Sur continuera d’apparaître dans la préférence Système Mise à jour de logiciels. Pour la masquer définitivement, utilisez la commande suivante (en root) :
softwareupdate --ignore "macOS Big Sur"
Cependant, cette commande ne sera efficace que si votre Mac est intégré dans un MDM. Si ce n’est pas le cas, elle ne fera absolument rien. Si votre Mac fonctionne sous mac OS Catalina, elle ne devrait être fonctionnelle que pour macOS 10.15.6 avec les dernières mises à jour de sécurité (Apple ayant apporté quelques changements pénibles sur les versions précédentes de la commande softwareupdate).
Si vous souhaitez à nouveau faire apparaître la mise à jour, envoyez la commande :
Je me suis encore pris la tête chez un client sur un problème d’installation des apps Adobe. Il faut savoir que la suite Creative Cloud , qui est quand même un outil qu’on a tendance à déployer beaucoup en entreprise, fait partie de ces produits qui sont particulièrement pénibles à déployer en entreprise. Enfin, qui ont été, à priori, car si ça a été très compliqué à une époque, Adobe fournit depuis quelques temps une console d’administration en ligne qui permet de générer des paquets customisés qu’on peut facilement déployer.
Sauf que.
Récemment, mon client m’informe qu’il n’arrive pas à installer un paquet d’installation fraichement généré pour la suite complète. Même en local, rien à faire, ça ne se déploie pas.
On tente de re-créer les paquets, pareil. On tente de créer un paquet de Photoshop seul, pareil.
Dans l’historique d’installation, un code d’erreur -112, et rien de bien probant sur internet. Les liens vers les quelques articles de base de connaissance d’Adobe que je trouve… ne fonctionnent pas parce que ÉVIDEMMENT les hyperliens c’est trop compliqué de les laisser fonctionnels (non). Mais je trouve finalement un dossier d’historique (/Library/Logs/Adobe/Installers/) qui contient deux fichiers, l’un totalement inutile, le second étant un log d’Adobe Acrobat. Vu que les développeurs d’Acrobat ont l’art et la manière de déployer leur soft de façon pour la moins pourrie alambiquée, je regarde, et là :
Quoi hein ? Safari ??? Donc, ça serait l’installation d’Acrobat qui bloque TOUTE l’installation parce que Safari est ouvert ???
Je quitte Safari, je relance, et là… OH ÇA S’INSTALLE DIS DONC.
Donc, les développeurs d’Adobe (enfin, plus particulièrement, l’équipe en charge de l’installation des logiciels) sont des rigolos. Si un simple navigateur ouvert peut bloquer complètement une installation, on peut parfaitement indiquer dans un script de préinstallation qu’il est indispensable de quitter les navigateurs ouverts avant l’installation (je peux même parfaitement comprendre qu’Adobe souhaite cela pour pouvoir installer son plug-in PDF de daube).
Mais être incapable de générer un vrai message d’erreur compréhensible par l’utilisateur et lui imposer de se démerder par lui-même pour trouver une solution ? Ça confine juste au ridicule, et ça montre aussi le piètre niveau des tests de QA d’Adobe. Ce qui ne m’étonne plus vraiment.
