Add support for remote installs to Linux box

[wincent]

Add support for remote installs to Linux box

[AttilaForgacs]

Do I get you right, you'd have a vagrant or real linux, and with Ansible via ssh it'd set up the whole environment ? If so I am all in, let's hack together. I use osx/ubuntu and windows as well, and now got fed up with manually trying to consolidate the env, keep them up to date etc...

[wincent]

Here's what I currently have in this repo: a bunch of Ansible roles/playbooks and an install script that runs either the linux.yml or darwin.yml playbook, depending on the platform.

In practice, that means I can set up my dotfiles and other stuff on my laptop running OS X, but also on a remote Linux host that I call my "sandbox". Note that I'm not following the typical Ansible pattern here of orchestrating multiple hosts from a central command host; rather, I set up each machine by cloning this repo and running the install script on that machine. I'm using Ansible as a glorified (glorious?) Makefile.

Things are pretty consolidated already, but there is one key difference that I want to address in this issue: there are some encrypted files in the repo (eg. my ~/.ssh/config) and these currently only get set-up on the laptop, because only the laptop has access to the private key necessary to decrypt them.

So, the two or three obvious strategies I have considered are:

• Use Ansible in a more typical way, running it from the laptop and having it connect to the Linux box to do its thing; note this could mean doing it for the entire set-up, or just to deal with the encrypted files (pro: solves the problem; con: potentially two-step process, requires host-based futzing with inventory, may need special steps to deal with corporate firewalls etc).
• Decrypt the encrypted files on the Linux box using symmetric encryption and a passphrase, so that I don't have to worry about dealing with private keys (pro: not too invasive change; con: manual passphrase management).
• Figure out if I can somehow forward gpg-agent to the remote host, so that it can decrypt without having direct access to the private key material (pro: minimally invasive change; con: not sure if possible/supported, not sure if corp firewall will cause problems).

[AttilaForgacs]

But you are not managing 1000 of clusters, so i totally agree with your way of using Ansible. Back in the days I was using Fab in a similar fashion, that is not for deployment. Using the macbook as a command server would be my preferred way too. ;) So you are actually using a command server.
I tried to use install on ubuntus, with many issues, not installed packages in virtualenv. My idea would be to have a portable env across work machines (OSX, linux and yes potentially windows 10 with ubuntu running bash) and to some extent dev/qa/prod clusters. I think you need the some parts of the same sane zsh/vim/tmux config when you ssh into prod - all i see is a minimal korn shell, c shell , stripped down bash - and i make 100s of mistakes on the command line, lack of aliases - etc.. Having encrypted stuff in the repo is a must, e.g. Prezi got pwned by having keys on github. Let me know if you'd be available for a voice call/chat. A fire and forget solution to setup a VPS or vagrant box would be amazing (fire and forget as in after keys/auth)

[wincent]

For context, I'm living in a situation where I have 4 machines that I care about, and they end up getting configured in 3 different ways.

Machines I care about

Group A: Machines on which I do active development

• My laptop: an OS X machine, gets replaced infrequently (ie.every couple of years), want the ability to perform initial set-up bootstrap in a repeatable, error-free way, but also want an idempotent set-up that I can run (often) to keep it up-to-date as I make configuration changes.
• "Sandbox": physical Linux machine that gets replaced whenever it dies.

By "active development" here I mean intensive usage of Vim, build tools, command-line etc, so it's critical that dot-files get set-up. I work on very large products where virtualized environments won't cut it, at least with today's computing tech.

So I'm not "ssh-ing into prod" or even into VMs though in the sense that you're talking about; I work at a big company where I'm definitely on the developer/sandboxed-environment side and not at all on the ops/prod side. There are of course other machines on the network, but I don't need to know about them or connect to them in order to get my job done.

Group B: Other machines

• Two AWS instances that I use to host websites and other services. Personal, not work related. Things like my blog, some Git repos etc.

I don't do active development on these at all, so I don't care about my dotfiles being available on them. They tend to be "throwaway" machines which I replace whenever they die or I need to do a major OS upgrade or migration to a new instance-type.

How they are configured

• This repo configures the Group A machines. As you say, Ansible is well-suited to this task even if I'm not using it in the textbook "fleet-management" way.
• I have another (private) Ansible repo for configuring/provisioning the Group B machines. That one is totally "textbook" Ansible, even if the inventory only has 2 to 4 machines in it (the 2 I explicitly mentioned above, plus sometimes 2 more when I want a separate staging environment to test big changes).
• Corporate-maintained Chef provides another layer of configuration for the Group A machines, which are all company-owned/company-maintained. Chef runs automatically all the time on those and I let it do its thing, and my Ansible-driven config (this repo) ends up being a thin, manually-initiated layer of configuration on top of that, mostly dealing with "user-space" stuff (mostly preferences).

What that means for this repo

It means I have a fairly well-defined scope, in which I don't have a use case for spinning up virtual machines on a regular basis, but I still have an interest in making things as automated and reproducible as possible. I totally get your desire for fire-and-forget type workflow, though; I'm just not sure exactly what is the scope of your proposed/desired changes.

FWIW, in my brief googling it looks like the third option I mentioned above (gpg-agent forwarding) looks trivially doable with UNIX domain socket forwarding available in OpenSSH 6.7 and up, so that's something I want to explore when I get a chance.

See also

• http://code.v.igoro.us/posts/2015/11/remote-gpg-agent.html
• https://lists.gnupg.org/pipermail/gnupg-users/2016-January/054935.html
• https://github.com/Homebrew/homebrew-versions
• https://github.com/Homebrew/homebrew-versions/blob/master/gnupg21.rb
• https://www.gnupg.org/faq/whats-new-in-2.1.html

[wincent]

Not really working with any remote Linux boxes at the moment so closing this one.