[mosh-users] Automated Persistent Sessions with GNU Screen

[Keith Winstein]

I'm curious what some of the other developers think -- I think my first
reaction is that I do want similar functionality in the long-term
(persistent sessions that maybe you can migrate between machines) in a
"Mosh2", but am somewhat scared of trying to bolt this on to Mosh as it
stands now (either by distributing shell scripts or altering the Mosh
protocol). But, that is what I say these days to many proposed improvements
to Mosh, and maybe I am being too conservative...

My own behavior here is just to start sessions with:

$ mosh SERVERNAME -- screen -S mysessionN

and then if my client crashes or runs out of batteries or whatever, just
resume them with:

$ mosh trolley.stanford.edu -- screen -dr mysessionN

Admittedly it's a little more clunky because you have to explicitly name
the session when you start it (at least if you want to be able to
unambiguously resume from among multiple sessions on the same server), but
I'm not sure we would want to own (and maintain) the complexity of this
script to be able to autogenerate UUIDs.

-Keith

On Thu, Jan 4, 2018 at 4:26 PM, Jared Sutton <jpsutton at gmail.com> wrote:

> Is the project leadership open to accepting pull requests that would
> integrate similar functionality into the core product?  Perhaps I should
> join the Dev list and discuss there...
>
>
> On Jan 4, 2018 7:11 PM, "Keith Winstein" <keithw at cs.stanford.edu> wrote:
>
> Thanks for sending this! Very interesting, and makes me wonder whether we
> should think about long-running migratable sessions in a future version of
> Mosh.
>
> Best regards,
> Keith
>
> On Thu, Dec 28, 2017 at 8:45 PM, Jared Sutton <jpsutton at gmail.com> wrote:
>
>> Hi all,
>>
>> I've seen several posts in various places about the Mosh's lack of
>> ability to re-connect to a session on a mosh server after the mosh client
>> that created it had been terminated.  If you reconnect, even from the same
>> system and to the same user account on the server, you're greeted with the
>> message "Mosh: You have a detached Mosh session on this server".  This
>> is extremely frustrating to me because it's basically just saying...
>> "there's a session on this server running your stuff, but ¯\_(ツ)_/¯"
>>
>> Each time this issue is brought up, the solution suggested is to use
>> something like GNU Screen or tmux to maintain the persistence of your
>> session, and reconnect to that as needed.  Obviously, that's a good bit of
>> manual effort each time you start a mosh session.  My opinion on the matter
>> is that a purposeful integration should be developed for these tools (or
>> other similar ones) to automate their use with mosh, but that's a
>> discussion for the dev mailing list I think.
>>
>> My purpose for this message was to present my own minimal set of changes
>> to my servers/clients to allow reconnecting to sessions automatically.
>> These changes were developed for my own use cases, so make of them what you
>> will and feel free to suggest changes if you think of any better ways to do
>> what I'm doing, or just ignore me. ;)
>>
>> Here's the TLDR of what my changes do:
>>
>>    - On the client end:
>>
>>
>>    1. Create a wrapper shell script around the "mosh" client executable.
>>       2. Add an alias entry into .bashrc or .bash_profile to intercept
>>       the use of the "mosh" executable
>>       3. The wrapper script creates a token string which should be
>>       unique to the client system which is passed as an environment variable to
>>       the mosh server upon launching a new session.
>>
>>
>>    - On the server end, add a small block of shell script into .bashrc
>>    or .bash_profile which starts/resumes a screen session automatically, but
>>    only if the shell was started from mosh_server and if the CLIENT_UUID
>>    variable is defined and non-empty.
>>    - The CLIENT_UUID which is passed from client to server provides a
>>    way to tie a session to a client system it was initiated from, meaning that
>>    it won't be automatically resumed if I mosh from another client system (but
>>    could be manually, if so desired).
>>    - Client-side requirements: bash, md5sum (coreutils), awk
>>    - Server-side requirements: bash, ps (tested on Linux, can't
>>    guarantee Unix/Mac support to the ps options I used)
>>
>> And here's the nitty-gritty changes:
>>
>>    - Create a wrapper script somewhere (I put mine in a ~/bin directory
>>    which I've included on my $PATH).  It should contain the following script
>>    code:
>>
>> #!/bin/bash
>>
>> # Find the block device associated with the root partition
>> ROOT_BLK_DEV=$(readlink -f $(df --output=source -h / | tail -1))
>> ROOT_UUID=""
>>
>> # Find the UUID of the root partition's block device
>> for uuid in $(ls /dev/disk/by-uuid/); do
>>  BLK_DEV=$(readlink -f /dev/disk/by-uuid/"$uuid")
>>  if [ "$ROOT_BLK_DEV" == "$BLK_DEV" ]; then
>>    export ROOT_UUID="$uuid"
>>    break
>>  fi
>> done
>>
>> # If we can't find the root UUID, hash the user at hostname and use that
>> instead
>> if [ "$ROOT_UUID" == "" ]; then
>>  hostname="$(hostname -f)"
>>  export ROOT_UUID=$(echo "${USER}@${hostname}" | md5sum | awk '{ print
>> $1 }')
>> fi
>>
>> # Call the standard mosh client, sending the UUID to the server, and
>> passing the user's args
>> CLIENT_EXEC=$(which mosh)
>> $CLIENT_EXEC --server="CLIENT_UUID=\"$ROOT_UUID\" mosh-server" "$@"
>>
>>
>>    - Add the following entry into .bashrc or .bash_profile on the
>>    *client* (obviously, this should be modified to point to the location
>>    of the wrapper script you created):
>>
>> alias mosh="/home/user/bin/mosh_client.sh"
>>
>>
>>    - Add the following entry into the .bashrc or .bash_profile on the
>>    *server*:
>>
>> PARENT_EXEC=$(ps --no-headers -o command -p $PPID | awk '{ print $1 }')
>>
>> if [ "$PARENT_EXEC" == "mosh-server" ]; then
>>  if [ "$CLIENT_UUID" != "" ]; then
>>    screen -DR "$CLIENT_UUID"
>>    exit
>>  fi
>> fi
>>
>>
>> I was thinking about creating a way to automatically deploy this on
>> servers as I connected to them, but I'm hesitant to do such things, as
>> automated tampering of the .bashrc/.bash_profile files could introduce
>> subtle "I can't login to my server" bugs.
>>
>> Anyway, this effort was quick-and-dirty, and I know it's probably got
>> some warts, so I'm open to critique if you all are interested.
>>
>> Thanks,
>> Jared
>>
>> _______________________________________________
>> mosh-users mailing list
>> mosh-users at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-users
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-users/attachments/20180105/9a0b4c2e/attachment.html