Dans mon petit réseau local, j'ai un serveur, des postes clients, tous
sous linux, et le /home monté en nfs.
Et, je viens de me rendre compte que maintenant, screen stocke les
"sessions" non plus dans /var/run/S-$USER comme précédemment, mais dans /
home/$USER/.screen/.
Forcément, avec le /home commun à toutes les machines, ça fout bien le
boxon quand je me connecte à chacune en ssh et que j'y lance un screen.
Je suppose que cela fait suite à une mise à jour de screen.
J'ai donc cherché quelle pouvait être la solution, et je me suis dit que
comme je suis le seul utilisateur à lancer des screen, j'allais mettre
export SCREENDIR=/var/run/screen/S-$USER dans mon .bashrc, et que ça
suffirait.
Et c'est vrai. Si je lance "konsole", que dedans, je lance un ssh vers
une autre machine, et que de là je lance un screen, c'est tout bon.
Mais, si je fais :
ssh -t serveur2 screen
rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en
compte. J'en déduis que l'environnement n'est pas le même...sans pour
autant savoir pourquoi, ni s'il est simple d'y remédier.
Quand je regarde les options de compilation du screen installé (par
ebuild sous gentoo), je peux voir :
--with-socket-dir=/var/run/screen
ce qui ne m'explique pas bien pourquoi c'est passé à $HOME/screen
récemment.
Du coup, j'ai pensé à aller voir le Changelog de l'ebuild, et comme par
hasard, je vois qu'une version masquée encore à l'heure actuelle indique :
*screen-4.0.3-r8 (21 Dec 2012)
21 Dec 2012; Sven Wegener <swegener@gentoo.org> +screen-4.0.3-r8.ebuild,
screen-9999.ebuild:
Change socket location to /run/screen.
mais aussi :
*screen-4.0.3-r5 (24 May 2012)
24 May 2012; Jeremy Olexa <darkside@gentoo.org> +screen-4.0.3-r5.ebuild:
Revision bump to disable socket dir (and use ~/.screen/ instead) for
cases
where /var/run is tmpfs, etc. This seems more portable and has been the
best
solution proposed on bug 333821
Et j'ai bien une 4.0.3-r6 installée.
Bon, donc les prochaines versions vont à priori remettre le SCREENDIR
comme à l'origine.
Mais quand même, j'aimerais bien l'avis de personne éclairées sur le
comment résoudre le problème si jamais les packager de l'ebuild devaient
encore changer d'avis.
Merci d'avance.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
YBM
Le 25/02/2013 15:44, Christophe PEREZ a écrit :
J'ai donc cherché quelle pouvait être la solution, et je me suis dit que comme je suis le seul utilisateur à lancer des screen, j'allais mettre export SCREENDIR=/var/run/screen/S-$USER dans mon .bashrc, et que ça suffirait. Et c'est vrai. Si je lance "konsole", que dedans, je lance un ssh vers une autre machine, et que de là je lance un screen, c'est tout bon. Mais, si je fais : ssh -t serveur2 screen rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en compte. J'en déduis que l'environnement n'est pas le même...sans pour autant savoir pourquoi, ni s'il est simple d'y remédier.
Essaye de mettre côté serveur dans sshd_config :
AcceptEnv SCREENDIR
et côté client :
ssh -o SendEnv=SCREENDIR ...
Qui peut être rendu automatique avec un SendEnv SCREENDIR côté client dans ssh_config ou ~/.ssh/config
Le 25/02/2013 15:44, Christophe PEREZ a écrit :
J'ai donc cherché quelle pouvait être la solution, et je me suis dit que
comme je suis le seul utilisateur à lancer des screen, j'allais mettre
export SCREENDIR=/var/run/screen/S-$USER dans mon .bashrc, et que ça
suffirait.
Et c'est vrai. Si je lance "konsole", que dedans, je lance un ssh vers
une autre machine, et que de là je lance un screen, c'est tout bon.
Mais, si je fais :
ssh -t serveur2 screen
rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en
compte. J'en déduis que l'environnement n'est pas le même...sans pour
autant savoir pourquoi, ni s'il est simple d'y remédier.
Essaye de mettre côté serveur dans sshd_config :
AcceptEnv SCREENDIR
et côté client :
ssh -o SendEnv=SCREENDIR ...
Qui peut être rendu automatique avec un
SendEnv SCREENDIR
côté client dans ssh_config ou ~/.ssh/config
J'ai donc cherché quelle pouvait être la solution, et je me suis dit que comme je suis le seul utilisateur à lancer des screen, j'allais mettre export SCREENDIR=/var/run/screen/S-$USER dans mon .bashrc, et que ça suffirait. Et c'est vrai. Si je lance "konsole", que dedans, je lance un ssh vers une autre machine, et que de là je lance un screen, c'est tout bon. Mais, si je fais : ssh -t serveur2 screen rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en compte. J'en déduis que l'environnement n'est pas le même...sans pour autant savoir pourquoi, ni s'il est simple d'y remédier.
Essaye de mettre côté serveur dans sshd_config :
AcceptEnv SCREENDIR
et côté client :
ssh -o SendEnv=SCREENDIR ...
Qui peut être rendu automatique avec un SendEnv SCREENDIR côté client dans ssh_config ou ~/.ssh/config
Christophe PEREZ
Le Mon, 25 Feb 2013 16:09:55 +0100, YBM a écrit :
Essaye de mettre côté serveur dans sshd_config :
AcceptEnv SCREENDIR
et côté client :
ssh -o SendEnv=SCREENDIR ...
Qui peut être rendu automatique avec un SendEnv SCREENDIR côté client dans ssh_config ou ~/.ssh/config
Ah oui, effectivement, cela fonctionne comme souhaité. Merci pour l'information complète, je me note tout ça dans un petit coin (pas que de ma tête), et je le ressortirai au besoin.
Le Mon, 25 Feb 2013 16:09:55 +0100, YBM a écrit :
Essaye de mettre côté serveur dans sshd_config :
AcceptEnv SCREENDIR
et côté client :
ssh -o SendEnv=SCREENDIR ...
Qui peut être rendu automatique avec un SendEnv SCREENDIR
côté client dans ssh_config ou ~/.ssh/config
Ah oui, effectivement, cela fonctionne comme souhaité.
Merci pour l'information complète, je me note tout ça dans un petit coin
(pas que de ma tête), et je le ressortirai au besoin.
Qui peut être rendu automatique avec un SendEnv SCREENDIR côté client dans ssh_config ou ~/.ssh/config
Ah oui, effectivement, cela fonctionne comme souhaité. Merci pour l'information complète, je me note tout ça dans un petit coin (pas que de ma tête), et je le ressortirai au besoin.
Nicolas George
Christophe PEREZ , dans le message <kgftbm$42q$, a écrit :
rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en compte. J'en déduis que l'environnement n'est pas le même...sans pour autant savoir pourquoi, ni s'il est simple d'y remédier.
C'est bash le coupable, il fait complètement n'importe quoi avec ses fichiers de config.
Passe à zsh, et mets l'environnement dans .zshenv.
Christophe PEREZ , dans le message <kgftbm$42q$1@serveur2.novazur.fr>, a
écrit :
rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en
compte. J'en déduis que l'environnement n'est pas le même...sans pour
autant savoir pourquoi, ni s'il est simple d'y remédier.
C'est bash le coupable, il fait complètement n'importe quoi avec ses
fichiers de config.
Passe à zsh, et mets l'environnement dans .zshenv.
Christophe PEREZ , dans le message <kgftbm$42q$, a écrit :
rien ne va plus, ce n'est pas le SCREENDIR de mon bashrc qui est pris en compte. J'en déduis que l'environnement n'est pas le même...sans pour autant savoir pourquoi, ni s'il est simple d'y remédier.
C'est bash le coupable, il fait complètement n'importe quoi avec ses fichiers de config.
Passe à zsh, et mets l'environnement dans .zshenv.
