Forum Linux.général rediriger la console vers :0

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes : aucune
0
29
oct.
2015

bonjour la banquise

j'ai juste une petite question

il m'arrive couramment d'utiliser le terminal. De temps en temps, en me connectant sur un utilisateur différent pour faire des tests.

Le probleme, c'est que certaines fois les applis sont graphiques et exigent d'etre redirigées sur X=:0

par ex, bob est connecté sur une session graphique
alice, a coté de bob, ouvre sa session dans un terminal
comment faire pour qu'alice dispose d'un accès au serveur graphique pour lancer des applis en parallele?

j'ai cherché via la commande export, mais j'ai rien trouvé, comme pré-commande qui redirigerait tout ce qui suit vers l'affichage :0

quelqu'un sait?

merci

  • # il faut d'abord lancer une 2e session graphique

    Posté par  . Évalué à 2.

    sur une machine simple, il est possible de demarrer plusieurs serveurs X
    le premier est alors :0 (generalement sur Ctrl+Alt+F7)
    le 2e est :1 (sur Ctrl+Alt+F8)
    etc

    mais ce que tu cherches à faire ressemble à du multiseat, car tu dis que bob et alice sont cote à cote, sur la MEME machine…

    je suppose donc qu'ils ont tous les deux un clavier, une souris et un ecran.

  • # xhost - server access control program for X

    Posté par  . Évalué à 4.

    Il me semble qu'il manque à ton puzzle la brique xhost.
    man xhost
    ==>
    bob@machine$xhost +local:alice
    alice@machine$ env DISPLAY=:0 xterm

    Bob autorise Alice à se connecter sur son X en local?

  • # Transférer les autorisations X

    Posté par  . Évalué à 2.

    Salut,

    En fait, les autorisations d'accès au serveur X sont gérées par des "cookies" stockés dans un fichier (le fichier lui-même dépend de ta version de X et, certainement, de ta distribution : il s'agit de ~/.Xauthority ou du fichier indiqué par la variable XAUTHORITY).

    Pour que Alice puisse afficher sur le serveur X :0, il faut donc :
    - que la variable DISPLAY soit positionnée à :0
    - que Alice possède l'autorisation dans son fichier XAUTHORITY.

    Ce dernier point peut être réglé ainsi :
    - Bob exporte ses données avec xauth extract /tmp/bob.xauth :0
    - Alice importe l'autorisation avec xauth merge /tmp/bob.xauth
    Il faut que le fichier XAUTHORITY de Alice existe et qu'elle puisse écrire dedans (et pour des raison de sécurité, il faut éviter que d'autres utilisateurs puissent lire le fichier exporté par Bob).

    Mais il y a des façon plus simples de gérer tout ça de façon automatique. Comment est-ce que Alice ouvre sa session ? Est-ce dans une émulation de terminal du type xterm/rxvt/konsole/gnome-terminal/eterm/xfce4-terminal/… (désolé pour ceux que j'ai oubliés : je ne voudrais pas déclencher une guerre de clochers) avec une commande de type "su" ? Si c'est cela, regarde du côte de gksu/kdesu qui permettent de lancer une application graphique (donc, au besoin, une émulation de terminal avec un shell) sous un autre utilisateur.

    Il est aussi possible d'ouvrir une session en exportant le display en faisant une connexion ssh locale ! Il suffit que bob exécute (si un serveur SSH est actif)
    ssh -X alice@localhost
    C'est un peu la grosse artillerie mais ça a l'avantage d'être simple.

    A+

    • [^] # Re: Transférer les autorisations X

      Posté par  . Évalué à 1.

      En relisant le man de xauth, il semble que la commande generate soit préférable dans ce cas:

      xauth generate $DISPLAY .
      xauth extract /tmp/bob.xauth $DISPLAY
      

      puis:

      xauth merge /tmp/bob.xauth
      

      Savez-vous ensuite si la configuration xhost est prise en compte? Notamment si un xhost - a été fait sur la machine par bob ?

      • [^] # Re: Transférer les autorisations X

        Posté par  . Évalué à 1.

        Mais normalement Bob, dont c'est la session graphique, a déjà un fichier XAUTHORITY avec les autorisations nécessaires. Le generate ne sert donc à rien (voire va casser l'existant). Ces autorisations sont normalement créées au lancement du serveur X (et le plus souvent, c'est le gestionnaire de session, gdm/xdm/…, qui les transmet à l'utilisateur).

        En revanche, je viens de découvrir des choses avec xhost (au moins sur une Debian SID). Si bob fait un xhost +SI:localuser:alice, ça semble permettre à alice (avec un DISPLAY positionné à :0) d'utiliser le serveur X local (sans XAUTHORITY). Il faudra que je fouille un peu pour voir comment cela fonctionne…

    • [^] # Re: Transférer les autorisations X

      Posté par  . Évalué à 3.

      Il est aussi possible d'ouvrir une session en exportant le display en faisant une connexion ssh locale ! Il suffit que bob exécute (si un serveur SSH est actif)
      ssh -X alice@localhost

      ou moins contraignant, un peu de conf si ce n'est pas déjà fait dans /etc/pam.d/su
      session optional pam_xauth.so

      $>su alice -
      $>xeyes

      voila moins chiant, pas de serveur à ajouter, et souvent c'est déjà fait dans les distrib

      Les option à coup d'export DISPLAY nécessitent généralement de retirer le -nolisten tcp du serveur X

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # a

    Posté par  (Mastodon) . Évalué à 1.

    j'essaie de bien cerner vos réponses

    pour préciser, bob et alice sont sur une seule et meme machine (un ordi portable)
    bob est sur sa session X, avec ses logiciels, ses données
    Alice doit accéder aussi à ses logiciels, à travers la meme session X, et ses données. Ce pourquoi elle passe au travers d'un terminal.

    La distribution est slitaz, et il n'y a qu'un seul serveur d'affichage.
    De plus, je souhaite que les deux applications se cotoient sur le meme serveur X
    Ca a l'air compliqué, mais avec deux users différents on peut le faire sous fedora.
    Or, j'y arrive pas sous slitaz

    • [^] # Re: a

      Posté par  . Évalué à 2.

      Je pense que tu peux faire ce que tu veux quelle que soit ta distribution, mais il serait intéressant que tu indiques plus précisément comment tu fais cela sous Fedora et ce que tu ne retrouves pas sous slitaz.

    • [^] # Re: a

      Posté par  . Évalué à 3.

      Alice doit accéder aussi à ses logiciels, à travers la meme session X,

      en meme temps, sur le meme ordi, avec le meme clavier/ecran/souris ?
      c'est chaud d'etre à deux sur un clavier/trackpad/ecran d'un ordi portable :/

      ou depuis un autre ordinateur avec un "terminal" comme ssh ?

      ou simplement quand elle se connecte en l'absence de BOB, mais sans fermer la session de BOB qui est parti en laissant l'ordi allumé ?

      • [^] # Re: a

        Posté par  (Mastodon) . Évalué à 1.

        on va dire qu'ils bossent sur le meme projet, mais avec des données exploitées par des logiciels différents sur la meme machine

        par ex, les deux utilisent leur navigateur pour accéder a des marques-pages précis, ou des blocs notes via leafpad, et autres logiciels différents ou commun, ayant pour chaque des données bien attribuées à un utilisateur ou à l'autre.

        ils bossent ensemble, ils arrivent juste pas a ouvrir de fenetre a travers le terminal quand un user différent s'y connecte par se biais

        • [^] # Re: a

          Posté par  . Évalué à 1. Dernière modification le 30 octobre 2015 à 09:39.

          ils bossent ensemble, ils arrivent juste pas a ouvrir de fenetre a travers le terminal quand un user différent s'y connecte par se biais

          ca ne repond toujours pas à la question :

          sont-ils devant la machine en MEME temps (2 ecrans, 2 souris, 2 claviers) sur UNE SEULE machine ?
          ou à des periodes differentes (machine commune utilisée en temps partagé)

          • [^] # Re: a

            Posté par  (Mastodon) . Évalué à 1.

            en se partageant écran clavier souris (a tour de role)
            c'est un simple ordi portable, sans clavier ou souris externe

            • [^] # Re: a

              Posté par  . Évalué à 2.

              en se partageant écran clavier souris (a tour de role)

              à tour de role,

              donc pourquoi ne pas laisser le gestionnaire de fenetre/bureau faire son travail,
              en lui demandant de basculer sur la session ALICE sans fermer la session BOB
              afin qu'ALICE puisse travailler quand BOB n'est pas là et a laissé sa sessoin ouverte ?

              • [^] # Re: a

                Posté par  (Mastodon) . Évalué à 1. Dernière modification le 31 octobre 2015 à 19:15.

                parce que les deux utilisateurs souhaitent partager leurs informations simultanément :
                le doc libreoffice de Alice pour etre comparé à des informations sur le firefox de Bob par exemple, ainsi qu'un autre doc libreoffice de Bob.

                Avec un affichage simultané de ces fenetres sur le meme écran, sans basculement : les deux utilisateurs sont présent en meme temps devant la machine, ya juste un écran/cl/souris pour deux

                c'est faisable sous fedora, je comprend pas pourquoi sous slitaz j'ai un probleme de connexion à :0

                • [^] # Re: a

                  Posté par  . Évalué à 1. Dernière modification le 31 octobre 2015 à 19:25.

                  ah oui, c'est un scenario bizarre, auquel je n'avais jamais pensé.

                  tu sais qu'ALICE peut donner les droits sur un dossier/une document, pour que BOB puisse venir le lire,
                  ce serait quand meme plus simple non ?

                  BOB navigue alors dans les fichiers, va chercher le fichier dans /home/alice/mes documents/partage_avec_BOB/
                  et ouvre le document.

                  bon, faudra que j'essaie l'histoire de l'appli,
                  mais je penses que ca devrait fonctionner en faisant :

                  TERMINAL BOB : xhost + pour autoriser tout le monde à afficher sur l'ecran de BOB

                  TERMINAL BOB : su - alice pour basculer sous l'identité ALICE
                  Le terminal devient alors celui d'ALICE.
                  TERMINAL ALICE : export DISPLAY=:0.0 monappli

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.