Why I (as a sysadmin) reflexively dislike various remote file access tools for editors

March 5, 2017

I somewhat recently ran across this irreal.org entry (because it refers to my entry on staying with Emacs for code editing), and in a side note it mentions this:

[Chris] does a lot of sysadmin work and prefers Vim for that (although I think Tramp would go a long way towards meeting the needs that he thinks Vim resolves).

This is partly in reference to my entry on Why vi has become my sysadmin's editor, and at the end of that entry I dismissed remote file access things like Tramp. I think it's worth spending a little bit of time talking about why I reflexively don't like them, at least with my sysadmin hat on.

There are several reasons for this. Let's start with the mechanics of remote access to files. If you're a sysadmin, it's quite common for you to be editing files that require root permissions to write to, and sometimes to even read. This presents two issues for a Tramp like system. The first is that either you arrange passwordless access to root-privileged files or that at some point during this process you provide your root-access password. The first is very alarming and the second requires a great deal of trust in Tramp or other code to securely handle the situation. The additional issue for root access is that best practices today is to not log or scp in directly as root but instead to log in as yourself and then use su or sudo to gain root access. Perhaps you can make the remote file access system of choice do this, but it's extremely unlikely to be simple because this is not at all a common usage case for them. Almost all of these systems are built by developers to allow them to access their own files remotely; indirect access to privileged contexts is a side feature at best.

(Let's set aside issues of, say, two-factor authentication.)

All of this means that I would have to build access to an extremely sensitive context on uncertain foundations that require me to have a great deal of trust in both the system's security (when it probably wasn't built with high security worries in the first place) and that it will always do exactly and only the right thing, because once I give it root permissions one slip or accident could be extremely destructive.

But wait, there's more. Merely writing sensitive files is a dangerous and somewhat complicated process, one where it's actually not clear what you should always do and some of the ordinary rules don't always apply. For instance, in a sysadmin context if a file has hardlinks, you generally want to overwrite it in place so that those hardlinks stay. And you absolutely have to get the permissions and even ownership correct (yes, sysadmins may use root permissions to write to files that are owned by someone other than root, and that ownership had better stay). Again, it's possible for a remote file access system to get this right (or be capable of being set up that way), but it's probably not something that the system's developers have had as a high priority because it's not a common usage case. And I have to trust that this is all going to work, all the time.

Finally, often editing a file is only part of what I'm doing as root. I hopefully want to commit that file to version control and also perhaps (re)start daemons or run additional commands to make my change take effect and do something. Perhaps a remote file editing system even has support for this, even running as a privileged user through some additional access path, but frankly this is starting to strain my ability to trust this system to get everything right (and actually do this well). Of course I don't have to use the remote access system for this, since I can just get root privileges directly and do all of this by hand, but if I'm going to be setting up a root session anyways to do additional work, why not go the small extra step to run vi in it? That way I know exactly what I'm getting and I don't have to extend a great deal of trust that a great deal of magic will do the right thing and not blow up in my face.

(And if the magic blows up, it's not just my face that's affected.)

Ultimately, directly editing files with vim as root (or the appropriate user) on the target system is straightforward, simple, and basically guaranteed to work. It has very few moving parts and they are mostly simple ones that are amenable to inspection and understanding. All of this is something that sysadmins generally value quite a bit, because we have enough complexity in our jobs as it is.


Comments on this page:

By dozzie at 2017-03-06 05:07:11:

Not to mention that each of such tool introduces its own scheme for specifying filenames. It's slightly different for Vim, for lftp through sftp/scp, for rsync, and for git. I only recently started to somewhat remember how many slashes after hostname does Vim require for absolute paths (two, while lftp only expects one and needs sftp protocol part).

That's surprisingly reasonable. Do you customize your vim setup at all? Most of my friends who use vim bring a fairly complex setup to any new machine they use. It's not super hard to set up (some git clones, copying a config file of some sort, etc), but I always rib them a bit when I see them doing it. I prefer to access remote files via TRAMP, so that I can keep using my heavily-customized emacs setup without any extra work. On the other hand, we're all programmers, not sysadmins.

TRAMP is quite complete though; you can chain together multiple "remote" filenames to do complicated things like sshing to machine A, then sshing to machine B, then using sudo to access a protected file. It also integrates with eshell so that you can have a local interactive shell that runs commands on remote machines; it overloads the 'cd' command to support TRAMP-style filenames. I don't know how it compares with vim in that regard. Also, I recall that you have a pretty specific choice of shell, and wouldn't necessarily like switching.

By cks at 2017-03-06 16:26:17:

I don't customize my vim setup very much (mostly I turn various 'smart' things off), and we try to have the root vim environment be as dumb as possible. Especially when working as root, we want an editor that is as predictable and straightforward as possible. Basic vim is reasonably powerful these days; when editing files as root, most of what I care about is multi-level undo and being able to edit multiple files at once.

(I don't edit code as root except in very rare circumstances. That's something better done as me, where I have my full editor environment. Even if root is eventually going to run the shell script or program, I can usually get pretty far developing or bug-fixing it as an unprivileged user and doing so makes programming mistakes much less dangerous.)

It's probably worth noting that we have a fileserver environment so most machines have access to my home directory. This means I don't need to set up my editing environment on a whole bunch of different machines; I can set it up once, edit on one of our login servers, and easily access those files from other machines.

By mofo at 2018-05-25 05:29:25:

What you'll do, if there is no vi/vim/anything at all on remote side? And this is not such rare situation, cos there are many boxes just with kind of remote access daemon (sshd,telnetd,something else) and bunch of files, what you need to edit.

Remote editing is a bad practice and ugly hack. Ideally, all your configs must be in some config management system, edited locally and then pushed to remote end.

Written on 05 March 2017.
« Should you add MX entries for hosts in your (public) DNS?
Modern X Windows can be a very complicated environment »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 5 23:25:24 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.