RFC: Snappy shell

[Dustin Kirkland]

On Mon, Jun 15, 2015 at 12:46 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Hey all,
>
> Gustavo Niemeyer [2015-06-15 13:42 -0300]:
>> On the other hand, there's no relevant init cost for the snappy cli, and
>> custom shell can become an annoyance rather than an advantage. For example,
>> I use traditional unix tools such as grep, sed, awk, sort, all the time
>> when interacting with textual output from dpkg, apt, etc, and also use text
>> files as temporary storage, shell variables, etc.
>
> Indeed. It also breaks ssh based automation and monitoring, such as
> "ssh snappy.remote uptime" or other remote commands like "cat
> /var/log/sensor-data", "journalctl -p warning", etc.
>
> Moreover, wouldn't a "snappy" shell need to run as root, i. e. you
> couldn't log in as unprivileged user any more?
>
> Perhaps as a compromise we could run a "snappy" ssh on a different
> port? I don't see why this would be much different than running "ssh
> snappy.remote sudo snappy", but it would save some typing and more
> importantly could also be firewalled differently?

I thought long and hard about this problem, as it relates to Byobu, in
that some users really want that to be their entry point when ssh'ing
or tty'ing into a system, while others explicitly don't.  Moreover, as
Martin says, it's critically important not to break the ssh automation
workflows.

The solution that has worked very well for Byobu since 2009 is to use
~/.profile to call the interactive binary you want as its last command
(/usr/bin/byobu in my case, snappy in your case).

It's easy to enable/disable by having or not having that one line in
each individual user's ~/.profile or system wide in /etc/profile.d/*.

Also, even if you have it set to launch by default, it's easy to opt
out of it on an individual session basis by either of two methods:
 1) exporting an LC_BYOBU=0 environment variable:   LC_BYOBU=0 ssh user at host
 2) ssh -t user at host /bin/bash

Cheers,
Dustin