8 ms·

It gets worse when you work in ops and are constantly needing to remote into servers and you regularly have tmux within a tmux within a tmux... Littering config

It gets worse when you work in ops and are constantly needing to remote into servers and you regularly have tmux within a tmux within a tmux... Littering config files across the datacenter just isn't an option.

bostand 10y ago
I learned to give up making things exactly to my liking and learn to use the default key bindings. Now I can log into any machine and be 100% productive.
- jfoutz 10y ago
  Yeah, this is a good approach. I have memorized how to set up three settings for vim I just have to have, but I can usually do that in less than a minute.
  - anjanb 10y ago
    what are those 3 settings on vim ? I assume line numbers is one of them, which are the other 2 ?
    - jfoutz 10y ago
      shiftwidth, tabstop and expandtab
    - tasuki 10y ago
      For many people, line numbers are the first thing they set up - I never understood that. I customize vim quite heavily, and have tried showing line numbers, but all they do is take up 4-5 characters of precious window width! I can see the current line in bottom right, and when I want to go to a line, I use `45gg`. TL;DR people are different.
      - psquid 10y ago
        I've never really gotten into absolute line numbers, but relative ones are a godsend for me since I use <num>j, <num>d, et al a lot but can't really eyeball how many lines away something is once it gets to be more than 2 or 3.
- gnuvince 10y ago
  I consider myself a power Emacs user, I have a sizeable Emacs configuration, but when I connect to servers, I just use vi. Simpler, faster, less fuss.
  - bostand 10y ago
    Try mg :) Edit: mg is an emacs-like editor that is even leaner than vi, has off course the same key bindings as emacs, and also shares the same openbsd roots as tmux. It is also the default editor in openbsd.
  - deleted 10y ago
    [deleted]
  - klibertp 10y ago
    Exactly. There's such a great difference between Emacs with half a million of lines of Elisp loaded and a vanilla version that it's easier for me to just use Vim (it's everywhere anyway, but I can work with Vi too). Using vanilla Emacs is like writing a GUI application with nothing but the primitive X (or GDI) operations. The potential is there and is visible, and it's sometimes the right thing to do, but normally you'd use GTK or QT, right? Same is true with Emacs: in its vanilla form, it's just an API for text editing with a bunch of outdated defaults. It's superb as a platform for writing text-editing related (and sometimes others) applications in Elisp. I think that Emacs is not supposed to be used in that state at all, even. Vim, on the other hand, is pretty much designed around one UI & text-editing philosophy, which makes it less extensible, but much more usable out of the box.
tjr225 10y ago
For this reason I started using tmux exclusively on my local workstation and screen remotely.
hashkb 10y ago
Actually this benefits me, having identical settings in my nested session means typing :send-prefix all the time... remembering how to use tmux with default settings makes life easier.
bpchaps 10y ago
I do 90% ops stuff and never have this issue with tmux, so I'm curious what your workflow's like. Why not just have tmux running on your host machine and ssh from a tmux window?
- AlexCoventry 10y ago
  It preserves the shell, history and outputs if the ssh session is dropped.
  - bpchaps 10y ago
    Fair enough. My personal workaround (though, hacky, I guess) is to use screen for preserving the shell. It has a slight advantage of being more accessible, since more people know screen than tmux.
derefr 10y ago
> Littering config files across the datacenter just isn't an option. Er, what about an LDAP server for user profiles and an NFS server for home directories, like the university timesharing clusters of olde? Any box you'd log into would have "your config files" (in fact, your whole home directory) on it. Or, if the LDAP part is a hassle, be a hipster and pull all the 'user profile' info from GitHub (https://github.com/tsutsu/github-auth3 https://github.com/tsutsu/github-auth3).
- stevekemp 10y ago
  NFS is a nightmare, for many reasons. But there are similar solutions such as `pam_mkhomedir` which can be coerced into fetching dotfiles when a user logs in, etc.
  - yjftsjthsd-h 10y ago
    Could you please share some of those reasons? I ask because I'm doing this... hasn't been a problem yet, but I'd rather know about issues now than later!
    - stevekemp 10y ago
      NFS can frequently cause hanging guests if the server goes away, leaving the filesystem mounted. Locking is often a problem, for example if you've got ~ mounted on NFS and you're delivering mail to mboxes - obviously maildirs sidestep that particular problem. Firewalling is a real pain, as is access-control and UID remapping. (These are more concerns when you have a single server sharing a tree to multiple clients.) Finally failover & high-availablity are hard because you can't do transitions terribly easily, although hacks exist using automounter, etc.
      - derefr 10y ago
        > as is access-control and UID remapping Mind you, these are obviated if, as I was saying above, the NFS server and its clients are all part of the same directory-services domain.
vhost- 10y ago
You can make use of your configuration management for this. If you use something like Chef or Puppet, you probably have user accounts being created on servers when they are provisioned. We have user configs, like bashrc, tmux.conf, vimrc and all that stored in Puppet so they have those files on every single server. It all goes through code review so we can always see if something is overreaching or dangerous. If you are creating user accounts on servers by hand in a datacenter, then when that person quits... well, you have other problems I guess.

bostand 10y ago

I learned to give up making things exactly to my liking and learn to use the default key bindings. Now I can log into any machine and be 100% productive.

jfoutz 10y ago
Yeah, this is a good approach. I have memorized how to set up three settings for vim I just have to have, but I can usually do that in less than a minute.
- anjanb 10y ago
  what are those 3 settings on vim ? I assume line numbers is one of them, which are the other 2 ?
  - jfoutz 10y ago
    shiftwidth, tabstop and expandtab
  - tasuki 10y ago
    For many people, line numbers are the first thing they set up - I never understood that. I customize vim quite heavily, and have tried showing line numbers, but all they do is take up 4-5 characters of precious window width! I can see the current line in bottom right, and when I want to go to a line, I use `45gg`. TL;DR people are different.
    - psquid 10y ago
      I've never really gotten into absolute line numbers, but relative ones are a godsend for me since I use <num>j, <num>d, et al a lot but can't really eyeball how many lines away something is once it gets to be more than 2 or 3.
gnuvince 10y ago
I consider myself a power Emacs user, I have a sizeable Emacs configuration, but when I connect to servers, I just use vi. Simpler, faster, less fuss.
- bostand 10y ago
  Try mg :) Edit: mg is an emacs-like editor that is even leaner than vi, has off course the same key bindings as emacs, and also shares the same openbsd roots as tmux. It is also the default editor in openbsd.
- deleted 10y ago
  [deleted]
- klibertp 10y ago
  Exactly. There's such a great difference between Emacs with half a million of lines of Elisp loaded and a vanilla version that it's easier for me to just use Vim (it's everywhere anyway, but I can work with Vi too). Using vanilla Emacs is like writing a GUI application with nothing but the primitive X (or GDI) operations. The potential is there and is visible, and it's sometimes the right thing to do, but normally you'd use GTK or QT, right? Same is true with Emacs: in its vanilla form, it's just an API for text editing with a bunch of outdated defaults. It's superb as a platform for writing text-editing related (and sometimes others) applications in Elisp. I think that Emacs is not supposed to be used in that state at all, even. Vim, on the other hand, is pretty much designed around one UI & text-editing philosophy, which makes it less extensible, but much more usable out of the box.

tjr225 10y ago

For this reason I started using tmux exclusively on my local workstation and screen remotely.

hashkb 10y ago

Actually this benefits me, having identical settings in my nested session means typing :send-prefix all the time... remembering how to use tmux with default settings makes life easier.

bpchaps 10y ago

I do 90% ops stuff and never have this issue with tmux, so I'm curious what your workflow's like. Why not just have tmux running on your host machine and ssh from a tmux window?

AlexCoventry 10y ago
It preserves the shell, history and outputs if the ssh session is dropped.
- bpchaps 10y ago
  Fair enough. My personal workaround (though, hacky, I guess) is to use screen for preserving the shell. It has a slight advantage of being more accessible, since more people know screen than tmux.

derefr 10y ago

> Littering config files across the datacenter just isn't an option. Er, what about an LDAP server for user profiles and an NFS server for home directories, like the university timesharing clusters of olde? Any box you'd log into would have "your config files" (in fact, your whole home directory) on it. Or, if the LDAP part is a hassle, be a hipster and pull all the 'user profile' info from GitHub (https://github.com/tsutsu/github-auth3 https://github.com/tsutsu/github-auth3).

stevekemp 10y ago
NFS is a nightmare, for many reasons. But there are similar solutions such as `pam_mkhomedir` which can be coerced into fetching dotfiles when a user logs in, etc.
- yjftsjthsd-h 10y ago
  Could you please share some of those reasons? I ask because I'm doing this... hasn't been a problem yet, but I'd rather know about issues now than later!
  - stevekemp 10y ago
    NFS can frequently cause hanging guests if the server goes away, leaving the filesystem mounted. Locking is often a problem, for example if you've got ~ mounted on NFS and you're delivering mail to mboxes - obviously maildirs sidestep that particular problem. Firewalling is a real pain, as is access-control and UID remapping. (These are more concerns when you have a single server sharing a tree to multiple clients.) Finally failover & high-availablity are hard because you can't do transitions terribly easily, although hacks exist using automounter, etc.
    - derefr 10y ago
      > as is access-control and UID remapping Mind you, these are obviated if, as I was saying above, the NFS server and its clients are all part of the same directory-services domain.

vhost- 10y ago

You can make use of your configuration management for this. If you use something like Chef or Puppet, you probably have user accounts being created on servers when they are provisioned. We have user configs, like bashrc, tmux.conf, vimrc and all that stored in Puppet so they have those files on every single server. It all goes through code review so we can always see if something is overreaching or dangerous. If you are creating user accounts on servers by hand in a datacenter, then when that person quits... well, you have other problems I guess.