Regardless of the frequency of such a situation, it can really bite you when something big breaks and you need to ssh into a vanilla server in the middle of the night under pressure. Trying to fix a production fire under the gaze of an angry CEO is stressful enough, but not being able to take care of business on a box because of a missing personal config is truly one of the worst experiences I've ever had in this business.

It's only happened to me once, but that one experience made me take a really hard look at my workflow, and years later, I have no regrets about scaling back my configs. I guess it really just depends on your job and on-call/firefighting responsibilities.

Keep your dot files in github. Grab them. No internet, I bet you have them on your laptop that you are ssh'd to the server from. SCP them over. Heck, cut and paste them if needed. If things are so bad nether of these work you have bigger issues and need to consider a design with some redundancy. Clos fabrics and VM/containers and if you have to have bare metal then you should have more then one (cluster or behind a SLB).

There is no excuse for a single point of failure in 2017. Not trying to sound like an ass but....

You did say it was years ago, so what I said seems to be true for today, no judgment on your situation years ago. My first major shit, got to fix it was on Solaris 2.51 so that shows my age.

I bind bash and tmux to vim keymaps. If that is not on the box it is the first thing I fix. I will be fast to resolve the issue if my fingers just work as I have trained them :)

Yep, I don't understand why people think you can't clone your dotfiles and copy over your ~/.tmux.conf to your home directory on the server. It's the first thing I do when I get an account set up, along with the ~/.zshrc and ~/.vimrc, and I have it all automated as a script. Makes everything easy.

I'm willing to bet many employers really don't like their employees putting personal config files on a production server...

At my employer, we have unix accounts for every employee, and the system automatically synchronizes your dotfiles to each server.

On a production server? You're doing it wrong.

Why? This lets admins log in as themselves (leaving an auditable trail) with access to their own dotfiles to debug and analyze on the fly. Even with ex. Ansible for managing and ex. Nagios for monitoring, being able to use a shell to diagnose and fix novel issues is invaluble. If you've got a better solution, please do share. (Sincerely: if you can make my job easier, I'm happy to listen)

what's the alternative?

Just learn the default key bindings.

Using Emacs config files as an example, what's the issue with storing config files on a server? Even if it's a 'production' server it's not like they contain much in the way of sensitive information. Does it matter if others have access to a list of keybindings, aliases, colour schemes, plugins, etc...?

Especially if your dotfiles are in a public repository anyway.

What do they gain from me having to type "ls -lah" instead of "ll"?

What if their contracts with their customers state everything that deployed is from an audited source in order to leave no loopholes in the event of a data breach?

And if there is a serious data breach you better be able to prove that you never installed anything malicious or dodgy on there.

> What if their contracts with their customers state everything that deployed is from an audited source in order to leave no loopholes in the event of a data breach?

Just delete the configs after you're done?

I place all my dotfiles in a directory, usually in ~/mgmnt/. Then I have a little shell script, which backs up all the dotfiles I need found in ~/ and symlinks the ones from the directory. It's .zshrc, .bashrc, .tmux.conf, .gitconfig, .emacs.d, and probably a couple of other config files. I only needed to do this a couple of times, but reverting such "installation" is as easy as a couple of rm/mv commands so I didn't even feel the need to write a script for this.

To be clear, I'm talking about your user account, not root or anything like that.

Source is a great command as are flags that point at which configuration to use when you start something. So...

This works fine if your configuration contains nothing too custom. Typically after copying my dotfiles I have to edit them quite substantially to make them actually work - mainly because they rely on outside sources (in .tmux.conf, stuff like `set-option -g default-command "reattach-to-user-namespace -l bash"`, in .vimrc it's usually colours, clipboard hacks etc that break). Maybe I should have a second, trimmed down version with no outside dependencies.

That's why I break out things that are platform-dependent. E.g.:

   if-shell "[ $(uname) = 'Darwin' -a -f ~/.tmux.macos.conf ]" "source-file ~/.tmux.macos.conf"

Technically `reattach-to-user-namespace` is a macOS-specific hack to get tmux working, so there's no need to jam it into your standard config.

For some of these files you can add logic to check for the system it is on. For example (on iPad, do not have the files to look at now..will try to post later) my bash and tmux configuration check to see if:

Linux or OS X (for terminal setting) If I am in tmux session already.

Check out https://github.com/thoughtbot/rcm. It has a hook system, so you can have it automatically run commands to install external dependencies – stuff like vim or Emacs plugins.

I manage hundreds of servers that are not connected to the Internet, to which I cannot connect any device without management approval, and which are redundant, but which are periodically reflashed and/or replaced with a whole new set with a 'clean' image, less dotfiles.

I keep my dotfiles short and sweet, because it's tedious to retype and I need the defaults to still be instinctive when I lose them.

If the only time you see a production box is when it's on fire, I think there's an organizational problem.

Occasionally acting as third-line support means real production disasters aren't an unfamiliar zone.

In the "immutable architecture" style, the only time you see a shell on a production box should be when it's on fire (and even then, only if you need to do some "perimortem" debugging because the problem keeps reoccurring even when you just blow the server's state away with a reboot, and nothing in the "postmortem" logs tell you enough to diagnose or even know what more logging you should add.)

I'd hope an immutable architecture wouldn't break inside the box, since that would indicate it mutated :) And if it did, you'd just blow it away and replace it.

At that level, it's the interactions with different components that can break down, and the tools you use are more about testing configured interactions. Also, bad data. That bit necessarily mutates.

I'm a big fan of developing in a similar environment to production, so that the debugging tools and interaction are familiar long before an emergency. At our company, we develop on Linux and deploy on Linux.

Does anyone have a good solution for deploying dot files to vim easily? Like a vim package manager that's easily installed.

I now use https://github.com/junegunn/vim-plug - you can setup a one-liner in your Vimrc to download and set it up, then :PlugInstall and you're done (similar to what they have in the readme but I linked to a specific hash on GitHub instead of master).

I also keep a separate file that lists the plugins to install and the source that from my main .vimrc. A lot of my coworkers have wanted my main vimrc for an "out of the box setup" of Vim and found it best for them to specify their own plugins rather than just blindly use mine - it also makes it easier for them to grab the latest copy without any conflicts.

Can you explain further what you want to do? But for me, I keep a github repo with my vimrc (among other configs) and I have a Makefile there that symlinks the repo files to ~/