Why I (as a sysadmin) reflexively dislike various remote file access tools for editors
[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
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
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.