3 ms·

I didn't mean to give the impression that you forget vanilla Vim, more that it becomes somewhat painful to use as you deal with the absence of what you've come

I didn't mean to give the impression that you forget vanilla Vim, more that it becomes somewhat painful to use as you deal with the absence of what you've come to expect. It doesn't really matter much whether you use tabs or spaces, or how many spaces a tab key (or tab character) represents, but having to swap between them multiple times a day gets... tiresome. There's a fluidity that comes with your tool behaving how you expect, and a time of acclimation when it changes. Whether the benefits of either keeping your config close to stock to reduce this acclimation period or highly customizing your personal Vim to be as efficient as possible is the better solution probably depends on the individual and the relative amount of time spent in each environment. I'm not really urging one approach over the other, but rather noting that one should be cognizant of this, as it may allow for better decisions at different times. I, for one, found certain Vim customizations to be not worth the effort at one point when I was doing a lot of remote Sysadmin work, but worth investigating more when my time in Vim shifted more towards being used in one main instance. As a simple example, if you spend 80%-90% of your time on remote servers, how useful is it to install Nerdtree on your main instance and spend the time configuring and learning how to use it well? Are the keys to Vim split windows and resizing better, or perhaps figuring out how to do that in screen/tmux is more effective a that time (can that be assumed to be on the servers?). If nothing else, I think it helps explain why some people are so enamored of some Vim plugins, while others try them and consider them "meh".

fiddlerwoaroof 8y ago
I’ve always found it rather trivial to scp my config onto the server, initialize the package manager and have it available everywhere.
- kbenson 8y ago
  It's a matter of scale. With a small amount of servers and people expected to be on them, it's not much of a problem. Once you scale to tens or hundreds of servers, and if you have multiple admins, if they don't each get their own account, you run into problems where pushing your config may conflict with someone else's config (or you must remember to set or push ENV vars on or after login). 1 admin with 1-10 servers is not much of a problem. As the number of admins and/or servers scales up, it starts becoming much more of a problem. I've worked in environments with 1-2 admins and <10 servers, and in environments with 20+ admins and hundreds of servers. In the latter environment, if you left an altered Vim config on a shared admin account, that's likely something you would be called out for, and rightly so. If anything doesn't look right when you're called onto a server at 3 AM to fix some random malfunction that's hard to diagnose, you start grasping at it as something that needs to be ruled out as part of the problem. Irate early morning emails from annoyed sysadmins over inconsistent server state are common.
  - isostatic 8y ago
    > and if you have multiple admins, if they don't each get their own account You really should have your own account on each machine. Deploy them via some push method like ansible, or some pull method like a daily cronjob. You can push a .vimrc out with them too.
    - kbenson 8y ago
      You state that as if it's a given, but I find that any increase in deployment complexity should be carefully considered. Rarely have I found "we can do this, so let's do it." a useful strategy in the end. As a very simple example of one of one possible downside of multiple accounts, consider an admin team with a high level of account additions and/or deletions (this does not mean quick turnover, it's also easily achieved through a large enough team). How robust are your routines for removing accounts when unused? How easy is it to check that every server is in a clean state? How much does it complicate and reporting of accounts on servers that have shells assigned to them or allow login? Simplicity has it's own benefits. Sometimes additional features are well worth the complexity cost, other times they are not. This is basically the same theme I initially stated with regard to Vim customization itself. Another way to look at it is as the Waterbed Theory of Complexity.[1] 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
      - isostatic 8y ago
        > How robust are your routines for removing accounts when unused? For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily. The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access. It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless) But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?

fiddlerwoaroof 8y ago

I’ve always found it rather trivial to scp my config onto the server, initialize the package manager and have it available everywhere.

kbenson 8y ago
It's a matter of scale. With a small amount of servers and people expected to be on them, it's not much of a problem. Once you scale to tens or hundreds of servers, and if you have multiple admins, if they don't each get their own account, you run into problems where pushing your config may conflict with someone else's config (or you must remember to set or push ENV vars on or after login). 1 admin with 1-10 servers is not much of a problem. As the number of admins and/or servers scales up, it starts becoming much more of a problem. I've worked in environments with 1-2 admins and <10 servers, and in environments with 20+ admins and hundreds of servers. In the latter environment, if you left an altered Vim config on a shared admin account, that's likely something you would be called out for, and rightly so. If anything doesn't look right when you're called onto a server at 3 AM to fix some random malfunction that's hard to diagnose, you start grasping at it as something that needs to be ruled out as part of the problem. Irate early morning emails from annoyed sysadmins over inconsistent server state are common.
- isostatic 8y ago
  > and if you have multiple admins, if they don't each get their own account You really should have your own account on each machine. Deploy them via some push method like ansible, or some pull method like a daily cronjob. You can push a .vimrc out with them too.
  - kbenson 8y ago
    You state that as if it's a given, but I find that any increase in deployment complexity should be carefully considered. Rarely have I found "we can do this, so let's do it." a useful strategy in the end. As a very simple example of one of one possible downside of multiple accounts, consider an admin team with a high level of account additions and/or deletions (this does not mean quick turnover, it's also easily achieved through a large enough team). How robust are your routines for removing accounts when unused? How easy is it to check that every server is in a clean state? How much does it complicate and reporting of accounts on servers that have shells assigned to them or allow login? Simplicity has it's own benefits. Sometimes additional features are well worth the complexity cost, other times they are not. This is basically the same theme I initially stated with regard to Vim customization itself. Another way to look at it is as the Waterbed Theory of Complexity.[1] 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
    - isostatic 8y ago
      > How robust are your routines for removing accounts when unused? For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily. The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access. It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog. How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless) But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?