Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developer.hashicorp.com/terraform/language/resources/provisioners/connection below:

Provisioner Connection Settings | Terraform

Most provisioners require access to the remote resource via SSH or WinRM and expect a nested connection block with details about how to connect.

Important: Use provisioners as a last resort. There are better alternatives for most situations. Refer to Declaring Provisioners for more details.

You can create one or more connection blocks that describe how to access the remote resource. One use case for providing multiple connections is to have an initial provisioner connect as the root user to set up user accounts and then have subsequent provisioners connect as a user with more limited permissions.

Connection blocks don't take a block label and can be nested within either a resource or a provisioner.

• A connection block nested directly within a resource affects all of that resource's provisioners.
• A connection block nested in a provisioner block only affects that provisioner and overrides any resource-level connection settings.

Since the SSH connection type is most often used with newly-created remote resources, validation of SSH host keys is disabled by default. If this is not acceptable, you can establish a separate mechanism for key distribution and explicitly set the host_key argument (details below) to verify against a specific key or signing CA.

Note: In Terraform 0.11 and earlier, providers could set default values for some connection settings, so that connection blocks could sometimes be omitted. This feature was removed in 0.12 in order to make Terraform's behavior more predictable.

Note: Ephemeral values are available in Terraform v1.10 and later.

The configuration for a connection block may use ephemeral values, such as ephemeral resources, ephemeral local values, ephemeral variables, or ephemeral output values.

Terraform will not store these values in your plan or state, or output them in logs.

# Copies the file as the root user using SSH
provisioner "file" {
  source      = "conf/myapp.conf"
  destination = "/etc/myapp.conf"

  connection {
    type     = "ssh"
    user     = "root"
    password = var.root_password
    host     = var.host
  }
}

# Copies the file as the Administrator user using WinRM
provisioner "file" {
  source      = "conf/myapp.conf"
  destination = "C:/App/myapp.conf"

  connection {
    type     = "winrm"
    user     = "Administrator"
    password = var.admin_password
    host     = var.host
  }
}

Expressions in connection blocks cannot refer to their parent resource by name. References create dependencies, and referring to a resource by name within its own block would create a dependency cycle. Instead, expressions can use the self object, which represents the connection's parent resource and has all of that resource's attributes. For example, use self.public_ip to reference an aws_instance's public_ip attribute.

The connection block supports the following arguments. Some arguments are only supported by either the SSH or the WinRM connection type.

The ssh connection also supports the following arguments to connect indirectly with a bastion host.

The ssh connection also supports the following fields to facilitate connections by SSH over HTTP or SOCKS5 proxy.

Provisioners which execute commands on a remote system via a protocol such as SSH typically achieve that by uploading a script file to the remote system and then asking the default shell to execute it. Provisioners use this strategy because it then allows you to use all of the typical scripting techniques supported by that shell, including preserving environment variable values and other context between script statements.

However, this approach does have some consequences which can be relevant in some unusual situations, even though this is just an implementation detail in typical use.

Most importantly, there must be a suitable location in the remote filesystem where the provisioner can create the script file. By default, Terraform chooses a path containing a random number using the following patterns depending on how target_platform is set:

• "unix": /tmp/terraform_%RAND%.sh
• "windows": C:/windows/temp/terraform_%RAND%.cmd

In both cases above, the provisioner replaces the sequence %RAND% with some randomly-chosen decimal digits.

Provisioners cannot react directly to remote environment variables such as TMPDIR or use functions like mktemp because they run on the system where Terraform is running, not on the remote system. Therefore if your remote system doesn't use the filesystem layout expected by these default paths then you can override it using the script_path option in your connection block:

connection {
  # ...
  script_path = "H:/terraform-temp/script_%RAND%.sh"
}

As with the default patterns, provisioners will replace the sequence %RAND% with randomly-selected decimal digits, to reduce the likelihood of collisions between multiple provisioners running concurrently.

If your target system is running Windows, we recommend using forward slashes instead of backslashes, despite the typical convention on Windows, because the Terraform language uses backslash as the quoted string escape character.

When using the SSH protocol, provisioners upload their script files using the Secure Copy Protocol (SCP), which requires that the remote system have the scp service program installed to act as the server for that protocol.

Provisioners will pass the chosen script path (after %RAND% expansion) directly to the remote scp process, which is responsible for interpreting it. With the default configuration of scp as distributed with OpenSSH, you can place temporary scripts in the home directory of the remote user by specifying a relative path:

connection {
  type = "ssh"
  # ...
  script_path = "terraform_provisioner_%RAND%.sh"
}

Warning: In Terraform v1.0 and earlier, the built-in provisioners incorrectly passed the script_path value to scp through a remote shell and thus allowed it to be subject to arbitrary shell expansion, and thus created an unintended opportunity for remote code execution. Terraform v1.1 and later will now correctly quote and escape the script path to ensure that the remote scp process can always interpret it literally. For modules that will be used with Terraform v1.0 and earlier, avoid using untrusted external values as part of the script_path argument.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4