Bonsoir à tous,
 
J'aimerais faire apparaitre un message à l'écran de l'utilisateur KDE en cours à un moment défini. (le but étant de le prévenir que dans 5 minutes on ferme ; histoire qu'il commence à plier bagage )
 
Pour le problème du quand, avec cron, c'est très simple, mais je ne vois pas comment faire apparaitre un message à l'écran... (avec Windows j'aurais par exemple programmé un net send)
 
Une idée ?
Merci

salut,
moi j'utilise kdialog pour mes affichages

zenity, xmessage, xdialog, ...

avec kdialog, j'ai "cannot connect to X server"
avec xmessage, j'ai "Can't open display:"
 
(Je me connecte en telnet sur les machines pour tester)

Normal tu n'as pas de session associée à ton utilisateur et donc le logiciel ne sait pas où envoyer ta requête.
Tu as surement un moyen de déporter ton dialog sur une session déjà en cours pour tester.

mais comment ? ...
 
--edit--
 
En googlant un peu j'ai trouvé qu'il fallait ajouter -display 127.0.0.1:0.0 (pour xmessage)... mais ça marche pas (Can't open display: 127.0.0.1:0.0)

si t'es sous debian et que root envoie le message aux utilisateurs, il faut d'abord débloquer le display, l'utilisateur doit donc avoir dans son fichier d'initiation de session graphique quelque chose du genre

Merci pour ton aide, c'est en effet lié à xhost. Je touche au but
 
Si je me mets sur l'ordi et que je tape xhost + (ça désactive le blocage d'affichage de fenêtre à distance) et donc après cela, ça marche. J'ai donc ajouté xhost + à mon script (appellé par cron), mais ça ne marche pas... xhost + doit être lancé directement sur la machine (à distance, ça marche pas)

tout à fait, c'est l'utilisateur local qui doit lancer cette commande, il faut donc mettre cette commande sur le fichier d'initiation de session X local dont je ne me rapelle plus du nom.

C'est dans ~/.kde/Autostart
 
Mais étant donné que le nombre d'utilisateurs est assez élevé, c'est compliqué d'aller dans chaque fichier de chaque utilisateur... Y'aurait pas un fichier global ?

tu crée un fichier .xinitrc qui contient la commande dans chaque dossier utilisateur.
très simple à mettre en place.
pas possible avec rc.local car x est pas encore lancé, et ce script a les droits root.
tu peux affiner la commande xhost pour éviter les blagues entre collègues =D et autoriser seulement du pc admin vers un display précis.
Pour cela, man xhost ou google.

ouais mais j'ai un grand nombre d'utilisateurs >100 et 3 PC; chaque utilisateur est suceptible d'aller sur n'importe quel PC... Je devrais faire la manip + de 300 fois ?! Il n'y a pas un fichier de lancement général ?

tu les lance comment ? via ssh ?

ben tu fais un script qui copie le fichier dans tous les dossiers utilisateur, 30 minutes à tout péter.
sinon, je ne sais pas, tu va devoir chercher.
mais je te conseille de rester dans la philosophie du serveur x qui lance le serveur pour un utilisateur, sinon niveau sécu c'est pas top.

De toute façon xhost+ niveau sécurité c'est le zéro absolu.

tout à fait d'accord c'est pour ca que je lui ai dit 'tu peux affiner la commande xhost' par exemple pour permettre l'accès d'une machine vers un display.
c'était juste pour tester si c'était son problème.

export XAUTHORITY=~userlogin/.Xauthority
 
Ca devrait te permettre de lancer des applis sur le serveur X de l'utilisateur "userlogin"

Rien à voir. C'est DISPLAY qui dit où afficher, pas XAUTHORITY. XAUTHORITY ça sert juste à dire où trouver le fichier .Xautority, quand tu utilises xauth et les magic cookies.

C'est pour ne pas avoir à utiliser ce horrible hack qu'est le 'xhost +'

 
il faut se loguer en tant que userlogin, aussi

hein

edité, je craque bourdel

Ben non
 
En tant que root il fait un export du DISPLAY qui va bien, un export du XAUTHORITY pour avoir le droit de causer au serveur X, et pis c'est tout.

En fait j'ai beau réfléchir je vois pas ce que xhost vient faire là dedans. Tu es sur ton serveur. Tu fais :

Et c'est tout, je vois pas le problème ?

 
on est bien d'accord
ou non, pourquoi utiliser root ?!

Parce que si j'ai bien compris il est root sur la machine, et il veut informer les utilisateurs qu'il faut partir

 
comme c'est mignon
mais il veut le faire à distance, et permitRootLogin yes c'est crado

Pas du tout, avec une clef RSA c'est très bien