Bonjour à tous,
Mon problème est dans le titre du post : kedit: cannot connect to X server
J’obtiens donc ce message lorsque je lance KEDIT en mode console…
Une idée?
ma distrib : Linux debian 2.6.18-4-686
Merci à tous.
c’est certain, c’est une logiciel qui vient avec KDE…donc tu peux pas faire ça si tu est en console…
Sert toi de vi ou de nano 
Au fait. as-tu un environnement graphique et surtout, as-tu essayé cette commande en étant loggué en root par hassard ?
Ah bon!
J’ai sûrement un ordinateur un peu spécial. :p!
Il n’y a pas de raison, chez moi j’arrive à lancer iceweasel depuis ma console, ainsi que emacs et même openoffice ou mon lecteur de video.
Je pense que c’est lié au fait qu’il soit en root quand il le fait.
[quote=“d2_racing”]c’est certain, c’est une logiciel qui vient avec KDE…donc tu peux pas faire ça si tu est en console…
[/quote]
qui te dis qu’il n’a pas KDE ?
kedit fonctionne parfaitement en user ou en tant que root, tout au moins, s’il est installé. 
Y’a le vrai mode console (ALT+CTRL+F1), et les consoles genre gnome-terminal qu’on lance en étant sous X.
On ne peut pas lancer une appli qui a besoin de X s’il n’est pas lancé, et ça peut arriver aussi à cause des mécanismes (du genre xhost) qui interdisent à d’autres utilisateurs de squatter la session X.
[quote=“ricardo”]
kedit fonctionne parfaitement en user ou en tant que root, tout au moins, s’il est installé. [/quote]
Le lancement d’une application graphique depuis une console (pas les ttyx), ce fait sans problème pour l’utilisateur, car c’est son environnement graphique. Cependant, pour root, c’est pas aussi simple. C’est certains que si tu installes toute la suite kde ou gnome, il y a peu de chances d’avoir des problèmes.
Sur ma machine (fluxbox), il m’était impossible de lancer une application graphique depuis une console en tant que root car ce dernier n’avait pas le droit.
J’ai trouvé une parade, mais c’est un peu obscure encore :
et pas très sécurisé.
Bon, j’ai trouvé la solution à xhost +.
Je n’explique pas, tout est dans le lien :
Cela se trouve dans la section How do I run an X client as root when the X session is run by a user?
Je vais enfin pouvoir lancer mon petit wireshark en root 
PS : si quelqu’un trouve la doc sur le système Debian je veux bien.
en principe, on ne doit presque jamais se servir de root sauf pour installer / désinstaller.
pour ce qui est de ce que l’on appelle “console”, c’est en graphique.
si on parle de ce que l’on tape en dehors d’x, il faut dire “mode texte” pour ne pas mélanger le smilblick.
D’après le manuel de référence Debian, on parle bel et bien de console ou pseudo-terminaux pour le mode texte.
http://www.debian.org/doc/manuals/reference/ch-tutorial.fr.html#s-sw-console
Mais il faudrait dire console virtuelle pour ne pas s’emmeler les pinceaux.
sujet traité 200 fois merci de bien vouloir chercher:
[code]console@MAT64LIN:~$ aptitude show sudo sux
Package: sudo
State: installed
Automatically installed: no
Version: 1.6.8p12-4
Priority: optional
Section: admin
Maintainer: Bdale Garbee bdale@gag.com
Uncompressed Size: 426k
Depends: libc6 (>= 2.3.5-1), libpam0g (>= 0.76), libpam-modules
Conflicts: sudo-ldap
Replaces: sudo-ldap
Provided by: sudo-ldap
Description: Provide limited super user privileges to specific users
Sudo is a program designed to allow a sysadmin to give limited root privileges to users and log root activity. The basic
philosophy is to give as few privileges as possible but still allow people to get their work done.
This version is built with minimal shared library dependencies, use the sudo-ldap package instead if you need LDAP support.
Tags: admin::login, admin::user-management, interface::commandline, role::program, scope::utility, security::authentication,
special::completely-tagged, use::login, use::monitor
Package: sux
State: not installed
Version: 1.0.1-3.2
Priority: optional
Section: admin
Maintainer: Millis Miller millis@faztek.org
Uncompressed Size: 65.5k
Recommends: xbase-clients
Description: wrapper around su which will transfer your X credentials
Sux is a wrapper around the standard su command which will transfer your X credentials to the target user.
http://sourceforge.net/projects/sux/ ( from http://fgouget.free.fr/sux/ )
Tags: admin::login, interface::commandline, security::authentication, use::login, x11::application
[/code]
Et bien pour le problème initial, on ne connait pas les conditions de l’erreur, donc ce n’est pas forcément réglé.
Pour mon cas, aucun rapport avec sudo vu que je ne l’utilise pas !
U talkin’ 2 me ?
Peut être pas règlé ici, mais règlé dans 200 autres fils.
[quote=“thialme”]Pour mon cas, aucun rapport avec sudo vu que je ne l’utilise pas ![/quote]Tu fais comme tu veux si tu as une meilleurs solution, tu la donnes (celle du lien n’est pas utilisable si tu dois aller modifier le cookie chaque fois que tu ouvres une session), et la solution en xhost est ultra à déconseiller pour des raisons de sécurité.
Maintenant, si tu ne veux pas utiliser sudo, c’est quand même la méthode AMA la plus simple avec sux (mais qui est moins généralement utile que sudo) pour accèder en root au serveur X d’un user.
U talkin’ 2 me ??
[quote=“usinagaz”]… le tout n’étant possible qu’en lançant à l’ouverture de session X la commande:
Où user est mon user habituel.
ps: j’attend d’éventuelles remarques avant de mettre en résolu.[/quote]
J’attends toujours qu’on m’explique 
si ça c’est dangereux …
PS: attention abdmaa, c’est parrallèle mais ça ne concerne pas ton problème … donc ne lance pas cette commande.
U talkin’ 2 me ?
Peut être pas règlé ici, mais règlé dans 200 autres fils.
[/quote]
Of course, as you have very well understood, I am talking to you and please, stop showing up. If you want us to have a little chat in English, there is no matter for me.
Pour ma part le problème initial n’est pas clair car on ne sait rien, mais peut-être as tu raison tout de même.
[quote=“mattotop”][quote=“thialme”]Pour mon cas, aucun rapport avec sudo vu que je ne l’utilise pas ![/quote]Tu fais comme tu veux si tu as une meilleurs solution, tu la donnes (celle du lien n’est pas utilisable si tu dois aller modifier le cookie chaque fois que tu ouvres une session), et la solution en xhost est ultra à déconseiller pour des raisons de sécurité.
Maintenant, si tu ne veux pas utiliser sudo, c’est quand même la méthode AMA la plus simple avec sux (mais qui est moins généralement utile que sudo) pour accèder en root au serveur X d’un user.[/quote]
Tu déformes mes propos, je n’ai jamais dit que j’avais une meilleure solution. J’ai simplement dit que j’utilisais su et non pas sudo, et c’est à mes risques et périls, c’est tout.
C’est bien rare que je mette un lien que je n’ai pas personnellement testé, dans le cas contraire je le mentionne explicitement, normalement !
La méthode qui fonctionne tout le temps en utilisant su, sans avoir à revenir dessus en permanence, consiste à remplacer le fichier .Xauthority de root par un lien symbolique sur le .XAuthority du user qui détient la session courante de X. C’est facile comme je n’ai qu’un seul utilisateur qu’il a le droit de devenir root sur mon serveur. Il y a sûrement d’autres méthodes, mais c’est celle là que j’ai choisie, et cela fonctionne parfaitement.
Quant à l’utilisation de
je l’utilisais comme rustine, et je sais que ce n’est pas conseillé, c’est pour celà que j’ai trouvé une autre méthode, pour éviter à tout le monde d’afficher des messages sur ma session X courante.