{"version": "https://jsonfeed.org/version/1", "title": "/dev/posts/ - Tag index - screen", "home_page_url": "https://www.gabriel.urdhr.fr", "feed_url": "/tags/screen/feed.json", "items": [{"id": "http://www.gabriel.urdhr.fr/2016/10/18/terminal-sharing/", "title": "Terminal read-only live sharing", "url": "https://www.gabriel.urdhr.fr/2016/10/18/terminal-sharing/", "date_published": "2016-10-18T00:00:00+02:00", "date_modified": "2017-05-06T00:00:00+02:00", "tags": ["computer", "unix", "ssh", "screen"], "content_html": "

Live sharing a terminal session to another (shared) host over SSH in\nread-only mode.

\n

Update: 2017-05-06 add broadcastting over the web with\nnode-webterm

\n

TLDR

\n
#!/bin/sh\n\nhost=\"$1\"\n\nfile=script.log\ntouch \"$file\"\ntail -f $file | ssh $host 'cat > script.log' &\nscript -f \"$file\"\nkill %1\nssh $host \"rm $file\"\nrm \"$file\"\n
\n\n\n

Using screen

\n

screen can save the content of the screen session on a file. This is\nenabled with the following screen commands:

\n
logfile screen.log\nlogfile flush 0\nlog on\n
\n\n\n

The logfile flush 0 command removes the buffering delay in screen\nin order to reduce the latency.

\n

We can watch the session locally (from another terminal) with:

\n
tail -f screen.log\n
\n\n\n

This might produce some garbage if the original and target terminals are not\ncompatible (echo $TERM is different) or if the terminal sizes are different:

\n\n

Instead of watching it locally, we want to send the content to another (shared)\nhost over SSH:

\n
tail -f screen.log | ssh $server 'cat > /tmp/logfile'\n
\n\n\n

Other users can now watch the session on the remote host with:

\n
tail -f screen.log\n
\n\n\n

Using xterm

\n

You can create a log file from xterm:

\n
xterm -l -lf xterm.log\n
\n\n\n

The rest of the technique applies the same.

\n

Best viewed from an xterm-compatible terminal.

\n

Using script

\n

script can be used to create a log file as well:

\n
script -f script.log\n
\n\n\n

Downsides

\n

The downside is that a log file is created on both the local and server-side.\nThis might file grow (especially if you broadcast\nnyancat \"\ud83d\ude38\" for a long time)\nand need to be cleaned up afterwards.

\n

A FIFO might be used instead of a log file with some programs. It\nworks with screen and script but not with xterm. However, I\nexperienced quite a few broken pipes (and associated brokeness) when\ntrying to use this method. Moreover, using a FIFO can probably stall\nsome terminals if the consumer does not consume the data fast enough.

\n

Broadcast service

\n

In order to avoid the remote log file, a solution is to setup a terminal\nbroadcast service. A local terminal broadcast service can be set up with:

\n
socat UNIX-LISTEN:script.socket,fork SYSTEM:'tail -f script.log'\n
\n\n\n

And we can watch it with:

\n
socat STDIO UNIX-CONNECT:script.socket\n
\n\n\n

We can expose this service to a remote host over SSH:

\n
ssh $server -R script.socket:script.socket -N\n
\n\n\n

The downside of this approach is that the content is transfered over\nSSH once per viewer instead of only once.

\n

Web broadcast

\n

node-webterm can be used to\nbroadcast the log over HTTP:

\n
{\n    \"login\": \"tail -f script.log\",\n    \"port\": 3000,\n    \"interface\": \"127.0.0.1\",\n    \"input\": true\n}\n
\n\n\n

This displays the terminal in the browser using\nterminal.js, a JavaScript\nxterm-compatible terminal emulator (executing client-side).\nThe default terminal size is the same as the default xterm size.\nIt can be configured in index.html.

"}]}