Who cares if I press cmd-t to open a file or my pair prefers to open a file with cmd-shift-n? Just send me the action that a file was opened.
I wrote up my detailed thoughts on fixing remote pair programming here.
> Who cares if I press cmd-t to open a file or my pair
> prefers to open a file with cmd-shift-n? Just send
> me the action that a file was opened.
Yes and no. Would be really fun for five minutes and really irritating for the rest of the time.
What we came up with is creating a new "pair user" and running tmux within that.
The configuration wasn't a problem for us since one of us hadn't ever used tmux and had therefore had no opinion.
> Both pairs get access to whatever user starts tmux
> What we came up with is creating a new
> "pair user" and running tmux within that.
> The configuration wasn't a problem for us
> since one of us hadn't ever used tmux and
> had therefore had no opinion.
I'm not sure why you need to set suid on tmux. Before we created the pair user I just used the -S option to specify a socket path and then chmoded the created socket so my pair could access it.
So far so good with the new pair user. The only thing that's different is that to push our changes up to the main repo we need ssh keys and we haven't gone through the trouble of creating a new ssh key for the pair user and adding it to our teams github repo, so we have to git push and pull from a non-pair login. That can be fixed when it gets annoying but so far I'm always logged in to that machine as myself as well as the pair user so I can just switch tabs and git push/pull when needed.
> I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.
I use C-\ myself since C-a and C-b are both prominent Emacs keys.
> I'm not sure why you need to set suid on tmux
> This also gets around the "GNU screen" suid root issue
1) Use a combination of ssh-agent fowarding and manually exporting the $SSH_AUTH_SOCK variable to switch between two users' ssh-agent sockets.
2) Each user commits from a separate window/shell. Each window/shell has a separate ssh-agent running in it, with that user's ssh key ssh-add'd to it.
Though, options 2 is less secure.
3) Tmux sessions are restricted to the size of the smallest client connected to the session. We've recently started using it at work and it works fine for 2 of us, but 2 others found that the resolution differences between their 13" and 15" macbooks means that the 13" sets the tmux session size so the 15" doesn't use the whole screen.
> if you are doing software development on a
> system with any security requirements at all,
> you have already lost
If my development server is exposed to the Internet and I do something like disable root logins in ssh, why/what have I 'lost?'
Specifically: dickering over whether or not to make screen suid root on your dev boxes is an exercise in needless optimization.
> Specifically: dickering over whether or not to make
> screen suid root on your dev boxes is an exercise
> in needless optimization.
But isn't running applications only as regular users just that, limiting exposure?
tmux and screen both have upsides and downsides for pair programming. Ones that I know of:
1. screen requires itself to be setuid root for session sharing. This is security issue to say the least. The frustrating part of this is that screen explicitly checks that that uid == 0. This means that, even if you can iron out all of the permissions issues between you and your partner without needing root access, screen will only accept suid root as the solution.
2. When you are screen sharing in tmux, the configuration used is the configuration of the person hosting the session. This can suck if you have a lot of non-standard bindings, because it forces the person you're pairing with to know them too. screen allows you to both use your own configurations while being connected to the same session.