[Résolu] Firefox se ferme tout seul

rcollobe · Le 16/05/2010, à 21:50

Ui je vais le faire de suite !
Merci encore pour votre aide
Content d'avoir servi de cobaye ^^

NB: Je remarque quand meme un disfonctionnement dans le Terminale lors des opérations "sudo" après avoir taper le mot de passe j'obtient:

rcolobe2 is not in the sudoers file

pbout340 · Le 17/05/2010, à 12:14

rcolobe2 is not in the sudoers file

Je m'attendais à l'objection pour avoir constaté moi-même ce problème après avoir voulu supprimer l'utilisateur supplémentaire qui nous avait permis de nous sortir de cette impasse.
Le problème n'est donc pas entièrement résolu et je compte bien le résoudre.
Je vous tiens au courant.
Pour le cobaye, j'essaie d'éviter de penser à ces petits animaux lors de ces aides qui sont donc bénévoles et, par ce fait, non astreintes à un quelconque résultat certifié. Mais, pour en revenir aux cobayes, et pour en avoir eu plusieurs à la maison, ces petits rongeurs sont bien fragiles et craignent beaucoup les courants d'air qui ont tendance à provoquer leur mort prématurée ;
et pour en revenir à cette aide bénévole, je peux vous assurer que je ferai ce qu'il est possible pour rétablir cette situation à la normale autant par envie de le faire que par ce nécessaire besoin qu'il est d'avancer dans ma connaissance de Linux.
et vous redonne, au passage, les conseils classiques en la matière : moins l'on est connaisseur de linux, moins l'on touche à sudo au hasard. Ce qui ne veut pas dire qu'il ne faut pas le faire, mais signifie principalement qu'il est préférable de s'abstenir à moins d'avoir bien intégré le but et le résultat de la commande envoyée avec sudo qui est, je vous le rappelle, une commande qui vous laisse toute possibilité de réparer, de configurer... mais aussi, de détruire lorsque les manipulations sont menées sans filet ou sans prise de connaissance et intégration des mécanismes alors mis en oeuvre.
Il est assez facile de provoquer une erreur, beaucoup plus ardu de la réparer.

Dernière modification par pbout340 (Le 17/05/2010, à 12:15)

kamui57 · Le 17/05/2010, à 12:53

rcolobe2 is not in the sudoers file

http://doc.ubuntu-fr.org/sudo#perte_du_ … _de_sudoer

pbout340 · Le 17/05/2010, à 13:57

@kamui57 :
je vois que tu suis toujours l'affaire d'assez près.

et que penses-tu de

-l, --lock
Lock the password of the named account. This option disables a
password by changing it to a value which matches no possible
encrypted value (it adds a ´!´ at the beginning of the password).

sudo passwd -l (nom d'utilisateur) ! ... pour tester après redémarrage son savoir faire en matière de récupération d'accès au logon !!!! pour être locké, t'es locké!

sinon, j'ai tenté la manip indiquée :

addgroup user1 admin

je fais bien partie du groupe admin. >>>

user1@www-xxx:~$ grep admin /etc/group
dip:x:30:user1,user2,user3,root
www-data:x:1001:user1,user2
lpadmin:x:106:user1,user2,root
netdev:x:112:user1,user2,user3,root
admin:x:121:user1,user2,user3,root
user2:x:1002:
user1@www-xxx:~$

user1 n'a pas la possibilité de modifier quoique ce soit dans utilisateurs et groupe (alors qu'il pouvait le faire auparavant) s'il passe par le GUI. Avant, je pouvais le faire en cliquant sur le trousseau + mdp hors ceci n'est plus possible. Il me faut passer par la ligne de commande :

sudo users-admin

+ (ici la demande de mdp est bien faite).

pour le moment, je n'ai pas reçu l'avertissement :

user1 is not in the sudoers file

Je ne me rappelle plus sur quelle commande je l'ai eu hier en testant parce que, sur le moment, je me suis juste dit : ben... rcollobe y va râler !

@rcollobe : mise à part ce problème avec le GUI de users-admin, tout semble être rentré dans l'ordre en appliquant la commande conseillée par kamui57 et dans la doc Ubuntu.

Il vous faut l'adapter ainsi (en Recovery mode) :

addgroup rcollobe2 admin

Pour supprimer l'utilisateur rcollobe dont le /home semble bien perturbé, il vous faut ouvrir, depuis votre session rcollobe2, users-admin en sudo :

sudo users-admin

Puis vous cliquez sur la ligne rcollobe pour la placer en surbrillance
puis vous cliquez sur "supprimer" et rcollobe ne sera plus cobaye ! RIP !

Ensuite, il est possible de finasser pour retrouver un rcollobe et un /home/rcollobe... mais cela fait beaucoup de manipulations à risque dans l'état actuel de la situation.

Pour retrouver la ou les commandes qui ont pu occasionner le problème ICEAthaurity, vous auriez pu lancer ceci dans le terminal en session rcollobe:

history

le retour vous listera les 500 dernières commandes passées en terminal (s'il y en a 500 au moins) ; s'il y en à moins, ce sera encore plus facile de retrouver celle qu'il ne fallait pas faire !

Dernière modification par pbout340 (Le 17/05/2010, à 19:35)

pbout340 · Le 17/05/2010, à 18:45

Je ne modifie pas le post précédent car je préfère séparer la démarche de réparation de la démarche de recherches qui me conduit à rajouter un certains nombres d'informations qui pourraient éclairer les uns et les autre au sujet de ICE, DCOP, KDE et Gnome.

DCOP : http://www.lea-linux.org/documentations … p/Dev-dcop

DCOP (Desktop COmmunication Protocol) est un service interne à KDE permettant de communiquer avec les applications KDE. Vous allez donc pouvoir communiquer avec ces applications grâce à votre shell. Cela inclut la récupération d'informations, ou la demande d'exécution d'actions à ces applications.

Cette entrée en matière concerne donc les utilsat-rices/eurs de KDE dont je ne suis pas. Ce qui ne m'empêche pas d'obtenir le message d'erreur ICEauthority avec Gnome.
La raison en est que pour diverses raisons liées à l'usage mal à propos de la commande sudo sur le répertoire /home, il est donc possible de se retrouver bloquer et de ne plus avoir la possibilité d'accéder à son bureau car root à pris la main sur /home/.ICEauthority et, de ce fait, l'utilsateur non root ne peut plus rentrer chez lui.
Une parade à ce genre de problème fait assez vite son chemin dans la tête des débutant-e-s sous Linux. Je ne peux pas en simple utilisateur ; pas grave, je colle un sudo sur tout ça ou un bon coup de chown -R root (CHange OWNer >>> changement de propriétaire) sur /home et on verra bien qui fait la loi ! Le raisonnement tient la route en apparence mais au redémarrage, il est clair que /home appartenant désormais à root, petit user pourra aller se faire voir ailleurs et dire adios à son Bureau.
Donc Linux est un gros C... et wiwe win ! sauf que c'est le contraire et que Win est fait de telle façon que n'importe qui peut à peu près y faire n'importe quoi...et cliquer allégrement sur n'importe quel pop-up qui conduira à n'importe quel exécutable malicieux (autrement dit un virus, par exemple), lequel s'installera tranquillement puisqu'aucun garde-fou ne prévient les cliqueurs fous de la gachette.
Partant de ce principe et des constatations réalisées plusieurs fois que l'usage fait par les linuxien-ne-s débutant-e-s de la commande sudo est généralement assez catastrophique pour la survie de leurs documents, il ne paraît donc pas inutile (et sans jouer au guru que je ne suis pas) de rappeler une dix millionième fois que l'on ne fait pas impunément joujou avec sudo.
Mais les users (j'en ai marre de le dire en FR parce que FR sexualise user et que ce n'est pas possible de répéter toujours françaises ! français ! sans se tromper dans l'ordre hein !)
de KDE ont une vague excuse car il se trouve que certaines applications KDE (k3b ou krusader, par exemple) ne peuvent fonctionner correctement qu'en passant par un sudo et se mêlent alors de changer le propriétaire du .ICEauthority (propriétaire passe de l'utilisateur normal à root). Du moins cela arrive-t-il à des users... mais il faut supposer que si K3B se mêlait ainsi de provoquer une erreur aussi handicapante à chacune de ses utilisations... il aurait été depuis longtemps jeté aux oubliettes... donc, nous en revenons bien encore et toujours aux users ! mais je n'utilise plus K3B.... Why ?
La réponse mérite le détour car elle est la clé d'une partie des causes qui entraînent l'erreur ICEAuthority (que les grands connaisseurs de KDE et Linux veuillent bien m'excuser si je fais quelques erreurs d'interprétation, et les corriger).
Je n'utilise plus KDE parce que le K est une lettre détestable surtout quand il est multiplié par 3... non, c'est juste un effet de rhétorique... en fait, un jour j'ai choisi Gnome, pourquoi... allez savoir ? ça n'a pas grande importance. Ce n'est qu'un choix tout personnel.
Mais avant de choisir, j'ai tout de même essayé KDE et Gnome ! et en bon petit ignorant naïf, j'ai lancé des applications KDE depuis Gnome... ce qui est une excellente méthode pour se ramasser avec ICEAuthority. Pour éviter ce genre de désagrément, il y 2 choses à faire (à mon avis) :
ne pas hésiter à utiliser la commande dcop dans sa plus simple expression :

dcop

le retour sera la liste des applications KDE installées et fonctionnelles... ce qui permet d'y voir plus clair.
ensuite, l'autre solution, toute aussi triviale, consiste à rentrer dans Menu Principal et à le réorganiser de manière à construire un menu avec des applications KDE et un menu avec des applications Gnome. Ceci a le grand avantage de clarifier la situation... avant le clic.
Vu que j'ai passé l'après-midi à farfouiller dans les forums, je ne priverai personne de cette petite ballade édifiante :

http://forum.ubuntu-fr.org/viewtopic.php?id=29616
Certains d'entre vous on certainement deja eu les erreurs DCOPserver (sous Gnome) et l'erreur could not start kstartupconfig check your installation en lancant une session KDE. Ces deux erreurs sont liées.
L'erreur DCOPserver .... survient lorsque l'on veut lancer une application KDE.
Cela vient de problèmes de droits du répertoire /home/user/.kde qui sont attribués uniquement a root (au lieu de l'user).
Pour résoudre ces problèmes taper simplement la commande suivante :
sudo chown -R nom_user:groupe_user /home/nom_user/.kde
Exemple :
Code:
sudo chown -R toto:toto /home/toto/.kde
Voila j'espere que ca pourra aider

sources : http://forum.ubuntu-fr.org/viewtopic.php?id=29616

man iceauth
The iceauth program is used to edit and display the authorization
information used in connecting with ICE. This program is usually used
to extract authorization records from one machine and merge them in on
another (as is the case when using remote logins or granting access to
other users). Commands (described below) may be entered interactively,
on the iceauth command line, or in scripts.

un serveur X distant peut se connecter à un windows manager et afficher les applications. Il y a donc besoin de gérer des permissions et autorisations. A une certaine époque, ce n'était pas fait, et c'est ainsi que des plaisanteries stupides ont pu être faites dans les universités (genre lancer l'affichage d'une image de fesse sur l'ordinateur du directeur de labo pendant qu'il est en réunion avec des financiers). Autant dire que ça ne pouvait pas durer. iceauth comme xauth font partie de cette chaine de sécurité.
.ICEauthority sera automatiquement recrée sans problèmes lors du lancement de X et window-manager.

sources : http://www.developpez.net/forums/d68525 … authority/

sous Gnome, le fait d'utiliser k3b ou krusader via un sudo change le propriétaire du .ICEauthority (propriétaire passe de l'utilisateur normal à root).
Ce n'est qu'au démarrage de X suivant que l'on s'en rend compte :-/

Ce genre de problême peut se poser quand tu te logues en root via su, à partir du home de l'utilisateur, et que tu lances une application kde en root . Il faut controler les variables de ton shell notament la $ICEAUTHORITY qui indique l'emplacement du fichier pour l'utilisateur donné.
Si cette variable est vide, je soupçonne dcop d'écraser le fichier home de l'utilisateur, et crée le nouveau .Iceauthority dans le home de l'utilisateur avec root en propriétaire, au lieu de créer ce fichier dans le home du root.
Ca a pour effet de bloquer l'utilisateur du compte, car le fichier .Iceauthority (qui appartient au root) n'est pas lisible par l'utilisateur.
C'est un problème classique avec "sudo". On lance une appli en tant que root, mais le gros de l'environnement (dont la variable $HOME) est encore celui de l'utilisateur. À mon avis, "sudo" n'a qu'une utilité, celle de faire des "su" sans password. Par exemple, au lieu de faire "sudo k3b", il faut faire "sudo su - -c k3b". La commande est alors lancé avec l'environnement du root comme il se doit. Un bon truc consiste à se faire un alias pour ce sudo intelligent :
alias sud='sudo su - -c'

sources : http://linuxfr.org/~cho7kipu/12496.html

J'ai réinstallé ubuntu proprement, reconfiguré mes logiciels, logiciel de messagerie/ etc etc, et hier j'installe Imule avec un serveur I2P externe (donc sans utilisé le router interne à I2P) en suivant mot à mot le tutoriel dédié à ça sur ubuntu-fr.com .
Donc j'établis des connexions avec le logiciel, je lance un téléchargement sur une distribution, c"est bon ça marche, niquel...., jusqu'à ce matin, plus aucune connexion à internet (la connexion fonctionne car sur les pc équipés de windows ça marche) mais aucune connexion n'est établi sur mon poste ou ubuntu est installé (icône de connexion absent en haut à droite), j'ai bien sur essayé de connecter, reconnecter, rien n'y fait ..
et donc je redémarre le pc et la voici les 3 message d'erreurs qui apparaissent à l'écran ::
(icône sens interdit) > could not update ICE authority file /home/turok10101/.ICE authority
Il y à un problème avec le serveur de configuration (usr/lib/libgconf2-4/gconf-sanity-check-2 a quitté avec l'état 256)
Nautilus est incapable de créer les dossiers requis : /home/turok10101/Desktop, /home/turok10101/.Nautilus.
Avant d'exécuter Nautilus, veuillez créer ces dossiers, ou définir les permisions de telle sorte que Nautilus puisse les créer.

sources : http://www.commentcamarche.net/forum/af … -authority

j'ai installé un service d'annuaire openldap , aprés la configuration du client ldap ,quand j'essaie de s'authentifier je reçoie ce message "could not update iceauthority file...."

sources : http://forums.fedora-fr.org/viewtopic.php?id=46976

J'ai une mandrake 10.0 qui fonctionnais tres bien jusqu'au jour ou je
tente d'installer un réseau local.

sources : http://www.frameip.com/nntp/fr-comp-os- … server.htm

et un grand classique !!! :

suite au lancement de startx en root....
Il vous suffit alors de faire un petit
sudo chown votre_login:votre_login ~/.ICEauthority
en mettant bien évidemment votre login à la place de "votre_login" (attention, il faut le remplacer 2 fois ;-)
NB : Entrez votre mot de passe s'il vous est demandé
Puis tapez
exit
Et re-changez la session en gnome (ou kde) et logguez-vous
autre cause : Vérifiez les permissions de votre répertoire /tmp (en drwxrwxrwt via chmod 1777 /tmp)

sources : http://doc.ubuntu-fr.org/tutoriel/votre … 0_secondes

un après-midi bien rempli !

Dernière modification par pbout340 (Le 17/05/2010, à 19:23)

rcollobe · Le 21/05/2010, à 20:19

excusez moi pour le retard (coupure internet ...)
Je pense avoir résolu le petit probleme en fait je n'avait pas donner de droits d'utilisateurs a ce nouveau compte, je pense donc que c'est bon.

une question peut on supprimer le premier compte ? et renommer le second ?

Sinon une question qui n'a rien a voir avec cette rubrique, c'est juste que mon lecteur audio ne sait pas lire les mp3 malgré les codecs téléchargés du coup comment puis-je faire ?

pbout340 · Le 22/05/2010, à 15:07

Suppression de rcollobe
J'ai posé le problème sur le principe que l'utilisateur fonctionnel rcollobe2 doit être renommé rcollobe. Hors rcollobe, ayant un répertoire /home/rcollobe corrompu, est encore existant. Il faut donc d'abord supprimer cet utilisateur rcollobe et son répertoire /home/rcollobe. Pour réaliser l'opération, rcollobe2 doit avoir des privilèges d'administration :

1. Depuis la session rcollobe2 vérifier que rcollob2 fait bien partie du groupe admin :

grep admin /etc/group

retour possible de la commande (qui renvoie donc au moins une ligne qui mentionne donc clairement que rcollobe2 appartient bien au groupe admin):

grep admin /etc/group
admin:x:121:root,rcollobe2

Si rcollobe2 n'appartient pas au groupe admin, la solution est alors de redémarrer en Recovery mode et d'ouvrir une session root.

Il faut alors ajouter rcollobe2 au group admin de cette façon :

addgroup rcollobe2 admin

puis vérifier que ceci a bien été réalisé en renvoyant la commande :

grep admin /etc/group

Rester en Recovery mode

2.supprimer le compte et le répertoire /home/rcollobe (premier compte rcollobe mal configuré dès le départ)

sudo userdel -r rcollobe

3. sauvegarder le répertoire /home/rcollobe2 par création d'un répertoire rcollobe2_back :

cp -a -R /home/rcollobe2 /home/rcollobe2_back

Ensuite, renommer le répertoire de rcollobe2 en rcollobe :

sudo mv /home/rcollobe2 /home/rcollobe

renommer l'utilisateur (la commande n'envoie aucun retour) :

sudo usermod -l rcollobe2 rcollobe

puis

sudo usermod -d /home/rcollobe -m rcollobe

-d indique le chemin vers le nouveau dossier de l'utilisateur et -m lui transmet les droits appropriés (la commande n'envoie aucun retour).

renommer le groupe principal de l'utilisateur :

sudo groupmod -n rcollobe2 rcollobe

Modifier le nom complet et les informations associées à rcollobe :

sudo chfn rcollobe

créer le nouveau mot de passe pour rcollobe :

sudo passwd rcollobe

redémarrer.

(j'espère ne pas m'être embrouillé dans les noms des utilisateurs car il m'a fallu me mettre à votre place).

Pour les MP3, ouvrir un nouveau fil dans les questions forum liées au Multimedia car hors sujet dans accès internet et réseau en re-précisant quel lecteur audio est utilisé et quels sont aussi les codecs téléchargés et actuellement installé.

Vérifier également que l'utilisateur en cours fait partie du groupe audio. Parfois cela peut résoudre le problème sans faire autre chose.

Dernière modification par pbout340 (Le 22/05/2010, à 15:13)

rcollobe · Le 22/05/2010, à 21:42

Merci de votre réponse !
Je ferais la manip demin sans doute, quand j'aurais un second ordi' a disposition a moins de tout recopier ^^
je vous tiendrais donc au courant du résultat sous peu

pbout340 · Le 23/05/2010, à 09:48

et si vous avez à nouveau un problème avec ICEauthority, redémarrez en Recovery mode et relancer la commande :

sudo chown rcollobe:rcollobe ~/.ICEauthority

et

addgroup rcollobe admin

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 16/05/2010, à 21:50

Re : [Résolu] Firefox se ferme tout seul

#52 Le 17/05/2010, à 12:14

Re : [Résolu] Firefox se ferme tout seul

#53 Le 17/05/2010, à 12:53

Re : [Résolu] Firefox se ferme tout seul

#54 Le 17/05/2010, à 13:57

Re : [Résolu] Firefox se ferme tout seul

#55 Le 17/05/2010, à 18:45

Re : [Résolu] Firefox se ferme tout seul

#56 Le 21/05/2010, à 20:19

Re : [Résolu] Firefox se ferme tout seul

#57 Le 22/05/2010, à 15:07

Re : [Résolu] Firefox se ferme tout seul

#58 Le 22/05/2010, à 21:42

Re : [Résolu] Firefox se ferme tout seul

#59 Le 23/05/2010, à 09:48

Re : [Résolu] Firefox se ferme tout seul

Pied de page des forums