Impossible d'ouvrir ma propre session

[trypsine]

Alors à propos des bizarreries, mon mac est en anglais car je l'ai décidé ainsi. Le full name est indiqué dans l'onglet précédent (c'est déjà ça) et pas dans les options avancées, c'est vrai. A propos de l'appleID, aucune case, mais je ne l'utilise pour ainsi dire jamais, je n'ai pas souvenir d'avoir dû m'en servir quand j'ai configuré ma machine (début 2011) et je snobbe l'AppStore. Peut-être cela explique-t-il son absence ?

Je ne faisais rien de spécial avant que l'incident ne se produise. Je travaillais sagement, en faisant du web. Mais pourrais-tu me donner des exemples d'opérations auxquelles tu penses ? Franchement, je ne vois pas, mais peut-être oublié-je quelque chose ?

Merci beaucoup en tout cas.

 

[Membre supprimé 1060554]

Chez moi, titi a une carte d'identité franche du collier -->

mais foin de scrupules : «vous pouvez passer, trypsine» (voix de douanier caverneuse)

--------------------
​

Il arrive qu'un processus impliquant le Finder soit à destination directe du Bureau (comme le déplacement par erreur de dizaines de milliers de photos dans le dossier Desktop de l'utilisateur), soit dans ses fonctions de service de l'utilisateur (mise à la corbeille d'énormément d'éléments par exemple) plante ses fonctions et par là-même ses capacités d'affichage graphique. Mais il peut y avoir aussi d'autres sources de plantage, comme un LaunchAgent pernicieux (c'est une tâche de toile fond axée "utilisateur" et démarrant avec la session) organe d'une application incompatible.

Bref, mon idée était la suivante : un utilisateur d'OSX étant la combinaison d'une identité logique (la "carte d'identité" que tu vois affichée dans le panneau des Options Avancées at: Préférences Système/Utilisateurs et Groupes, qui décrit l'UserID) + une identité graphique (le "domicile d'utilisateur" qui correspond au dossier de compte contenu dans le répertoire-Système des Utilisateurs et qui contient les "données personnelles" de l'utilisateur : le Home_Folder) --> ton plantage à ouvrir la session, pour me montrer bien binaire, relève alors soit de l'identité logique, soit de l'identité graphique.

À supposer que ton identité logique soit hors de cause (et déjà ton mot-de-passe d'utilisatrice a l'air tout à fait fonctionnel) - alors le blocage d'ouverture de ta session doit dépendre de ton identité graphique (quelque chose relevant de ton dossier de compte contenu dans le répertoire des Utilisateurs). Quoi? mystère et boules de gomme...

--------------------
​

Comme tu m'as l'air tout à fait à l'aise avec le panneau des Options Avancées des Préférences Système/Utilisateurs et Groupes (qui manipule graphiquement les paramètres d'utilisateur de la base de données d'Annuaire de l'Open Directory - ce qui évite les affres indicibles d'invoquer le programme dscl dans le «Terminal»

) - tu pourrais te livrer à une expérimentation croisée à mon sens sans danger mais susceptible d'être instructive.

- 1° Logée dans la nouvelle session de l'utilisateur nommé : admin, tu vas au panneau des Préférences Système/Utilisateurs et Groupes, tu déverrouilles le cadenas d'administration et tu presses le bouton '+' pour créer un nouvel utilisateur expérimental aux privilèges admin encore, du type : Nom Complet = lolo ; nom-de-compte = lolo ; mot-de-passe = lolo --> un dossier de compte intitulé lolo (arborescence vierge de données) se trouve créé dans le répertoire des utilisateurs /Users où il cotoie désormais les dossiers de compte déjà en place de : anais, admin, anais73, Guest & Shared (saperliflûte! il y a en a des "avatars" là-dedans...).

- 2° À présent, toujours dans le panneau des Préférences Système/Utilisateurs et Groupes, tu sélectionnes le nom d'utilisateur anais en pressant simultanément la touche ctrl afin de démasquer le panneau des Options Avancées relatives à cet utilisateur --> à la rubrique Home directory où se trouve renseigné : /Users/anais (il s'agit du chemin absolu liant à l'UserID : anais le Home_Folder : /Users/anais qui permet d'ouvrir une session graphique à partir de l'affichage Finder du dossier /Users/anais/Desktop = le Bureau d'utilisateur) --> opère l'édition suivante : tu écris /Users/lolo et tu fais OK.

- 3° Démarche croisée à présent. Tu reviens au panneau global Préférences Système/Utilisateurs et Groupes, tu sélectionnes cette fois-ci le néo-utilisateur : lolo avec la touche ctrl pressée pour démasquer le panneau des Options Avancées --> à la rubrique Home directory où se trouve renseigné : /Users/lolo (le Home_Folder vierge du nouvel utilisateur créé), tu opères une édition altéro-symétrique de la première en saisissant : /Users/anais et tu fais OK. Comme tu le vois, tu as croisé les chemins aux dossiers de départ des 2 utilisateurs : anais a pour dossier de départ désormais celui de lolo et lolo a pour dossier de départ celui d'anais.

- 4° Quitte à présent la session de l'utilisateur admin (il ne faut pas que tu sois en ouverture automatique de session sur cet utilisateur) et loge-toi dans la session anais (avec le mot-de-passe courant d'anais) --> qu'est-ce qui se passe? Si tu parviens à ouvrir une session, le dossier de départ, étant celui du nouvel utilisateur lolo, est vierge et donc le Bureau est vide a priori. Mais l'enseignement serait que ton UserID (identité logique) : anais ne rencontre intrinsèquement aucun problème pour ouvrir une session graphique, dès lors que le Home_Folder est sain. Tu aurais là la preuve suffisante que l'UserID : anais (la "carte d'identité" d'utilisatrice dans l'Open Directory) ne comporte pas d'erreur.

- 5° Quitte cette session anais (qui repose donc sur l'affichage du néo-dossier de compte lolo dans /Users) et loge-toi ce coup-ci dans la session lolo (avec le mot-de-passe lolo) --> qu'est-ce qui se passe encore? L'UserID : lolo qui vient d'être créée dans le répertoire d'Annunaire de l'Open Directory est a priori au-dessus de tout soupçon et constitue une identité logique valide a priori. Mais l'ouverture de session se réfère au dossier de compte anais dans /Users (d'après le chemin édité) --> il s'agit donc ici d'un test concernant l'identité graphique ( ce qui relève des contenus du Home_Folder : anais dans /Users) --> si l'ouverture de session plantait, ce serait la preuve suffisante que quelque chose dans le Home_Folder : anais est bloquant ; si l'ouverture de session s'opérait sans problème (tu te retrouverais avec l'affichage du Bureau d'anais mais en tant qu'utilisatrice lolo squattant son domicile (c'est pas beau, ça!) - alors le problème deviendrait délicat à gérer : il s'agirait d'une tâche relative à des contenus du Home_Folder : anais qui ne se lancerait que si ce dossier de compte était ouvert graphiquement sous l'identité logique : anais, avec des préférences relatives à cette utilisatrice en tant qu'initiatrice du processus. Car ouvrir une session graphique exploitant un Home_Folder : x à partir d'une UserID : y impose récursivement à l'ouverture de session l'UserID de l'opérateur y comme propriétaire de toute l'arborescence du dossier de compte x. Tous les dossiers et tous les fichiers sont donc récursivement édités à y quant à l'identité de l'owner. Donc si lolo arrive à ouvrir une session graphique avec le dossier de compte d'anais, c'est parce qu'en tant que néo-opératrice, lolo a suspendu la tâche de session qui demandait une iniatrice de processus du nom d'anais.​

☞ quelle que soit l'issue de cette expérimentation croisée, l'édition à rebours est absolument possible, à partir de la session tierce de l'utilisateur admin et je t'engage à l'opérer --> il suffit, pour l'utilisateur anais de restaurer à /Users/anais le chemin à son Home_Folder et pour l'utilisateur lolo de restaurer à /Users/lolo le chemin à son Home_Folder dans les panneaux Options Avancées relatifs à chaque utilisateur et de faire OK chaque fois. Essaye alors d'ouvrir la session anais --> le processus de rétablissement récursif de l'UserID : anais sur l'arborescence du Home_Folder en remplacement de la ci-devante owner : lolo permet-il une ouverture de session régulière? Si oui, l'inter-règne récursif de lolo sur l'arborescence du Home_Folder : anais aurait suffi à "tuer" le processus en cours demandant un nom d'initiateur anais - sans que le rétablissement récursif d'anais en opératrice-owner du Home_Folder n'ait relancé la tâche a posteriori (je sais : "ca-pil-lo-trac-té" !)

--------------------​

 

[Anonyme]

Chez moi, titi a une carte d'identité franche du collier -->

Mais ça, c'est sous Yosemite : http://hpics.li/ee6c77f

La dame est sous Snow Leopard, et jusqu'à Mavericks, la présentation est identique : pas de "nom complet", pas d'identifiant Apple.

 

[Membre supprimé 1060554]

Mais ça, c'est sous Yosemite.
La dame est sous Snow Leopard, et jusqu'à Mavericks, la présentation est identique : pas de "nom complet", pas d'identifiant Apple.

«Et voilà pourquoi votre fille est muette !» - Je n'avais pas prêté attention à la version de l'OS...​

 

[trypsine]

Alors, alors, au rapport :

La manip de création d'un autre compte (maintenant nous sommes 4, youhou !) et d'inversion des Home respectifs mène à : les deux s'ouvrent correctement. Good news?

Pour la seconde partie, retour aux Home initiaux, et changement de propriétaire pour le compte qui bug, mon ancienne session anais maintenant privée de ses droits (la pauvre) démarre correctement. Et la nouvelle maintenant super puissante plante. Comme quoi dominer la planète ne permet pas forcément de survivre dans ce monde hostile.

Vous savez en déduire un diagnostic ?

 

[Membre supprimé 1060554]

trypsine:La manip de création d'un autre compte (maintenant nous sommes 4, youhou !) et d'inversion des Home respectifs mène à : les deux s'ouvrent correctement. Good news?

[user:anais x home:lolo] = 1 --> l'UserID:anais est valide, mot-de-passe inclus, et opérationnelle avec un home neuf.
[user:lolo x home:anais] = 1 --> le home:anais supporte l'ouverture de session par un autre user que l'aborigène.​

trypsine:Pour la seconde partie, retour aux Home initiaux, et changement de propriétaire pour le compte qui bug, mon ancienne session anais maintenant privée de ses droits (la pauvre) démarre correctement. Et la nouvelle maintenant super puissante plante.

Je ne suis pas sûr de lire correctement la nouvelle donne : tu as bien "dé-croisé" les home_folders pour restituer chacun à son user aborigène, soit home:lolo à user:lolo et home:anais à user:anais? Càd. reconstitution exacte de la situation originelle? Pourquoi dis-tu alors que la session anais est "privée de ses droits"? Ce doit être une session où le home:anais a retrouvé son user:anais primitif qui possède toujours des privilèges admin, non?

Si oui, dois-je en déduire que les résultats seraient :

[user:anais x home:anais] = 1 --> le problème serait réglé : la session s'ouvre de nouveau correctement. Il se serait agi d'une tâche plantogène que le va-et-vient de propriétaires du home:anais (anais --> lolo --> anais) a stoppé. Si relance de la tâche --> re-plantage probable = "Épée de Damoclès" sur la session --> nécessité d'inspecter les applications qui se lancent au démarrage de session, les LaunchAgents etc. afin de faire le ménage.

[user:lolo x home:lolo] = 0 --> la nouvelle session où le home:lolo vierge a récupéré son user:lolo (comme lors de la toute fraîche création) planterait à son tour au démarrage? Si c'était le cas, en pratique aucune importance (compte expérimental supprimable), mais en théorie j'en serais baba (le "pourquoi du comment" m'échappe - si c'est bien le cas...).​

☞ comme tu vois, je cafouille pour lire exactement la donne "retour à la case départ" (à chaque user son home originel derechef), parce que j'ai du mal à interpréter ton "péjoratif" («privée de ses droits (la pauvre)» = [user:anais x home:anais]- n'est-ce pas?) comme ton "mélioratif" («maintenant super puissante» = [user:lolo x home:lolo] - n'est-ce pas encore?)

 

[trypsine]

Oui bon, j'étais pas claire, j'ai dû comprendre un truc de travers.

Après l'inversion des home qui donnait : tout le monde réussit à démarrer, j'ai fait d'autres trucs.

1. restauration des home naturels ==> retour au point initial
[user:anais x home:anais] = 0
[user:lolo x home:lolo] = 1

2. changement du owner du home:anais
[user:anais x home:anais] = 1
[user:lolo x home:lolo] = 1
mais
[user:lolo x home:anais] = 0

C'était pour cette dernière partie que je parlais de perte de pouvoir et de toute-puissance.

Bon, sinon, pour les LaunchAgents, j'avais pas grand chose. Mais je vais regarder de côté-là.

 

[Membre supprimé 1060554]

Ton point 1. --> je le saisis bien : quand tu rétablis à nouveau la situation de départ [user:anais x home:anais], rien n'a changé et la session ne s'ouvre toujours pas. Ce que tu as gagné comme informations de tes manipulations, c'est que : a) ton userID:anais est valide isolément ; b) ton homefolder:anais est démarrable par une autre identité d'user ; c) la combinaison [user:anais x home:anais] par contre bloque --> ma conjecture tient toujours : quand l'user:anais démarre son home:anais, cette identité d'opératrice doit relancer un processus bloquant d'entrée de jeu (alors qu'une autre identité d'opératrice ne le fait pas). Quoi? Aucune idée : processus du Finder? Agent d'une application? En tout cas, un truc ayant besoin d'une identité d'opératrice précise pour se ré-initier.

♤
​

Ton point 2. --> macomaniac va-t-il en perdre son Latin? Ou le garder pour s'écrier : «O fortunatos nimium, sua si bona norint agricolas !» [Les ploucs de l'Antiquité, s'ils s'étaient sus indemnes des affres à venir de l'informatique - quel n'aurait pas été leur sentiment de félicité !] ? Car j'ai du mal à cerner ce que tu appelles exactement «changement du owner du home:anais» et comment tu t'y prends pour ce faire...

S'agit-il d'une manipulation graphique dans une fenêtre d'information du Finder (de la session admin) ciblée sur le dossier home:anais du répertoire des /Users? Tu créerais une ACL autorisant un co-propriétaire du dossier home:anais (lequel alors?), puis tu supprimerais le propriétaire anais pour ne garder que le co-propriétaire promu nouveau propriétaire (= "owner") et tu étendrais récursivement ce statut à tout le contenu de l'arborescence du dossier? Et cette manip permettrait alors l'ouverture de session de l'user:anais restée la même? Si c'était le cas, pourquoi ça n'aurait pas marché avant, lorsque le démarrage du home:anais par l'user:lolo avait établi récursivement la propriétaire lolo sur toute l'arborescence du home:anais?

Je crois que j'ai besoin d'un "décodage" du sens de : «changement du owner du home:anais», opération permettant alors [user:anais x home:anais] = 1 --> le problème serait-il alors résolu?

♧
​

Sinon, il m'est venu une idée simple pour débloquer l'ouverture de session à partir du home:anais. On a appris de tes manipulations qu'une UserID différente de user:anais (user:lolo en l'occurrence) permet de démarrer le home:anais. Suffirait-il alors (à partir de la session admin, accès au panneau des Options Avancées du compte anais) --> de modifier seulement la casse du Nom de compte (username): anais --> Anais et de faire OK, le numéro d'utilisatrice (501), le shell d'accès (/bin/bash), le mot-de-passe, le Nom Complet, le chemin au home_folder (/Users/anais) demeurant par ailleurs invariables? Bref, ne modifer dans la carte d'identité de l'utilisatrice 501 que l'username (= nom de compte)? Le passer de anais à Anais? Et tenter d'ouvrir une session pour voir si : [user:Anais x home:anais]= 1?

Si un processus bloquant a besoin strictement de l'username:anais pour se relancer en ouverture de session, alors démarrer le dossier home:anais en tant qu'user:Anais empêcherait peut-être le processus bloquant de s'autoriser de l'opératrice attendue (anais) et la session s'ouvrirait-elle? Avec l'énorme avantage de tous les autres paramètres de l'UserID inchangés (dont le mot-de-passe sur lequel le Trousseau de session est synchronisé)? Ce qui permettrait de faire un ménage avisé dans le compte anais (ce qui se lance en ouverture de session...) et, en cas de succès présumé, repasser ultérieurement par la session admin et ré-éditer l'username Anais --> anais pour voir si l'ouverture de session s'opère désormais bien?

♡​

 

[trypsine]

S'agit-il d'une manipulation graphique dans une fenêtre d'information du Finder (de la session admin) ciblée sur le dossier home:anais du répertoire des /Users? Tu créerais une ACL autorisant un co-propriétaire du dossier home:anais (lequel alors?), puis tu supprimerais le propriétaire anais pour ne garder que le co-propriétaire promu nouveau propriétaire (= "owner") et tu étendrais récursivement ce statut à tout le contenu de l'arborescence du dossier? Et cette manip permettrait alors l'ouverture de session de l'user:anais restée la même? Si c'était le cas, pourquoi ça n'aurait pas marché avant, lorsque le démarrage du home:anais par l'user:lolo avait établi récursivement la propriétaire lolo sur toute l'arborescence du home:anais?

Je crois que j'ai besoin d'un "décodage" du sens de : «changement du owner du home:anais», opération permettant alors [user:anais x home:anais] = 1 --> le problème serait-il alors résolu?

Alors pas de manipulation graphique (même si apparemment il est possible de changer le owner via la fenêtre d'info). J'ai fait ça en ligne de commande, de façon récursive. Bref, j'ai fait la manip inverse, tout est redevenu normal (chacun est propriétaire de son home) et retour à la case initiale : anais ne répond plus.

J'ai fait la manip de changer la casse du username : échec cuisant.

Bon, ensuite vous n'allez sûrement pas être contents, mais j'ai fait la bourrine en supprimant le dossier LauchAgents de mon compte anais.
(Pas de panique, j'ai fait mille sauvegardes de tout -- bien avant de rencontrer ce souci -- et je l'ai pas complètement supprimé de ma machine donc j'étais capable de faire marche arrière.) Et là j'arrive à ouvrir ma session. Youpi.
Puis marche arrière en remettant mes LauchAgents (re-failed) puis en supprimant seulement les trucs les plus récents (même si j'étais sceptique car les derniers datent du 24 février alors que mon plantage date du 26 et que c'est sûr et certain que j'ai rebooté ma machine depuis. Anyway.)
Re-re-failed.

Bref, le résultat final est que je réussis à reprendre le contrôle de ma vraie session en virant les LauchAgents. Mais je ne comprends toujours pas, alors ça me turlupine.

Bon samedi !

 

[Anonyme]

Bonjour,

si ce n'est pas indiscret, il y avait quoi, dans le dossier LaunchAgents de ta session malade ??

 

[trypsine]

Question très indiscrète, c'est un peu comme l'âge, pas le genre de choses qu'on demande à une fille…

UpdateDownloader
com.Installer.completer.download.plist
com.Installer.completer.ltvbit.plist
com.Installer.completer.update.plist
com.adobe.AAM.Updater-1.0.plist
com.adobe.ARM.82b60eb7d56c3a399b68a4aed6529847d61b16568fc56ea3a2dc25da.plist
com.adobe.ARM.a07a5dc52b60251866873a0fdd37594b79a2d8502345e4ec54417ad0.plist
com.extensions.updater69337.agent.plist
com.extensions.updater69337.ver
com.spotify.webhelper.plist
com.wondershare.mobilegodaemon.plist
org.virtualbox.vboxwebsrv.plist


Ceux qui datent de mardi sont les com.Installer.* et les com.extensions.*

 

[Anonyme]

C'est plein comme dans le sac à main d'une fille, dis-donc.

Dans le mien, il n'y a rien et il n'y a jamais rien eu...

 

[trypsine]

Bah écoute, ça doit être justement pour pallier à mon manque de sac à main de fille.
Et je sais pas à quoi ça correspond vu qu'en théorie j'interdis à l'univers de se lancer au démarrage. A part TigerLaunch.
Bref…

Et sinon, deux questions subsidiaires :
est-ce possible de récupérer le Keychain de mon compte à moitié cassé pour l'utiliser avec un autre ? Et idem pour les mailboxes créées dans Mail ?

 

[Membre supprimé 1060554]

C'était donc bien un LaunchAgent qui fichait le bazar. Donc tu as quasiment partie gagnée.

Vu que tu n'as qu'une douzaine d'Agents, voici ce que tu pourrais faire : au lieu de supprimer le dossier : LaunchAgents (avec ses fichiers contenus), laisse en place le dossier (car c'est une localisation que des applications sont susceptibles d'aller chercher pour installer leurs services axés utilisateur), et borne-toi à le vider de ses fichiers. Puis, avec un tout petit peu de patience, tu rajoutes au compte-goutte untel, puis untel... de ces fichiers d'Agents dans le dossier LaunchAgents en intercalant chaque fois une expérience de quitter/réouvrir la session anais. Tu devrais vite détecter quel est l'Agent plantogène (qui n'était peut-être pas sensible à la casse?). Dans ce cas, tu le bennes, en suspectant de fil en aiguille l'application au service de laquelle il roule - et tu conserves les autres.

 

[trypsine]

Bah c'est ce que j'ai fait, avec ceux qui datent de la semaine dernière. Enfin dans l'autre sens, en les supprimant un par un. Ça donne rien. Je poursuis donc la manip avec les plus vieux.

 

[Anonyme]

Pour Keychain, normalement oui.

Tu vas à ~/Library/Keychains, tu prends copie de "login.keychain" (celui sans les chiffres et lettres après).

Ah non, gasp, tu es sous SL, donc je suppose qu'il faut prendre tout le dossier Keychains.

Pour le mail, tout dépend si c'est un compte POP ou IMAP : en IMAP, rien de spécial à faire, ça se fera tout seul.

 

[trypsine]

Ok, oui ça marche pour Keychain. Juste ça me demande toujours les identifiants de mon ancien compte, mais je peux sûrement modifier ça.

Pour les mails, je parle en fait des boîtes créées en local sur ma machine, et qui du coup n'existent pas sur mes serveurs. Bref, pas important.

 

[Anonyme]

Pour les mails il a plusieurs solutions possibles.

IMAP : faire monter les BAL sur le serveur (glissé déposé dans la barre latérale de Mail)

Ou "Fichier / Importer" pour importer les BAL.