Comment propager des erreurs par l'intermédiaire de la doc…

cqfd93 · Le 13/12/2023, à 15:50

Bonjour,

En recherchant ce que la doc contient comme informations pour lancer un éditeur de texte (en l'occurrence gedit) en mode administrateur, je suis tombée sur cette page : https://doc.ubuntu-fr.org/tutoriel/comm … un_fichier.

En bas de cette page, on trouve un lien externe (pas vers la doc) vers un tuto vidéo qui date de 2010 et qui m'a hérissé le poil :
Tutoriel vidéo : Éditer des fichiers en mode administrateur sur Ubuntu (fr)

En plus de montrer l'utilisation de gksudo gedit (obsolète) et surtout sudo gedit (absolument déconseillé), il utilise la bannière ubuntu ce qui peut tromper les utilisateurs qui lui feraient confiance.

Je vais donc supprimer ce lien de la page en question.

xubu1957 · Le 13/12/2023, à 15:57

Bonjour,

C'était un rajout de juillet 2010 :

Le 24/07/2010, 11:33 Différences avec la version actuelle tutoriel:comment_modifier_un_fichier – ajout d'un tutoriel video dans la partie sur gnome Madrzejewski

et dans sa page tutoriels-video.fr/editer-un-fichier-en-mode-administrateur-sur-ubuntu/

3eme méthodes (la plus compliquée) : Jusqu’ici on a utilisé gedit qui est un logiciel en mode graphique, c’est-à-dire qu’il possède une interface et qu’il se lance dans une fenêtre indépendante. Or, parfois il arrive qu’on n’est pas accès à ce genre de logiciel et qu’on soit obligé de travailler en mode console, via le terminal. C’est le cas par exemple, lorsqu’on administre des serveurs ou ce genre de choses.
La dernière méthode utilise un autre logiciel qui s’appelle « nano » et qui est légèrement plus compliqué à utiliser puisque tout se lance en mode console, dans le terminal. Les commandes à taper sont identiques sauf qu’on remplace « gedit » par « nano ». ...

Dernière modification par xubu1957 (Le 13/12/2023, à 16:02)

jplemoine · Le 13/12/2023, à 16:20

Et si tu es sur un serveur où nano n'est pas installé (par exemple, une red hat from scratch), il ne reste plus que le seul éditeur de texte que tu trouveras sur toutes les distributions Linux : vi
Et là, si tu ne t'es pas entraîné(e) avant, c'est 2 doses de paracétamol + 1 (forte) dose de xanax.

Et au fait, c'est quoi la bonne méthode pour éditer un fichier sous gedit et les droits root ?

xubu1957 · Le 13/12/2023, à 16:29

Le 16/11/2021, nany a écrit :

JAMAIS de sudo gedit, malheureux !
gedit admin:///chemin/absolu/vers/fichier
J’ai édité mon message précédent (...) pour mettre un lien vers une page de la doc.
_ _ _
D’une manière générale, il ne faut pas lancer d’applications graphiques avec sudo sous peine de changements possibles de la propriété de certains fichiers dans le home.
Il faut utiliser pkexec (policykit §4) ou, avec gedit par exemple, le chemin canonique comme dans la page que j’ai mise en lien dans mon précédent message.

dans RESOLU - Scanner epson perfection V30 reconnu mais ne communique pas

Dernière modification par xubu1957 (Le 13/12/2023, à 16:32)

nany · Le 13/12/2023, à 16:33

Bonjour,

On peut aussi faire :

VISUAL=gedit sudoedit /chemin/fichier

Ou dorénavant :

VISUAL=gted sudoedit /chemin/fichier

[edit]
Pour être un peu plus clair sur la question : https://askubuntu.com/questions/1162608 … -with-sudo.
Traduction pour les anglophobes : https://stackovercoder.fr/ubuntu/116260 … -with-sudo.
[/edit]

Dernière modification par nany (Le 13/12/2023, à 16:55)

erresse · Le 13/12/2023, à 16:44

Ne soyons pas restrictifs ou sectaires, chaque variante de *buntu ayant son propre éditeur de textes graphique, quelle méthode est-elle à péconiser comme universelle pour éditer ses fichiers en mode "root" avec son éditeur graphique ?
Est-ce que :

<mon_éditeur> admin:///chemin/absolu/vers/fichier

fonctionne même si ce n'est pas avec "gedit" ?
Est-ce mieux (plus universel) d'ouvrir son éditeur avec :

pkexec <mon_éditeur> /chemin/absolu/vers/fichier

Autre chose encore ???

nany · Le 13/12/2023, à 16:46

erresse a écrit :

Autre chose encore ???

VISUAL=<mon_éditeur> sudoedit /chemin/fichier

?

ylag · Le 13/12/2023, à 17:33

Bonjour,

Concernant l'utilisation d'un éditeur de fichier en mode graphique tel que Gedit avec les droits root, on pourrait peut-être tenter une bidouille de ce genre :

sudo chown $USER: /chemin/vers/fichier

gedit /chemin/vers/fichier

... on réassigne le fichier à root une fois la modification enregistrée :

sudo chown root: /chemin/vers/fichier

il faut que l'utilisateur ait les permissions en lecture/écriture sur le fichier concerné.
... ?

A+

Dernière modification par ylag (Le 13/12/2023, à 17:38)

geole · Le 13/12/2023, à 17:41

Bonjour
Cela me semble beaucoup plus simple de faire un copier coller de la ligne de commande suivante

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/NomDuFichier

qui semble être celle conseillée en attendant la fourniture d'un alias correctement réfléchi qui ne viendra certainement jamais.

Dernière modification par geole (Le 13/12/2023, à 17:43)

ylag · Le 13/12/2023, à 19:46

geole a écrit :

Bonjour
Cela me semble beaucoup plus simple de faire un copier coller de la ligne de commande suivante
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/NomDuFichier
qui semble être celle conseillée en attendant la fourniture d'un alias correctement réfléchi qui ne viendra certainement jamais.

La commande fonctionne-t-elle dans une session Wayland ?
Impossible pour moi de le tester, pour cause de vieille machine incompatible avec Wayland ...

Pour les utilisateurs de Nautilus, il y a le paquet nautilus-admin, toujours présent dans les dépôts officiels, proposant au clic de droite l'ouverture d'un fichier en mode administrateur ; si ma mémoire est bonne, ça utilse une commande du genre de :

gedit admin///chemin/vers/fichier

A+

Dernière modification par ylag (Le 13/12/2023, à 19:49)

nany · Le 13/12/2023, à 19:49

Comme l’a fait remarquer bruno dans le fil dans l’éphémère, on ne peut pas faire confiance totalement en xdg-open.

Je viens de tester dans toutes les variantes officielles en 22.04 (sauf Kylin) ma proposition du message #7 et ça fonctionne partout. Le seul truc est qu’il faut connaître le nom de l’éditeur de texte graphique de la variante.

ylag · Le 13/12/2023, à 19:53

@nany :

Bonjour,

Avez-vous vérifié quelle était la ligne de commande générée pour l'ouverture du fichier ?

A+

Dernière modification par ylag (Le 13/12/2023, à 19:53)

nany · Le 13/12/2023, à 19:58

ylag a écrit :

geole a écrit :
Bonjour
Cela me semble beaucoup plus simple de faire un copier coller de la ligne de commande suivante
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/NomDuFichier
qui semble être celle conseillée en attendant la fourniture d'un alias correctement réfléchi qui ne viendra certainement jamais.
La commande fonctionne-t-elle dans une session Wayland ?
Impossible pour moi de le tester, pour cause de vieille machine incompatible avec Wayland ...

Ça fonctionne avec des alertes :

~$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab

(gedit:16993): dconf-WARNING **: 18:51:08.023: failed to commit changes to dconf: L’exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)

(gedit:16993): dconf-WARNING **: 18:51:08.028: failed to commit changes to dconf: L’exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)

(gedit:16993): dconf-WARNING **: 18:51:08.273: failed to commit changes to dconf: L’exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)

(gedit:16993): dconf-WARNING **: 18:51:08.274: failed to commit changes to dconf: L’exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)

(gedit:16993): dconf-WARNING **: 18:51:08.274: failed to commit changes to dconf: L’exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)

** (gedit:16993): WARNING **: 18:51:16.772: Set document metadata failed: La définition de l’attribut metadata::gedit-position n’est pas prise en charge

(gedit:16993): dconf-WARNING **: 18:51:16.800: failed to commit changes to dconf: L’exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)
~$

Mais au fait, pourquoi le répertoire /etc ? Les autres répertoires systèmes sont aussi valables.

ylag · Le 13/12/2023, à 22:38

Bonsoir,

Quelle serait la valeur de la variable XAUTHORITY pour l'utilisateur (id >= 1000) dans une session Wayland :

echo $XAUTHORITY

Désolé si je suis un peu hors-sujet ...
Merci d'avance à qui pourra éclairer ma lanterne.

A+

geole · Le 14/12/2023, à 00:14

nany a écrit :

Comme l’a fait remarquer bruno dans le fil dans l’éphémère, on ne peut pas faire confiance totalement en xdg-open.
Je viens de tester dans toutes les variantes officielles en 22.04 (sauf Kylin) ma proposition du message #7 et ça fonctionne partout. Le seul truc est qu’il faut connaître le nom de l’éditeur de texte graphique de la variante.

A mon avis, Nano est moins pratique que gedit.
Je viens de récupérer un message posté dans une discussion éphémère.
"Merci pour la précision.
Dans mon environnement xdg-open utilise "editeur de texte" (gedit) lorsque le fichier a une terminaison .txt et libreoffice lorsque le fichier a une terminaison .doc
J'ignorais qu'on pouvait le remplacer par une application inadaptée au format texte en écriture.
et editor utilise nano.
Finalement il n'y a rien de simple"

Dernière modification par geole (Le 14/12/2023, à 00:15)

jplemoine · Le 14/12/2023, à 00:22

nano et gedit n'ont rien à voir... L'un est graphique, l'autre en mode console...
Et franchement, je préfère largement nano que vi ou vim.
Mais comme je l'ai dit précédemment, vi est le seul qui soit installé de base sur toutes les distributions.

alex2423 · Le 14/12/2023, à 00:46

jplemoine a écrit :

nano et gedit n'ont rien à voir... L'un est graphique, l'autre en mode console...
Et franchement, je préfère largement nano que vi ou vim.
Mais comme je l'ai dit précédemment, vi est le seul qui soit installé de base sur toutes les distributions.

nano n'est pas installable sur les distrib à base Red Hat et Arch ?

Pour ma part, par habitude, j'ai une nette préférence pour vim si je n'ai pas d'interface.

jplemoine · Le 14/12/2023, à 01:18

Quand tu as un serveur Red Hat serveur dans un sous-réseau sans DHCP, il faut au moins mettre les paramètres réseaux avec l'installation de base.
Et tu n'as droit qu'à vi (à moins que ça est changé sur les versions récentes).
Une fois le réseau ok, tu peux peut-être installer nano ou vim (je ne souviens plus).

nany · Le 14/12/2023, à 09:09

Bonjour,

ylag a écrit :

Quelle serait la valeur de la variable XAUTHORITY pour l'utilisateur (id >= 1000) dans une session Wayland :
echo $XAUTHORITY
Désolé si je suis un peu hors-sujet ...
Merci d'avance à qui pourra éclairer ma lanterne.

~$ echo "$XAUTHORITY"
/run/user/1000/.mutter-Xwaylandauth.R8SKF2
~$

bruno · Le 14/12/2023, à 09:36

Je ne vais pas revenir en détail sur chaque commande proposée, mais il n'y a rien qui ne sera jamais universel avec les éditeurs en mode graphique. Bon nombre de solution données ne fonctionne que dans environnement GNOME d'Ubuntu. Cela ne fonctionne pas sous KDE, où ces trucs alambiqués sont de toute façon inutiles
Les commandes données doivent donc être accompagnées du contexte : « avec Ubuntu GNOME », par exemple.

La seule commende qui fonctionnera a peu près partout en mode textuel c'est :

sudo editor /fichier/a/modifier

ou l'équivalent donné en #7 par nany.

J'ai déjà dit que xdg-open était piégeux.
pkexec l'est également. Ce n'est qu'une alternative à su / sudo qui utilise polkit. Je ne vais pas rentrer dans les détails mais :

$ pkexec env
SHELL=/bin/bash
LANG=fr_FR.UTF-8
LANGUAGE=fr
TERM=xterm-256color
COLORTERM=truecolor
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
LOGNAME=root
USER=root
HOME=/root
PKEXEC_UID=1000

et

man xdg-open a écrit :

xdg-open is for use inside a desktop session only. It is not recommended to use xdg-open as root.

Donc AMHA cette commande est valable en spécifiant l'éditeur à utiliser mais pas avec xdg-open.

Dernière modification par bruno (Le 14/12/2023, à 10:24)

bruno · Le 14/12/2023, à 10:11

Ah tiens en naviguant dans les pages de docs et en faisant quelques corrections, je suis tombé la-dessus :
https://doc.ubuntu-fr.org/tutoriel/chan … tilisateur
Avec au point 2.2 :

doc ubuntu-fr a écrit :

L'association entre type de fichier et logiciel à utiliser est définie dans le fichier /usr/share/applications/defaults.list qu'il vous faut éditer avec les droits d'administrateur.

Je pense qu'il ne faut jamais modifier les fichiers installés par les paquets Ubuntu sous /usr. C'est dangereux, cela peut bloquer une mise à jour et cela va être écrasé à coup sûr lors d'une mise à jour.
Surtout que dans le cas présent il y a des fichiers sous /etc pour faire cela :
https://help.gnome.org/admin/system-adm … on.html.en
et contrairement à ce qui est dit dans la suite de la doc ce n'est pas un lien symbolique vers /etc/gnome/defaults.list.

Je n'ai pas de machine avec GNOME installé sous la main pour vérifier où cela se règle exactement. La doc GNOME conseille de créer le fichier /etc/xdg/mimeapps.list pour surcharger la configuration par défaut. Je vous laisse donc aller corriger cette doc, qui aurait besoin d'un bon rafraîchissement global . Merci d'avance.

Dernière modification par bruno (Le 14/12/2023, à 10:12)

geole · Le 14/12/2023, à 11:35

Bonjour.
Je voudrais simplement préciser que si on propose la commande vi à utilisateur qui vient demander de l'aide, c'est l'inciter à fuir cette distribution.
Je pense d'ailleurs que c'est pareil avec la commande nano ( ou editor qui lance nano) qu'il faut réserver à une utilisation en mode recovery pour modifier des fichiers système.

En attendant, pour éviter de proposer illégallement mais sans danger la commande "sudo gedit" pour l'accés à des fichiers existants interdits d'écriture à l'utilisateur, je me suis astreins à mettre dans ma signature la commande à proposer.
Si vous indiquez que celle-ci ne vaut rien non plus... cela devient très compliqué de pas faire de bourde.

Je ne vois pourquoi les commandes qu'on propose devraient être compatibles red hat serveur.

Nota. Je vais certainement ouvrir une discussion sur l'application GnomeTextEDitor.
Sur trois points.
a) Comment déactiver le controle de l'orthographe française. L'idéal serait de lui apprendre à reconnaitre la langue du document.
b) Comment indiquer plus discrétement les mots qui sont mal orthographiés.
c) Comment indiquer moins discrètement les mots dont on a demandé la recherche.

Dernière modification par geole (Le 14/12/2023, à 11:40)

bruno · Le 14/12/2023, à 11:57

Je n'ai pas dit que cette commande ne vaut rien.

Je dis qu'il faut remplacer :

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab

par

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit /etc/fstab

parce que le comportement de xdg-open est imprévisible et qu'il ne doit pas être utilisé en root.

Ex:

[bruno@aboulafia:~]$ pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab
Warning: unknown mime-type for "/etc/fstab" -- using "application/octet-stream"
Error: no "view" mailcap rules found for type "application/octet-stream"
Opening "/etc/fstab" with LibreOffice Writer  (text/plain)

--

geole a écrit :

Je ne vois pourquoi les commandes qu'on propose devraient être compatibles red hat serveur.

Le message auquel tu fais référence était pour moi totalement hors-sujet. Ici on parle de modifier en mode graphique un fichier de configuration appartenant à root.
Accessoirement un administrateur système connaît au moins les commandes basiques de vi

Dernière modification par bruno (Le 14/12/2023, à 12:01)

Astrolivier · Le 14/12/2023, à 12:17

salut,

la méthode la plus propre à mon avis pour les débutants (édition de fichiers sys)

## leur fournir le fichier dans les balises codes ##

copier/coller/enregister sous un nom en graphique

sudo cp ~/Document/leFichierEnQuestion /etc/truc/leFichierEnQuestion

sudo chown root /etc/truc/leFichierEnQuestion

sudo chmod 644 /etc/truc/leFichierEnQuestion

(on adapte au cas)
c'est pour moi la meilleure école même si copier 4 lignes peut être impressionnant au début. Même un débutant doit comprendre le principe de ces 4 lignes

après les gens sont pas con et ont le droit de tenter sudo editeurGraph si ça leur chante. normalement on comprend vite que si toutes les distro font chier autant qu'elles peuvent (plus les warning des forums/ blogs) pour editer un fichier root en graphique, c'est pas juste pour le plaisir de faire chier.

après nano est une bonne solution qui permet de ne pas avoir à s'étendre. ceux qui installent un serveur sans nano doivent bien trouver comment on fait un :!q. vi c'est chiant quand on l'utilise jamais, mais c'est quand même le standard

Dernière modification par Astrolivier (Le 14/12/2023, à 12:19)

jplemoine · Le 14/12/2023, à 12:26

geole a écrit :

Je ne vois pourquoi les commandes qu'on propose devraient être compatibles red hat serveur.

C'est moi qui est parlé de red hat pour juste dire que nano n'est pas systématique au contraire de vi.
Après l'un ou l'autre ne sont que des éditeurs de texte en mode console.

Donc, pour l'utilisateur courant, ce n'est pas ce qu'il va utiliser le plus.
Perso, j'ai installé gedit sur xubuntu.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/12/2023, à 15:50

Comment propager des erreurs par l'intermédiaire de la doc…

#2 Le 13/12/2023, à 15:57

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#3 Le 13/12/2023, à 16:20

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#4 Le 13/12/2023, à 16:29

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#5 Le 13/12/2023, à 16:33

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#6 Le 13/12/2023, à 16:44

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#7 Le 13/12/2023, à 16:46

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#8 Le 13/12/2023, à 17:33

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#9 Le 13/12/2023, à 17:41

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#10 Le 13/12/2023, à 19:46

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#11 Le 13/12/2023, à 19:49

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#12 Le 13/12/2023, à 19:53

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#13 Le 13/12/2023, à 19:58

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#14 Le 13/12/2023, à 22:38

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#15 Le 14/12/2023, à 00:14

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#16 Le 14/12/2023, à 00:22

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#17 Le 14/12/2023, à 00:46

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#18 Le 14/12/2023, à 01:18

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#19 Le 14/12/2023, à 09:09

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#20 Le 14/12/2023, à 09:36

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#21 Le 14/12/2023, à 10:11

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#22 Le 14/12/2023, à 11:35

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#23 Le 14/12/2023, à 11:57

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#24 Le 14/12/2023, à 12:17

Re : Comment propager des erreurs par l'intermédiaire de la doc…

#25 Le 14/12/2023, à 12:26

Re : Comment propager des erreurs par l'intermédiaire de la doc…

Pied de page des forums