I'm moving into a 100% remote strategy. Meaning, I'm giving up my Windows, OSX and Linux computers in favor of a ChromeOS solution. Each of my kids have their own Asus Chromebox, I have a similar Chromebox as a stationary desktop and two Chromebooks for mobile ad experimentation. And... with the Google Pixel I even have a 3 year 1TB data plan.
I'm adapting to the remote/wireless lifestyle well. It's actually working out very well. Between tethering with my cell phone, free wifi at my favorite stores, and the library... I have never been with the ability to work. It's actually better than it was when I had my 11in MBA.
And there is one downside.
I'm putting together my server farm and I've decided to use CoreOS. There are many reasons for this decision.
- auto updates (similar to ChromeOS)
- containers (rkt and docker)
- clustering and hs (etcd, fleet)
And while I'm also doing my development on the CoreOS server I'm using the CoreOS-toolbox. Unfortunately there are a few weaknesses. (a) only one instance at a time per user (b) tmux and screen are ok but when you drop the connection everything is terminated. (c) have you ever seen those people rnuning around the office with their computers open because they did not want to lose their active sessions.
So there are a couple of options.
Install the mosh server on the CoreOS host and use that as your point of entry. To the credit of the CoreOS designers there is no package manager. So that's just not going to work. And frankly I do not think I want my users logging in this way.
The next option is to integrate mosh into the toolbox script. This should work, for the most part, however it's also going to create some entropy(if that's the right word). The scenario is like this: the user logs in. CoreOS authentication, like others, grabs the shell script from the passwd file and executes it. At this point the ssh session has been established and forwards the connection to mosh... assuming that this works (does not currently).
- Assuming I've lost the client connection... logging in with a second connection should still fail because it's a second connection request an one is already in progress
- we will need a way to kill the current connection if the client suffers a failure or related use-cases
- The active client session should still be able to reestablish that server connection
This might be a strong use-case for mosh.