From owner-freebsd-ports@FreeBSD.ORG Fri Nov 18 14:51:31 2011 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FA46106564A for ; Fri, 18 Nov 2011 14:51:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 677818FC13 for ; Fri, 18 Nov 2011 14:51:29 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAIEpAaB083594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Nov 2011 16:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAIEpAcV018658; Fri, 18 Nov 2011 16:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAIEpAcf018657; Fri, 18 Nov 2011 16:51:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Nov 2011 16:51:10 +0200 From: Kostik Belousov To: David Wolfskill Message-ID: <20111118145110.GG50300@deviant.kiev.zoral.com.ua> References: <20111117194412.GP1706@albert.catwhisker.org> <20111118091146.GZ50300@deviant.kiev.zoral.com.ua> <20111118141320.GV1706@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2m8r6DNGXlsmV3Rl" Content-Disposition: inline In-Reply-To: <20111118141320.GV1706@albert.catwhisker.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-ports@freebsd.org Subject: Re: Support for running xterm within a jail? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 14:51:31 -0000 --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--