UserNotes:vielmetti

User notes are notes you take as a user of cmd.io to share with the community.

Getting started

First: I had to update my Github keys, per the Github ssh settings page. I also updated my .ssh/config file.

Second: there don't seem to be currently any default installed commands, not even a "help" command.

Edwards-MacBook-Air:.ssh emv$ ssh alpha.cmd.io :ls

Installed Commands:

Third: after I read for a while, I wanted to explore what other people had published and shared.

Fourth: after following the examples, it was easy to get jq into the system. So far so good.

Installing a non-trivial command

I want to get an AWS CLI command, e.g. like https://github.com/xueshanf/docker-awscli so that I can run Amazon administration tasks. This requires careful understanding of how credentials are packaged up and shared (or not shared).

Following the instructions I get this set up. Now, where do the creds live?

ssh_exchange_identification: Connection closed by remote host is an error message, caused temporarily by an SSH bug which has been addressed.

Sharing your work

Now that I have this awscli command loaded, how do I share with others? Cf the help text

emv$ ssh alpha.cmd.io awscli:access --help
Manage command access
Usage:
  awscli :access

Can you install a secret and also share a command?

Tried to build a few secrets into awscli to allow me to do tasks that require access, e.g. dropping data into AWS IOT via the aws iot-data command. However I was stopped for the day with

emv$ ssh alpha.cmd.io awscli:config set foo=bar
ssh_exchange_identification: Connection closed by remote host

Ideal systems to install here

I suspect that the best kinds of things to put here (rather than install locally) are the sets of tasks where you would otherwise either do a complex install onto your local system, or hope that a Docker container is available to avoid the install process. The trickier the dependencies the more likely that Docker is the right answer to corral them. It would be best to avoid anything too CPU intensive (as there is a timeout on cmd.io tasks) but in general when install time >> run time this is a good option.

The other set of good things to do here are instances where you want a non-trivial command to be ubiquitously available, so that you can bootstrap a new machine or work in an unfamiliar environment and have your tools available to you without going through a big install process.

Leaking environment information from AWS CLI

ssh alpha.cmd.io vielmetti/awscli --region us-east-1 ec2 describe-instances

says an awful lot about the running environment.

Getting information into the running environment with cmd:config set

I'm putting a wrapper around a script that requires an API key (not the AWS key but something simpler and lower risk).

ssh alpha.cmd.io getpredictions:config set AAATA=rw9xxxxxxxxxxxxxx

to set the key. The Dockerfile runs a shell script, and the shell script has a line

curl "http://rt.theride.org/bustime/api/v1/getpredictions?key=$AAATA&stpid=$1" 

and the resulting setup handily pushes the AAATA variable into the environment into the variable for use by the script. Et voila.

Making really tiny Docker files

It would perhaps be helpful to have the moral equivalent of "ls -l" so that we can see how big the Docker containers we are running are. In a small amount of experimentation I seem to be able to demonstrate that smaller setups do better. My experiments led me to alpine of course, and the smallest container I have that does useful work is 27 mb compressed (says Docker Hub).

Smaller than that, yet; an alpine image with only 2 megabytes, vielmetti/oblique (Oblique Strategies).

Public / published commands

I put together a tiny command ssh alpha.cmd.io vielmetti/directory that spits back a list of some of the commands that people have shared. It should be possible to make shared commands more discoverable, if people want to share them. You might trap "cmd:access public" and update some registry, or otherwise derive some shared space that people can scribble on together to share what they are up to.

Mimicking persistent storage

There's no reason that commands couldn't keep some credentials that would allow them to mount some persistent storage somewhere, do reads and writes, and then when they exit the persistent storage is still around for the next time the command is invoked.

The test would be two containers "increment" and "decrement" that shared a counter somewhere, and when you ran "increment" the number would go up, and when you ran "decrement" the number would go down.

Consider different filing systems. The count data could live on

• a public wiki
• a private S3 bucket
• a private or public Git repository, or maybe the Git repo's wiki
• some kind of user-level file system mounted with FUSE, with any number of back ends
• an anonymous FTP server that supports GET and PUT
• an NFS file system mounted within the container, like Amazon's EFS?
• a Github gist, especially if you can create a nonce that gives write privs just to that gist.

Ideally you'd be able to do this in such a way that if the secret was in any way compromised, that you would not risk anything else.

Pushing environment variables into every session you run with .ssh/config

If you want every session you run to have variables set - e.g. to help with the process of getting secrets into the environment without clogging up your command line - use something like this

Host alpha.cmd.io
    User vielmetti
    SendEnv MY_KEY

Note that this would insert this key into the environment for every command you run, so you would be best to only run commands that you trust in this case. (Not really sure if this is a great idea, but it really depends on your level of mutual trust. Then when you want to run a command that needs a key you can run it on your command line as

MY_KEY=secret ssh alpha.cmd.io mycommand

Til next time!