11 ms·

That's why I have public dotfiles. Also this situation happens rarely. The whole beauty of software is that you can customize it and make it your own. The only

That's why I have public dotfiles. Also this situation happens rarely. The whole beauty of software is that you can customize it and make it your own. The only downside I see with customization is that it can be huge timesink. I guess to each his own, but I think you're really missing out. P. S. Backups.

save_ferris 10y ago
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.
- barrkel 10y ago
  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.
  - derefr 10y ago
    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.)
    - barrkel 10y ago
      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.
- myrandomcomment 10y ago
  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 :)
  - wyclif 10y ago
    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.
    - heywire 10y ago
      I'm willing to bet many employers really don't like their employees putting personal config files on a production server...
      - myrandomcomment 10y ago
        Source is a great command as are flags that point at which configuration to use when you start something. So...
      - greenleafjacob 10y ago
        At my employer, we have unix accounts for every employee, and the system automatically synchronizes your dotfiles to each server.
CardenB 10y ago
Does anyone have a good solution for deploying dot files to vim easily? Like a vim package manager that's easily installed.
- spraak 10y ago
  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 ~/
- haar 10y ago
  I now use https://github.com/junegunn/vim-plug 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.

save_ferris 10y ago

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.

barrkel 10y ago
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.
- derefr 10y ago
  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.)
  - barrkel 10y ago
    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.
myrandomcomment 10y ago
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 :)
- wyclif 10y ago
  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.
  - heywire 10y ago
    I'm willing to bet many employers really don't like their employees putting personal config files on a production server...
    - myrandomcomment 10y ago
      Source is a great command as are flags that point at which configuration to use when you start something. So...
    - greenleafjacob 10y ago
      At my employer, we have unix accounts for every employee, and the system automatically synchronizes your dotfiles to each server.

CardenB 10y ago

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

spraak 10y ago
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 ~/
haar 10y ago
I now use https://github.com/junegunn/vim-plug 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.