[Résolu] sudo gedit réagit mal...

Foromus · Le 22/02/2018, à 15:51

Bonjour,

A ma grande surprise, je ne peux plus modifier mon fichier host.
Et ce, sur mes deux machines.
Voici ce qu'affiche la console :

********:~$ sudo gedit /etc/hosts
[sudo] Mot de passe de **** : 

** (gedit:28592): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-x0kLPFgq1D: Connexion refusée

(gedit:28592): Gtk-WARNING **: Theme directory  of theme default.kde4 has no size field


** (gedit:28592): WARNING **: Set document metadata failed: La définition de l’attribut metadata::gedit-position n’est pas prise en charge
********:~$

Pour le moment, ça marche, mais le jour où un site va changer son IP, je vais être mal...
Je ne sais quoi penser....
Merci pour le coup de main !

Dernière modification par Foromus (Le 24/02/2018, à 11:41)

Roschan · Le 22/02/2018, à 15:52

Étonnant.

Foromus · Le 22/02/2018, à 16:05

Merci pour le retour.

Voici ce que j'obtiens dans la console :

*******:~$ gedit admin:///etc/hosts

(gedit:29460): Gtk-WARNING **: Attempting to read the recently used resources file at '/home/***/.local/share/recently-used.xbel', but the parser failed: L'ouverture du fichier « /home/***/.local/share/recently-used.xbel » a échoué : Permission non accordée.

(gedit:29460): Gtk-WARNING **: Theme directory  of theme default.kde4 has no size field


** (gedit:29460): WARNING **: L'emplacement indiqué n'est pas pris en charge
*******:~$

Au passage, je me demande ce qu'il va chercher dans mon /home/...
Au fait, j'ai essayé avec un autre fichier, c'est la même chose.
Normalement, gedit n'est pas l'éditeur par défaut sous xubuntu, mais jusqu'à présent, ça marchait bien, et je suis habitué, j'aime bien gedit.

erresse · Le 22/02/2018, à 16:41

En référence à ton autre discussion : https://forum.ubuntu-fr.org/viewtopic.php?id=2022669
Tu n'essaierais pas de passer des commandes d'administration depuis ton nouveau compte (qui n'est pas forcément administrateur), par hasard ?

Foromus · Le 22/02/2018, à 17:22

En fait, si, j'ai essayé un coup !
Le système m'a demandé le pass de l'utilisateur du nouveau compte, ce qui m'a étonné, je l'ai donné, naturellement, ça n'a pas marché ! J'ai mis le pass admin, çà n'a pas marché non plus, ce qui ne m'étonne pas vraiment.
Après, je suis revenu sur mon comte habituel (admin, donc), là j'ai bien agi dans la console, avec le résultat que j'ai posté plus haut.
En clair, et pour l'heure, je suis dans l'incapacité totale de modifier un fichier en mode admin !
(Pour les permissions, je vais voir, c'est vrai que je n'ai pas essayé d'écrire, juste étonné de pouvoir lire. Mais si c'est normal à la base...).
Maintenant pour les comptes, peut-être que je ne suis pas bien configuré.
Quand je vais dans les commandes "utilisateurs et groupes", j'ai en fait 3 choix : "Personnalisé, Administrateur, Utilisateur".
Quand j'installe xubuntu, je suis configuré sur Personnalisé, et ça marche comme ça, et quand j'ai besoin d'une action admin, je tape mon pass, jusqu'à présent ça marchait très bien, sauf pour sudo gedit. Après, je suppose que certains se créent un compte Admin, et ne l'utilisent qu'à bon escient, cela dit, en tant que Personnalisé, ce n'est pas spécialement dangereux dans ce sens que toute action qui engage des risques est soumise à l'entrée du pass Admin. Peut-être que je ne saisis pas toutes les nuances, je ne suis pas un pro !

GammaDraconis · Le 22/02/2018, à 17:26

De toute façon il ne faut pas faire comme ça !

utilise vim ou nano pour éditer ton fichier.

par exemple :

sudo vim /etc/hosts

et si tu ne sais pas te servir de vim :

sudo nano /etc/hosts

erresse · Le 22/02/2018, à 17:33

Mais même Gedit peut parfaitement faire l'affaire pour modifier un fichier du système, il faut juste le lancer CORRECTEMENT en mode administrateur : PAS "sudo gedit" qui risque de casser l'interface graphique, MAIS "gksudo gedit" qui va fonctionner parfaitement !

Roschan · Le 22/02/2018, à 17:53

erresse a écrit :

Mais même Gedit peut parfaitement faire l'affaire pour modifier un fichier du système, il faut juste le lancer CORRECTEMENT en mode administrateur : PAS "sudo gedit" qui risque de casser l'interface graphique, MAIS "gksudo gedit" qui va fonctionner parfaitement !

gksudo c'est la roue de secours pour les gens incapables d'utiliser nano, au cas où la modification "propre" via gedit admin://chemin n'existe pas pour la version donnée.

Mais il n'a pas indiqué sa version dans ses messages, et à en juger par sa signature sur le forum, il semblerait qu'il n'ait pas du tout une version compatible avec gedit admin:// (auquel cas pourquoi avoir essayé ? la documentation n'est pas assez claire quand elle indique explicitement qu'il faut une version datant d'au moins 2017 ?) donc il faut bel et bien faire sudo nano. Par défaut gksudo n'est pas installé, ce n'est pas par hasard.

Dernière modification par Roschan (Le 22/02/2018, à 17:55)

krodelabestiole · Le 22/02/2018, à 18:51

ça correspond à quoi cette notation admin:// ? c'est propre à gedit ? ou à wayland ?

Roschan · Le 22/02/2018, à 18:54

Non c'est un truc de GNOME, ça marche dans Gedit et Nautilus (même si d'expérience, ça fait de la merde dans Nautilus)

Dernière modification par Roschan (Le 22/02/2018, à 18:54)

bruno · Le 22/02/2018, à 19:24

Bonjour,

Pour modifier un fichier aussi simple, nano va très bien.
Par contre je suis encore un fois très surpris par les choix des développeurs GNOME. C'est quand même tordu et franchement pas pratique cette pseudo URL admin:// .
Avec KDE on ouvre un fichier avec kate, on modifie, et quand on veut enregistrer le mot de passe est demandé.

Roschan · Le 22/02/2018, à 19:46

Les URI des fichiers normaux sont file:///chemin/du/fichier donc je ne vois pas fondamentalement ce que ça change d'avoir admin:///chemin/du/fichier à la place.

Ce que fait GNOME est en tout cas nettement plus malin que ce que fait Kate : déjà c'est un système compatible avec Nautilus, alors que Dolphin reste incapable d'autoriser les manipulations de fichiers en admin, aussi ça évite les modifications non-désirées de la part de gens ne comprenant pas le système de permissions ("oh Kate me demande le mdp, je ne me pose pas de question et zou je le donne"), et surtout, ça permet de modifier les fichiers dont on n'a pas les droits de lecture.

L'aspect "pas malin" de GNOME, c'est d'avoir caché ce système, qui n'est pas vraiment documenté dans leur doc officielle ni mis en avant dans leurs release notes ; didrocks nous avait dit que c'est parce que ce n'est pas un système entièrement au point.

Foromus · Le 22/02/2018, à 21:27

Bon, c'est bien rigolo tout ça, mais ça surprend quand même.
J'avais un truc qui marchait bien avec sudo gedit, d'un coup, ça ne fonctionne plus, vu que c'est maintenant réservé à une version ultérieure. Et vu que je n'installe que les LTS, et vu que je ne modifie pas des fichiers système tous les quatre matins, alors forcément, je manque d’entraînement.
J'ai tenté une ouverture avec sudo vim /etc/hosts ... et je me suis fait bouler...
J'ai tenté une ouverture avec sudo nano /etc/hosts ... et mon fichier s'est bien ouvert !
Le plus beau, c'est que lors de ma tentative avec sudo gedit, j'avais, certes, obtenu un journal complet dans ma console, mais en plus, la modification avait quand même bien été enregistrée malgré tout, malgré les avertissements et les sommations de m'en remettre au politiquement correct. Et c'est bien lorsque j'ai ouvert avec nano que je m'en suis aperçu, je n'ai donc rien modifié avec cette commande. En clair, il est peut-être encore possible d'utiliser gedit, malgré les menaces, après tout, si le résultat souhaité est là.
Maintenant, je ne comprends pas trop le pourquoi et le comment de cette nouvelle évolution, en principe, les développeurs s'arrangent pour que les commandes relatives à une version soient efficaces tant qu'elle est supportée. Je sais bien qu'il y a des différences entre les distributions d'ubuntu, mais il est pourtant largement claironné que tel truc, bien que prévu sur telle distribution, est tout à fait opérationnel sur les autres.
Au passage, cette évolution m'inquiète tout de même, ainsi, j'utilise K3b pour la gravure, une application que j'apprécie vraiment, d'ici à ce qu'elle foire lamentablement au prochain besoin, j'en tremble d'avance et vit dès maintenant une peur dantesque qui pourrait bien altérer significativement ma pauvre santé déjà si fragile.
Comme pour l'instant, le problème est résolu - un peu par hasard d'ailleurs, il serait opportun que je passe en [Résolu].
Merci à tous pour votre collaboration et pour tous les renseignements que j'ai pu apprendre.

nam1962 · Le 22/02/2018, à 21:44

L'idée absconse de transformer une commande en un appel URL, qui plus est imbitable ( /// ), est presque digne de W$. J'adorerai savoir si Linus en est informé et si oui ce qu'il en pense !

Dernière modification par nam1962 (Le 22/02/2018, à 21:45)

Roschan · Le 22/02/2018, à 22:00

Foromus a écrit :

Bon, c'est bien rigolo tout ça, mais ça surprend quand même.
J'avais un truc qui marchait bien avec sudo gedit, d'un coup, ça ne fonctionne plus, vu que c'est maintenant réservé à une version ultérieure

Ce n'est réservé à rien du tout, ça n'a jamais été censé être une méthode sérieuse pour lancer un logiciel graphique. Ça fait des décennies que gksudo existe, justement pour fournir une solution pas trop crado.

Donc à moins que la version antérieure dont tu parles soit Ubuntu LTS 6.06 Dapper Drake, non, "sudo gedit" n'est réservé à rien d'autre que la poubelle.

Foromus a écrit :

Et vu que je n'installe que les LTS, et vu que je ne modifie pas des fichiers système tous les quatre matins, alors forcément, je manque d’entraînement.
J'ai tenté une ouverture avec sudo vim /etc/hosts ... et je me suis fait bouler...

Sauf erreur de ma part, vim n'est jamais installé par défaut, je ne sais pas pourquoi on te l'a conseillé.

Foromus a écrit :

J'ai tenté une ouverture avec sudo nano /etc/hosts ... et mon fichier s'est bien ouvert !
Le plus beau, c'est que lors de ma tentative avec sudo gedit, j'avais, certes, obtenu un journal complet dans ma console, mais en plus, la modification avait quand même bien été enregistrée malgré tout, malgré les avertissements et les sommations de m'en remettre au politiquement correct. Et c'est bien lorsque j'ai ouvert avec nano que je m'en suis aperçu, je n'ai donc rien modifié avec cette commande. En clair, il est peut-être encore possible d'utiliser gedit, malgré les menaces, après tout, si le résultat souhaité est là.

Résumé : le logiciel s'était bien lancé, tu avais enregistré les modifications, et tu n'as pas jugé utile de préciser le moindre de ces faits en ouvrant la discussion. Ok génial.

Ce ne sont pas de menaces, ce sont des instructions du code du logiciel qui ne peuvent pas s'exécuter correctement puisque le logiciel est lancé n'importe comment, et qui ont la gentillesse de te prévenir que tu fais n'importe quoi. Au mieux ça peut aboutir à un crash un jour ou l'autre, au pire ça fera buguer d'autres logiciels suite à des problèmes de corruption de permissions de fichiers. Mais puisque tu te sens subversif en faisant sudo gedit...

Foromus a écrit :

Maintenant, je ne comprends pas trop le pourquoi et le comment de cette nouvelle évolution, en principe, les développeurs s'arrangent pour que les commandes relatives à une version soient efficaces tant qu'elle est supportée.

Plutôt que d'invoquer le politiquement correct ou je ne sais quoi, il faudrait que tu lises un peu les choses.

Tu n'avais pas lu la documentation et tu as essayé la commande pour Ubuntu 17.10 sur Ubuntu 16.04, pour ensuite venir t'étonner que ça ne marche pas.
Tu n'as pas lu les 3 ou 4 fois où il a clairement été dit que "sudo gedit" n'a jamais recommandé nulle part, pour ensuite oser dire que c'est une commande "relative à une version" (laquelle ? 6.06 ?)
gksudo gedit est supporté sur 16.04 ; sudo nano est supporté par 16.04 ; ...

Donc de quelle commande te plains-tu ? De quelle "nouvelle évolution" parles-tu ?

Foromus a écrit :

Je sais bien qu'il y a des différences entre les distributions d'ubuntu, mais il est pourtant largement claironné que tel truc, bien que prévu sur telle distribution, est tout à fait opérationnel sur les autres.

Trouve une distribution qui prévoit explicitement de faire sudo gedit ? Une qui date de moins de 10 ans, bien sûr.

Même ce truc https://help.ubuntu.com/community/gedit qui date manifestement de bien avant 2010 préconise explicitement d'utiliser gksudo pour les applications graphiques au lieu de sudo.

Accessoirement, il n'a jamais été dit nulle part qu'Ubuntu se comporterait comme toutes les autres distributions, bien au contraire. Sur Fedora, celui qui ferait "sudo gedit" il n'aurait même pas la moindre fenêtre qui s'ouvre, alors si toutes les distributions devaient se comporter à l'identique, tu serais encore en train d'éditer ton fichier sur nano. Et sur Debian c'est carrément la commande sudo qui n'existe pas par défaut...

Foromus a écrit :

Au passage, cette évolution m'inquiète tout de même, ainsi, j'utilise K3b pour la gravure, une application que j'apprécie vraiment, d'ici à ce qu'elle foire lamentablement au prochain besoin, j'en tremble d'avance et vit dès maintenant une peur dantesque qui pourrait bien altérer significativement ma pauvre santé déjà si fragile.

Aucun rapport. Si ça t'intéresse de le savoir, K3b sera présent sans problème dans la prochaine version LTS.

Dernière modification par Roschan (Le 22/02/2018, à 22:21)

Roschan · Le 22/02/2018, à 22:12

nam1962 a écrit :

L'idée absconse de transformer une commande en un appel URL, qui plus est imbitable ( /// ), est presque digne de W$. J'adorerai savoir si Linus en est informé et si oui ce qu'il en pense !

Personne ne transforme une commande en un appel URL, déjà parce que ce sont URI, et ensuite parce que ce n'est pas la commande mais simplement le fichier qui est désigné par son URI. Et oui Torsvald est totalement informé que les fichiers s'identifient par leur URI, ça ne date pas d'hier http://manpagesfr.free.fr/man/man7/uri.7.html les développeurs de GNOME n'ont fait qu'étendre le format déjà appliqué de manière standard aux fichiers normaux.

bruno · Le 23/02/2018, à 09:17

Roschan a écrit :

Les URI des fichiers normaux sont file:///chemin/du/fichier donc je ne vois pas fondamentalement ce que ça change d'avoir admin:///chemin/du/fichier à la place.

Justement ce n'est pas un URI standard. admin:// n'est pas un protocole, et je trouve cela contre intuitif de l'utiliser comme protocole… (alors que l'usage de psudo protocoles comme network://, mtp://, etc. me semble tout à fait évident)

Roschan a écrit :

Ce que fait GNOME est en tout cas nettement plus malin que ce que fait Kate : déjà c'est un système compatible avec Nautilus, alors que Dolphin reste incapable d'autoriser les manipulations de fichiers en admin, aussi ça évite les modifications non-désirées de la part de gens ne comprenant pas le système de permissions ("oh Kate me demande le mdp, je ne me pose pas de question et zou je le donne"), et surtout, ça permet de modifier les fichiers dont on n'a pas les droits de lecture.

Ah, GNOME est compatible avec son propre gestionnaire de fichiers, c'est une bonne nouvelle
Heureusement que Dolphin n'autorise pas les manipulations de fichiers en tant que "root", j'ose espérer que c'est la me chose pour les autres gestionnaires de fichiers !
On ne peut pas ouvrir un fichier dont on a pas le droit en lecture, jamais. C'est le principe même des droits UNIX.

Roschan a écrit :

L'aspect "pas malin" de GNOME, c'est d'avoir caché ce système, qui n'est pas vraiment documenté dans leur doc officielle ni mis en avant dans leurs release notes ; didrocks nous avait dit que c'est parce que ce n'est pas un système entièrement au point.

Au final, on est donc d'accord
KDE a fait un choix simple : lorsqu'on modifie avec l'éditeur graphique un fichier dont a pas les droits en écriture, le mot de passe pour l'enregistrer en tant que root est demandé. Si l'utilisateur peut le faire c'est qu'il est administrateur du système.
GNOME a choisi d'empêcher de la faire par des moyens simples et de le permettre par une obscure commande plus ou mois cachée.
D'un point de vue de la sécurité cela ne change strictement rien, c'est juste de la sécurité par l'obscurité.

nam1962 · Le 23/02/2018, à 09:27

Alors, merci Roschan pour m'avoir appris des trucs
Côté UX, je reste sur la longueur d'ondes de bruno : utiliser une méthode et sa syntaxe si différente de l'usage ne va pas aider l'utilisateur de base même de bonne volonté !

krodelabestiole · Le 23/02/2018, à 15:53

sur un os grand public bien foutu, l'utilisateur de base ne devrait pas avoir besoin de se servir de la ligne de commande.

GammaDraconis · Le 23/02/2018, à 16:05

krodelabestiole a écrit :

sur un os grand public bien foutu, l'utilisateur de base ne devrait pas avoir besoin de se servir de la ligne de commande.

Sauf que la ligne de commande est plus rapide que par l'interface graphique pour certains cas !
Donc même pour un débutant, il faut utiliser un minimum le terminal pour gagner en rapidité.

Après oui il est possible de se passer totalement du terminal mais ça sera au finale moins rapide.

Et pour info, un débutant n'est pas censé modifier son fichier hosts, c'est un travail d'adminstrateur.

erresse · Le 23/02/2018, à 16:08

krodelabestiole a écrit :

sur un os grand public bien foutu, l'utilisateur de base ne devrait pas avoir besoin de se servir de la ligne de commande.

Ben, c'est bien le cas... L'utilisateur "de base" sous Ubuntu ou autre variante n'a pas à utiliser la ligne de commande, il lui suffit de sa souris comme sous un bête Windows pour faire tout ce qu'il est autorisé à faire !
Par contre, l'administrateur, lui, en a besoin de la ligne de commande, et même s'il est assez compétent pour assimiler les trucs tordus (et ce n'est pas ce qui manque en informatique, grand public ou pas), je conçois mal l'intérêt qu'il y a à lui compliquer la vie inutilement...

krodelabestiole · Le 23/02/2018, à 16:21

je maintiens ce que je dis, et j'ajouterais même que l'utilisateur de base ne devrait pas avoir besoin de consulter la documentation.
ni évidemment besoin de modifier manuellement des fichiers du système.

je parle de besoin, l'optimisation et la recherche de la performance c'est le domaine de l'utilisateur avancé. c'est très bien que ce soit disponible mais ça ne doit pas être nécessaire : l'usage de la ligne de commande n'est pas et ne sera jamais quelque chose d'intuitif.

krodelabestiole · Le 23/02/2018, à 16:29

erresse a écrit :

je conçois mal l'intérêt qu'il y a à lui compliquer la vie inutilement...

sauf que c'est rarement inutile : la sécurité informatique nécessite malheureusement une complexification des usages. c'est le cas ici : d'après ce que je comprends le problème est lié à la plus grand sécurité de wayland par rapport à X.org.

krodelabestiole · Le 23/02/2018, à 16:50

nam1962 a écrit :

utiliser une méthode et sa syntaxe si différente de l'usage ne va pas aider l'utilisateur de base même de bonne volonté !

pour rappel je répondais à ça.

pour le reste de mon point de vue des distros comme ubuntu ou solus font très bien leur taf pour le grand public.

nam1962 · Le 23/02/2018, à 16:56

Pas confondre utilisateur basique (pour lequel, à part dans un fil d'aide je te rejoins : pas besoin de ligne de commande) et l'utilisateur de base (je m'inclus dedans) qui n'est ni dev, ni gestionnaire de système, mais qui cherche à adapter son système. Compliquer les méthodes et syntaxes n'est pas génial, génial.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 22/02/2018, à 15:51

[Résolu] sudo gedit réagit mal...

#2 Le 22/02/2018, à 15:52

Re : [Résolu] sudo gedit réagit mal...

#3 Le 22/02/2018, à 16:05

Re : [Résolu] sudo gedit réagit mal...

#4 Le 22/02/2018, à 16:41

Re : [Résolu] sudo gedit réagit mal...

#5 Le 22/02/2018, à 17:22

Re : [Résolu] sudo gedit réagit mal...

#6 Le 22/02/2018, à 17:26

Re : [Résolu] sudo gedit réagit mal...

#7 Le 22/02/2018, à 17:33

Re : [Résolu] sudo gedit réagit mal...

#8 Le 22/02/2018, à 17:53

Re : [Résolu] sudo gedit réagit mal...

#9 Le 22/02/2018, à 18:51

Re : [Résolu] sudo gedit réagit mal...

#10 Le 22/02/2018, à 18:54

Re : [Résolu] sudo gedit réagit mal...

#11 Le 22/02/2018, à 19:24

Re : [Résolu] sudo gedit réagit mal...

#12 Le 22/02/2018, à 19:46

Re : [Résolu] sudo gedit réagit mal...

#13 Le 22/02/2018, à 21:27

Re : [Résolu] sudo gedit réagit mal...

#14 Le 22/02/2018, à 21:44

Re : [Résolu] sudo gedit réagit mal...

#15 Le 22/02/2018, à 22:00

Re : [Résolu] sudo gedit réagit mal...

#16 Le 22/02/2018, à 22:12

Re : [Résolu] sudo gedit réagit mal...

#17 Le 23/02/2018, à 09:17

Re : [Résolu] sudo gedit réagit mal...

#18 Le 23/02/2018, à 09:27

Re : [Résolu] sudo gedit réagit mal...

#19 Le 23/02/2018, à 15:53

Re : [Résolu] sudo gedit réagit mal...

#20 Le 23/02/2018, à 16:05

Re : [Résolu] sudo gedit réagit mal...

#21 Le 23/02/2018, à 16:08

Re : [Résolu] sudo gedit réagit mal...

#22 Le 23/02/2018, à 16:21

Re : [Résolu] sudo gedit réagit mal...

#23 Le 23/02/2018, à 16:29

Re : [Résolu] sudo gedit réagit mal...

#24 Le 23/02/2018, à 16:50

Re : [Résolu] sudo gedit réagit mal...

#25 Le 23/02/2018, à 16:56

Re : [Résolu] sudo gedit réagit mal...

Pied de page des forums