Terraform: Add "sudo" support to file provisioner

[thedebugger]

If the connection user doesn't have the permissions to copy the file to the destination directory, it fails because of "permission denied" error. Perhaps file provisioner can expose other options to set file permissions, file owner, etc., in the longer run.

[mitchellh]

The file provisioner is purposely incredibly dumb to allow the remote-exec provisioner to take the brunt of the work to doing what you want to do with the file. This is to say: we don't want to expose file permissions, owner, etc. information.

That said, you can already do sudo-like things by embedding another connection block within the file provisioner:

provision "file" {
    ...

    connection {
         ... privileged info ...
    }
}

This will create a new SSH connection with the privileged info and allow you to upload separately.

[mitchellh]

I just want to add a bit more to "why keep it dumb":

Because we want the file provisioner to be able to support Windows, and beyond "source" and "destination" there really is no common abstract features that can be built onto it. The "remote-exec" provisioner could easily be a powershell script or something in the future that knows how to deal with the files.

[thedebugger]

make sense. As soon as I added the issue, I realized I can use the remote-exec. Before I can update it, you latched on it :+1:

[mitchellh]

:)

[bradenwright]

Ahhh.... I must be missing something. This seems like a completely valid ask. Isn't that the point, to keep things simple, declarative and let terraform/code take care of it behind the scenes.

Or just say the property isn't available on windows, this already occurs multiple places in terraform. Basically its a pain, to have to add extra resources/steps to make this happen and I really don't see downside.

[mwthink]

While I do appreciate the keep it dumb mentality, as it would allow for more modularity across the board, I think this position should be reconsidered.

I am working with CoreOS, as such all actions are taken over SSH as the core user. To place files on a remote machine, my current resources are set to copy files to /tmp via the file provisioner, then move them around/manage permissions via the remote-exec provisioner.

While this works, it causes a lot of WET configuration to occur in my files. Lots of mv this, chmod/chown that, etc. The entire purpose of modularity is to promote code reuse and keep things DRY. If I have to repeat the same boilerplate code every time, for every file, and terraform does not offer me a way to create something like a reusable inline function, it gets really chaotic and hard to manage.

Now, I could create a module to handle this to some degree, but modules have their own modularity issues and, unfortunately, don't support the count parameter.

I see this across a lot of places in Terraform, some more than others, but this file issue has been the one irking me the most lately. Terraform needs to figure out if they're meant to be easy (i.e. Opinionated), in which case the file provisioner should support permissions/sudo, or if they're meant to be modular, in which case it shouldn't be such a huge pain to compose custom action chains.

[gerhard]

This is an oldie and unlikely to change, but I've just come across this in the context of CoreOS. Good to know that I'm not the only one that hit this particular issue.

[neurogenesis]

Would be helpful if file provisioner allowed options for sudo, ownership, and permissions.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.