Journal OOo et erminaux X

Posté par .
Tags : aucun
0
19
août
2003
Salut.

J'ai constaté, un peu par hasard une fonctionnalité de OOo qui me vient assez mal à propos.

J'ai installé (enfin, pas seul, avec d'autres membres de mon LUG) une salle avec des vieux ordi P133 qui servent de terminaux X pour un serveur. Jusque là ça va bien, mais on a eut des drôles de choses quant on a testé OOo, une fois le programme démarré sur un des terminaux, essayer de le démarrer sur un autre (que ce soit oowriter, oocalc, ...) ouvrait une nouvelle fenêtre sur le terminal où il était déjà démarré.
Je pense avoir compris le problème, nous nous étions connecté avec le même login sur les différents terminaux, et il semble donc que relancer un oowriter, oocalc, ... sur la même machine (le serveur) alors qu'une instance de OOo est déjà en cours d'exécution ne va pas charger une nouvelle instance mais demander à celle existante de créer une nouvelle fenêtre, qui va donc apparraitre sur le terminal de la première.

Ce comportement est assez gênant dans ce genre de situation, connaissez-vous un moyen de l'inhiber?
Parce que cette salle devra servir notament à des formations pour débutants, et c'est pas pratique de devoir créer un login pour chaque personne (c'est plus simple de dire collectivement au début connectez-vous avez le login xxx et le mdp yyy).
  • # Re: OOo et erminaux X

    Posté par (page perso) . Évalué à 2.

    En lisant le $OPEN_OFFICE_HOME/program/soffice, j'ai repéré une section traitant d'une variable $SO_REMOTE_START, à mon avis en creusant par là, tu doit pouvoir faire ce que tu veux
    • [^] # Re: OOo et erminaux X

      Posté par . Évalué à 1.

      J'ai pas l'impression, ça semble être en rapport avec le démarrage de OOo à travers rsh ou ssh.

      # start soffice by remote shell
      if [ "X${SO_REMOTE_START}" = "Xrsh" ]; then
      ....remote_server=`echo ${SO_REMOTE_APPLICATION} | sed 's/:.*//g'`
      ....remote_path=`echo ${SO_REMOTE_APPLICATION} | sed 's/.*://g'`
      ....echo remote_server=\"${remote_server}\" remote_path=\"${remote_path}\"
      ....if [ "X${DISPLAY}" = "X" ]; then
      ........local_display=`uname -n`:0
      ....else
      ........local_display=${DISPLAY}
      ....fi

      ....if [ "X${remote_server}" != "X" -a "X${remote_path}" != "X" ]; then
      ....rsh ${remote_server} ${remote_path} -norsh -display ${local_display}
      ....exit 0
      ....else
      ........err "invalid rsh arguments host=\"$remote_server\", command=\"${remote_path}\""
      ....fi
      fi
  • # Re: OOo et erminaux X

    Posté par (page perso) . Évalué à 3.

    Et pourquoi ne pas fixer un login/mot de passe par machine ?
    Après tout, tu pourrais même afficher les logins et mots de passe correspondants sur chaque machine, ainsi tu n'aurais plus qu'à dire aux étudiants : "Connectez-vous avec le login et le mot de passe affichés sur votre machine" ... Et voilà, problème résolu.
    • [^] # Re: OOo et erminaux X

      Posté par . Évalué à 3.

      Problème évité plutot :)
      • [^] # Re: OOo et erminaux X

        Posté par (page perso) . Évalué à 1.

        Encore mieux : un autologin ...
        • [^] # Re: OOo et erminaux X

          Posté par . Évalué à 1.

          L'autologin il va connecter tout le temps avec le même login, justement le contraire de ce qu'il faudrait.
          Ou alors il faut faire des modifications (non triviales) à kdm pour qu'il choisisse à chaque fois un nouvel utilisateur.
    • [^] # Re: OOo et erminaux X

      Posté par . Évalué à 2.

      Marchera pas.
      D'abord les machines et leur nombre peut varier.
      Ensuite tu peux être sur qu'il y aura des gens qui vont se connecter sur un autre terminal avec le login qu'ils avaient utilisé sur le premier.
      Et avec ce système faut pas changer de machine entre deux utilisations, sinon ce que tu pouvais avoir enregistré la fois précédente l'est ailleurs sous un autre login. Pas pratique.
      • [^] # Re: OOo et erminaux X

        Posté par . Évalué à 1.

        Je propose que dés le début du 1er cours, chacun se créer un utilisateur avec son mot de passe associé. Evidenment, il faut mettre en place une petite procédure (login/mot de passe commun à tous au départ pour lancer la procédure). Un script à la con qui initialise un fichier d'utilisateur que l'administrateur utilise ensuite pour mettre à jour la liste des utilisateurs du serveur.
        A la fin du cours, la liste est sauvegardée, la liste du serveur réinitialisée pour le prochain cours.
        Lors de la deuxième session, l'administrateur initilise la liste sauvegardée.

        A mon avis, c'est encore plus compliqué que ça, car il faut sans doute conserver les comptes utilisateur (notament les préférences de OOo de l'utilisateur).
  • # Re: OOo et erminaux X

    Posté par (page perso) . Évalué à 0.

    hum, encore une recherche de solution technique a un probleme humain.

    Arretons de prendre les utilisateurs pour des neuneux only

Suivre le flux des commentaires

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