RFC: Snappy shell
Loïc Minier
loic.minier at ubuntu.com
Tue Jun 16 08:44:38 UTC 2015
You're suggesting to kill the idea entirely; that might be a valid
standpoint, but you've dismissed this a bit quickly.
First, consider that the networking industry is proposing this today: in
all products, for all major brands, you end up in a custom CLI experience.
I certainly agree it's painful to learn a new one each time, much like it's
a pain to learn how to use/configure a new piece of software of any kind.
But at least we get to define this one and offer it as a base for others to
derive from. Perhaps frameworks/snaps could extent the command set with
additional commands, e.g. to manage the ASIC, or provide hardware
diagnostics etc.
I'm not convinced that this shell approach is inherently good or bad for
these network vendors, but it's a fact that they all do this, and snappy
shell gives a path towards this kind of user experience.
Second, you've dismissed the other benefits towards delivering a more
locked down user experience (e.g. I want to ship a critical piece of
hardware based on snappy, they may/may not install apps, they may/may not
change the config of snaps, they may/may not run random shell commands).
I also mentioned smoothing the move to a more minimal system (without some
of the tools you like). But on this Comfy part, it's fair to point out we
should judge this one on its own merits though.
Snappy shell needs not be required for all snappy based images and/or needs
not be on port 22, it is rather an optional interface to snappy, much like
webdm is an useful tool and default web user experience. (Perhaps it should
be implemented as a completely separate addon, but it felt more natural to
tie it to the main command-line tool.) Perhaps we'll have a snappy router
image where it makes sense to make this shell the default, with or without
direct shell access enabled, while a snappy media-center image would not
have it.
Cheers,
On Mon, Jun 15, 2015 at 6:42 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:
> I'm personally two-hearted about this idea.
>
> On one hand, I can see the appeal, and have used something similar to that
> myself for Smart Package Manager, where people could use a shell to type in
> the all of the subcommands that they could use under the "smart" command
> line tool. It was a neat way to type several subcommands in a row without
> the cost of initializing the in-memory graph cache necessary for computing
> operations, and was expensive to do.
>
> 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. Being in a custom shell
> means people will be constrained in an unusual way within an atypical shell
> to the tasks which they tend to understand otherwise.
>
> The thing that fired my worries while reading your message was the part
> where you say the goal is to deliver a slick console user experience as
> found when telneting into network equipment. While I don't have much
> experience there, the few times I did that I found myself within an alien
> and apparently clumsy environment where I'd have to re-learn everything. It
> wasn't a smooth feeling at all.
>
> So, here is an idea: rather than redoing the whole shell, can we identify
> what are the winning aspects of that integrated shell (good help? pleasant
> command names? etc) and try to replicate that within a traditional shell?
>
>
>
> On Mon, Jun 15, 2015 at 12:50 PM, Loïc Minier <loic.minier at ubuntu.com>
> wrote:
>
>> User experience
>>
>> When you SSH into a Snappy system, you currently end up on a shell
>> prompt. Wouldn’t it be great to actually land in Snappy itself?
>>
>> Welcome to Snappy Ubuntu Core 15.04
>>
>> snappy#
>>
>> How do I get started?
>>
>> snappy# help
>>
>> Usage:
>>
>> <command> [<arg>...]
>>
>> Available commands
>>
>> booted Flag that rootfs booted successfully
>>
>> build Builds a snap package (aliases: bu)
>>
>> config Set configuration for an installed package.
>>
>> [... edited for brievety...]
>>
>> shell Start a shell
>>
>> update Update all installed parts
>>
>> versions (deprecated) please use "list"
>>
>> Simple commands like install, update etc. work as expected:
>>
>> snappy# info
>>
>> release: ubuntu-core/15.04/stable
>>
>> architecture: amd64
>>
>> frameworks: webdm
>>
>> apps:
>>
>> snappy# list -v
>>
>> Name Date Version Developer
>>
>> ubuntu-core 2015-06-11 3 ubuntu*
>>
>> webdm 2015-06-11 0.9 *
>>
>> generic-amd64 2015-06-11 1.1.1 *
>>
>> We should revisit some commands or aliases to have a friendlier, more
>> rewarding user experience, e.g. update could provide some output when no
>> update is available and entering a shell command like ls would hint at
>> using help:
>>
>> snappy# update
>>
>> System is up-to-date!
>>
>> snappy# ls
>>
>> No such command; “help” for a list of commands
>>
>> Configuration is only possible for snaps that have the required hook and
>> may be set manually by key or globally from an URL, and of course immutable
>> configs can’t be changed.
>>
>> snappy# config
>>
>> (config)# list
>>
>> Name Date Version Developer
>>
>> ubuntu-core 2015-06-11 3 ubuntu
>>
>> config-example 2015-06-15 1.0.6 canonical
>>
>> webdm 2015-06-11 0.9
>>
>> (config)# config xkcd-webserver
>>
>> No config found for this snap
>>
>> (config)# config ubuntu-core
>>
>> (ubuntu-core)# show
>>
>> autopilot: true
>>
>> timezone: Etc/UTC
>>
>> hostname: localhost.localdomain
>>
>> (ubuntu-core)# set autopilot false
>>
>> Config set
>>
>> (ubuntu-core)# exit
>>
>> snappy# config config-example set -u
>> https://conf.example.com/config-example.yaml
>>
>> Config set
>>
>> A new shell command is provided to start the default user’s interactive
>> shell or to run commands ( under “sh -c”).
>>
>> Goals of snappy shell
>>
>>
>> -
>>
>> Deliver a slick console user experience as found when SSH-ing (or
>> telnet-ing) into network equipments such as switches, routers, firewalls
>> etc.
>> -
>>
>> Allows restricting access to the shell while allowing for useful
>> features such as update, install etc. (could be controlled by a new
>> allowed-cli-commands ubuntu-core config or similar)
>> -
>>
>> Smoothes transition into a Comfy world where the regular rootfs
>> becomes smaller and smaller.
>>
>>
>> Implementation
>>
>> This user experience would be delivered by the main “snappy” binary when
>> it’s launched as “snappy-cli” as the basename of argv[0]. If this
>> feature is not enabled by default, or from a shell, you would run “snappy
>> cli” to start an interactive snappy shell session. NB: cli is to avoid
>> confusion with the shell command to run a command or an interactive
>> shell.
>>
>> SSH integration could be done in multiple ways:
>>
>> 1.
>>
>> integrate a SSH server in snappy itself; I don’t know how hard this
>> is in go today; this might be a worthwhile exercise long-term to get a
>> smaller rootfs
>> 2.
>>
>> configure SSH server and login to always start /bin/snappy-cli
>> instead of the user’s shell, then lookup the user’s shell in the
>> passwd database to run the preferred shell with “snappy shell”
>> 3.
>>
>> (preferred) configure the user’s shell to /bin/snappy-cli and create
>> a new snappy-only ubuntu-core config for the preferred interactive shell
>> (defaults to /bin/bash); drawback: this would be system-wide as we
>> don’t have per-user configs
>>
>>
>> Questions? Comments? Pile on at:
>> https://docs.google.com/document/d/1DeR2JoCBDX2C1r6a2wV60uqvi7a89OwHh5gJ19tBZvM/edit
>>
>> Cheers,
>> --
>> Loïc Minier
>>
>> --
>> snappy-devel mailing list
>> snappy-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>>
>>
>
>
> --
> gustavo @ http://niemeyer.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150616/7f5bdf43/attachment-0001.html>
More information about the snappy-devel
mailing list