Date: Fri, 18 Nov 2011 16:51:10 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: David Wolfskill <david@catwhisker.org> Cc: freebsd-ports@freebsd.org Subject: Re: Support for running xterm within a jail? Message-ID: <20111118145110.GG50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111118141320.GV1706@albert.catwhisker.org> References: <20111117194412.GP1706@albert.catwhisker.org> <20111118091146.GZ50300@deviant.kiev.zoral.com.ua> <20111118141320.GV1706@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--2m8r6DNGXlsmV3Rl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2011 at 06:13:20AM -0800, David Wolfskill wrote: > On Fri, Nov 18, 2011 at 11:11:46AM +0200, Kostik Belousov wrote: > > ... > > I am sure that the issue is a misconfiguration of the jail or attempt to > > start xterm from the process that has no control terminal. For jail > > misconfiguration, I mean either failure to properly mount devfs into > > the jail /dev, or a rule that hides /dev/tty from the jail. > >=20 > > I use very similar configuration (32bit stable/8 jail on amd64 stable/9 > > kernel) and have no issues starting xterm. > >=20 > > That said, you should diagnose the issue further, otherwise I think the > > patch is unneccessary. >=20 > I appreciate that, but admit that I'm not especially familiar with > working with jails. i also admit that the use case is one that > strikes me as perverse, in that I would expect someone to run an > xterm locally. >=20 > In the case in question, the folks encountering the problem do not have > local X servers; they use MS Windows (with which I am almost completely > unfamiliar -- and in which I have no interest) on their desktops. >=20 > As I type, I am logged in to my desktop machine at work remotely (from > home, in another xterm). From that xterm, I can run (e.g.): >=20 > dwolf-bsd(8.2-S)[10] ssh -Yfn dwolf-bsd xterm -T testing >=20 > and get a new xterm up, running on my desktop with DISPLAY set to a > value that will allow me to run other X clients from it. This is the > functionality that is wanted. >=20 >=20 > If, instead, I do something similar to one of our older build machines: >=20 > dwolf-bsd(8.2-S)[11] ssh -Yfn dwolf.svl-lb xterm -T testing >=20 > I get a similar result -- an xterm running on the build machine with > DISPLAY set so I could run other X clients (e.g., emacs). >=20 >=20 > If I do the same for one of the jails: >=20 > dwolf-bsd(8.2-S)[12] ssh -Yfn svl-jail xterm -T testing > dwolf-bsd(8.2-S)[13] xterm: Error 14, errno 2: No such file or directory > Reason: spawn: open() failed on /dev/tty >=20 > If I use ssh & login to the jail: >=20 > dwolf-bsd(8.2-S)[13] ssh -Y svl-jail > ... > svl-jail(7.1-R)[1]=20 >=20 > I can manually fire off xterm because /dev/tty exists and I am already > running an X server locally: >=20 > svl-jail(7.1-R)[1] ls -lTio /dev/tty > 135 crw--w---- 1 dwolf tty - 0, 135 Nov 18 05:59:58 2011 /dev/tty >=20 >=20 > But if I terminate that connection, then try to perform that "ls" > command (as the only thing I want ssh to do for me), that only works if > I include the "-t" on the ssh invocation. >=20 > So if I try adding -t when I try to start the remote xterm, I see: >=20 > dwolf-bsd(8.2-S)[17] ssh -Ytfn svl-jail xterm -T testing > Pseudo-terminal will not be allocated because stdin is not a terminal. > dwolf-bsd(8.2-S)[18] xterm: Error 14, errno 2: No such file or directory > Reason: spawn: open() failed on /dev/tty >=20 >=20 > So I think it's apparent that we don't have a case where /dev/tty is > never available, but I don't know how to make it show up for the > intended use case. The ssh is explicitely saying you what is going on. Did you note the 'Pseudo-terminal will not be allocated because stdin is not a terminal.' line ?=20 It telling that the control terminal will not be allocated. As a consequenc= e, /dev/tty cannot be opened. This has nothing to do with jail. % ssh -Ytfn localhost tty Pseudo-terminal will not be allocated because stdin is not a terminal. not a tty % >=20 > And there already exists code in xterm to ignore the ENOENT case for > CygWin, so it seems that there really isn't much of a reason to treat > ENOENT on /dev/tty as a fatal error for xterm invocation. Further, > applying the patch in question does provide the desired functionality. >=20 > If you (or anyone else) could provide some clues as to where to direct > my attention, that would be wonderful. >=20 > (In the mean time, upstream xterm developer has agreed to make the > change for xterm-277, and ehaupt@ has updated the x11/xterm port to > include the patch, pending xterm-277.) >=20 > Peace, > david > --=20 > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. >=20 > See http://www.catwhisker.org/~david/publickey.gpg for my public key. --2m8r6DNGXlsmV3Rl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7GcN4ACgkQC3+MBN1Mb4ig8wCg3BsyD6hyiV+170FGHoDLbWDg 5JAAn3NE6tO1zeWLTUplhBP4yUdNPC3z =snZe -----END PGP SIGNATURE----- --2m8r6DNGXlsmV3Rl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111118145110.GG50300>