Salut
quequoi
Puisque tu as l'air de goûter le
laïus > alors pourquoi me priverais-je du recours à la rhétorique ?
En ce qui concerne la commande
sudo.
sudo est un utilitaire dont l'intitulé abrège l'expression :
substitute_user_do --> exécuter une commande en tant qu'utilisateur subtitué. C'est donc un utilitaire permettant d'exécuter une commande, non en tant que "soi-même" (utilisateur connecté, qui se trouve automatiquement loggé dans le
shell sous cette même identité, laquelle est mentionnée dans l'invite de commande du «
Terminal») > mais en tant qu'une "autre-que-soi".
Étant donné cette fonction spécialisée de substitution d'identité d'utilisateur pour l'exécution ponctuelle d'une commande >
sudo se trouve donc toujours appelé avant une commande (en guise de "préface", dirons-nous). Lorsque l'utilitaire
sudo est ainsi appelé en en-tête d'une commande sans aucune option particulière, comme «
sudo » tout court > alors cette mention est automatiquement comprise comme signifiant : "exécuter la commande qui suit en tant qu'utilisateur
root (le
System_Administrator) par défaut".
Vu la portée de cette substitution d'identité d'utilisateur (exécuter une commande en tant que substitut ponctuel de
root) > l'invocation de
sudo est soumise à des conditions d'autorisations particulières qui sont les suivantes :
- un fichier spécifique consignant les utilisateurs « ayant-droit de sudo » se trouve consulté at: /etc/sudoers > suite à quoi l'utilisateur loggé dans le shell qui invoque sudo dans une commande se trouve identifié comme faisant ou ne faisant pas partie des utilisateurs autorisés à opérer en mode sudo (dans notre cas : à utiliser l'identité de substitution de root). La règle par défaut est la suivante : est autorisé à sudo un membre du groupe admin.
- le renseignement du mot-de-passe d'ouverture de session est obligatoire pour valider la requête sudo --> si l'utilisateur qui invoque sudo est reconnu membre du groupe admin et si son mot-de-passe est valide > alors la commande qui suit sudo va être exécutée en identité root ; si l'utilisateur n'est pas identifié comme membre du groupe admin ou si son mot-de-passe est non-valide (après tout > un collègue de travail pourrait profiter d'une absence de l'intéressé ayant laissé son ordinateur allumé et sa session ouverte pour tenter un sudo - sans la connaissance du mot-de-passe de session > ça ne va pas le faire) > alors l'invocation de sudo est rejetée et la commande avortée.
- par principe de précaution > la saisie du mot-de-passe de confirmation ne donne pas lieu à une sortie d'affichage à l'écran : il y a donc frappe en aveugle du mot-de-passe d'utilisateur.
=> d'après ce bref descriptif du mécanisme de
sudo > je ne comprends pas très bien le blocage dont tu parles pour la commande
sudo > à part si tu n'étais pas en tant qu'utilisateur connecté membre du groupe
admin. Pour le vérifier > tu n'as qu'à faire un copier-coller dans une fenêtre du «
Terminal» de la commande :
Bloc de code:
dscacheutil -q group -a name admin
et l'exécuter > en retour tu vas voir s'afficher la liste des utilisateurs membres du groupe
admin --> vois-tu ton nom d'utilisateur connecté dans cette liste ?
Si tu le vois bien > alors il n'y a pas de raison que tu ne puisses valider l'invocation de
sudo > sauf :
- si tu échouais 3 fois d'affilée à saisir correctement ton mot-de-passe de session à l'aveugle (ça peut arriver) ;
- si le fichier /etc/sudoers était "trafiqué" dans ses entrées > au point de ne pas autoriser un admin en général à sudo > ou du moins toi spécifiquement parmi les admin à sudo.
Si tu passes la commande banale :
(en t'authentifiant par ton mot-de-passe à l'aveugle correctement) > est-ce que tu vois s'afficher en retour la liste des répertoires de l'espace racine du volume de ton OS ?
[Je ne comprends pas du tout comment tu peux passer une commande
su (
substitute_user_identity) = changer d'identité dans le
shell et se logger comme
root > et pas passer une commande
sudo : emprunter une autre identité d'utilisateur dans le même
shell pour passer la commande qui suit. Il y a quelque chose qui m'échappe...].
--------------------
Tant qu'à tester des logiciels graphiques gratuits > tu n'as qu'à télécharger et installer : ☞
Disk Inventory X☜ puis faire un double essai : le lancer normalement > choisir le volume
Macintosh HD > presser le bouton
Open Volume vs le lancer par la commande :
Bloc de code:
sudo open -a Disk\ Inventory\ X
(ou l'appeler une fois loggé via
su en
sh-3.2#) --> est-ce que tu notes une différence de visibilité graphique des fichiers ?
--------------------
com.apple.coresymbolicationd est un dossier de caches --> poubelle.
Par contre > tu aurais intérêt à vérifier si c'est ce dossier, une fois re-créé, qui regonfle en Go ou non. Tu me fais me souvenir aussi qu'un méchant bogue affectait l'OS «
Mavericks» : une inflation de fichiers relevant du processus
IconServiceAgent > qui finissaient par prendre une masse de Go considérable > est-ce que tu notes ce problème chez toi ?
--------------------
Pour ce qui est de tes OS > tu aurais intérêt à cloner ton volume
Macintosh HD V dans le volume d'un DDE > effacer ce volume de tête > cloner
Macintosh HD dans le volume de tête vidé > effacer le volume de queue
Macintosh HD + sa
Recovery HD > cloner à rebours dans ce volume subalterne une version allégée en données du clone «
Snow Léopard». Utiliser la démo (gratuite un mois) de ☞
Carbon Copy Cloner☜ pour ce faire («
CCC» clone la
Recovery HD en plus du volume de l'OS qui en comporte une).
Ce tour de passe-passe > parce que la distribution hiérarchique de tes volumes en emplacements et tailles > est chez toi un héritage du passé dépourvu d'actualité pratique. Bref : ce serait une bonne apuration. Tu es passé au SSD que diable ! > alors autant accorder à «
Mavericks» la priorité en localisation et en taille de volume. Tu reconnais toi-même que tu ne lances plus qu'occasionnellemen ton «
Snow Léopard» - lequel occupe
168 Go sur les
250 de ton SSD !
--------------------
> patienter le temps que la recherche s'opère > et poster le tableau résultant.
