Support for running xterm within a jail?

[Kostik Belousov]

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.
> > 
> > I use very similar configuration (32bit stable/8 jail on amd64 stable/9
> > kernel) and have no issues starting xterm.
> > 
> > That said, you should diagnose the issue further, otherwise I think the
> > patch is unneccessary.
> 
> 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.
> 
> 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.
> 
> 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.):
> 
> dwolf-bsd(8.2-S)[10] ssh -Yfn dwolf-bsd xterm -T testing
> 
> 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.
> 
> 
> If, instead, I do something similar to one of our older build machines:
> 
> dwolf-bsd(8.2-S)[11] ssh -Yfn dwolf.svl-lb xterm -T testing
> 
> 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).
> 
> 
> If I do the same for one of the jails:
> 
> 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
> 
> If I use ssh & login to the jail:
> 
> dwolf-bsd(8.2-S)[13] ssh -Y svl-jail
> ...
> svl-jail(7.1-R)[1] 
> 
> I can manually fire off xterm because /dev/tty exists and I am already
> running an X server locally:
> 
> 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
> 
> 
> 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.
> 
> So if I try adding -t when I try to start the remote xterm, I see:
> 
> 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
> 
> 
> 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 ? 

It telling that the control terminal will not be allocated. As a consequence,
/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
%

> 
> 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.
> 
> If you (or anyone else) could provide some clues as to where to direct
> my attention, that would be wonderful.
> 
> (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.)
> 
> Peace,
> david
> -- 
> David H. Wolfskill				david at catwhisker.org
> Depriving a girl or boy of an opportunity for education is evil.
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20111118/f07c091d/attachment.pgp