The forum

Bonjour à tous,

Suite à un commentaire sur mon blog, j'ai effectivement constaté que les scripts permettant de démarrer les jeux sur un serveur X dédié n'utilisait pas la version de wine spécifiée par PlayOnLinux le cas échéant pour l'application.
Voila le script actuel:
#/bin/bash
# Notez ci-dessous le nom précédé du chemin absolu de l'exécutable du jeu.
FULL_PATH="/home/USER/.PlayOnLinux/wineprefix/PREFIX/drive_c/CHEMIN DU JEU/EXECUTABLE.exe"
#
#
#
# Remplace l'éventuel ~ par /home/USER pour éviter une erreur de wine
FULL_PATH=$(echo $FULL_PATH | sed -e "s|~|$HOME|g")
# Calcul le nombre de / dans le chemin pour parser l'exécutable
NBS=$(echo $FULL_PATH | grep -o "/" | wc -l)
# Jeu_path (Isole le dossier de l'exécutable en supprimant le nom de l'exécutable)
JEU_PATH=$(echo $FULL_PATH | cut -d / -f -$NBS)
# WinePrefix (Isole le nom du dossier dans wineprefix, en supposant qu'il soit à sa place dans home)
WINEPREFIX=$(echo $FULL_PATH | cut -d / -f -6)
# exe (Isole le nom de l'exécutable seulement)
EXE=$(echo $FULL_PATH | cut -d / -f `expr $NBS + 1`-)
echo "FULL_PATH=$FULL_PATH"
echo "JEU_PATH=$JEU_PATH"
echo "WINEPREFIX=$WINEPREFIX"
echo "EXE=$EXE"

sudo echo "Lancement du jeu"     # Ce premier sudo ne sert à rien d'autre qu'éviter qu'il ne le redemande ensuite sur des commandes plus importantes
export JEU_PATH # Chemin d'installation
if !( ps -e | grep "tty8" ); then     #Vérifie l'existence du second serveur X
sudo X :3 -ac -terminate & # Lance sur un nouveau serveur X affichage 3 (Uniquement si il n'est pas déjà lancé)
fi
sleep 1 # Attend 1 secondes que le serveur soit prêt
export WINEPREFIX     #Utilise le profil wine spécifique au jeu
cd "${JEU_PATH}" # Cible le répertoire du jeu
DISPLAY=:3 xclock &     #Lance xclock dans le serveur X pour le faire patienter durant le démarrage du jeu. (Sinon il risque de se fermer prématurément)
DISPLAY=:3 WINEDEBUG=-all ck-launch-session wine $EXE # Lance le jeu avec Wine
pkill xclock     #Arrête xclock pour quitter le serveur X
sleep 5          #Attend 5 secondes l'arrêt du serveur X
if ( ps -e | grep "tty8" ); then     #Si il ne s'est pas arrêté
sudo kill $(ps -e | grep "tty8" | cut -f 1 -d ' ')     #Arrête le second serveur X
fi
Toute la question étant, comment intégrer à ce script l'usage de la version de wine spécifiée par POL pour une application donnée?
Et pour cela, comment POL gère les versions de wine à utiliser?

Je me répond à moi même mais ça pourrait servir à d'autre.
Il semblerais que l'usage de playonlinux --run "NOM_DU_JEU" permette d'utiliser la bonne version de wine, tout en simplifiant le script.

Mais d'autres tests me permettrons de le confirmer.

Edited by maniack crudelis

Il y a moyen de faire un tel script en utilisant sudo une bonne fois pour toute ?

En l'occurrence, je profite de la rémanence de sudo lors de la première commande pour que le mot de passe ne soit pas redemandé au second. En effet, lors du démarrage du serveur X, il risque de tenter de démarrer sans attendre la fin de la saisie du mot de passe.
L'autre solution serait de se connecter en root au début de script et se déconnecter avant le lancement du jeu, mais pour ça il faut créer un compte root dans ubuntu.

Mon problème est résolu (et testé) avec un script plus simple.
#/bin/bash
# Notez ci-dessous le nom du jeu tel que renseigné dans PlayOnLinux.
GAME="NOM_DU_JEU"
#
#
#
sudo echo "Lancement du jeu"     # Ce premier sudo ne sert à rien d'autre qu'éviter qu'il ne le redemande ensuite sur des commandes plus importantes
if !( ps -e | grep "tty8" ); then     #Vérifie l'existence du second serveur X
sudo X :3 -ac -terminate & # Lance sur un nouveau serveur X affichage 3 (Uniquement si il n'est pas déjà lancé)
fi
sleep 1 # Attend 1 secondes que le serveur soit prêt
DISPLAY=:3 xclock &     #Lance xclock dans le serveur X pour le faire patienter durant le démarrage du jeu. (Sinon il risque de se fermer prématurément)
DISPLAY=:3 WINEDEBUG=-all ck-launch-session playonlinux --run "$GAME" # Lance le jeu avec Wine
pkill xclock     #Arrête xclock pour quitter le serveur X
sleep 5          #Attend 5 secondes l'arrêt du serveur X
if ( ps -e | grep "tty8" ); then     #Si il ne s'est pas arrêté
sudo kill $(ps -e | grep "tty8" | cut -f 1 -d ' ')     #Arrête le second serveur X
fi

En fait on pourrait en faire un plugin, mais il faudrait arriver à autoriser l'utilisateur à créer un serveur X sans utiliser sudo

Il existe une solution consistant à modifier le fichier /etc/X11/Xwrapper.config en modifiant allowed_users=console par allowed_users=anybody

Mais j'ignore les conséquences en terme de sécurité, et il faut une élévation de droit pour modifier le fichier, bien évidemment!

EDIT: Après quelques recherches, je ne trouve pas d'autres solutions et je suis toujours opposé à une erreur m'indiquant que l'user n'a pas les droits nécessaires. Même en tentant d'utiliser le tty1 qui est déjà lancé.
La solution à explorer serait sans doute de ce côté là, modifier peut-être le xhost du tty1 pour autoriser une exécution du jeu directement dans celui-ci. Mais je ne connaît pas son numéro de display, tty7 étant déjà le display 0!

Edited by maniack crudelis

Aucune avancée sur le sujet.
tty1 contient une console texte, pas de serveur graphique, d'où le display 0 en tty7.

Seule piste à explorer, par défaut, Xwrapper.config autorise 'console', soit tout utilisateur loggué sur une console. Mais le sens exact m'échappe.

J'en reste là. Si d'autres que moi ont des pistes sérieuses à explorer, je suis preneur.

Pourtant un utilisateur peut utiliser la commande startx non ?

Ça me renvoi la même erreur.
Mais effectivement, startx fonctionne lorsqu'on se trouve sur un terminal sans X, sur tty1 par exemple, ça fonctionne sans problème.
C'est peut-être le fait d'être sur un terminal émulé qui dérange.

Hum startx en ssh fonctionne si ma mémoire est bonne

J'ignore si ssh se connecte sur l'une des consoles ouverte sur la machine. Pour ma part je ne peux pas tester, x.org n'est pas installé sur mon serveur.
Mais il me semble qu'il faut spécifier à ssh lors de la connexion que l'on veut un support de X.
Toutefois, cela ne nous avance guère, passer un jeu par un tunnel ssh n'est surement pas une bonne idée ;-)
Il faudrait trouver moyen de lancer la commande depuis une console...

Après un essai, il est intéressant de constater qu'il est possible de démarrer un serveur X depuis tty1 sans élévation de droit.
X :3 -ac -terminateToutefois, le & à la fin de la commande dans le script ramène cette erreur de droit (Un problème que j'avais vu passer durant mes recherches sur le web, manifestement ça se contourne, à retrouver).

Toutefois, la manœuvre nécessite une connexion manuelle dans le tty1. Le réglage par défaut de Xwrapper.config prend tout son sens ici, reste à trouver moyen de lancer la commande depuis l'une des consoles ouverte. Chez moi, tty1 à 6 sont ouvert mais demande un login.
On tourne en rond!

Ouaip !

Pour le &, on peut peut être utiliser screen ?

Quelques recherches plus tard,
le seul moyen trouvé pour le moment pour lancer une commande dans un autre tty est encore une fois d'utiliser DISPLAY=X, sauf que 0 correspond à tty7, display semble ne considérer que les serveurs graphiques, et je ne trouve pas de man sur le sujet.

Je parviens tout de même à rediriger une sortie sur tty1.
echo hello > /dev/tty1Mais la commande en elle-même est effectuée sur mon terminal émulé, seule la sortie est sur tty1...

Je retrouve régulièrement screen, mais je crois comprendre qu'il émule des terminaux dans un terminal, pas certain qu'il fasse avancer le problème.

Toutefois le problème reste entier, je me suis connecté manuellement sur mon tty1. Sur tty2 (non loggué), je reçois "bash: /dev/tty2: Permission non accordée"

EDIT:
Un peu d'avancée statique (!)

Depuis tty1, 'chvt 2' nous fais sauter directement sur tty2. Depuis X sur tty7, 'chvt 1' ne fonctionne pas sauf avec sudo...

Edited by maniack crudelis