Hacker News Reader

Comment by spacelizard | Hacker News Reader

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.

View on HN

> 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).

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.

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!

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.

> 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.

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.

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.

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.

what are those 3 settings on vim ? I assume line numbers is one of them, which are the other 2 ?

shiftwidth, tabstop and expandtab

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.

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.

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.

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.

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.

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

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?

It preserves the shell, history and outputs if the ssh session is dropped.

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.

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.

Reply on news.ycombinator.com